Building the wrong product — 9 antipatterns you should avoid

By Marcus Castenfors

Photo by SpaceX on Unsplash

It was the day after launch.

You were so excited to finally have pushed the button. You had been working hard for months and you were thrilled to show the world the fruit of your labor. And then, trouble started. Customers were unhappy, stakeholders were furious, team morale sank.

This story is not uncommon. Perhaps you have experienced it yourself? Personally, I have definitely been there. It’s not fun.

The question is: why do we end up in this type of situation? Why do we keep building the wrong products?

In this article, I have listed 9 antipatterns to building the right product — lessons that I have learned from the trenches.

Photo by John Matychuk on Unsplash

The solution that you launched wasn’t based on insights around the customers’ problems or a market opportunity. The Product Manager relied on their own gut-feeling and expertise to make decisions.

“-Steve Jobs never did any user research” —Someone with an inflated ego

Try this instead:

  • Conduct research to find problems that are worth solving for customers

The team knew that there were issues with the solution, but no one dared to speak up.

Try this instead:

  • Empower the team to be involved in every step of the product development process. Let engineers do research, let designers test the code etc. Break the silos, and foster a collaborative environment
  • Create a Working Agreement that captures expectations around collaboration and communication within the team

“- We don’t have the budget”

“- We don’t have the time”

These are common statements why testing prototypes and concepts on customers is not prioritized.

“Testing with one user early in the project is better than testing with 50 near the end.” — Steve Krug

Try this instead:

  • Create a rhythm for conducting usability testing, for instance once every two weeks. Have the mindset of always testing prototypes on real users — early and often
  • Make usability testing a spectator sport. Involve the entire team to watch how users are interacting with the solution. This will foster empathy and ground everyone on the main usability issues

You tested the solution on customers, but what you were really doing was looking for anything that would support the opinion that you already had.

Try this instead:

  • Be aware of confirmation bias and seek feedback often. Be willing to change your mind
  • Take a step back from your role and put yourself in the shoes of customers and other stakeholders

You never tested alternating ideas.

Try this instead:

  • During Product Discovery, explore multiple directions (maximum 3) for the solution. The goal is to learn and you will acquire far more knowledge if you have multiple competing concepts. This approach is more costly but you will gain more insight around the right solution to customers’ problems
  • A/B test to mitigate the risk of being wrong

Management forced you to launch because of an important market window or customer. You had to cut corners.

Try this instead:

  • Push back. If the product is not ready, don’t launch. The situation will be far more uncomfortable if you launch a crappy product compared to letting stakeholders wait a bit longer.

You fell in love with the features and the solutions, rather than the problem to solve for customers. You were thrilled that the team had delivered a boatload of stories.

Try this instead:

  • Understand your customers’ problems using research and define what metrics can measure that you have solved their problems. Focus on those metrics rather than the output of features

The customer wanted a feature that was really important to him or her.

Try this instead:

  • Customers are experts in explaining problems, not solutions. When you receive specific feature requests, use the 5 Whys to understand the root cause. If the problem is unclear, pick up the phone and interview the customer to gain more clarity

For instance, the Product Owner only worked with a Designer and didn’t involve engineers or other stakeholders outside of the core team.

Try this instead

  • Make Product Discovery a team sport. Everyone in the team should be involved in contributing. Having a collaborative approach will gel the team and use the team’s diverse expertise to create a well-rounded solution

There you have them. Perhaps, you have one to add? If you do, please write a comment.