Got trapped in featuritis

From a product management point of view, during my roller coaster experience as a co-founder of an e-commerce solution, one of my biggest learnings was to understand, how to define in general and simple terms: what comes next.

It’s not new to say that in a small collaborative environment, where role definitions are vague, wearing multiple hats becomes part of the deal. This was the main reason that forced us, engineers, to learn about other areas, such as marketing, product, and sales, just to name a few.

With domain expertise that abstract feeling of defining the future took the shape of what's known as a road map, vision, and strategy. But as first-time creators, we didn't know much terminology or the different alternatives around shaping the future of a product.

Anyhow, the story I would like to share today started way before we came to that conclusion. At the beginning of our journey, while trying to find the market fit, we made one of the most common mistakes and misunderstood the meaning of putting the focus into delivering. Centering on building new things for the sake of creating something competitive or innovative just to not fall behind our competitors.

The problem has a name

My experience in product companies gave me the sense and taught me the importance of why there's usually a whole department dedicated to the management of the product, and why priorities and alternatives need to be on the roadmap before jumping into execution mode.

It was while reading a book called The Design of Everyday Things that I came to the conclusion that our mistake had a name. Far from feeling comforted by this, it helped me understand the underlying problems this has and how to prevent falling into this trap again.

Directly from the book:

The term is dated back to 1976, but the phenomenon likely existed before this date. You hear customers asking for features, competitors launching new features, and new technologies emerging you think you must jump on to make your product cutting edge… but once these forces convince you to impulsively add the feature, once the excitement has waned and the feature is no longer shiny, you can’t remove it.

In the frantic pace of development, we neglected the core principles of product management—understanding user needs and problem-solving. The book's insight into featuritis resonated deeply with our situation. We had unknowingly fallen into the trap of perpetual feature additions without considering their impact.

Looking back to this story, if I were to bet on the root cause, I believe it was that we, as engineers, lacked perspective about the whole spectrum. We were enthusiastic and fully motivated, accelerating the delivery of new things without many purposes, migrating to newer technologies, and adding features and improvements we thought were cool.

Obviously, no one was advising us on what to do and what not to do, which felt like an enjoyable dangerous freedom, and was difficult not to fall into the temptation to push new functionality all around.

Putting all this evidence together, in my own words, we basically invested too much capacity in things that had no impact. We didn't validate the need for what we thought in advance was a great idea. As you can imagine, when you have a lower capacity of resources and money, the risks and the price you pay due to bad decisions are higher.

This is by far the biggest learning I took from that experience, and in a smaller proportion, the power of iteration, user research, and experimentation, among other things. And how those steps can save us from investing time in solutions that have no problem linked.

Develop your own framework

Although we came late to the party to combat featuritis, we created a simple yet effective matrix. By measuring user impact against time complexity, we could prioritize tasks effectively. High-impact, low-complexity tasks took precedence, ensuring that our efforts were channeled into meaningful solutions. As simple as it sounds, it helped to have a “metric” on which we could rely on. Easily spotting tasks or ideas to discard that were too complex and/or with no expected impact.

This process not only helped with the sorting but also the conversations during that time, ensuring we were not making many assumptions on the go, that we were able to measure the user impact, and, most importantly, ensuring we were solving a problem and not creating a solution for a non-existent problem.

As the book says, featuritis is a disease difficult to eradicate and impossible to vaccinate against. It’s easy to fall into the trap and insist upon the addition of new features, but there is no process or budget to get rid of the unneeded ones.

There is no way that a product can remain understandable by the time it has all those special-purpose features added over time.

When two companies make their products exactly the same to compete, customers don't have a reason to choose one over the other. This approach, based solely on competition, can be harmful and make you lose perspective. Some companies fail because they focus on copying others instead of improving their own product, or what makes them unique.

Scoped experimentation

In terms of prevention, from a technical perspective, there's a lot we can do to avoid being driven by assumptions.

There are cases where data-driven decisions will not be possible. So we have to be creative in finding those channels or sources from which we can get qualitative and quantitative data.

One of the main resources in this regard is scoped experimentation, which is definitely another activity I incorporated into my set of common practices. It brings a lot of perspective and helps to prevent a product/software from evolving into a monster.

There are times when we have to experiment with a potential solution to a defined problem, times when the data we have is not enough, and A/B testing is needed (just to name one example) to validate our hypothesis.

Within this context, shortcuts are allowed, as the main purpose is to gather data, to better understand where our proposed solution stands. Abstracting this problem and isolating it from the main business logic core will help us keep things decoupled in case there are no iterations needed.

Once the validation is over, we can better decide where it's worth making that part of our code solution or iteration, or if this makes no sense, we can just easily remove it. This is where the decoupling of the experiment pays off.

A path to a healthier product development

Featuritis is a common ailment in the world of product development. However, by understanding its pitfalls and adopting practices like scoped experimentation and prioritization matrices, we can navigate the complexities of product design. It’s essential to focus on solving real problems and avoiding unnecessary feature additions.

Remember, the key lies in iterative development, user-centric approaches, and a relentless commitment to understanding your users' needs. By avoiding the trap of featuritis, we can pave the way for strategic, user-focused, and impactful product development.