Building the wrong product — 9

antipatterns you should avoid

Marcus Castenfors
Feb 11

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

1. You relied on gut-feeling

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

2. There was a lack of psychological safety

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

3. You didn’t validate with customers prior to launch

“- 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

4. You had confirmation bias

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

5. You only had one core concept

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
6. You were in a time crunch

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.

7. You focused on output rather than an outcome

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

8. You listened to a vocal high-profile customer

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

9. Only a few team members were involved in Product Discovery

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.

 UX
 Product Management
 Product Discovery


Marcus Castenfors

Product Discovery Coach at Crisp. Previously @SR_ and @nordnet