8 common mistakes in a Product Management interview.
Product Management is a profession, a mindset, an art, and a science. And this art, science, & mindset can be developed. There are certain traits that successful product managers exhibit. These are also the traits that an interviewer expects from a candidate who is appearing for a product management interview.
You can read this post as common mistakes that one makes in a product management interview or the mindset and traits of a successful product manager.
I have added quick bite 1 minute videos for those who are not fond of reading and prefer listening instead.
1. Solution Bias
This is the #1 mistake that folks who are not conversant with problem solving may make. Simply put, solution bias is about jumping to a solution when asked a problem. For example, as soon as an interviewer asks to build a ride hailing application, one may fall into the trap of building another Uber or Ola. If you are in a product management interview, this may not go in your favor.
You need to have a problem first mindset where you spend time understanding the problem, articulating your hypothesis, validate whether the problem being stated by the interviewer is the actual problem that the customer is facing before getting into solutions.
For example, in an interview, if the interviewer asks to build a ride hailing application, then we need to double click into the exact problem scenario. I.e. what is the problem that customers are facing with transport for which ride hailing may be touted as a solution. Is the problem that driver partners are cancelling trips, poor transport in a region, no sense of ownership of a vehicle, traffic congestion, or lack of hygienic cabs etc. We need to first understand the problem clearly before we start articulating the solution. Let’s assume that the problem identified is that “the drivers are cancelling cabs at their will” therefore the solution for this problem may be very different from building an entire ride hailing application.
Spend a good quality 10 -15 minutes of your interview to brainstorm the exact problem with your interviewer and avoid the urge to simply state the solution.
2. Missing Customer Personas
The problem first mindset starts with the user or customer persona in mind. It is a good practice to have some user or a persona in mind who will be using your application or solution. Here be very clear on who is your customer and user. E.g. if the interviewer asks you to build a karate learning platform for kids, then the users are kids but the customers may be parents or institutes.
It is important to vocalize your persona explicitly i.e., state that I believe my core customer segment will be anyone in the age group of 6 –40 years who wants to live a healthy lifestyle. You should be able to quickly size your market and identify the total addressable market based on few assumptions if need be, once you have the customer segment identified.
This exercise is important since the problems that you may articulate may be very specific to a customer segment. Therefore, once the customer segment is understood, then the problem articulation becomes easier else you may find it hard to scope down the problem in your 1-hour interview.
3. Time management
Manage your time well in your interview. Though this is something that both interviewer and interviewee can manage, you should also ensure that during your interview you give brief and succinct replies so that the interview can be completed on time. Here is a very high-level guideline on time spent on various aspects:
- Introduction ~5-10 minutes
- Problem & customer scenario validation ~ 10-15 minutes
- Solution ~ 25–30 minutes
- Conclusion ~5-10 minutes
In my own experience, there have been few interviews where we ended up spending 30–35 minutes in introductions and problem understanding, leaving us very less time for the solution discussion. The only word of advice is that that keep an eye on the watch as you navigate through your interview and feel encouraged to pace your own interview.
4. Answer Why?
For every solution you suggest, keep the WHY at the back of your mind. At times interviews become a feature fest i.e., given a problem, one begins to narrate one feature after another. Let’s go back to the ride hailing application example to explain. If I ask you for features in a ride hailing app, you can talk about at least 20 features. Let me try to enumerate the 20 features that come to my mind in no order.
(1) Search location (2) Maps (3) Location finder (4) Commerce (5) Authentication (6) Frequent traveler incentive (7) Support call (8) Find a driver partner (9) Call a driver partner (10) Feedback and reviews (11) Route optimization (12) Book now (13) Book later (14) Driver tracking (15) Payment options (16) Preferred driver (17) Add multiple drop points (18) Trip history (19) Payment history (20) Recently visited places (21) Saved locations etc.
Avoid enumerating features in bullet points as I have done above. Whenever you have a feature in mind, it needs to be mapped to a problem first. Generally, you may be asked why you are recommending a particular solution or feature. Here, WHY boils down to the customer persona and the problem that you have in mind for the feature that you are recommending. You may want to articulate your solution as follows:
We should have <feature / solution name> because <reason>. This is very similar to a hypothesis:
We should do <this>, so that the user can do <that>.
In product management, user stories follow a similar paradigm but that is a discussion for another day.
5. Don’t get married to your solution.
Another common trait that we often fall prey to is falling in love with our solution. This behavior is also seen with product managers, chief product officers, and CEOs where they get married to their product and start missing out on important cues that invalidate their love for their own solution.
When you have a solution in mind and have a strong belief about why your solution holds ground, you should state that belief clearly. However, at the same time keep a look out on cues from your interviewer who may be stating certain facts that may invalidate your hypothesis. At that moment, consider your interviewer as your customer and keep your eyes and ears open to any cues that are proposing you to rethink your solution or hypothesis.
There is another side to this as well. Do not fall into the trap of compliance without putting forth your point. Often, when we are being interviewed, we associate disagreement with disrespect therefore we comply even though our heart states otherwise.
To summarize, hold your ground when you are convinced about your solution and at the same time be open minded and inquisitive about another’s viewpoint.
6. How would you measure the success of anything that you build?
During your interview, as you build your product or solution, you should also think about how you would measure its success. Here are some golden rules while thinking about metrics:
- Ensure your metrics tie back to the overall business objective or the business problem of the interview.
- If you can articulate a north star for the product then align the metrics to that north star.
- Clearly differentiate between vanity metrics and business metrics.
For example, if customer engagement is the goal then Net Promoter Score, conversion funnels, session time could be good metrics to discuss. If customer acquisition is the goal then # of downloads, monthly active users, churn rate etc. may be good metrics. You may wish to do your research on some common metrics that are used for B2C and B2B products upfront and apply those for your interview use case.
7 . Overfitting a structure
There are times when we come with a structure in mind while attending a product management interview and try to overfit the structure in an interview. You can be aware of 4Ps, 5C, PESTEL, STP, any other structure in mind but you should not force fit every interview into these frameworks. E.g., What may happen in such cases is that for a given problem, all elements of the framework may not be applicable. E.g. if you are building a weather API then channel may not be applicable in your use case. The advise is to not get stuck with the frameworks and let these be enablers to further the conversation.
One very simple and broad structure that I find useful in most product management interviews is:
- Problem — understand the problem & business / product objectives.
- Customer Persona — articulate the persona for whom you are building the solution.
- Customer Journey — narrate the customer’s journey to identify the customer’s pain points.
- Solution — translate the pain points, problems, and product objectives to a solution.
- Metrics — identify metrics for your solution.
But again, use these or any frameworks with caution and don’t get too hung up on crossing all t’s and dotting all i’s in the framework for all problems.
8. Do you have a question for me?
Most interviews end with the interviewers asking whether you have any questions for me. While this may sound like the end of most interviews, the interview is not quite over yet. This could be your opportunity to leave a lasting impression to show that you came prepared for the interview and that you are serious about the profession and the organization.
I would strongly suggest reading the first few pages of the organization’s annual or quarterly statement to understand the culture, products, business priorities etc. of the organization. It would give you a good idea about the organization in general and may answer a bunch of questions that you may have.
In addition, whatever question you have, please search it on the internet upfront. That will not only help you learn more about the organization but also help refine your question for the organization & the interviewer. A little bit of homework can take you a long way here.
These are patterns that I observed in the last few years of my interviewing experience. It is not a one size fits all and these observations may change depending on the situation. At the end, give it your best since that is the best that we can all do :)
