Releasing new features nobody cares about

How’s your experience releasing new features? Maybe it’s hit or miss. Unfortunately, many teams fall into the trap of becoming feature factories. In his book, David Pereira, a Product Coach and Author, helps teams overcome these dangerous traps and build products that customers truly love.

Below is a short excerpt from his book on releasing features that nobody cares about. If you like what you read, you can check out the full book here.

After months of hard work and exhaustive coordination, the product team finally releases a new feature. Everyone on the team and in the business loves it. The new shiny feature is ready for customers, but something unexpected happens. Customers who interact with the new feature don’t understand its purpose and cannot benefit from it. Confused, customers reject the shiny new feature beloved by business stakeholders, and inevitably, everyone becomes frustrated.

Creating solutions companies love but customers couldn’t care less about isn’t why product teams exist. Yet, that happens more often than it should. I call it a bug, not a feature. As with all critical bugs, it requires a hotfix. 

If the feature factory is a bug, what would fix that? You cannot expect a simple fix, but fostering empowered teams with collaborative flows will transform the situation. Marty Cagan, SVPG Partner, defines empowered teams as: 

 "Great teams are comprised of ordinary people that are empowered and inspired. They are empowered to solve hard problems in ways their customers love, yet work for their business. They are inspired with ideas and techniques for quickly evaluating those ideas to discover solutions that work: they are valuable, usable, feasible, and viable."

Empowered teams have significantly higher chances than feature factory teams to create value. Yet, enabling empowered teams isn’t trivial. For now, let’s focus on the collaboration challenges.

Over the years, I’ve noticed two standard product development flows across companies regardless of their framework:

1. Coordinative Flow: Team members spend significant time coordinating activities among themselves, stakeholders, and other teams. Most of their energy goes into organizing how to get the work done. This approach aims to avoid mistakes and failures, forcing teams to be rigid with their development flow. It becomes a “strict” contract because someone gets the blame when something goes wrong.

2. Collaborative Flow: Team members focus on collaborating to use their current knowledge to uncover promising opportunities. The ultimate goal is to create value for customers and the business. The team is flexible with how they get the job done while focusing on driving value. Trust is the basis for the collaborative approach. When something derails, the team takes responsibility and jointly finds a solution.

How do you transform an idea into something valuable? That’s one of the most important questions for companies. A poor answer leads to waste and demotivation. 

1. Prioritization: The coordinative flow starts with prioritization, aiming to find the most promising idea. However, that’s easier said than done because several discussion rounds will occur. When you say yes to an idea, you’re saying no to numerous others, and almost no business stakeholder accepts that answer easily

2. Design: The design phase starts once you define what the team will work on. The result is often a highfidelity prototype that business stakeholders approve. This approach is dangerous because software engineers and customers tend to be left out of it. Sadly, the solution becomes the focus, not the outcome.

3. User Test: After much coordination, business stakeholders finally approve the design, and it’s time to test it with potential customers. The results are probably compromised because everyone already loves the solution. Sadly, falling prey to confirmation bias isn’t the exception but rather the typical outcome. Given their passion for the solution, product designers search for positive signs—and unsurprisingly, they find them. They may accept minor solution tweaks, but no solution pivot or drop will happen in this phase.

4. Develop: After product designers confirm the high-fidelity prototype makes sense to end users, it’s time to develop the solution. Product designers throw the specs over the fence and hope software engineers do the job right. Of course, software engineers aren’t likely to welcome the solution with wide-open arms because they weren’t part of the previous steps. Even so, it becomes their job to transform the high-fidelity prototype into a working solution.

5. Launch: Given the amount of coordination needed, it takes months to transform an idea into a solution. You shouldn’t be surprised when something takes half a year. Each phase is strictly defined and has many steps to ensure a perfect solution by the end of it. Yet, something unexpected happens when you launch the solution. Despite all of the internal enthusiasm and love for the newest fancy solution, customers don’t engage with it—and you have no idea why.

What shocks me isn’t winding up in this tragic situation. I ended there more times than I can count, but I learned my lesson. The question is, what do you do after you face an undesired outcome? The most common answer makes little sense to me. Go back to prioritization, pick another idea, and do it all over again. When you follow the same approach, chances are high that you will face the same results again. The coordinative flow forces teams to focus on outputs over outcomes, diminishing them to feature factories.

Our success rate is worse than we can imagine. Look at start-ups. Ninety percent of them don’t last more than five years. Ideas suffer much the same fate. Curiously, that goes unnoticed as teams invest much time figuring out how to reduce development time. I see value in this matter, though I perceive another question as more pressing: How fast can you drop bad ideas? We assume our ideas are good, but reality shows us otherwise. Yet, we insist on following the same approach repeatedly. No wonder we face undesired results.

Sound product management requires adapting based on learning. It’s fine to get things wrong. It’s not fine to ignore reality. Collaboration over coordination is the principle that can get you out of this trap. Instead of making your development flow rigid and complex, you will benefit by making it simple and flexible. Let’s explore a different way of working that increases the odds of driving value faster.

Nobody deserves to waste time. After many years on the road, I learned that failures are inevitable. Instead of adding steps to prevent failures, identifying and quickly dropping flawed ideas makes more sense. Unlike the coordinative flow, the collaborative flow focuses on iterations instead of phases. 

Steps of a collaborative flow

1. Evaluate: The beginning of a collaborative flow is the same as for a coordinative flow. You’ve got plenty of ideas, and everyone wants everything done by yesterday. The trick isn’t to identify the most promising ideas upfront, but rather to evaluate all of them and drop the misfitting ones. Dropping ideas gives you freedom because you’ve got fewer expectations to manage.

2. Learn: The learning iteration starts with ideas fitting your strategy, but that doesn’t mean jumping straight to implementation. You should drop ideas your customers don’t desire, the business cannot support, you don’t have the technology to develop, or it’s unethical to pursue. Keep it simple, and ask the following questions about each remaining idea:

3. Experiment: After learning about the key aspects of your ideas, it’s time to run more robust experiments. You want to test which solutions can deliver the potential results. Exploring a few alternatives and sticking with the most promising ones is essential. It’s all too common to pick one solution and go all in with it. I discourage you from following this path, because it quickly escalates commitment. As humans, the more invested we are in something, the more willingly we invest in it.

4. Launch: Ideas that survive the experiment iteration are the prominent ones. In the previous iteration, you built to learn. Now, you build to scale. Paying the tech debt off before you make the solution available to your whole audience or jump to your next opportunity is fundamental