Over the years of working on different ventures, I’ve been able to get a lot done with little resource. A big part of that has been the good fortune of working with talented people.
The other big part is “brutal prioritisation”. I once wrote that the fundamental job of a product manager is to prioritise. Brutal prioritisation (BP) is the extreme version of this.
Why is it brutal?
The “brutality” of this prioritisation is that you’re not just rejecting bad ideas. You’re rejecting good ones too. In other words, you’re working on only the highest value items and making good (but less valuable) items wait.
The other reason it’s brutal is because of speed and uncertainty. You’re making these decisions fast and over-and-over again, each day, sprint and year. You don’t have perfect information. You’re taking risk (and managing it). And you’re not kicking the decision to a committee, thereby delaying everything.
Why would you ever reject a good idea?
Because you’re severely resource constrained. Demand always outstrips supply. But when you’re in a new ambitious venture, that imbalance is much more severe. Saying “yes” to anything that is a good idea implicitly means saying “no” randomly to something else. That’s the reality of finite time and talent.
So instead of saying “no” haphazardly, be deliberate. It’s not enough to be a good idea. It has to be one of the highest value ideas at the time.
As an example, a common conundrum for an ambitious company is deciding whether to build for new customers or existing customers. Both are good ideas. But if you don’t have the resource, then you need to be deliberate about which ones get a “yes” or a “no”.
Keep in mind that saying “no” doesn’t necessarily mean “never”. It just means “not now”. It goes in the backlog. And chances are, some version of it will eventually get done, when the time is right.
How do you make brutal prioritisation decisions?
With a lot of difficulty. Just kidding. Seriously, you need two pieces:
- Clarity of your top goals
- Strong understanding of the drivers
Clear goal priority is pretty self-explanatory. What’s the company trying to do? What’s your team aiming for? If it’s unclear, then figuring this out is your top priority goal.
Strong understanding of drivers means that you need to know a) what will “move the needle” towards your goal and b) how much. Anyone can come up with (a). Most people fail at (b). Most people could tell you the 12 items that help with the goal. Only the talented ones could point to the 2 that will deliver 80% of the outcome.
Knowing “how much?” is hard. It comes from a combination of analytics, customer research, deep experience, etc. Most of all, it comes from having a detailed mind and problem solving power. The people who fail at (b) do so because they miss key details or can’t integrate disparate pieces of information.
Your organisation has to buy into this
Your organisation needs to entrust you (or you plus one other key person like the CEO) to make swift, brutal decisions, which may not always be popular. Your organisation needs to also understand that many times a good item will get a “no” (because it doesn’t move the needle on the top priority and you don’t have the resources to pursue it simultaneously).
If your organisation doesn’t trust you, you end up with product-management-by-committee. It’s costly. “I need control over what gets done.” “I need to be consulted before something is released.” “I want dates for when my stuff will be done.” “My idea is great. Justify why it’s not being worked on now.”
Doing it this way takes serious resource. To put it more simply, if people want it, then the organisation needs to at least double the team (and slow down delivery). This isn’t an exaggeration. It goes a long way to explaining how small companies run circles around giant corporates, despite the apparent inequality in resources.
I’m not advocating a total absence of internal communication or co-operation. But a product manager should be spending the vast majority of their time on users, insight, design and development. Not slides, emails and meetings for internal stakeholders.
One other way to screw up brutal prioritisation is to have far too little resource. While BP allows you to do a lot more with relatively little, it isn’t magic. While you don’t need fat, you still need muscle. Otherwise you’re just a pile of bones.
Why not just hire more people?
If the company is doing well and you find yourself saying “no” a lot, why not just go add more people? It’s a fair question. The considerations are:
- Finding good people is hard and adding lots of them very quickly may break a team
- Brutal prioritisation forces the company to only serve needs, not whims
The last one needs some explanation. A lot of times, people internally will ask for something. “In my last meeting, the customer said we should totally make the button green and the text bigger.” This is a whim. It’s knee jerk. It’s badly understood. They aren’t harmless. Because they’re badly thought out, they often knock back or break the product elsewhere, requiring more work to fix.
In an undisciplined organisation, having a bigger team means doing more whims (rather than real needs). In other words, if you haven’t figured out how to prioritise well with a small team, having a larger team isn’t going to teach you.
Be smart + move fast
I previously wrote about how product orgs need to close their development loops quickly. Brutal prioritisation is basically an extension of this concept. You need to be smart (about your goals and drivers) and organisationally be setup to enable you to move fast. Doing this means you can outperform other teams and punch well above your weight.
GS Dun provides leadership for new ventures. When you’re at an inflection point and need to do something different, we help. Our name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.
blog.GSDUN 