A simple framework to triage and prioritise new ideas

For any product startup, prioritisation is everything. Spend time working on the wrong things, and you’ll waste both time and money – two things you have in very limited supply as a startup.

Lots has been written about prioritisation in product teams, and it’s often cited as one of the biggest challenges facing startups and product teams today. But it’s really not that difficult if you approach it with deliberate focus.

At it’s core, prioritisation is simple:
Find the highest-leverage things (features, services, tools) and focus on those first.


As a Product Manager you’ll be constantly bombarded with new ideas: the might be your own ideas, they could come from the founders, from customers, from investors, or from your team. There’s never any shortage of ideas – and that’s great. The problem is that investigating and assessing these ideas takes a lot of time. To make sure you only spend time on the things that matter, (and to keep your sanity), you need to be able to quickly and effectively triage this flow of input.

I have a simple two-step framework I use to quickly triage ideas.

Does this idea, if implemented, directly and positively impact our key product goals/metrics?

This step is simple. You just need to ask: if we do this, will it have an impact on what is important?

(The prerequisite is, of course, that you already have a clear view on what your product goals actually are. If you don’t, then you need to get that clear right now – otherwise, how can you prioritise anything? With no key goals to prioritise against, how can one thing ever be more important than another?)

Will this idea, if implemented, have a positive impact on the goals you’re trying to achieve? Does it have leverage? If the answer is ‘no’, you know you can immediately stop investigating. Maybe this idea will be useful later, when your product strategy matures and focuses on other goals, or maybe it will never be useful. Either way, don’t waste any more time on it.

Note that in Step 1 we don’t consider how to implement the idea. How is irrelevant at this stage: the only question that matter is: is this the right thing to do?

Is the effort/impact tradeoff aligned?

Once you’ve weeded out the ideas that are not going to impact the product goals you care about, you can assess if the value/effort tradeoff is aligned. Map the idea on the Effort/Value grid:


If the idea doesn’t fall into the top part of the graph, discard it. You don’t want to focus on low-value items: even when the effort is really low. Avoid the trap of thinking “oh well, it’s only a couple of hours’ work, so…”. Every hour you spend on low-value work is an hour you’re not spending on high-value work. Don’t do it.

(You can read more about the effort/value grid here.)

If you’re honest with yourself about the value each idea contributes, and to which goal, you’ll find you can safely discard many, if not most, of the new ideas that come flowing your way. When you learn to filter and triage quickly and effectively, you’ll minimise the time you spend on dealing with noise and be able to spend more time focussing on what’s important.

Try it out and feel free to let me know how it works for you.

Let the team decide…

In a typical agile development team a few hundred decisions get made every day, by everyone. Should we build this user story first or that one? Should I refactor this method now or do it later? Is this bug more important than that user story? Should I call that meeting for this week or next week?

Every decision that gets made, in the end, makes its mark on your product. Every decision impacts the team’s velocity or productivity, the product quality, the product features and the user experience.

If you’re planning a trip in your car, every decision you make along the way will impact where you arrive at, how long it takes and how many dents you have on your car when you get there. Do you want to get there quickly, or is time not so important? Do you want to avoid dirt roads, or do you prefer them? Is there a particular landmark you want to see on the way? You have an idea of what your journey will be like before you leave, and your decisions are based on that vision of your journey.

Back to the development team: every decision made will impact where and how you arrive at your destination. So the question is: does everyone in the team have the same vision of what your journey will look like?

One of the Product Owner’s most important roles is to define and communicate the product vision. The more the team understands and buys into the product vision, the more likely it is that each decision they make will lead the journey in the same direction you want to go.

Here’s a concrete example: a lot of POs spend a lot of time prioritising things: bugs, stories, meetings, etc. Many POs I know want to be involved in every decision the team makes. What makes one thing more important and/or urgent than another thing is all about vision and context. What would happen if the PO spent all the time she spent prioritising bugs on communicating the product vision? If the team understands the vision and context, then they should be able to make the right priority decision based on that vision and context.

Time invested making a single decision for the team has little return beyond the decision itself. Time invested in communicating vision will repay itself over and over with better decisions across the team, fewer bottlenecks and less wasted time.