Deciding which features to build and how to prioritize them
Many startups or product teams often struggle with the decision which features to build and how to prioritize which features to build first. Others often think they need to add more features to build better products, while sometimes the opposite would be more beneficial.
Adding the right features can improve your product exponentially, adding the wrong ones can make your product to a feature cemetery, adding too many will dilute the perception of your product in your customers’ mind. It’s more than important to think of which features should be built and which of them should be prioritized.
In the past I have worked in many different product teams and there’s no real one-fits-it-all approach on how this decision and prioritization process should be done. There are some starting points though which helped me to make decisions easier. A while ago I started to draft a list of questions I try to answer before implementing new features:
- Is it something which is relevant to many users or just a few? (User Relevance)
When talking to customers, you often get the feeling that their problem is something other users encounter as well, while in reality this problem might only effect a subset of users. Features add complexity and therefore should be worth adding it. The more users it effects, the more important it is. - How often will it be used? (Usage frequency)
Same as relevance goes for usage frequency of features. It’s worth thinking of how often this feature will be used. Is it something users use on a hourly, daily, weekly, monthly basis? Maybe even less?
Usually we want to spend most of our resources building features which are use by most of the users for most of the time.
🛈 Des Traynor from Intercom wrote a great piece about Prioritizing Features. - Can it be communicated? (Communication)
When adding features we want to communicate them to our users. There are features with high impact and features with lower impact. High impact features are something you often can build a story around them. Ask yourself, is it something you can tweet about or even write a blog post about it? Maybe this is something even publications or magazines are interested in? - Does it strengthen your position in the market? (Positioning)
Every new feature should be a step supporting the mission you are working on. It’s worth to think about how adding this new feature can help communicating what you are working on and how it strengthen the position of your product in the market. Adding too many features, especially those not directly supporting your vision, can lead to a diluted perception of what people think about your product. This often opens up opportunities for competitors who have less features but a very clear market communication. - Does it give super powers to users? (Value)
A super power is something which has a high positive impact in the user’s workflow. It’s something users can do with this new feature they couldn’t do before or where a workaround was needed. Similar questions could be “Can we make other tools they are currently using obsolete?” or “Does it improve efficiency?”. - Does it reduce or increase complexity? (Low Complexity)
Not every feature you add makes your product easier to use. Some may add more complexity, some reduce complexity. A good way to explore this is to think of the kind of users who can use this. Is this something for power users or something new users can use straight away? - Is there a workaround we can suggest our customers with our current feature set? (Substitutable)
When talking to customers they describe problems they have with your product and sometimes even suggest features they need. Sometimes it’s just a workflow issue and it’s enough to suggest them a slightly different workflow which solves their problem with your current feature set. Even though that might add more complexity in their workflow, it could be a good trade-off for features which are used less frequently or by the minority of users. - How easy or difficult is it to implement it? (Low Implementation Effort)
New features can sometimes be low hanging fruits in terms of time and resources needed for the implementation, sometimes it needs a lot of resources. High resource features should be planned carefully and it’s worth exploring low resource alternatives to test the usage frequency and user relevance of these features. - Does this feature help us grow? (Growth potential)
“Helping us grow” is kind of a fuzzy description, but it’s worth thinking of how adding this feature can effect your growth. This can be various things, like removing friction for users who want to switch from a competitor’s product, adding support for a 3rd party platform (e.g. Slack) to benefit from their distribution ecosystem or just something which makes it easier to refer your product or invite other people to use it.
This list can be seen as a continuous process rather than a fixed set of questions, going through them during decision processes usually helps me to get a better sense of what to build and how to prioritize it.
I created a simple Google Sheet to make this process more feasible. Each feature is represented as row, each question as column. For every cell a value between 0 and 5 can be chosen, defining 0 as not valuable and 5 as most valuable. Each feature ends up with a score between 0 and 45, the higher the score, the more you should implement it.
What is your process in deciding which features to build? Which questions do you ask yourself or your customers?
I send out new articles and updates on my personal mailing list and on Messenger. I’m also on Twitter.
