Product Manager Interview – 7 Cardinal Sins

So you have landed an interview for a software product manager position. You are excited! You show up for the interview and the interview is a bust. You do not get the job. Causes? Having interviewed many product managers, who looked very promising on the resume and ended up being disappointing during the interview, I have compiled the patterns I have seen as “7 Cardinal Sins”. This can also be considered as general tips for any position that you are interviewing for.

  1. You hardly know anything about the company – I have had at least two instances where the candidate told me that s/he was hoping that I would explain what we do, our business model etc during the phone screen. Surprised? Think it is not possible? I was too until I heard this. Good thing this happened on a phone screen.
  2. You do not know the job description/responsibilities in and out – If you don’t know the job description, why did you even apply? How did you figure out that your skills match what the company is looking for? The way a hiring manager can figure this out is by asking the question – “Why do you want to work for us?” or “Why should we hire you?” – These questions should be slam dunk for you if you are prepared, you can show case how much you know about the company, what you bring to the table that relates to the job description and your past successes and accomplishments that are relevant to the job. I have heard lame answers such as “Recruiter called me about this job and hence submitted my resume” or “You guys called me and wanted to talk to me.” Come on, while that may be true, you need to still do a sales job – you need to sell the product you have – “YOU”!Cardinal-Sin
  3. You do not have an elevator pitch – Same as the above, but if the interviewer asks the question – tell me about yourself, try to hit the ball out of the park. Relate your experiences that are relevant to the job. Sell, sell, sell! Your elevator pitch should be 2-3 min max. Give an overview that piques the interest of the interviewer that they want to know more.
  4. You don’t know anything about the people you are going to interview you – You need to ask for the interview schedule before you get there. Then do the research – where have these folks worked at? Use LinkedIn. Do you and them have common connections? What questions can you anticipate given their background?
  5. You do not have questions for the interviewers – when asked if you have any questions, you say No. It is quite possible that towards the tail end of an interview schedule that your questions may have been answered. But instead of a terse No, mention that you had many questions about X, Y and Z that you have asked the previous interviewers. Give everyone a window into your preparation. Ask questions that gives you a deeper understanding of the problems that they are looking to solve by making this hire, the organizational structure, decision making process etc. Ask the same question to multiple people and see if you get a consistent answer.
  6. You have not anticipated questions or prepped for the interview – Research sites such as glassdoor.com to see what questions get asked in interviews at the company. Ask your contact what a typical interview looks like? Do they have a problem solving round where you are asked to solve a given problem? Practice doing a problem solving round before hand to get your thoughts together. It is hard to think on your feet when you are under pressure at the interview. So play through such a session before hand so that you can come up with a strategy of tackling it in the real session.
  7. You lie on the resume – Believe it or not, this happens. If you get caught, not only will you not get the job but your reputation and integrity will be tarnished. In the world we live in, word travels fast. The tech world is highly networked, so don’t take a risk. I had one instance where a product manager claimed that he came up with a pricing strategy – when I asked him to explain it, I was told that he put it on the resume just to make it look well rounded. He admitted that he does not have experience with pricing. End of the interview, right there and then! I am not going to hire you as a PM and put you in front of customers if I cannot trust you. Never, ever lie on your resume.

Image: Courtesy of smallbusiness.yahoo.com

Competitive Analysis: 5 reasons why Apple in-store iphone trade-in program should not impact Gazelle.com

Apple recently announced its iphone trade-in program whereby consumers can walk into an Apple store and trade-in their old phones and walk out with a new phone. While minimal details are still available on the program, as a product manager, I was left to wonder if this program constitutes a threat for established trade-in programs such as Gazelle? Full disclosure: I was the Director of Product Management at Gazelle 2 years back and am an employee  investor in Gazelle. But I have not been asked by anyone at Gazelle to write this post and it represents a product manager’s opinion on a competitive threat from a company with deep pockets.

Here are the five reasons why I think Apple in-store trade-in program should not impact Gazelle.com

  1. Inconvenience: Apple’s new program is only available via its retail stores.There are only ~250 stores in the US. Only 20% of iPhone sales happen in their stores. 80% happens via carriers, online sales and retailers such as Best Buy, Walmart etc. (Source: TUAW). 250 stores does not represent great coverage for US customers of iphones. For example, the nearest Apple store to me is 22 miles away. I have always bought my iphones via the Apple website because I am not driving that far and standing in line. Every time I have visited the store during the early days of a new iPhone, the store has been sold out of the new phone.
  2. Price paid: All news articles point to a trade-in price of upto $250-280 for an iphone 5 16GB (AT&T) in excellent condition. Gazelle at the time of writing this post pays $330 for the same phone. That is an extra $50-100 in your pocket if you lock in the price today with Gazelle.
  3. Can only trade-in an iPhone for an iPhone: Among the people switching brands, Apple took in three times more customers from Samsung (33%) than Samsung took away from Apple (11%). (Source: cnnmoney.com). Apple’s trade-in program does not help these Samsung customers, while Gazelle is a viable choice because they accept Samsung trade-ins.
  4. Have to buy a new iphone: Apple’s trade-in program works only if you want to purchase a new iphone. You cannot get a store credit or walk away with the cash. No such restrictions at Gazelle. So if you have already switched to other popular phones such as Samsung Galaxy 4, you are out of luck. While this may seem to be a weak argument because of the strong loyalty of iphone customers, it is a factor you cannot discount.11% of users who switched to Samsung Galaxy were prior iPhone users.
  5. Not sure if Apple is serious about the trade-in program: I am not convinced that Apple is serious about this program. This is the second avatar of a trade-in program being launched by Apple. There has always been an online program that they have had, but not something they have promoted. While I am a huge Apple fan for the products it creates, I have never been a fan of its customer service in its retail stores. My previous post of How Apple sucks at customer service is the post with highest comments and 6 years later still gets comments from pissed off customers. How much marketing muscle Apple will put against this program remains to be seen. In the mean time, iPhone trade-in programs are the lifeblood of sites such as Gazelle. It is what they do day-in and day-out. Having worked at Gazelle, I know how much effort it puts into the customer experience. Reviews from real customers are testimonials for the great experience provided by Gazelle.

Now will Apple’s trade-in program help Gazelle – absolutely. Electronic trade-in programs are still in its infancy. My best guess is that the number of iPhones traded in are probably about 5-10 million per year. Compare this to 86 million iPhones sold in the US as of 2012 Q2 (2012 is not a typo – could not find the figures for 2013). That means just 10% of the phones are being traded-in. Apple’s foray into the trade-in program is only going to increase the awareness and Gazelle stands to gain by increasing its market share.

What do you think? Do you agree or am I missing the boat? Or is it too early to tell?

Building Rapport – “How” you say it vs. “What” you say

A large portion of software product manager’s working life is spent working with cross-functional teams – whether it is trying to meet everyone’s expectations (or to be more exact aligning them), or communicating to them (since they often tend to speak using their own terminology) such that everyone is singing off the same song book. When you are new and have not established the rapport or the relationships with your shipmates, it is not “what” you say that tends to be important, but “how” you say it. Everyone is looking for “What is in it for them?” and “Why they should listen to you”. You have not earned your stripes yet. This holds true, no matter whether you are the new product manager or the new CEO.rapport

But once people get to know you and a good working relationship gets established, magic happens. Now, “what” you say becomes more important than “how” you say it. You could even drop every other word and speak (not that I recommend you do this) and still your team magically knows where you are coming from and what you are trying to say. Once the rapport has been built, people start believing in you and you can move a mountain.

So I don’t care what social networks come and go, what technologies make it easier to communicate, nothing comes even close to the traditional “human” face-to-face connection in building relationships. So what have you as a software product manager done lately to build or strengthen existing relationships at work? If you are new at your job, what have you done so that the magic happens that switches the conversation from “how you say it” to “what you say”? After all, it is all about human relationships, not about products. Relationships – internal and external – will outlast any product you will ever build.

Agree? Comments?

Image: Courtesy of presentationmagazine.com

Other articles you may like:

Customer Visits – Do’s and Don’ts

Don’t be an “I” specialist

B2B vs B2C Product Management -16 Differences

What should keep a product manager awake?

Should it be the state of product development, the next release, the next sprint? Should it be what keeps the company executives awake? Should it be the competitors? While some of these should indeed keep a product manager awake, the most important thing that should keep him/her awake should be what keeps customers awake. Customers have problems today that are real pain points. They are struggling to solve them using current means and are hoping that someone will solve them. They are willing to pay someone to solve these problems for them. This is what product managers should focus on and spend most of their energies. If you do this, everything else should follow. If you do not do this, then all of the other things tend to happen – your execs tend to stay awake, you start worrying about competitors, your sales start to shrink, you start worrying about hitting the numbers etc. So focus on the only thing that really matters – understand better what keeps your customers awake and solve them via your products – existing or new.

Thoughts? Please share them via comments.

Power of “Breaking it down” – 10 minutes and NOW

It has been months since my last blog post. Call it laziness, lethargy, procrastination, sudden lack of confidence in my writing skills – every one of these had something to do with it. I used to tell myself that I had to do it. But never did it.

Last night, I was teaching my 9 nine year old daughter Navya how to compute the area of shapes. I was teaching her how to break the shape into rectangles and squares, calculate the area of each and then add them up. Suddenly, it dawned on me as to how I could break down this wall of not blogging.

Image

It is simple – “10 minutes” and “Now”. I even have this written down on my monitor at work. When something feels too big and I have trouble getting started, I try breaking it down into steps each of which would take 10 minutes. And then I start doing them NOW. Believe it or not, it has been working and a proof point is this blog post. I just opened WordPress and started writing.

Try it for yourself. Whether you are a software product manager procrastinating on starting a requirements doc for a complex feature or you are a painter wanting to start a painting, break it down into “10 minute” chunks and start on it “Now”.

10 minutes get over fast and before you realize you are 30 minutes into it. The sense of accomplishment suddenly carries you forward. Agile development methodology is built on this core principle of breaking things down, building fast and shipping often.

Do you agree? Thoughts, comments?

Image: Courtesy of digitalminimalism.com

Agile vs. Waterfall – what is the big deal?

I have been working in companies the last 5 years where we have followed the agile methodology in product development. Shorter sprints, faster releases as opposed to month long development cycles that were common in waterfall.

Here is a guest blog post written by Mike Cudemo of Sparta Systems that explains the differences between Agile and Waterfall product development methodologies in a very simple way. He also explains the benefits of doing agile as a way of increasing the success rate of IT projects.

Seeing is believing.  Agile methodologies are not perfect, but they are three times more successful than traditional waterfall methodologies (source: Standish Group).  Agile methodologies allow end users and stakeholders to visualize their requirements faster and catch errors earlier in the development process.

A waterfall process can be likened to building a house.  An architect translates your requirements into blueprints which only an architect can visualize.  Your first glimpse into reality occurs after the foundation is poured and the walls are erected.   While things can be changed, it is more expensive to change.  Most people struggle to catch problems until the drywall is up and the ductwork and plumbing are in place.  Again, you can make changes if there are issues, however, now it is even more expensive to address.  The waterfall process attempts to “freeze the requirements” after the blueprints are designed.   As you can imagine, this is not reality.  The later you catch a requirements problem (e.g. I want a larger master bedroom closet), the more expensive it is to fix.  In some cases, it is impossible to fix.  You can have the closet, but little Timmy needs to sleep on the roof!

The Agile Method does not attempt to “nail and freeze the requirements” all up front at one time.   It assumes that the requirements will evolve and change as the customer begins to visualize their own requirements.  The Agile Method attempts to build the house by first creating a visual 3D representation of the outside of the house.  This is how it is going to look when you come home from a long day at work.  After the outside look and feel is developed, you attempt to construct the house one to two rooms at a time.   The Agile Method attempts to focus the requirements, design, code and test into iterative smaller development phases.   Essentially, the Agile Method is a series of smaller contained waterfalls.  End users and business stakeholders get to see and experience the system as it unfolds.  Course corrections become more apparent and easier to navigate.

Waterfall processes attempt to minimize and control change.  Agile processes accept the inevitable need to accommodate learning about the real requirements.  End users think in broad strokes; however, we all know the devil truly lies in the details.   Skilled Agile development teams have a clear methodology to guide the process most effectively.  They will select the plot and then develop the look and feel of the outside of the house. Next, they will focus on the 1st floor, and then move to the second floor.  The finished basement will be last, because as we all know, we’ve run out of money by that time.

We find ourselves in the worst economy since the Great Depression.  Many CFOs find themselves in a complex juggling act of cutting operational costs and making technology investments.  CFOs are forcing their CIOs to come up with plans to leverage existing investments, yet develop the capabilities to rapidly respond to both economic growth and competitive changes. Project failure is really not an option, yet according to the statistics, waterfall approaches waste 60% of a company’s IT project budget.

Over 20 years ago, 90% of IT projects failed or under-delivered on functionality. Today, depending on your source for statistics, IT projects fail or under-deliver between 30-70% of the time.   It is better, but far from perfect.  It is clear, that Agile methodologies are at least 3x more likely to succeed.

Agile methodologies are iterative. Understanding is paramount to containing change.  Systems unfold one functional area and set of screens at a time.  An Agile Methodology will not fix a bad project vision, an impossible task, or a lack of skilled personnel.  Properly applied, an Agile approach will catch the poor vision, unattainable goals, or lack of resources early.  IT and application departments must learn that cancelling a project early is actually a win.   Broken processes should be fixed first before they become institutionalized with software or a system.

Companies that employ Agile methodologies and cancel unattainable projects early will thrive.  Their IT success rates will exceed 85%.  Most importantly, they will have more working capital to drive growth, innovate, and increase productivity.

About Mike Cudemo

Mike Cudemo runs the Customer Success Program at Sparta Systems.  The program accelerates knowledge transfer of best practices to our customers to enhance overall business performance.  Mike spent over 12 years integrating manufacturing operations with ERP and value chain systems at Fortune 100 clients, utilizing his expertise in value chain, quality, manufacturing execution and process automation systems. Trained as a systems engineer to analyze and simplify computer systems, Mike has spent a career helping clients understand their core business drivers, simplify the underlying processes, and automate the repetitive, non-value-added tasks which introduce defects and waste.

Importance of sprint demos

In an agile development process, you typically launch new features into production every 2-3 weeks. Before launch, it is important to ensure that all stakeholders get to know about the new features to be released. It is especially important for Customer Support, Training, Translators, Sales etc. to get to know these new features before customers get their hands on them. I have found the best way to do this is via a sprint demo. When I have organized these demos, here are three guidelines I have followed:

  1. All key stakeholders have been invited – marketing, sales, product, customer support, qa, …..
  2. The demo is held a couple of days before the release – stakeholders should have some time to react to the new features and also engineering – in case there are small changes that need to be made (textual changes or other very minor changes).
  3. The demo is done by engineering. This is very key for me. Engineers toil hard to get everything done and it is their work that is being shown in the demo. Given this, they are the best ones to show case what they have built. It also ensures that everything to be released is completed before these demoes.

What are your experiences? How do you do your sprint demos?