{"id":78329,"date":"2022-06-06T17:36:01","date_gmt":"2022-06-06T16:36:01","guid":{"rendered":"https:\/\/www.prodpad.com\/?p=78329"},"modified":"2025-01-13T16:25:52","modified_gmt":"2025-01-13T16:25:52","slug":"product-roadmap-experiments","status":"publish","type":"post","link":"https:\/\/www.prodpad.com\/blog\/product-roadmap-experiments\/","title":{"rendered":"Your Product Roadmap is a Tool for Experimenting"},"content":{"rendered":"\n

Some people still think about the product roadmap<\/a> as a planning tool. Old school roadmaps read like a list of features that you could or even will<\/em> build.<\/p>\n\n\n\n

I\u2019ll be honest with you: this is not a good practice. (In fact, it\u2019s #5 on my list of roadmap things to avoid<\/a>.)<\/p>\n\n\n\n

The roadmap is not a list of things that you will do. It’s a list of things that you could <\/em>do.<\/p>\n\n\n\n

More than anything, it\u2019s an experimentation tool \u2013 a place to lay out the solutions that you can test, <\/em>in order to address the most important problems facing your company.<\/p>\n\n\n\n

Once you\u2019ve identified the main problems according to the business\u2019 OKRs, then you brainstorm potential solutions. There are usually many, varied paths toward your goal. Each problem could have 5 to 10 potential solutions attached to it. Narrowing them down and selecting the best one requires experimentation.<\/p>\n\n\n\n

The product roadmap records what these experiments are, how they\u2019re going, and what\u2019s been learned.
<\/p>\n\n\n\n

\"Product<\/figure>\n\n\n\n


All of your ideas are hypotheses<\/h2>\n\n\n\n

All of your ideas are hypotheses, and as a PM, your job is actually to invalidate most of them! That said, product ideas don\u2019t pop out of the blue, and your hypotheses aren\u2019t created in a vacuum.<\/p>\n\n\n\n

Product ideas are derived from OKRs, top-level objectives that are defined by the business. The product team sets out to solve a problem around churn, retention, revenue, etc. For example, as a PM you can say, \u201cOkay, the problem we’re tackling this month is \u2014 we need to get conversion rates up, and the issue is around our sign-in flow area. We need to move people into the purchase flow. How can we do that?\u201d<\/p>\n\n\n\n

From there, you might brainstorm three to ten different ideas or potential solutions. Some will succeed and some will fail \u2013 that\u2019s a fact. But you don\u2019t know which ones until you test them. And to test them effectively, you need hypotheses.<\/p>\n\n\n\n

How to phrase a product hypothesis:<\/strong> If we [try this idea], it could solve [this problem] and it could uplift [this metric] by [N].<\/p>\n\n\n\n

Cool, that’s the experiment to run! Then you see how the new feature performs and take steps from there. But while we\u2019re here<\/em>, a quick note about new features\u2026<\/p>\n\n\n\n

What counts as a potential solution? Think wider.<\/h2>\n\n\n\n

Product solutions aren\u2019t necessarily new features. What about changing a feature \u2013 or even removing a feature? Either of these might improve usability or impact other metrics and objectives that you’re working toward.<\/p>\n\n\n\n

Some solutions might not involve code at all! The trick could be changing the price or the packaging or the value proposition<\/a>. Shift how you talk about a benefit on the homepage or rethink how you present certain information to the customer. Adjustments like these can transform the way people interact with your product \u2013 which, in turn, could solve some of the problems on your product roadmap.<\/p>\n\n\n\n

The point is: experimentation doesn’t always require the development team. Instead, it might require marketing, sales, customer success, and support. PMs should take a step back and think more holistically about what it is they’re actually solving so that the rest of the team can be involved as well.<\/p>\n\n\n\n

What counts as a product roadmap experiment? Think leaner.<\/h2>\n\n\n\n

Again, by \u201cexperiment\u201d I don’t necessarily mean build full-on code. Experiments can also be fast litmus tests to check what\u2019s viable or not before devoting any real resources to it. There are many ways to do customer decision discovery, do quick prototypes, and put in place little tests. It could even be a prototype on paper that you test with select customers. <\/p>\n\n\n\n

As you do these tests, you identify the experiment options that you think are going to be easy, the low-effort, high-impact ones, and float those to the top. Work through the list and see how close you come to solving the problem. 80% is close enough. Move on.<\/p>\n\n\n\n

Most importantly, record everything.<\/p>\n\n\n\n

The product roadmap is a record of learning<\/h2>\n\n\n\n

As a product team, one of the most important things you can do is log your decisions \u2013 for future you and <\/em>future team members who join. This starts with each of your tests.<\/p>\n\n\n\n

Logging experiments in the roadmap<\/h3>\n\n\n\n

You can use the product roadmap to display how you’re actually progressing with experiments, such as:<\/p>\n\n\n\n