Crash the App: What a 4.8-star rating can hide

A product I was responsible for had a 4.8-star rating. I still could not reliably apply a promo code. That contradiction made me think about a problem I had seen in growing product teams: the metrics can look healthy while using the product tells you something else.

As teams grow, ownership gets split across more people and systems. Product managers spend more time on dashboards and delivery, making it easier to lose touch with the day-to-day customer experience. You may know the conversion rate and support volume while still missing the small problems that make a journey frustrating.

I developed a product-immersion practice I call "Crash the App" to close that gap. The idea is simple: product teams regularly use their own product as customers, on real devices, with a specific task in mind. The goal is to notice recurring friction before it disappears into dashboards or gets treated as a series of unrelated tickets.

What Crash the App is

Each session starts with a real customer job. That might mean buying a product or redeeming a reward, depending on the product and the part of the journey being reviewed. The team completes the journey from start to finish without skipping awkward steps or using internal shortcuts.

During the session, I capture every point where the experience becomes harder than expected. Some findings are bugs, while others come from unclear copy or a process that forces the customer to repeat work. I also note moments where the product technically functions but the experience still feels confusing.

The useful part comes after the session. A one-off issue may need a ticket, but a recurring problem deserves a different question: what is causing it to recur? That is where Crash the App moves beyond basic bug hunting.

Why weekly sessions were not enough

I first ran the practice in scheduled 30-minute sessions with product managers and designers. We selected a core journey, used the app as customers would, and then logged what we found. The sessions exposed useful problems, but the weekly cadence created a growing backlog.

We would identify an issue and wait for it to move through the normal delivery process. By the time something was fixed, another session had produced more findings. We were getting better at seeing friction without becoming much faster at understanding why it kept appearing.

So I changed the practice and made product immersion part of the working day. The daily version still takes about 30 minutes, but it focuses on a different customer journey each time. The aim is not to audit the entire product every morning, but to stay close enough to the experience that repeated patterns are difficult to miss.

The promo code problem

One of the best examples came from promo codes. A customer could enter a valid code at checkout and see it fail, while another code worked without any problem. Support could not reproduce the issue consistently, and standard monitoring showed that the promotion was live.

At first, the issue looked like an app bug. Repeatedly walking through the checkout journey showed that the problem was coming from how promotions were configured behind the app. Each promotion had to be set up in two separate systems, and the customer experience depended on those configurations matching.

A missed date or market setting could cause a promotion to fail at checkout, even though the app itself was behaving as designed. The defect was not in the interface. It stemmed from a process that required the same information to be entered multiple times.

That changed the fix. Instead of correcting a broken promo code, the duplicate setup was removed so that a promotion could be configured once and propagated to the customer-facing system. A bug report would have fixed one instance of the code, while repeated product use would have revealed why the same class of problem kept recurring.

The judgement comes from repetition

Not every issue points to a broken process. Some problems are isolated, and others affect such a small part of the experience that they may never justify engineering work. The difficult part is learning to tell the difference between noise and a pattern.

A single complaint gives you limited context. Aggregated analytics can hide the source of friction because the same underlying problem may appear in different journeys. Repeated use of the product gives the team another form of evidence.

When you encounter the same problem more than once, the questions start to change. You begin to ask whether the same dependency appears in different parts of the product, or whether an internal process is causing several customer-facing symptoms. Those questions are often more useful than simply asking which team owns the bug.

Why engineers were sceptical

Product managers and designers tended to adopt the practice quickly. Engineers were more cautious because daily app use can sound like informal QA or another way to blame engineering when something breaks. That concern was reasonable, so forcing participation would have missed the point.

Focused workshops worked better. Engineers walked through customer journeys themselves and paid attention to what they expected to happen at each step. The discussion then shifted away from finding defects and towards understanding the gap between customer intent and system behaviour.

That change made the practice more useful. Engineers often noticed dependencies or system behaviour that product managers could not see from the interface alone. The session became a shared way to understand a problem before deciding what kind of fix it needed.

How to run it

The practice does not need a new programme or a separate project owner. Pick one customer journey and use the live product on a real device. Complete the task without shortcuts, then record every place where you hesitate or need to repeat a step.

After the session, review each finding and ask whether it is isolated or part of something you have seen before. Isolated issues can move through the normal product process. Repeated issues deserve a closer look at the systems and decisions behind the interface.

The cadence matters because repetition changes what you can see. One session may reveal a broken interaction, but repeated sessions can show that the same failure is being created by a process elsewhere in the product. That is the difference between fixing a symptom and understanding its source.

Final Thoughts

Crash the App changed how I think about product ownership. Dashboards and research remain useful, but they cannot replace regular contact with the product experience itself. Using the product often enough gives you a better chance of noticing when a small irritation is part of a larger problem.

Try it with one journey tomorrow morning. Complete the task yourself on a real device and write down every place where the experience makes you stop and think. The first finding may be small, but what matters is whether you see the same type of friction again.