Don't build software to fix an explanation problem
Marty Cagan says every product faces four big risks. After years of answering the wrong one with engineering, I add a fifth, legibility, and it's the one that more code makes worse.
When an AI product isn't selling, most founders reach for the same fix: build more. Add the feature the last prospect asked about. Make the model smarter. Ship the integration.
Sometimes that's right. Often the product was never the problem. The buyer simply couldn't tell what it was.
Cagan's four big risks
Marty Cagan, the founder of Silicon Valley Product Group and author of INSPIRED, argues that every product idea carries four big risks (SVPG, 2017):
Value
Whether customers will buy it, or users will choose to use it.
Usability
Whether users can figure out how to use it.
Feasibility
Whether your engineers can build it with the time, skills and technology you have.
Business viability
Whether it works for the rest of the business: sales, pricing, legal, cost of acquiring customers.
His point is that good teams tackle these risks before building, not after. It's the most useful checklist I know for anyone about to spend money on software.
My twist: the fifth risk is legibility
I add one more, and it sits in front of all four:
Legibility: can a buyer understand what this is, and why they need it, within seconds?
Legibility isn't the same as usability. Usability is about someone who has already signed up and is trying to use the thing. Legibility decides whether they sign up at all. It isn't quite value either. The value can be real and still invisible, because the buyer never got far enough to see it.
Here is what makes it dangerous: when legibility is the real problem, more engineering makes it worse. Every feature you add is one more thing to explain. The product gets more capable and harder to describe at the same time.
What that cost me
At Mindreader, we built AI that helped salespeople understand a prospect's communication style before a meeting. It reached more than 3,000 users and 100+ paying customers, and we raised about SGD 500K. So there was real value.
But when growth was slower than we hoped, I treated it as a feasibility problem. We spent about SGD 200K on engineering over three years, and much of what we built was technically impressive and genuinely hard. What it didn't fix was the thing actually holding us back: the market didn't understand the product. Looking back, our landing page needed a human translator.
The same issue showed up in quieter ways.
- Our free plan didn't convert. None of our free users went on to pay. We removed the free plan and moved to a 14-day trial.
- One explanation didn't fit two audiences. Workshops brought in 100+ sign-ups and paid ads 200+, and they wanted opposite things. People from workshops had heard the full story and wanted depth. People from an ad had read one line and wanted that promise kept, fast. We needed two different onboarding sequences, not one product with more features.
None of these were engineering problems. They were translation problems. The full story of what Mindreader learned, including why accuracy was never the bottleneck, is in the case study.
How to tell which problem you have
Before
A feasibility problem: prospects understand what you do, want it, and ask when a missing piece will be ready. Building the piece is the right move.
After
A legibility problem: prospects ask "so what does it actually do?", describe it back to you wrongly, or sign up and never come back. Building more will only add to the confusion.
A useful signal: listen to how customers describe your product to someone else. If their description is vague, wrong, or longer than yours, you have an explanation problem. And explanation problems are cheap to fix compared with software: a clearer headline, one audience per page, a demo that shows a single result instead of ten features.
This matters even more for AI products. "AI-powered" tells a buyer nothing, and the underlying technology is often unfamiliar, so the burden of translation is on you. It's the same reason I argue for the boring, familiar project first: people adopt what they can recognise.
Before you pay for the next feature
Run the five risks in order, and start with the cheapest one to test. Legibility costs an afternoon. Feasibility can cost a year.
If you want a second opinion before committing budget, this is the kind of question I work through as a fractional CTO or CPO: which of the five risks is actually in your way, and what's the cheapest way to prove it. Get in touch and bring your homepage.