Product Management is situational and contextual. No product development lifecycle is going to be seamlessly executed every single time for every single product. Similarly, during the interview process, don’t expect that the same answer you give to the same question will be correct. These answers change based on who is asking and the questions you are asking – specifically, for the case study based questions. This article assumes that you have a basic grasp of Product Management 101 concepts already.
So what is the right method to tackle these Product Management Interview Questions?
Let’s look an example: let’s say that an e-commerce furniture company wants to implement a feature – free returns. How would you go about implementing this?
Take a minute to think about this question. What is your first step?
If your first step is to start building requirements, talking with design partners, and write user stories for your engineers – you’ve made a fatal mistake.
Step 1: Evaluate the Need – Why are we doing this? Is this reason valid?
How did this company come up with this feature? Who suggested it – executives in a room or from customer feedback? What is the goal of this feature? Drive revenue? Increase loyalty? Am I assuming that leadership has already signed on board to this feature? Or am I assuming that this is just a small product that I’ve been given to test?
Essentially, you need to figure out the bounds and constraints of this question. You are likely not an industry expert on the business that your interviewer is in. You lack that domain knowledge. So in order to create an informed answer, you have to know what your answer is NOT.
Step 2: Validate the Need – We’ve figured out why we want to do this. SHOULD we do this?
You have to start on the pre-question. You’re asking yourself what are my assumptions, what are my known and unknowns, and whether or not there’s data. If there’s no data, well…there’s no data; if there’s data: is the data good?
So what are my assumptions? Free returns, right. What do I know? How many people already trying return? Do we know that? Do we not know that? Do we have data on this? Is the data good?
Are there specific types of products that we know people return? What do we not know? Are there some parts of the world where people expect free returns? Do we have data on that – the company isn’t going to necessarily know that from the data because customers are just going to be angry and just leave.
What am I assuming about free returns? Am I assuming it’s going to have a limit on weight? Am I assuming that it’s going to be released to only customers in a certain region? Am I assuming that I will have a big budget for this?
When you focus on these unknowns, what you’re really focusing on is time and resources. This gets into the business side of asking questions.
Again, you are not a domain expert in furniture e-commerce and even if you are, you are not familiar with their business model to give a nuanced response. So what are these Product Managers looking for in your response?
They are looking to see whether or not you can communicate competency in evaluating whether or not the product or feature should or should not be launched.
Step 3: We know why we should build this. We validated that we should do this. What should the goal of this feature be?
So in this specific case, you want to focus on time and resources, which is money. This specifically means profitability. Is it going to cost us a lot of money?
How much is this going to cost us?
How do you evaluate that cost?
Are we going to have to de-prioritize other features in the backlog?
Are we going to have to focus on other resources?
Are we going to have to deal with interstate laws, based on shipping?
How about shipping internationally or shipping interstate – Taxes?
What are all the areas that might factor into profitability?
Step 4: Decision-Making
The rabbit hole of questions can go as far as how you want to evaluate these unknowns based on the business requirements. You may need to spend these resources and push back the engineering deadline. Is the company OK with that?
It depends also on how you communicate YES or NO. Yes, I want to prioritize this feature. I want to do this. OK. Why? Because manager has signed off on the strategy, I know who the customers are, I have the data to back it up, I have the stakeholder consensus to do it, I have a timeline that I feel confident executing on.
Or, if you say no, they’re the same questions. No, I don’t have a clear strategy from management or, no, the manager wants me to validate this before we spend extra resources on it, we don’t have enough engineers or resources for this no we have to use the sales cycle for another feature – if we try to implement this and we are going to lose the seasonal sales cycle.
These are all moving parts that you want to evaluate and then communicate to the Product Manager interviewing you. The best thing to do when you are asking these questions is to try and use a specific example of a time where you had to go to someone and say:”We can’t do this for whatever reason”, or “Yes, we can do this because whatever reason” based on these moving parts.
Again you are communicating competency on how you evaluate whether or not you implement a feature.
Ask questions to create constraints and bounds to the interview case study. You must control the scope of the case study. Once you have this information, you will know how to best approach the questions based on the Product Management knowledge you know.