Being a PM means being fully or partially in charge of the product strategy and of the engineering team’s roadmap. Seasoned PMs are so used to this that sometimes they don’t even mention it as part of their daily duties. But for aspiring PMs and entry-level specialists, it is normal to be a little scared of taking this responsibility.
When I started thinking of a PM job, imagining an engineer asking “Hey, I ran out of tasks. What’s next?” gave me goosebumps and made my mind race randomly through the screens of the apps I’ve seen before searching for useful features.
The worst outcome of such an exercise is the conclusion “I am not creative enough for the job”. In this article, I will shed some light on where the product ideas and roadmaps come from. Hopefully, you will not get discouraged but will learn that one can become a successful PM regardless of their creativity.
First, let’s start with what the product roadmap IS NOT:
-
NOT a list of random UI improvements: As an app user, you sometimes get annoyed by small imperfections — like when you zoom in by a double tap on Google Maps but instead, you accidentally open a random restaurant’s card. Although a good product doesn’t have too many bugs and imperfections, fixing them should consume no more than 10% of your team’s time. This process is driven mostly by the designer and the engineers.
-
NOT a list of features your competitors have: Benchmarking your app against competitors is a good idea, but making your backlog look like you’re trying to create a “better version of Instagram” rarely leads to success. First, your roadmap should be coherent and lead you somewhere. If the destination is your competitor’s app then how are you making your app more attractive? Second, you never know if a feature worked for your competitor or if it is just something they don’t have time to get rid of.
-
NOT a list of what you’ve been told to do. Although this is quite frequently the case, we assume for this article that we’re talking about the role of an empowered product manager rather than a backlog administrator.
From the points above, you can already see that the product ideas don’t randomly come out of thin air. The list of product ideas and projects should form a strategy, that leads you to a goal dictated by your product vision.
For now, we will not focus on how the strategy and vision are written (although I highly recommend reading another Hackernoon article about the product strategy). At earlier stages of your product career, you will usually work on a part of a bigger product, which overall strategy is (hopefully) already defined.
In such a context, your area of responsibility can be called a problem space: you know what needs your product should meet, and this is when you are asked to come up with a backlog of ideas on how to solve this problem. You will later lay this backlog into a timed roadmap.
Knowing what problem you are solving, it’s time to start populating your backlog.
Here is a list of methods I suggest trying for that:
-
User interviews: Ask your consumers directly. If they have a problem — investigate what they feel about it and how they solve it now. When possible, try to ⬇️
-
Brainstorming: Pick people with diverse backgrounds and let them ideate together
-
Analyse user behaviour: Customers’ real-life actions are the best way you can learn when and what is not working. So you should become best friends with your product analytics, build the most basic user segments and funnels, and then start investigating step by step where the problems occur.
-
Compare your product to direct competitors:Even though doing full copycat is bad, it is a good idea to look out for the already existing solutions to your problem.
Of course, you will not know if a certain feature was successful, but knowing that
it exists already gives you an upper hand: e.g. you can ask about it during user interviews ⬆️ -
Look into the same problems in other industries: Most probably there is already an industry that had a head start and has already been tested way more than yours: e.g. telecom providers had a problem of customer churn long before internet and mobile subscription services took over — how did they solve churn problems?
Picking and trying these approaches, you will populate your backlog with ideas, which you can then start prioritising. To do that, you will work continuously with your design, research, and data people to do the following:
- Design and test a prototype on customers or even just your colleagues (corridor testing)
- Analyse data to estimate the impact a problem has on customers and the business
- Estimate the effort to implement a feature
Finally, in pursuit of maximum efficiency, you will scope your projects to deliver maximum value. If your confidence in the project’s success is low — look into the riskiest assumption testing (RAT) method and prove your hypotheses with smoke tests; if the confidence is high — scope out a proper MVP that solves a problem (and plan a few improvement iterations — for that I suggest conducting a premortem session).
Now, the hard truth is that the whole process I described is very idealised. In real life, you might not have as clear a product strategy or well-defined customer problems; you might not have a mature user research methodology and a researcher in a team; or sometimes you’ll be asked to come up with a product feature just because the team ran out of things to build. This is also a normal part of the PMs’ routine, and the road to success may be full of obstacles.
But you should remember: strategy and the problem space matter the most, so put a lot of effort into making sure your roadmap is a true derivative of your product strategy, and don’t be afraid of challenging the status quo and rewriting the strategy over and over.
Good luck! ;)