What should we build next? How do you put a value on a feature? Prioritising the big bits of work...
Updated: Dec 2, 2021
Continuing our Product Management blog series…
What should we build next?
As a Product Manager, arguably the hardest question you have to answer on a regular basis is ‘what feature should we build next?’
It’s a nearly impossible question. Everyone has a view, no one actually knows and there’s typically little or no data to work with.
But to be clear, as a Product Manager this is your problem. You have to own it, as you’re the one who is going to be left holding the baby once it’s built.
There are dozens of different prioritisation techniques around, most of which suck. One that doesn’t however is the Weighted Shortest Job First model or ‘WSJF’.
Here’s what you do…
Gather all of the different feature options that pass the sniff test into a spreadsheet
Get a great dev to give you a T-shirt size for each feature based on a simple one paragraph definition provided by the feature sponsor
As a team (Devs, Exec, Customer Success, Uncle Tom Cobly…) score / re-score each feature using the Fibonacci sequence against a common set of questions
You should shape the questions, so they relate to your exact business. The question list below is fairly generic and is a good starting point for most SaaS businesses.
Does the piece of work unlock / bring forward recurring revenue?
Is there a non-financial consequence of delaying not doing the work? (are any key relationships negatively impacted by not doing this?)
How many existing customers benefit? (measure of ‘churn-protection’)
Is there a ‘JFDI’ factor involved? (this is always a controversial one!)
Does it drive future acquisition / awareness / channel?
Start with the feature you know most about as the score for that question is likely to be the most accurate and then score the other features relative to the one you started with. Using the Fibonacci Sequence (1,2,3,5,8,13,21 etc) allows you to recognise the higher value and uncertainty that comes with more complex problems/opportunities.
4. Now divide the total score for each feature by the T-shirt size and sort the
rows/columns from smallest to largest. The feature with the highest score is the feature
you should build first.
There are a couple of things to take note of when using this method:
The model favours small bits of work, which is not a bad thing. It encourages feature sponsors to focus on the smallest possible piece of work they can do (MVP) and strip out any/all superfluous noise
The model only gives you a relative ranking between features. It is not in itself a ‘business case’. Put another way, just because a given feature has floated to the top of the pile does not mean you should dive straight in and build it
As a Product Manager, if you use this framework religiously as the basis for your fortnightly prioritisation meeting you will not go too far wrong. Sure, you’ll frustrate the life out of some people who hate frameworks and just want to get stuck in, but in the end you will start making better, more aligned decisions and the business will thank you for it.
How do you put a value on a feature?
If you’ve followed the above, then you should now be sitting on a list of agreed prioritised features and be feeling pretty good about yourself.
But the question ‘should you actually build it?’ still isn’t answered. Relative to the other options on the table, absolutely, but relative to the actual real ($)cost of building it, the answer isn’t so obvious…
Remember, as the Product Manager, you own this decision. If you ‘commission’ a feature and it doesn’t deliver what you said it was going to deliver, then your life is going to get very uncomfortable very quickly. Welcome to Product Management!
So, what do you do? Well, at this point you need the help of your CFO and you need to answer a very specific question:
‘How many additional subscriptions do we need to sell for this to be something worth investing in?’
This is different to the question the business really wants to know (‘how many extra subs do you think you will sell as a result of building this feature?’). There is no crystal ball, no one actually knows how many you are going to sell, so it’s an unreasonable question and you should push back on anyone that asks it.
To answer the question ‘how many do I need to sell?” you need to understand two things:
How much is it really going to cost to build it (this number is invariably bigger than you think it is, but that’s a topic for another blog)
What your company discount rate is (or what return the business needs to make on its money to keep investors happy).
The discount rate for a company that is loss-making is likely to be different to the discount rate used for profitable businesses. For an unprofitable business 25% is a good benchmark.
Next you need to apply some excel wizardry to calculate exactly how many incremental subs you need to make to make in the next 12 months to actually make the thing worth developing…. This gives you a single number (X)
Then the interesting, meaty conversation takes place. Marketing, Sales, Customer Success get in a room with the Exec, look each other in the eye and answer the question together ‘Will it deliver at least X?’ And then everyone is complicit in the decision…. If there’s any doubt that it won’t deliver X then it’s back to the drawing board.
Of course, everyone hopes and expects it will deliver more than the minimum required to make it worth doing. No one goes in expecting it to do the bare minimum necessary, but given all of the vagaries, risks and unknowns involved, it’s the only rational way to look at investment decisions.
How do you get big bits of work prioritised?
If you’ve followed all of this so far and you’re going through the process, then there’s a chance you’ve discovered a flaw in the plan.
The Product Management prioritisation framework we’ve discussed so far is a really effective and efficient way of prioritising one feature against another, but the model – by definition - favours small bits of work and penalises big bits. So, if every bit of work is small, and you can’t break a big project down into small bits, how do you get big bits of work done?
Invariably organisations have lots of competing dev priorities and they need to solve different problems in parallel. It’s common to see businesses trying to simultaneously prioritise and deliver:
features the market wants
Performance / scalability / security related projects
Large ‘strategic’ initiatives
Technical debt / re-platforming problems etc
Internal system fixes
Trying to prioritise these requirements using the same framework is doomed to failure, so smart organisations get themselves some buckets…
They use buckets to allocate their development resources (at a team level) to different categories of work before they start thinking about what work is actually going to get done inside the bucket. By doing this they ensure they get horizontal and vertical coverage across the different areas.
This model introduces a different, equally hard ‘strategic’ question: ‘how big should each bucket be?’ There are no hard-and-fast rules here and every business is different, however there is a high likelihood that most businesses will have a roadmap of stuff spread across multiple categories and will benefit by thinking this way.
Start by listing-out the different categories of work that you NEED to do and allocate your team resources equally across them (equal sized buckets). Next, start to change the size of the buckets to reflect your reality, but just make sure you don’t end up with so little resource allocated to any single bucket that nothing meaningful will ever get delivered. You can always change the allocations every few months to reflect changes in your position/the market. A good example of how/why this works is the delivery of a new mobile app.
Mobile apps have a shelf life of about 4 years - maybe 5 - before they start to look old and clunky and need to be rebuilt. But rebuilding a mobile app is a BIG project. If you look at a mobile re-build through the feature delivery prioritisation model described above it will never get done, as it’s just too big. The ONLY way to get a mobile rebuild prioritised is to deliver it out of a different bucket, where the rules are different. In this case, our ‘strategic initiative’ bucket.
Obviously, the more teams you have the easier this model is to run. Big organisations have whole teams dedicated to buckets year-round, but it’s still possible to use the technique where there’s only one or two dev teams to work with – it just involves context switching.
So, to come back to our original question, ‘how do I get big bits of work prioritised’ the answer is to get some new buckets!