Asher's Blog

Many years ago, I bought a small digital device that contained the Bible.

I cannot remember its name now. I remember that it was brownish, small enough to carry around, and had a screen and buttons that allowed me to scroll through the text. I could type, but I could not do very much beyond finding and reading Scripture. I do not even remember whether it allowed me to highlight passages.

At the time, it felt remarkable: an entire Bible inside a portable electronic device.

This was before the iPod arrived and made a small digital object feel like something the whole world could desire. Yet the Bible device never became culturally significant. I rarely heard anybody talk about it, and I have sometimes wondered what happened to the company that made it.

Was the idea ahead of its time? Was the market too small? Was the product not good enough? Or did the company fail to explain why people should replace a familiar physical Bible with an electronic device that could do only one thing?

I do not know the answer. But the memory has stayed with me because it illustrates an uncomfortable truth about innovation:

A product can be right and still be too early.

Timing is part of the product

Founders often think about timing as something external to the product. The product is what we build; timing is simply when we happen to launch it.

In reality, timing shapes whether the product is useful at all. A digital product may depend on affordable smartphones, reliable internet, online payments, digital identity or customer trust. An electric vehicle may depend on charging infrastructure and battery economics. A remote-health product may require regulatory permission, trained providers and patients who are comfortable receiving care through a screen. An AI agent may require reliable models, secure access to data and customers willing to let software take actions on their behalf.

If those surrounding conditions do not yet exist, the founder is not merely building the product. The founder is also being asked to build the market, educate the customer, create missing infrastructure and absorb risks that later companies may not have to carry.

This is why being early can look very similar to being wrong. Bill Gross, the founder of Idealab, reviewed companies inside and outside his portfolio and argued in a widely watched TED talk that timing explained more of the difference between success and failure than the idea, team, business model or funding. His analysis attributed 42 per cent of the difference to timing. That figure should not be treated as a universal scientific law, but the underlying point is powerful: a great company cannot force the market to be ready merely because the founder can see the future.

In Africa, readiness is uneven

Timing is particularly complex when building for Nigeria and other African markets because readiness does not move uniformly.

A customer may own a smartphone but struggle with data costs. A company may want digital payroll while some employees lack reliable identity or bank records. A consumer may understand online payments but distrust a new provider with long-term savings. A product may work beautifully in Lagos and fail elsewhere because connectivity, distribution, language or purchasing power is different.

This creates a mistake founders must avoid: confusing visible adoption within a small, privileged group with readiness across the market.

The first thousand users may be founders, professionals and technology enthusiasts who tolerate friction because they enjoy trying new things. The next hundred thousand customers may need the product to work on less expensive devices, under weaker connectivity, with simpler language and more human reassurance. A flow that feels obvious to the product team may be completely unfamiliar to the wider market.

African companies therefore have to examine several kinds of readiness:

• Infrastructure readiness: Can customers access the internet, power, payments and devices the product requires?
• Economic readiness: Can enough people afford the product, and is the problem painful enough for them to prioritise it?
• Behavioural readiness: Are customers willing to change how they currently solve the problem?
• Institutional readiness: Do regulation, identity systems, banks, employers and other partners support the product?
• Trust readiness: Will customers entrust the company with their money, data or an important workflow?

A market can be ready in one dimension and unready in another. Timing is the point at which enough of these conditions become favourable for adoption to compound.

The iPod was not the first; it was the complete answer

Portable digital music existed before the iPod. Apple did not invent the MP3 player.

When Apple introduced the original iPod on 23 October 2001, it combined a compact five-gigabyte device capable of holding about 1,000 songs with a ten-hour battery, a scroll wheel and integration with iTunes. The product arrived when compressed digital music, personal computers, storage technology and consumer frustration with existing music players were converging.

The technology mattered, but so did the experience. Competing products often made customers think about storage capacity, file transfers and complicated menus. Apple gave the market a simpler promise: a thousand songs in your pocket. The company did not merely manufacture a device. It integrated the hardware, software, music management and message into one understandable experience.

That is the difference between having a technology and having a product. The old digital Bible I owned may have contained an important technical idea: portable digital reading. But if the device was difficult to navigate, offered little advantage over a printed Bible, lacked search and annotation tools, or could not connect to other parts of a person’s spiritual life, then being early was not its only problem. The product may also have been incomplete.

Founders should be careful not to use “the market was not ready” as a flattering explanation for a product customers simply did not love.

How to tell “too early” from “not good enough”

The distinction is difficult because both conditions produce weak adoption. An early product may solve a real problem but require customers to overcome too many external barriers. A poor product may operate in a ready market but deliver the solution badly. Poor product marketing may cause customers who need the solution never to understand it.

Ask three different questions:

1. Is the problem urgent? Customers should already be spending money, time or emotional energy on some form of solution.
2. Does the product solve it well? Customers who use the product should reach the intended outcome with acceptable effort and reliability.
3. Can the market understand and adopt it now? The customer should possess the infrastructure, trust, budget and behaviour required to begin.

If users experience strong value after adoption but very few can overcome the prerequisites, the product may be early. If customers can adopt easily but do not continue using it, the product itself may be weak. If customers love the product once somebody carefully explains it, but the wider market does not understand the promise, product marketing may be the problem.

These diagnoses lead to different decisions. An early company may need to narrow its market, wait, partner or build a temporary bridge around missing infrastructure. A weak product needs improvement. A poorly positioned product needs a clearer story and distribution strategy.

Calling every failure “timing” protects the founder’s ego but does not protect the company.

Product marketing is not decoration

Many products die not because they lack functionality but because the market never understands what they are for.

Product marketing is not simply advertising after engineers finish building. It is the discipline of connecting a particular customer’s problem to a product they can understand, trust and choose. It helps determine who the product is for, what urgent job it performs, why it is different and how the customer should experience its value quickly.

Clayton Christensen’s “Jobs to Be Done” theory provides a useful way to think about this. Customers do not buy a product merely because of its features; they “hire” it to make progress in a particular circumstance. The same technology can succeed or fail depending on whether it helps the customer complete that job better than the current alternative.

A payroll product is not hired merely to calculate salaries. An employer may be hiring it to avoid errors, comply with regulation, pay everyone on time, preserve employee trust and stop worrying. A savings product is not hired merely to display an interest rate. A customer may be hiring it to impose discipline, protect money from impulsive spending and create confidence about the future.

When the company understands the job, product design and product marketing begin to reinforce each other. The features address the real anxiety, and the message describes the progress the customer wants.

Watch customers; do not only ask them

Customers are essential sources of truth, but customer research requires more than asking, “What feature do you want?”

People often describe solutions in terms of what they already know. They may ask for another button when the entire process should disappear. They may say they want more options when what they need is confidence about the correct one. They may praise a design during an interview and still fail to use it when left alone.

The product team must observe behaviour. Where does the customer pause? Which field do they misunderstand? When do they leave the process? Which task causes them to contact support? What workaround do they use outside the product? Which feature do they ignore? What information do they repeatedly ask another person to explain?

Usage data reveals where friction occurs, while conversation helps explain why. Neither is complete alone.

One of the most valuable things a founder can do is sit beside a customer and watch them use the product without rescuing them. The silence can be uncomfortable. The founder sees labels that made sense inside the company but mean nothing to the customer. Steps the team considered simple reveal hidden assumptions. A product that looked beautiful in a presentation becomes difficult in real life.

That discomfort is useful. It is the product teaching the company what to build next.

Get into the mind of the customer

When I think about building products today, I try to enter the customer’s mind and follow the journey from their perspective.

What has happened immediately before they open the product? Are they calm, hurried, afraid or confused? What do they expect to see first? Which decision do they believe they are making? What would make them stop? What result would make them feel relief?

The flow should reflect the customer’s mental model, not the company’s organisational chart.

Customers should not need to understand which internal department owns a process. They should not have to learn the company’s language before receiving value. They should not encounter five screens because five teams need different data. Complexity may be unavoidable inside the system, but the product’s job is often to hide that complexity responsibly from the user.

Simplicity is not the absence of sophistication. It is sophistication organised around the person using it.

Product disagreement can be productive

My head of engineering and I debate product decisions frequently. Sometimes I think he wins about 60 or 70 per cent of our arguments. On reflection, it is probably closer to fifty-fifty; but winning is not the point. We are trying to discover the best flow for the customer.

Healthy disagreement improves a product when both people are defending evidence and the customer rather than their status. The founder may understand the commercial promise and emotional problem. The engineer may understand technical constraints, reliability and the cost of complexity. Design may understand comprehension and behaviour. Customer success may understand where real users become stranded.

The best product decision often emerges from the tension between these perspectives. The organisation becomes weaker when the highest-ranking person always wins, or when technical difficulty is treated as a sufficient reason to ignore customer pain. It also becomes weaker when every founder preference overrides engineering reality. Debate should lead to a testable decision: build the simplest responsible version, put it before customers, measure behaviour and learn.

Good product culture does not eliminate disagreement; it gives disagreement a shared purpose.

A design can unlock a company’s next chapter

For years, I kept telling my team what I wanted our product to feel like. I could see the outcome, but the versions in front of me did not yet express it.

Then I saw a new design and flow, and my reaction was immediate: Yes. This is it. This is what I have been talking about.

That feeling matters, but it is not enough on its own. Founders naturally love products that resemble their vision. The market still has to validate the design through comprehension, adoption, repeated use and payment.

Yet there are moments when a new flow resolves several tensions at once. The product becomes easier to explain. Important actions become obvious; the design reflects how customers actually think. The team can see how the current feature leads into a much larger journey.

I believe our new direction can become the beginning of the impact we want to make in the market. That confidence comes not merely from appearance, but from seeing the customer’s pain translated into a simpler experience. Great design gives ambition a usable form.

The product continues after the screen fails

A product is not only the interface a customer uses when everything works.

The product includes onboarding, documentation, pricing, notifications, support, refunds, error messages and the way the company responds when something goes wrong. For an enterprise product, implementation and account management are part of the product. For a financial product, settlement, reconciliation, security and complaint resolution are part of the product.

The moment of failure is often when the customer discovers what kind of company built the product.

Can they understand what happened? Is their money safe? Does somebody take responsibility? Are they forced to repeat the same story to several agents? Does the company communicate before the customer has to complain? Is the problem resolved in a way that restores confidence?

A beautiful interface followed by a terrible support experience is not a beautiful product.

The objective should be to make every interaction feel coherent, even when the customer is experiencing a problem. This does not mean making failure enjoyable in a superficial sense. It means reducing anxiety, communicating clearly and helping the customer regain control. Customer experience is the product over time.

AI does not remove the need for product judgment

We are now living through a proliferation of artificial intelligence products and agents. Almost every company is asking what it should build with AI.

The temptation is to add AI because the technology is fashionable. That can produce impressive demonstrations without useful products.

An AI feature should begin with the same customer question as any other product: what painful job becomes meaningfully easier, faster, safer or more accessible? If the feature introduces uncertainty, requires constant correction or performs a task the customer never cared about, intelligence inside the model will not rescue the experience.

For an agent that can take actions, trust becomes even more important. The customer must understand what the agent can do, what it cannot do, which decisions require approval, how errors will be corrected and how personal or company data is protected. Autonomy without control may create more anxiety than convenience.

The winners in AI may not be the companies that attach the most AI to their products. They may be the companies that make powerful intelligence feel simple, dependable and appropriately invisible.

Technology should expand what the customer can accomplish without expanding what the customer has to understand.

What to do when the product may be early

If the market is not fully ready, the choice is not limited to giving up or spending until everyone catches up.

The company can:

1. Find the narrow group that is ready now. A niche can sustain the company while the larger market develops.
2. Remove a dependency. Offer offline capability, assisted onboarding, a lower-cost channel or an integration with infrastructure customers already trust.
3. Sell the outcome as a service first. Human delivery can reveal the workflow before it is fully automated.
4. Partner rather than build everything. Banks, employers, distributors or established platforms may supply trust and access the startup lacks.
5. Reduce the burn rate. If readiness is a matter of time, the company must survive time.
6. Measure leading indicators. Falling customer-education costs, improving infrastructure, regulatory change and growing use of adjacent products can show that the market is approaching.
7. Set a deadline for the thesis. “Too early” should not become an indefinite excuse. Decide what evidence must appear and by when.

An early product can win if the company learns cheaply enough to remain alive until the market changes. But survival alone is not proof. The product must keep becoming better while the world becomes more ready.

Make using the product beautiful

Great products matter. How we think about them, simplify them and place them in the customer’s life matters.

A product does not become great because the founder can list many features. It becomes great when the customer can move from pain to progress with less confusion, effort and fear. It becomes great when its timing, design, positioning and delivery reinforce one another.

Listen constantly, but do more than collect requests. Observe behaviour. Understand the customer’s job. Build the simplest flow that completes it. Debate vigorously inside the company, then allow evidence to settle the argument. Treat support and failure recovery as part of the experience. Use AI where it removes real friction, not where it merely makes the company look current.

And be honest about timing. Sometimes the world is not ready. Sometimes the product is not good enough. Sometimes the customer simply does not understand why it matters. Wisdom is knowing which problem you actually have.

The goal is not merely to build a product before everybody else. The goal is to build the product customers are ready to love—and to make the experience so clear and beautiful that, once they use it, they do not want to return to the old way. —

References and further reading

• Bill Gross, “The Single Biggest Reason Why Start-ups Succeed”.
• Apple, “The Music Lives On”.
• Clayton M. Christensen, Taddy Hall, Karen Dillon and David S. Duncan, “Know Your Customers’ Jobs to Be Done,” Harvard Business Review.
• Clayton Christensen Institute, “Jobs to Be Done Theory”.
• Don Norman, The Design of Everyday Things.
• Geoffrey A. Moore, Crossing the Chasm.