CEE: A Framework For Priotising & Developing Features
A product, and by extension business is nothing without its features so it’s a ripe area for scrutinising how you invest time and resources in developing them. I’ve been building high-value digital products for over 20 years at companies like Yahoo, BBC and a handful of startups so I feel I’ve got a good feel for impactful and efficient product delivery.
Whilst there’s a lot of talk about strategy in succeeding via product-led growth, there are still the tactics required to launch individual features.
It really boils down to running through 3 steps for delivering successful features:
- Collect (requirements, feedback, thoughts, metrics)
- Experiment (mockups, prototype, deploy features, add metrics for success)
- Establish (refine, fix bugs, document, train, communicate)
1. Collect
If you observe how features are already being developed today, they don’t just magically appear in your backlog — they have origin stories and forces that carry them forward.
The two origins I see:
- Customer requests
- Stakeholder requests
Customer originated requests
The best chance of a successful feature is one driven by the customer as there’s prior validation of the demand. The risk you’re faced with here is taking customer requests too literally and releasing a sub-optimal solution.
“If I had asked people what they wanted, they would have said faster horses.” — Maybe Henry Ford
It’s useful to use the Jobs To Be Done framework in prizing out what problem a customer is trying to solve and then work from first principles to translate their request into a feature spec.
Stakeholder originated requests
The stakeholder requests come with an eclectic set of angles, some more dangerous than others. Here are some examples of internal requests:
- Someone on the team wants to appear clever so confabulate a theoretically useful feature (main danger)
- Tech leader wants to improve infrastructure or pay off technical debt
- Sales team members are getting recurring signals from prospective customers of missing features that are preventing conversions
- A product manager has done user research in a particular area and synthesised findings down into a set of features.
It’s fairly obvious that all except the first are valid and valuable feature sources. Handling whimsical feature suggestions requires a considered approach and effort so as not to demoralise or deter future suggestions. If a stakeholder suggests a feature and is persistent about it, they should demonstrate some skin in the game to move it forward, e.g. assign some budget or add personal involvement to get it delivered. If you become a “yes man” to whimsical requests, you’ll find yourself chasing your tail and not delivering true value. Get good at learning various ways of saying no.
Evaluating a feature
Now, let’s say you’ve decided to focus on taking a feature through your product development pipeline; before you get underway scoping out and working on the feature, you need to consider:
- How broadly applicable is this request to other users? If not broad, how can you make it broader for a better return on investment?
- What’s the business upside of adding this? E.g. additional revenue, greater moat, unlocking new customers
- What risks would it impose? E.g. security implications, churn risk, added bloat and complexity
- What’s the smallest amount of work required to get this functionality?
For a more formal process, use the RICE framework to help you determine prioritisation.
Muse over the smallest amount of work part most as it’s surprising how you can use parts of what you’ve already got or off-the-shelf SaaS offerings with small tweaks to make it suitable. At this stage, it’s all about validating that you‘re solving a problem.
2. Experiment
When you’ve picked up a feature to work on, you need to remind yourself that it’s an unproven experiment so you can’t get too wed to the implementation.
You should be working from the cheapest execution possible:
- Customer discovery interview over speculative feature delivery
- Wireframes over designs
- Designs over code
- Prototype over fully coded features
- Limit the scope of features and rapidly release in small batches
Part of this experimental phase is pushing out ideas as rapidly as possible and monitoring all signals and metrics that give you validation that you’re on the right track. Signals can be as subtle as getting apathetic responses when demonstrating work, indicating that you’re off the mark.
We don’t do A/B tests. We validate ideas and assumptions that are driven by taste and opinions, rather than the other way around where tests drive decisions — How Linear Builds Product
Be careful with studying metrics at this point as you can quickly fall into the analysis paralysis trap.
Get feedback from customers as soon as possible. When a new feature is released, reach out to those who expressed interest to make them aware of it and ask for candid feedback. This keeps the context fresh in your mind to react with urgency.
Send out product announcement emails regularly. We’d like to think that customers will discover and understand all the changes we ship but they’re busy and follow a routine of using the features they’re familiar with.
The scientific method of an experiment is useful in making decisions. You should have an upfront gauge of what a success threshold looks like for a new feature. When the new feature has had a chance to bed in, evaluate whether it has met or surpassed expectations. If not, be ruthless in culling the feature or going back to the drawing board. Avoid the sunk cost fallacy.
3. Establish
You’ve found a feature that’s clearly proven to be valuable for customers and the business alike. Rather than moving on to the next feature and leaving behind a trail of half-finished work, it’s worth shoring up the feature.
As you’ve been sprinting to get an MVP validated, you’ve cut some corners, introduced some tech debt and neglected to add documentation.
Take some time to write documentation in the form of articles and tours to enable product-led growth and self-serve support, freeing up customer service bandwidth.
Add unit tests and end-to-end tests to ensure additional changes to the platform don’t break any prior work.
Add some scope to the feature to move from Minimum Viable Product to Minimum Lovable Product.
To summarise; when considering work on any new feature;
- Collect evidence about what and why you’re building it
- Experiment with delivering the smallest amount of work to validate the value of the feature
- Establish proven features to serve as the foundation for future growth
If you can keep to this cycle over a sustained period you’ll see compounding returns and a more healthy product.
If you’re facing issues with delivering features and this framework doesn’t help, let me know so I can bolster the details.
