Before building your startup, investigate the workaround

Start with the last real incident

Customer discovery becomes more useful when it examines a recent event. Instead of asking whether someone likes an app idea, ask how they handled the problem last time. What happened first? What did they try? What did it cost them in time or effort? Ask permission before recording and explain how you will use the notes.

Watch the workaround

A spreadsheet, phone call or paper notebook can reveal the job a new product must perform. Request a demonstration with private details removed. Notice who enters information, who approves it and who deals with mistakes. The person experiencing the pain may not control the budget.

Keep discovery separate from the pitch

Y Combinator’s startup teaching includes user conversations and early feedback as part of building a product. Our suggested adaptation is to keep the first part of a conversation about the participant’s experience. Showing a polished prototype immediately can turn a research session into a politeness test.

Look for repetition, then test a commitment

After several conversations, group recurring problems and contradictory evidence. Do not convert a handful of interviews into a market-size estimate. Pick one assumption to test: will a buyer share a sample workflow, schedule a pilot or introduce the person responsible for purchasing? Agree on the boundaries of any trial before accepting sensitive business data.

Write a decision, not a victory story

Use a one-page note containing the problem, current workaround, participants, strongest evidence against your idea and next experiment. If interviews differ across Lagos, Accra or Nairobi, preserve those differences. The goal is a decision you can revise, not a claim that a few friendly conversations validate an entire continent.

Sources and further reading

Y Combinator: Building product and talking to users