Diagnosing a stalled product: 2–3 hours down to 5 minutes

I built a tool that tells our project managers why a product has stopped growing: not enough demand, a price or features that don't hold up against competitors, or our own product page, images or ads. One analysis used to take 2–3 hours by hand. Now it takes about 5 minutes, and 4–5 project managers use it every day.

2–3 h → 5 minper analysis
300+analyses run so far
4–5project managers use it daily
Hamza Akbar · COO, Zelevate · Running since Jun 2026 · Numbers checked Oct 2026 · Last updated

What did it look like before?

When a product stops growing, someone has to say why. The answer usually sits in one of five places.

The marketNot enough demandPrice or features don't hold up
Our own workProduct page explains it badlyImages don't sell itAds reach the wrong people

Each one needs a different fix. Pick the wrong one and you lose weeks.

1Hours of manual workSeveral reports, long lists of customer searches sorted by hand, and competitors compared one by one.
2Scores nobody could explainAn outside research tool gave precise-looking scores. Nobody could explain them, so nobody could argue with them.
3Two people on one questionEvery project manager did it alone, 2–3 hours per product. A head then went through it all again before trusting it.

Why build this one?

The answer decides what the team works on next for that product, and a wrong answer doesn't show up straight away. It shows up weeks later.

I also didn't want to swap one black box for another. The goal I wrote down at the start was a tool whose answers the team could understand and question, rather than just trust.

I built this one myself because I already knew the context behind the question. As an operator I knew what the team was really trying to find out, and why each check mattered.

How did I approach it?

I started from the question I wanted answered, and worked back to the data. A few ideas shaped everything after that:

  1. One answer.A list of twenty possible issues just moves the thinking back to the person. The tool has to commit to the main thing holding the product back.
  2. Rule things out first.Before blaming anything, it checks what clearly isn't the problem. Whatever's left is where to look.
  3. Check our own work before blaming the product.If the ads aren't set up well, you can't tell whether the product page is any good. So the page only gets blamed once the ads are ruled out.
  4. Ignore thin evidence.A great result on a handful of clicks is luck. Anything with too little data behind it doesn't count.
  5. Fixed rules make the call.Claude reads product pages and writes up the explanation, but the verdict itself comes from rules I can check and change.
  6. Every “no” has a reason.When the tool rejects something, it says why in plain words, so someone on the team can disagree with it.

What broke, and what I changed

The first versions got things wrong in ways that taught me more than the parts that worked.

Fix 1

Two searches meant the same thing and got opposite answers.

One was kept and one was thrown out, only because one happened to share a word with the product's title. Nothing was wrong with the data. The rule treated every word in the title as equally important, when some words say what the product is and others only describe it. Once I split those apart, both searches got the same answer, and the ones that had slipped through were caught.

Fix 2

A helper step was quietly loosening the rules.

I'd added a step to rescue searches that had been thrown out unfairly. It worked, but it also let in things it shouldn't, and nobody was checking what it added. Now it can only make small additions, and every one of them shows up in the output with the search that triggered it.

Fix 3

Strict went too far.

I started strict on purpose, accepting that some good searches would be lost. Then it started throwing out the most obvious search for the product, the one buyers type first. I added a narrow exception for that case and left the rest strict.

Fix 4

Big products broke the AI step.

With hundreds of searches to sort, Claude's answer got cut off halfway and the whole step failed. Splitting the work into batches fixed it, and if one batch fails now, the rest still go through.

Fix 5

Small numbers looked like signals.

An ad position with almost no spend, or a search with a few lucky sales, kept getting picked as the best performer. Anything below a minimum amount of evidence is now left out of those comparisons.

How did the team take to it?

The team got a short guide covering two things: how to run it, and how to tell when its answer looks wrong.

There was no pushback. The team already knew why each check was there, and anything the tool throws out comes with a reason, so nobody had to take it on faith. It was useful from the first day.

What changed

2–3 h → ~5 minOne analysis, by hand vs with the tool.
4–5Project managers use it every day, and have for the last 3–4 months.
300+Analyses run so far.

Nobody's asked to use it. People pick it up because it saves them most of an afternoon.

What's still not right

  • Products that already lead their market confuse it. With nothing ahead of them to compare against, it flags too many things as possible problems.
  • I built a whole extra section that runs on every product and costs money each time, and it never shows up anywhere. I only found out when I sat down to document the tool.
  • Some rules were written around the first products I tested and don't fit every category yet.
  • On very large products it's slow, because it writes results one line at a time.

Read next

Is your team answering the same question by hand?

Tell me about it, and I'll tell you whether a system would help.

Send details →