Kumar Utsav’s Post

View profile for Kumar Utsav, graphic

ex-Product Lead @Facebook, Razorpay, WhitehatJr

Everything which matters about Product Roadmaps for a Product Manager but is not often discussed: 1️⃣ You define your roadmap once your product strategy is in place. Not the other way around. 2️⃣ Your roadmap should always be outcome driven rather than output driven eg %ge increase in revenue(outcome) vs count of features shipped (output). 3️⃣ Your roadmap should be seen as a portfolio of investment bets across a few themes rather than a stack ranked list in a single area. 4️⃣ Few themes you can consider:  → KTLO (Keeping the lights on): This theme ensures that your product works smoothly on a day to day basis. Incremental improvements, product maintenance, tech debts and bugs will form the bulk of this work.  → New feature work: This theme will include all the new feature work the team will work in short/mid term to move the needle for the short/mid term goals. → Moonshots: This theme focuses on work which has the potential to create 10X impact by either leveraging existing capabilities to new user segments expansion(e.g. geo expansion of the same product or a new toned down version of existing product at lower cost) or creating entirely new product categories.   → Note that the mix of these themes vary as per stage/requirements of the company.Eg early stage startups will be heavy on moonshots as they have no existing products and large tech companies with existing products will be heavier on KTLO/New feature work with less than 20-25% allocation to moonshots as existing products are already big. 5️⃣ Always prioritise roadmap items within a theme, not across combined themes. 6️⃣ Each item in your roadmap should take you closer to the goal. 7️⃣ The impact of each roadmap item could be measured via a outcome metric or a miletsone. Metric is always preferred but for foundational work for which you can't run experiments or release to customers, the progress is captured via milestones. 8️⃣ For software products quarterly/half yearly roadmaps are the norm as you learn new things in a quarter/half as cycle time from build to launch is faster with quick feedback loops but annual roadmaps are more suited for hardware products (as build to launch takes more time). 9️⃣ You should deeply understand the risk for each key roadmap items and derisk them early. Closing thought: Your roadmap will be as good as the inputs to it. So spend good time on finding insights that will form basis of your product strategy eg data analysis, user feedback, customer research, and competitive analysis. PS: How to prioritise roadmap is not part of this post. Will write about it sometime in future. #productmanagement #productroadmaps

Shweta Rajkarne

Mom, Staff Technical Product Manager @ServiceNow, Passionate about leveraging technology to solve business challenges

1mo

This is a great series Kumar Utsav, I have personally learnt a lot reading your posts so far. I couldn't agree more with above.. especially point no 4. This aspect is often overlooked with the ongoing roadmap/ future items. Keeping the product stable is absolutely something that should get its own importance and capacity. What are your thoughts on the features that somehow make it to the list but are not used as intended by the users ?

To view or add a comment, sign in

Explore topics