How to prioritise your time and stay sane as a Product Manager

I recently finished training a new Product Manager and on-boarding him onto a project. After his first week alone on the job full-time, he came to me on a Friday afternoon with a frazzled look on his face and asked me: “How do you cope with the continual and immense demands for my time as a PM – and then on top of that still find time to think about strategy, talking to customers, and evangelisation?”

This is the science, and art, of prioritisation.

I could point him to a ton of resources about how to approach product backlog prioritisation, such as the ICE method. But what he really needed to hear is not how to prioritise a backlog (although this is also important). He wanted to know how to prioritise his time.

I came up with these principles:

  1. Ruthless prioritisation of everything. You have to sort the world into “things that are important and urgent right now” and “things that are not”. And then to make this work, you have to ignore the things in the “not important” column! This is where many people get tripped up: they prioritise well enough but then end up working on stuff from the ‘not important’ area because an executive wants it, or because an important customer is asking for it…
  2. But in order to prioritise, you need to have clear product goals. This sounds like “duh” but you’d be surprised how many product teams I’ve seen who have no idea what the goal for the quarter is. They have a roadmap, sure… but what is the measure of the success of that roadmap? What ONE result/metric are you trying to move in this period (month/quarter/year)? A test of a good goal is that a) everybody can remember it immediately, and b) you can use it to make individual prioritisation decisions at any level (feature level, roadmap level, strategy level, etc). If for any item on your backlog/roadmap, you can clearly say that it either contributes directly to that goal, or it does not: then it’s a good goal. If you cannot, it means that goal – or at least, that articulation of it – is not useful for prioritising your strategy, which means it’s not useful as a goal.
  3. Related: Stack rank everything. For any two items, you must always be able to say which is more important than the other. Try the experiment: pick any two items from your roadmap, backlog, or wherever. Then ask yourself: if you could only have one of these things, which would it be? Do you have an answer? Good! If you don’t, then you need to get better at stack ranking.
  4. And finally: get used to disappointing people. It’s natural for Product Managers to measure their success against how happy they make their customers – both internal customers (colleagues, executives, engineers, designers, etc) and actual customers. But you’ll never be able to please everybody. We all agreed years ago that “design by committee” is a bad idea: try to build something for everyone, and you’ll end up building something for no-one. And yet, how many low-value items have you ever snuck into the roadmap because Sarah really wants it for her campaign, and she asked so nicely… Resist that urge. Learn to say (politely) no to requests, ideas and requirements that don’t align with what you’re trying to achieve right now. By all means, collect ideas often and from as many sources as you can: this can be a great source of inspiration and creativity for you. But don’t create expectations that every idea is created equal (because they aren’t).

This is how to stay productive – and stay sane – as a Product Manager.

Good luck!

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.

speed-prioritisation-focus

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.

STEP 1:
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?

STEP 2:
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:

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.