One of the core responsibilities as a product manager is to determine the long-term strategy for their product.
To do so, product managers create product roadmaps to orient themselves and their teams on what new initiatives, products, and features to tackle, and within what general sequence and timeframe.
During product manager interviews, many companies seek to understand your ability to execute against these responsibilities by asking you to create a product roadmap on the fly.
In fact, out of the on-site interviews that I've had, all of them had some sort of roadmap challenge. It's important for companies to know that you can plan out delivery based on core business objectives, and that you can manage dependencies across stakeholders. As a side note, I've found that it's rare for interviewers to ask you to create a roadmap during a phone interview.
The popular product roadmap question usually takes shape in the form of something like the following:
“Create a roadmap for X product to achieve ABC objectives.”
When you answer these types of product roadmap questions, you should approach them with a framework in mind. Below is one that we highly recommend.
- Align on the high-level objectives for the organization.
- Identify relevant metrics.
- Determine which customer segment to focus on.
- Identify customer needs and brainstorm features to solve those needs.
- Prioritize your features.
- Create a timeline of features, and highlight dependencies.
- Discuss how various factors and assumptions might change your roadmap.
First, ensure that you fully understand the objectives of the organization. Is the goal to increase profitability or to drive additional revenue? Is the goal to reach new users or to get more usage out of existing users?
Organizational objectives matter because they form the foundation for your roadmap.
Sometimes, the interviewer will not provide the objectives upfront. In cases such as these, ask the interviewer whether they have one in mind. If they tell you that they’d like you to come up with the objective, then go ahead and take the initiative!
Determine what the objective should be, based on your knowledge of business context. For example, it's probably inappropriate for a small startup to focus on increasing profit at the cost of shrinking their current user base.
Metrics of Success
Now that you know what the organizational objectives are, select metrics that makes sense based on where the business is today. For example, a very small startup might be interested in growing traffic, whereas a very large organization might be interested in further monetizing existing customers.
Why do you need to select metrics? Because you need to be able to measure your success! If you have no metrics, your roadmap can turn squishy very quickly.
For example, consider the objective "improve the brand". In the absence of metrics, nearly every product or feature can be justified as a way to improve the brand.
If, however, you identify that your metric for tracking brand performance is " of customer logos on the website" or " of positive press releases", you now have a clear way forward in defining success.
Furthermore, when selecting metrics, be as crisp as possible in your definition. For example, you may want to specify that you want to grow the monthly active users on the iOS app specifically, or that you are seeking to upsell monthly subscriptions to becoming annual subscriptions.
Target Customer Segment
Now that you have defined the metrics that you about, remember that while your goal is to create value for the business, your business cannot capture value unless you first create value for your customers.
Before you can capture value for your customers, you must first define who your customers should be. Sometimes your interviewer will tell you which customer segment to focus on; other times, you will have the responsibility of selecting a customer segment.
While it’s tempting to say that “everyone is a customer!”, remember that your job as a product manager is to prioritize and focus. Who is the best customer for the organization, based on the metrics that you previously defined?
When thinking about customer segment definitions, you have a wide variety of attributes at your disposal. You can use demographic attributes such as age, gender, income, or geographic location. You can also use behavioral attributes such as “heavy social media user”, or “goes grocery shopping twice a week.”
Don’t assume that the company’s current target customer segment is automatically the customer segment you should go after. On the flip side, you should seriously consider whether the company's current customer segment is the best for your objectives.
Pain Points and Features
You’ve now defined who your customers are. Next, you must determine what pain points they face, so that your product can provide value by solving those pains in a targeted manner.
Of course, you will not be able to conduct live customer research in the middle of your interview! At this point, describe your assumptions about your customers' pain points, based off of the segment that you created.
Work collaboratively with your interviewer to validate your assumptions. Do they agree with your assessment? If not, ask them for their reasoning, and reflect on whether their perspective makes sense to you. If so, you can then incorporate their logic into your thinking.
Now that you know your customer and have a couple of relevant pain points in mind, you can brainstorm features that can solve these pain points.
Discuss how each proposed feature specifically solves for each of the different pain points that you’re targeting. Keep track of these proposed features in a visible location, so that you can prioritize them in the next step.
Looking at your list of new features, you now need to determine what goes into a minimum viable product, what goes into a pilot, what goes into a rollout, and what should be left as future enhancements. Prioritization is key - determine which features deliver the core value the fastest.
I generally like to bundle together a core set of features as a minimum viable product (MVP), then show how I might add more features into a version 1 and a version 2.
This provides a great transition into timeline - I can now show about how long it would take to have the MVP available, and how much more time it takes to get to version 1 and version 2.
With your set of features, provide estimates on how long they would take to be completed. If possible, show what tasks could be done in parallel versus what tasks must be done serially. Using a whiteboard or a piece of paper to draw out a Gantt chart (Wikipedia article) can be helpful to visualize the timeline.
Remember that as a product manager, while you work most closely with your engineers, you need to account for dependencies with other stakeholders as well. For example, if you are working in a B2B organization, you’ll want to highlight dependencies with Business Development, Sales, Marketing, and Customer Success teams, and bake those times into your delivery timelines as well.
Assumptions and Impacts on Roadmap
Highlight your assumptions. For example, time to deliver = effort / resources.
If you're going to say when you want to deliver something (e.g. “in two quarters from today”), you need to tell your interviewer upfront what resources you expect to have, and what effort you estimate.
It doesn't need to be at the story point level or at the person-hour level - "shirt sizes" (large / / small) is generally sufficient.
If your interviewer raised any concerns or open questions throughout the roadmap challenge, now is a great time to revisit those questions and show how they might change the roadmap and timeline.
As a more concrete example: let's pretend that your interviewer mentioned in an earlier discussion that some of the technology needed in your roadmap requires partnerships with 3rd parties because those capabilities are not yet available in-house.
Show the tradeoffs that you'd make if you developed in-house vs. if you partnered with others, and show the critical steps needed to vet out and implement a 3rd party technology.
As another example, say you released your MVP, but then found out that your customers did not react positively to your MVP. How would you iterate? How long might that take? If you conducted additional customer research to flesh out learnings, what downstream impacts would that cause?
Remember that this roadmap challenge is meant simply to test your thinking on-the-fly - your interviewer does not expect you to have a fully bulletproof plan.
Plus, product roadmaps change over time due to market circumstances and user need discovery anyways - so there's no such thing as a perfect roadmap!
When practicing, practice under the same time constraints that you'd have in an interview.
Take no longer than 30 minutes to get through all aspects of the above framework, and note down areas where you feel you're a bit shaky or where you felt you didn't have sufficient time to explain yourself.
Practice your timing so that you don't spend too much time in any one section, but that you are ready to dive deep if your interviewer asks you for it.
Give your interviewer a sense of where you're going with your framework. Tell them upfront that you'll be tackling particular topics in a particular order, so that they understand the tradeoffs that you will make if they do decide to ask you to dive deep in a particular section.
While practicing can seem daunting, remember that by practicing now, you will dramatically improve your chances during the real interview. Stay motivated!
Interested in learning how to dominate these types of product manager interview questions and land the product manager job? You might want to check out our popular course: One Week PM.