Share this article

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

How to Build Great Products by Focusing on the Right Features


Our article has been originally published on DevPro Journal here. Here are its highlights.

Anaxi is my third startup, and you think I would have learned from the previous startups, but I do have to admit that some old habits resurface from time to time. For instance, at very early stage, there are often a LOT of product feature ideas. How many “Oh we should do this differently!” moments can there be in a single month? Let me tell you from my experience…a lot!

The problem is that it’s not possible to keep changing things or you won’t actually move forward. You run the risk that the team will get fed up, for good reasons, ditching work. So in my experience, I resisted the temptation to change things a lot for this reason. But, naturally, I would keep thinking about the same idea and wonder if we should do it or not. And that was wasting a part of my mental energy. So I needed a product feature selection process to handle this. This article is about this process.

1- Ensure you have the right culture to debate ideas internally

As mentioned, if your team perceives that you bring new feature ideas every week, they might think that you lack focus and that you will be a liability to the product feature selection process. Indeed, you don’t want to be perceived as bringing new ideas that can be thought of as synonymous with wanting to change things that may have been developed just a few days ago. And there is nothing more frustrating for developers than ditching their own work for “make work” like this.

However, you still need to bring new ideas in. You can’t afford to be impervious to new ideas or you will most probably end up with a mediocre product. So how do you manage this?

It’s all about the culture and the process. First, anybody should be able to bring in a new idea. It’s not the product manager’s privilege to do so. The team will be more open to ideas if those can come from within the team, as well.

Then you need a pragmatic product feature selection process to handle those ideas. It is important that this process applies to all ideas, whomever they are coming from. Let’s dive in.

2- Always go back to the problem and its root cause

The first and most important question you need to ask yourself is which problem are you trying to solve for your users with this new feature. If you’re not solving a problem, think again about your idea. You want to avoid feature creep which will make your product harder to understand.

If you work in product, marketing or growth, you need to be seeking the truth, the root cause, not symptoms. The right understanding of things is necessary for the foundation of a great product. One way of doing this is asking the 5 Whys, a very common and popular framework, and for good reason.

3- Consider the positioning and messaging value for specific audiences

In some cases, some features are not addressing a problem but can actually help to strengthen a positioning or messaging. This part is most often neglected by product teams, because it falls more under marketing than under product per se. But there could be great value in a feature if it enables improving your positioning and messaging towards an interesting audience that you’re targeting. Some would say you need to think about the benefits for the users and how to present them.

Considering the messaging and positioning for specific audiences helps you stay one step ahead and better understand the value the particular feature can bring.

Of course, in that case, you need to go back to the second point and verify your assumption and seek the truth about this new messaging and positioning.

What do you do next?

4- Verify your assumption

This can come as obvious for product managers. So I won’t spend much time on it. You can verify this through qualitative measures, such as user interviews and usability testing, or through quantitative indicators (usage metrics, survey, etc).

Just beware of two things:

  • Treat survey results with caution. They are only declarative data, and that doesn’t mean that the polled people would actually act on what they say.
  • Focus groups can introduce bias towards the person who speaks the loudest (I personally don’t use them for this reason)

I tend to prefer having both types of indicators, qualitative and quantitative, as qualitative data can help you understand the why of the quantitative ones.

5- When you verify, focus on your high-intent audience

While you’re validating your problem, you may have different results according to the audience you focus on. It’s very important that you focus on high-intent audience at that moment.

Just a little note: what does high-intent audience mean? It is an audience that has a pain point that you are solving, but that has also some high intention to get it solved. It is an audience willing to do something about this pain point, and that will move through your marketing funnel from the top to the bottom.

Indeed, what is important is to solve the problem for people who actually have the pain point you are intending to resolve. If you focus on a low-intent audience, you will be building a product that has diluted added value for everyone and that won’t make enough of a difference to be interesting to anyone. Remember that the product-market fit is described in most models by the percentage of your users that would be very disappointed if your product didn’t exist anymore. We don’t care about the other users, for this precise reason. There is no market for your product if nobody cares enough about it.

Is there anything else to consider?

6- If not sure, use the test of time

What is the test of time? It is giving you time, not to think actively about it, but rather to log off from the problem. The goal is to take a step back. All the more if you are doing things right…

That is talking to your customers and prospects very often – hopefully, you know the concept of customer development. This way, you will learn new things on a daily basis, and possibly things related to the root cause of the problem that you wanted to address initially.

The test of time helps you better focus on what actually matters and what will actually make a difference.

In summary

Here are a few bullet points that could summarize this product feature selection process. If we could have this in every article, that would help! So I’m going to practice what I preach for once.

  • Build a culture that accepts and welcomes new feature ideas. And set up a process that doesn’t consider who these ideas come from.
  • When considering a feature, first go back to the problem you are trying to solve, and its root cause. Don’t hesitate to use the 5-whys framework for this.
  • Consider the messaging / positioning value of your feature, and for which audience it is targeted.
  • Use qualitative measures (typically, user interviews – I’m personally not fond of focus groups, because the results will be the personal opinions of whoever speaks the loudest) and quantitative indicators (metrics, surveys, but beware of declarative metrics that are not the same as actual usage metrics) to verify your point about the problem or the new messaging/positioning.
  • Focus on verifying your assumptions for your high-intent audience, otherwise you might have some misleading results.
  • If the idea is still debatable, use the test of time to take a step back, get some new perspectives with the things you learn every day.

Obviously, when you have selected the features you need to work on, you also need to consider feasibility and time needed to develop, in order to prioritize properly. But there are a lot of articles on this topic so I won’t go into that here. Let me know your perspective on this pragmatic product feature selection process. Do you feel I’m missing some important point?

6 min​ read

Subscribe to our newsletter Weekly Bytes to get our curation of the top 5 articles of the week.

Subscribe to our newsletter Weekly Bytes to get our curation of the top 5 articles of the week.

Need visibility in your software development lifecycle?