A product I was responsible for had a 4.8-star rating, yet I could not reliably apply a promo code to it. That contradiction made me think about a problem I had seen in growing product teams: the metrics can look healthy, but 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 a rotating group of product managers and designers. We selected a core journey, used the app as customers would, and logged what we found. One person was responsible for taking those findings and raising them with the relevant teams—which meant there was an ownership gap built into the process. Not every finding made it into a backlog, and not every backlog item got prioritised.
So I changed two things. I made product immersion daily, and changed who owned it. Now each PM walks their own area of the product every morning—asynchronously, on their own device. Some start with the previous day's customer feedback or session replays to investigate a specific complaint before opening the app. Others just open the app, walk a journey, and capture anything that gives them pause with a screenshot or screen recording. Either way, findings go straight into their team's Jira backlog, triaged and prioritised without waiting for someone else to route them.
The loop compressed because ownership moved. Each PM is accountable for their slice of the experience, not a shared exercise that someone else has to follow up on.
The promo code problem
One of the clearest use cases for Crash the App came from promo codes. A customer could enter a valid code at checkout and see it fail, while another code worked without any issue. The relevant front-end team investigated each report, contacted the team responsible for the other system involved, and fixed the immediate problem. Each time, it stayed fixed, until it happened again.
We added alerts and logging. The issue kept recurring. Each recurrence was caused by a manual configuration error, but because the configuration lived in two separate systems that had to stay in sync, the opportunity for human error never went away. Fixing individual failures was not going to change that.
After a major campaign period, we ran a cross-functional retrospective. With the pattern visible across multiple incidents, the team could ask a harder question: why could we not guarantee this would not happen again? Working through that, we identified the root cause: there was a duplicate configuration requirement. This meant a promotion had to be set up in two separate systems and a missed date or market setting in either one would cause a checkout failure even though the app was behaving as designed. The defect was hiding not in the interface, but as a mismatch in the process.
The fix was to remove the duplication. The CMS had held its own copy of each promo code, with its dates and markets, so it could be displayed on the website and app. The promotions tool held the same details so the discount could be applied at checkout. We removed the manual fields from the CMS. It now fetches the code, dates and markets directly from the promotions tool, which became the single source of truth.
This needed two teams. We agreed with the promotions team how the data would be exposed, then rebuilt the CMS integration to read it instead of relying on manually entered fields. The work was prioritised for the quarter and shipped before the next major campaign.
Promo code failures had been a recurring category in our customer feedback. After that campaign, complaints about codes not working dropped significantly.
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, and that judgement only comes from repeated contact with the product.
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 gives the team another form of evidence, and the right tools to act on it.
We categorise customer feedback continuously and track emerging topics week on week. When a category starts rising, it is a signal worth investigating rather than fixing the latest instance in isolation. Findings from daily sessions are logged in team support channels and Jira, so during triage a team can check whether an issue has appeared before and whether a previous fix addressed the symptom or the cause.
For more significant incidents we run post-mortems and apply five whys, drilling down until we reach something structural rather than fixing the surface symptom again. The questions shift from which team owns the bug to why the same class of problem keeps appearing at all.
Sign-in problems are a good example. Complaints that customers couldn’t sign in kept rising in our weekly feedback categories, which told us this was a pattern, not a run of one-off issues. We asked the team that owns authentication to analyse every complaint and separate customer-side causes, such as a mistyped password or an account that didn’t exist, from genuine system faults. The confirmed faults went onto a fix roadmap, and we kept tracking the feedback until sign-in complaints dropped.
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.
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.
