By Arinze Chiama

Somewhere in a small office in Yaba, a Nigerian founder is staring at their dashboard, asking the question that keeps so many startup teams awake: “Why aren’t more people using this?”

Another week has passed, yet the user numbers have barely moved. Before long, they arrive at a conclusion I have heard repeatedly for more than a decade, whether the product is in fintech, healthcare, legal services, education, or recruitment.

We need a better UI. The product just needs a redesign. It sounds reasonable enough. The interface is the visible part; it is easy to point at, and reworking it feels like progress.

But most of the time it does not touch the actual problem. Products rarely fail because a button is the wrong colour or a screen looks dated. They fail because, long before anyone opened a design tool, someone decided what to build, who to build it for and why, and nobody checked whether that decision was right.

That is an uncomfortable idea, because it moves the problem out of the design file and back into the room where the roadmap gets set.

The most useful product designers I have worked with spend surprisingly little time drawing screens. Most of their time goes into questions. Are we solving something that actually matters to this customer? Who exactly is this for? What evidence do we have that it is worth building? Is this feature necessary, or does it only feel necessary because a competitor shipped it first? What are we assuming that we have never tested?

Marty Cagan describes product work as clearing four risks before you spend engineering time on an idea: whether it has value, whether people can use it, whether it can be built, and whether it works for the business. Teresa Torres makes a similar case from another direction. Every idea rests on a pile of assumptions, and the job is to find the one most likely to sink you and test it cheaply before a line of code is written. In both cases the interface is the last thing that happens, not the first. It is the visible result of decisions made much earlier.

The same patterns show up again and again in very different companies. A feature gets built because a rival has it, not because a customer asked. Scope grows to satisfy whoever spoke last or loudest in the meeting. Development starts before anyone has spoken to more than a handful of real users. Success gets counted by how much shipped this quarter rather than by whether anything changed for the person using the product. None of this comes from carelessness. It is what happens when a team under pressure to move fast starts treating motion as progress, which is close to what Melissa Perri calls the build trap, where a company rewards output and keeps shipping without ever confirming that any of it matters.

The bill arrives later, and it is large. When CB Insights went through the post-mortems founders wrote about their own dead companies, the most common reason was no market need, a product built before anyone confirmed that enough people cared. Running out of cash tends to be the final symptom rather than the cause. The African context makes this clearer rather than gentler. Money is not the constraint it used to be. Briter Bridges recorded a record year for startup funding on the continent, most of it flowing through a small number of large rounds, which means the gap between the companies that last and the ones that quietly close has little to do with how much they raised. SafeMotos is a fair example. After building a working motorcycle-taxi service in Kigali, it rebranded as CanGo and moved into ride-hailing in Kinshasa, a new city and a new model, without the runway to find out whether it would hold before the money ran out. It closed in early 2020. The engineering was capable, and the team had done this before. The decision that came ahead of the build is where it came apart.

None of this makes African founders reckless, or puts designers above the engineers and product managers next to them, and it certainly does not mean good design guarantees anything. It means the real value of an experienced designer has less to do with interfaces than people expect. It is judgment. Asking sharper questions before the money and the months are spent. Pushing on an assumption that feels too obvious to question. Testing an idea while it is still cheap to change. Keeping what the customer needs and what the business needs pointed in the same direction. None of this gets less true as the tools get better. The cost of building has collapsed, and with AI, a working version of almost any idea is now a few hours of work, which sounds like relief until you notice it lowers the price of the artifact and not the price of building the wrong thing.

Cheap execution does not forgive a poor decision. It just lets you reach it faster, and at greater scale. Good products are rarely the result of clean execution alone. They come from a long run of decisions made carefully, before execution starts. So the question worth sitting with is not whether the product needs a redesign. It is quieter than that, and harder to answer honestly. Are we solving the right problem before we start building the solution?

Arinze Chiama is the Founder and Product Strategy Lead at Design Sync, where he helps founders and product teams turn unclear product ideas into scalable digital products. With over a decade of experience across fintech, healthcare, legal services, education and recruitment, he combines product strategy, UX and design to solve complex business problems.