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.

The value of talking to customers

I spent about 4 hours last week conducting usability tests. No matter how often I do this, it always amazes me how incredibly valuable it is. Every test reveals something new about the product.

As a coincidence just this week I also came across this article talking about how many Product Managers lament that they don’t have time for customer or market research at all.

“I am too busy writing specifications to be able to do the important customer feedback, research, and strategic work.”

I see this all the time in product teams, and while I get it that there are always more specs to write and more bugs to triage, I always say:

What could possibly be more important than knowing you’re building the right product?

All other things being equal, the company who understands their customer the best will win the customer, and the market.

Talk to your customers. If you don’t have customers yet, then find people in the market who match your target segment and talk to them.

For some tips on how to do that, check out this video.

But whatever you do: get out of the building and talk to your customers.

Great PMs don’t work alone

Sometimes there’s a perception of Product Managers that the best ones are product geniuses who always and immediately have the right answers for every product problem: PMs whose product instincts are so sharp they can arrive at the best solution at a moment’s glance; who can look within themselves and find the solution deep down there and pull it out onto a wireframe through a simple act of will.

I suppose there are a few crazy geniuses out there. And I’m certainly not doubting the power and value of instinct built up over years of product experience.

But the whole truth is that being a great Product Manager is less about moments of divine inspiration, and more about work and grind: questioning, discussing and iterating. Hypothesising, experimenting, failing and repeating. Doing the work.

The whole truth is that great PMs don’t work alone. They’re not mad geniuses who are supposed to always have all the answers.

Great PMs are masters of The Process: the process of gathering input and inspiration from myriad places, and synthesising that into a solution. PMs talk to the customers, to the sales team, the finance team, the engineers: they talk to everybody. They know that ideas and inspiration can come from anywhere, and they actively seek out ideas and input from across the business.

But be careful. This is not the same as “gathering requirements” or “translating business objectives into development objectives” (two definitions that often come up in the context of Product Management that I really hate).

This is not about making sure everybody’s input and ideas are squeezed in to the product. It’s about a process of gathering ideas and inspiration from as far and wide as possible (the divergent thinking phase), then boiling that all down into the solution that best solves the problem for the customer (the convergent thinking phase).

Product instinct is less about always knowing what the solution is. It’s much more about knowing which solution, from a list of possible ones, is most likely to work, and which should be tested. It’s about quickly assessing and prioritising a variety of options and making the right call.

So don’t think you always need to have all the answers. Use your team and your network to build your list of options, pick the best one, or combination of best ones, and go.