01Where products go wrong
The same few mistakes, in every industry.
They are not technical problems. They happen in every industry, and they are easy to see afterwards. Here is what to look for before it is too late.
Nobody tested the main assumption
Everyone agreed it was true, so nobody checked. It turned out the whole plan depended on it.
Nobody asked the actual users
The people who would use the product every day were never in the room. Only their managers were.
Interest was mistaken for demand
People said they liked the idea. Very few of them changed what they actually did. Saying yes costs nothing.
A blocker turned up in month five
A rule, a cost, or a system that would not connect. It was there from the start. Nobody looked for it early, when finding it would have been cheap.
None of these are fixed by hiring better engineers. They are all decided before anyone writes code — and they are where most of the budget quietly goes in the wrong direction.
02What AI changed
Building got fast. Deciding did not.
AI can write a working system in an afternoon. It cannot tell you whether anyone wants it.
So the hard part moved. It used to be building. Now it is choosing — which problem is worth the effort, and how you would know that before you spend a year finding out.
And because building is cheap, there are now far more things you could build. So choosing got harder, not easier.
03A way through it
Be wrong sooner, and for less money.
Nothing stops you being wrong. But you can find out in a week instead of a year, and that changes what it costs. This is how we work. None of it is complicated.
Research
Spend time with the problem, and with the people who have it, before deciding on an answer.
Ideate
Pick the simplest idea that fits the facts. It is usually not the most impressive one.
Experiment
Build something small and put it in front of real users, early.
Learn
Change the plan when the evidence says so. That is the whole point.
Then again, knowing more than you did.
It is a loop, not a process — a process assumes you already know the route. The only hard part is that it looks slow at the start, which is exactly when everyone wants to see progress.
04Questions
Two that come up often.
How do you tell an assumption from a fact, early on?
Write it down and ask what would have to be true. An assumption you have named can be tested cheaply, often in an afternoon. An unnamed one gets built into the product, and only surfaces when it is expensive to remove.
How much research is enough before building?
Enough to know what would change your mind. If no realistic finding would alter the plan, more research is procrastination. If several findings would, you are not ready to build yet.
05Who is saying this
Who is saying all this.
Founded in 2015 by Santhosh Bandila. Based in India. We build products with other companies, and products of our own.
The work has covered telecom, identity, aviation, infrastructure, data engineering, retail and hospitality. We are not specialists in any of them. We are specialists in the part above.
What we do not do: hire out engineers by the month, promise a delivery date before the problem is clear, or bill research as a separate line item.
06Contact
Get in touch.
[email protected]If you are not sure whether you have a problem worth solving, that is a perfectly good reason to write.