Prioritizing Product Features in Startups
How difficult is it to choose what to be build?
Intro
Once your team grows beyond 3 engineers, the idea bank starts to grow. How do you prioritize features when that happens?
I’ve witnessed the growth from 3-4 engineers, to 10+ full-time members [developers, designers, product] in two companies. And while it might not seem like a big change in terms of numbers, in reality, it really is.
Everyone now starts to think about possible features, even possible new apps or business models.
Now, how do you start prioritizing all this?
Factors
There are some factors that need to be considered, perhaps before even thinking about using any prioritization framework or techniques.
Company Goals
How does this specific new feature align with the company goals?
Sometimes frameworks such as OKRs (Objectives and Key Results) can easily define and outline the company goals. If those are already outlined by your company, you should definitely check the feature against those goals.
Intuition vs. Data
Is there data supporting the development of this feature? Do we know how far-reaching it will be? Or how much need there is for it?
Or is the driver behind its development mainly using intuition?
Is this feature contributing to improving the North Star metric of the company?
Some ideas may seem shiny and interesting, but they don’t contribute to the North Star at all and have no data backing them up.
Resource Allocation
How many team members are needed for this feature from the different functions, and how many are actually available or will be available by the time they’re needed?
Are the right team members for the feature going to be available soon?
It can be a top-priority feature, but it would block the entire team or its key members. It’s not always possible to allow that to happen if there are many small but critical bugs that also need to be addressed.
Stakeholder Buy-In
Are the key stakeholders outside the product and engineering teams aligned on this? Do they see value in what you’re planning to build, and are planning to use it/market for it?
If you’re developing a tool for marketing and they’re against using it, that means you’re throwing engineering efforts into the trash. The feature will simply not be used.
Tools that help
Here are some tools that help make easier/better prioritization decisions.
User Feedback
If there’s explicit user feedback, whether that’s from in-app surveys, or from interviews, then definitely utilize that.
Sometimes the users can’t articulate the best solution, but they can surely help show you the real problems that your new features need to solve.
Prototyping / Reverse Demos
Rather than building the full feature, it takes less time to create a basic interactive prototype for it and demo it to a key stakeholder or a group of users.
A reverse demo is when the user is trying your feature themselves, rather than you showing the demo. It’s useful to see if there is anything unclear or if there are usability issues.
Comparing the results of multiple prototypes can help eliminate the time that was going to be taken to build a useless/less-useful feature.
Funnel Analysis
Viewing the conversion funnel can help in identifying which screens/segments in your application need enhancements.
Simply put, this is a visualization of all the steps a user takes to convert in your app and shows the dropoff percentage at each step (percentage of users exit the app at this step and don’t continue the process).
If you have four stages for conversion for example: (Landing, Registration, Subscription, and Payment), and you identify a significant dropoff between Subscription and Payment, then perhaps your subscription terms aren’t very clear and you could use an enhancement to this area.
Session Recordings
The ability to view recordings of what your users do in the app can be pretty useful.
You’ll be able to see in real-time how users navigate your app/website, and why they take a longer time than expected in specific steps.
This is particularly useful if your target segment has very unique properties (e.g. older population).
Prioritization Frameworks
I’ll outline a couple of frameworks that can be used to prioritize features.
RICE
It’s an acronym for: Reach - Impact - Confidence - Effort.
It was initially implemented by Intercom and uses numerical factors to give a score for each feature that is being considered for development.
What is meant by each term?
Reach: How many users will be impacted by this feature? The hypothesis is that the more users will be affected, the higher the priority of the feature.
Impact: What is the effect of the feature on the users it will reach? The hypothesis is that the more impactful a feature is, the higher the priority of the feature. It’s usually chosen as a factor from this numerical scale [.25, .5, 1, 2, 3].
Confidence: How sure are you about your estimations of this feature’s reach/impact? Are they more intuition-based or data-based? It’s usually chosen as a factor from this scale [50%, 80%, 100%].
Effort: the number of person-months this feature will take to develop. The hypothesis is that if two features share similar Reach/Impact/Confidence, you should build the one with less effort needed.
Then the final calculation is simply:
(Reach * Impact * Confidence) / Effort
You do this for every feature you’re trying to prioritize, and usually, you select the highest scores.
Shape Up
This is not really a prioritization framework per se, rather it is a set of tools that can assist with product development. It was started in Basecamp.
It’s a process that’s split into Shaping/Betting/Building stages.
Shaping is the step closest to product discovery. Trying to identify everything that can be built, refining it, and documenting it in order to be ready for the next step.
Betting is where the prioritization decision is reached. It is simply a betting table, where every key stakeholder/decision-maker joins, and they make bets on the features resulting from the shaping stage. The feature that will be developed is the one with the most bets and with the highest seniority of voters choosing it.
Building is a 6-week cycle of developing features/apps that were chosen in the betting stages.
What’s also interesting about Shape Up is that there are no backlogs (yes, no countless hours of grooming). The hypothesis is that if a feature is important enough, it’ll keep showing up in the shaping/betting cycles and will eventually be chosen for development.
Other Frameworks
MoSCoW: divides features into [must have, should have, could have, won’t have].
Kano: Features are assessed based on how much they affect user satisfaction (for example: must-be features are the ones that need to be developed, while attractive features are ones for delighting users)
How I’ve done it before
Now when it came to what I actually tried, it was less formal than what was mentioned above.
Objectives
We mainly focused on features that related to our two main objectives (increase weekly acquisition / reduce churn).
You might think that all features would’ve been related to those two objectives, but given that we had an internal back-office, and while we did add features to it, we didn’t focus on delighting the internal users. Most of our attention was on the customers. Sometimes I wonder if that was a mistake.
Difficulty vs. Priority
Similar to Effort vs. Impact in RICE.
Our definition of Priority varied often though, which is why using a framework might’ve helped. We did consider using a framework at some point, but the backlog was quite large and we felt it wasn’t really feasible.
“Difficulty” was divided in our case into:
Trivial: single/few-line code changes, such as changing the text in a button or banner.
Easy: simple modifications that should take an hour or two, such as adding filters or a small logical change.
Medium: a feature that might take a day or two.
Difficult: a big feature that would take a full week of work. A new non-trivial external API integration for example.
Major (max 2 weeks): usually an epic that needs to be broken down into other tasks
While “Priority” was mainly divided into:
P0 (most often defined as a blocker and needs to be done ASAP - usually a bug)
P1 (most features were assigned here)
P2 (less important items that were rarely ever done)
This helped us easily identify quick wins or easy blockers that needed to be implemented right away, and also ignore time-sinks that would take too much time with low priority or impact.
Other Factors
Availability of Engineers: Sometimes an important feature would wait, even with an available engineer, because the best person for the job is occupied at the moment. It was a tradeoff between getting something done quickly and with quality, and also between introducing engineers to areas they haven’t worked in before.
HiPPO: Sometimes you simply need to address the opinion of the highest-paid person in the room. Even if you reject the idea, you need to take note of the problem it was solving and work on it at some point (soon).
Addressing Bugs: Sometimes we had a heavy load of fixing issues, especially if we had a faulty production release. This meant fewer new features to be developed for a while.
Verdict
Our approach could’ve been done better. Discarding tasks that were never going to be done, estimating impact and reach, and developing final user personas were all things that could’ve helped us.
Points to note
Pivoting
It’s critical to allow room for pivoting and changing direction, especially in the early days of just a few employees.
Not doing so means you’re stuck with a hypothesis that might’ve already been proven wrong, and you’re inflexible to change it.
It’s okay (and expected), to change direction often early on.
Backlog Maintenance (Backlog Grooming)
Maintaining a backlog was tricky and is more work than it seems.
ShapeUp for example doesn’t keep backlogs to eliminate the hassle.
The way I see it though, it is still valuable:
When teams start to get idle, to have a queue for what needs to be done.
As not to miss any important feedback that was too difficult to start working on right away
Final Words
Deciding what to build seems easy on the outside.
With a good framework and solid process, it can be. But it’s a process that needs continuous adjustment as the size of the company grows.
Feel free to share how you do prioritization at your company!