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: 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 random UI improvements: 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 . 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 features your competitors have: lead you somewhere Although this is quite frequently the case, we assume for this article that we’re talking about the role of an rather than a . NOT a list of what you’ve been told to do. empowered product manager 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 , that leads you to a goal dictated by your . strategy 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 ). 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. product strategy In such a context, your area of responsibility can be called a : 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. problem space 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: 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 ⬇️ User interviews: Pick people with diverse backgrounds and let them ideate together Brainstorming: 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. Analyse user behaviour: 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 ⬆️ Compare your product to direct competitors: 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? Look into the same problems in other industries: Picking and trying these approaches, you will populate your backlog with , which you can then start . To do that, you will work continuously with your design, research, and data people to do the following: ideas prioritising 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 session). premortem 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 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. asked 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! ;)

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Too Long; Didn't Read

Let Your Engineers & PMs focus on Product. Apply for $50K Credits!

HackerNoon Mobile

Where Do Product Ideas Come From?

Too Long; Didn't Read

@easygogins

Credibility

RELATED STORIES