El Estandar Design Services Limited

It frustrates me to see how product managers have complicated the simple process of creating a roadmap Believe it or not, a product roadmap is nothing more than a 𝘵𝘰-𝘥𝘰 𝘭𝘪𝘴𝘵, where the items are sequenced based on some logic. For me, creating a roadmap is a simple 3-step process 1️⃣ Ideation 2️⃣ Impact estimation (and normalization) 3️⃣ Sequencing 1️⃣ 𝗜𝗱𝗲𝗮𝘁𝗶𝗼𝗻 This step takes time. And it deserves it. Therefore, product managers should do this 𝘵𝘩𝘳𝘰𝘶𝘨𝘩𝘰𝘶𝘵 𝘵𝘩𝘦 𝘺𝘦𝘢𝘳, instead of only until a few weeks before planning process To increase quality/quantity of ideas • talk to users • read about competition • know the market/industry • evaluate past wins and failures • analyse customer support tickets • talk to experts in/outside of your org (See image 1 below) 2️⃣ 𝗜𝗺𝗽𝗮𝗰𝘁 𝗲𝘀𝘁𝗶𝗺𝗮𝘁𝗶𝗼𝗻 (𝗮𝗻𝗱 𝗻𝗼𝗿𝗺𝗮𝗹𝗶𝘇𝗮𝘁𝗶𝗼𝗻) Some product teams make this process overly-complicated. But, some keep it simple. I am a fan of simple. Remember: when you’re impact sizing, your goal is to create 𝘳𝘦𝘭𝘢𝘵𝘪𝘷𝘦 sizing and not 𝘢𝘣𝘴𝘰𝘭𝘶𝘵𝘦 sizing. If feature A has an impact of X, and B has an impact of Y - the goal is not to accurately measure the values of X and Y, but to identify if X > Y or vice versa But even this (simple) approach has a challenge. Imagine: • A impacts 𝘙𝘦𝘷𝘦𝘯𝘶𝘦 • B impacts 𝘮𝘢𝘯-𝘩𝘰𝘶𝘳𝘴 𝘴𝘢𝘷𝘦𝘥. In this case, you're comparing apple and oranges, therefore you can't create the X>Y equation In such cases, you need to 𝗡𝗼𝗿𝗺𝗮𝗹𝗶𝘇𝗲: convert all 𝘶𝘯𝘪𝘵𝘴 𝘰𝘧 𝘪𝘮𝘱𝘢𝘤𝘵 into a common one. (See image 2 below) 3️⃣ 𝗦𝗲𝗾𝘂𝗲𝗻𝗰𝗶𝗻𝗴 If you’ve completed step 1 and 2, this step is super simple. It is as simple as sorting by the impact column in your sheet. And then you have your roadmap. (See image 3 below) -- Exceptions: Some teams use another variable: Cost (aka effort to build) That gives you more leverage. Introducing 𝘤𝘰𝘴𝘵 might unlock scenarios where: • Impact: of feature A > B • But, cost to build: A > B In this case, you can focus on B before A, if the goal is to deliver 𝘷𝘢𝘭𝘶𝘦 𝘲𝘶𝘪𝘤𝘬𝘭𝘺. OR You could break A into smaller chunks in a way that allows you to deliver value in less time. Both approaches are fine. I've used both. Which I choose depends on the focus of the team/company For ex: • Startups optimize for velocity • More mature orgs: optimize for high quality -- While the core roadmapping process is simple, it is imp. to understand there are many time-consuming activities happening in the background: 1. 𝗥𝗶𝗴𝗵𝘁 𝗺𝗶𝘅 𝗼𝗳 𝗶𝗱𝗲𝗮𝘀: I like to think of ideas in 3 buckets (big bets, new features, and bugs/small fixes/etc) and that takes time 2. 𝗔𝗹𝗶𝗴𝗻𝗺𝗲𝗻𝘁: for roadmaps to be successful, you need support from multiple teams. To have that, you need them to buy-in to your roadmap 3. 𝗜𝘁𝗲𝗿𝗮𝘁𝗶𝗼𝗻: roadmaps should not be set in stone. Your product (and roadmap) should respond to changes in user preferences, market conditions, competition. So, you should keep iterating when required