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 a 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 that process.

But first, let me tell you a story that happened to me in the last couple of months.

My Story: Simplifying my Product

We all know that one of the early struggles for a product is to simplify your FTUX (First-Time User Experience) or onboarding as much as you can, so you can keep the funnel conversion as high as possible until users get to your aha moment.

So, to do that, you keep thinking about your onboarding experience, but also simplifying your product. Pinterest CEO Ben Silbermann famously goes through Pinterest’s onboarding every now and then to make sure that it’s as perfect as it can be.

At Anaxi, I was convinced initially that we should have several sections, one focused on communication, one for keeping track of projects. But the current way we were doing things was to leave the choice entirely to the user, which required more understanding and effort on their part.

So, how should we handle this situation?

  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.

  1. Always go back to the problem and its root cause

The first and most important question you need to ask yourself is which problem you are 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.

In my case, I felt my answer was easy: users were having some difficulties understanding how to use the product and using it daily. But, at first, that was just a sense that I had. So I needed to confirm this problem really existed, either through metrics or usability testing, or both. I have a strong preference for both as it can shed light on the root cause of the problem. And that is an important notion — the root cause.

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 by asking the 5 Whys, a very common and popular framework, and for good reason.

  1. 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 position or message. 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.

In my case, that wasn’t the case, it wouldn’t have changed our positioning or messaging. I thought it was addressing a problem.

What do you do next?

  1. 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 a 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.

  1. 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 a 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 also has 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.

In my case, I couldn’t verify that there was actually a problem with our high-intent audience. The usability testing I did could have misled me if I were to consider all audiences, but there wasn’t actually a problem at all with my core audience.

Is there anything else to consider?

  1. 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.

In my case, I learned that communications was a view they wanted to have of their projects, not a separate section. So, in the end, my original idea wasn’t worth pursuing, even though I was so convinced about it at the beginning.

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? 

John Lafleur

John Lafleur is co-founder and COO (and developer himself) at Anaxi, which provides an application that helps software engineering teams understand the state and progress of their projects in addition to their own productivity. He co-founded three startups before becoming the CEO of CodinGame, a platform for 1 million developers who improve their coding skills through games. For the past nine years, John has been leading product and marketing teams aimed at developers and business-to-consumers.

John Lafleur

John Lafleur is co-founder and COO (and developer himself) at Anaxi, which provides an application that helps software engineering teams understand the state and progress of their projects in addition to their own productivity. He co-founded three startups before becoming the CEO of CodinGame, a platform for 1 million developers who improve their coding skills through games. For the past nine years, John has been leading product and marketing teams aimed at developers and business-to-consumers.