Product growth mistakes I keep seeing

You can improve the signup funnel and bring in more users, then lose them because the product still needs work. Even a 20% improvement to that funnel won’t solve a product people don’t want to use.

Before product-market fit, there is useful work to do: find the people with the problem, understand what they need and give them a reason to come back. The work needs to match that question. A list of conversion tests may be a distraction.

The economics matter too. A cheap signup can become an expensive way to acquire someone who never returns. Look at what you spend to acquire customers who stay and, where relevant, pay. Include what it costs to serve them. That gives you a better basis for deciding whether more acquisition is worth buying.

If you’ve worked on a team that won’t build analytics, you probably won’t want to do it again. You keep arguing about what happened, whether the numbers mean what people think they mean and whether the latest release helped.

Agree what success looks like and which behaviours should lead to it. Then check that the product records those behaviours properly. Definitions, missing events and broken tracking can change the answer before anyone gets to the analysis.

Build this into the work early. You don’t need a dashboard for every possible question. You do need enough reliable information to judge the decisions you’re making.

A funnel can show you where people leave. It usually gives you several possible explanations for why. It’s easy to pick the explanation that fits the feature you already wanted to build.

Talk to customers and watch them use the product. Someone may struggle with a step because it’s confusing, because they don’t trust what happens next or because they don’t want the thing you’re asking them to do. Those call for different changes.

What people say needs questioning too. Someone telling you they like an idea gives you a place to investigate. Seeing what they actually do helps you judge whether it works. Use the conversations and the data to challenge each other.

An overall retention figure can hide a group who love the product and another who never get going. It can also change because you’re acquiring a different mix of people, even when nothing has changed within either group.

The example below uses illustrative numbers. Both signup cohorts are measured four weeks after joining. Each audience has the same retention rate in January and February; the proportion of signups from each audience changes.

Overall retention falls from 37% to 13%. That could send the team looking for a product regression, when the change in this example is who signed up. Break the numbers down by signup cohort, acquisition source, use case or customer type. Compare people at the same point in their journey, and be careful with tiny groups.

A team starts running experiments before anyone has agreed which customers it is trying to help or what success looks like. Different people have different answers, so the goals keep changing and almost any idea can sound like a priority.

You need enough agreement to make choices. Who are we serving? What are we trying to improve? What are we prepared to put aside? A metric only helps if people understand why it matters and how their work could affect it.

The strategy can change when you learn something important. Keep track of the reason for the change, though. Otherwise the team can spend months responding to new instructions without finding out whether the previous approach worked.

You can get a result on a small part of the journey while making very little difference to the business. An easy-to-test page can attract a lot of attention because the work fits neatly into an experiment.

Compare the opportunities first. How many people reach this point? What would a plausible improvement be worth? How much work would it take? Include the uncertainty in those estimates. The biggest drop-off deserves investigation, but it may be the right place for unsuitable users to leave.

Follow the effect through. A bigger basket is less useful if fewer people finish checkout. A pushier checkout may increase orders while putting people off buying again. Choose an outcome that matters and check the other things a change could damage.

Some teams keep making small changes to a product that needs a rethink. Others make a large release, move on and never improve what they shipped. Both can leave useful work undone.

A new market or a change to the proposition may need a larger bet. A product that already works can have plenty to gain from removing friction and improving how people find its value. Look at the bets the rest of the business is making too. Your team’s work is part of that wider investment.

Make room to learn after a release. Early improvements can help users and give the team evidence that it is getting somewhere. If repeated small changes barely affect the outcome, revisit the problem rather than filling another quarter with similar tests.

Before running a test, ask what you would do with the result. If every outcome leads to shipping the same thing, it’s worth asking what the experiment is for.

For an A/B test, decide what effect would matter, whether you have enough traffic to detect it and how long the relevant behaviour takes to appear. Agree the main measure, the things you don’t want to damage and the analysis you’ll use. Check that the data is being recorded properly. Build this into the feature work, rather than adding testing at the end.

If the numbers cannot answer the question, use another way to learn: interviews, usability work or a prototype. Be clear about what each can establish. A before-and-after improvement can have other explanations, and an inconclusive experiment leaves uncertainty. Neither should quietly turn into proof that the feature worked.

Once the result is in, make a decision. Continue, change it, stop or gather more evidence. Someone needs to own that choice and explain what happens next.

Customers experience the advertising, the product, the price and the support they receive. If each team improves its own number without looking at the rest, the customer can end up with a worse journey.

Bring the people who can affect the problem into the work. That can include engineering, design, data, marketing, sales and customer success. Share enough context that they understand the customer and the outcome, and give them room to suggest and build improvements.

The growth person cannot be responsible for inventing every good idea. Part of the job is helping the team understand what matters and making it possible for people across the business to contribute.

The feature has shipped. It’s in a menu. Someone has written a release note. Then the team wonders why nobody uses it.

Where would a user expect to find it? At what point would it be useful? What are they trying to do at that moment? A prominent button can still be in the wrong place, and an extra explanation may arrive after someone has already given up.

Plan how people will discover and start using the product or feature as part of building it. Watch what happens after release. The team still has work to do if people cannot find it, understand it or get value from it.

Why does that email go out after seven days? Why is that the threshold in the model? Sometimes the answer is that someone had to choose a number and nobody has looked at it since.

The original choice may have been sensible. The product, the users or what you know about them may have changed. Look for decisions hidden in defaults, timings, eligibility rules and thresholds. Ask what they were intended to achieve.

Some will be worth testing; others may need customer research or a clearer explanation of the constraint. Keep a record of important assumptions and what would make you revisit them. Otherwise a temporary choice can keep shaping the product long after people have forgotten why it was made.