Textbook product discovery looks like this. Recruit 8 to 12 participants, run 45-minute moderated interviews, synthesize the themes, validate with a survey. It is a rigorous process and there are whole books about it. It also almost always produces insight that is correct, useful, and badly insufficient.
The methodology is not the problem. The relationship between the researcher and the subject is. In an interview you are an outsider asking questions, and the person across from you is performing, whether they mean to or not. They hand you the story they think you want, or at best a tidied version of the truth. The dread of a 7am commute that might not come. The math of "if I leave now there are two stops where I might still catch something." The worn-down "this is just how it works." None of that lands in a transcript.
"The sharpest product insight is the one you watch happen. Nobody hands it to you across a table."
What Riding the Minibus Actually Taught Me
Before I wrote a single user story for Kabba, I spent weeks riding as a commuter in Addis Ababa. Same routes, same hours. No clipboard, no recorder, no "I am building a product and would love your feedback." Just a guy trying to get somewhere, watching what broke when things went wrong.
Three things surfaced that no interview would have given me.
First: the pre-departure negotiation. Every trip opened with a negotiation I had not expected, and it had nothing to do with price. Fares were loosely standardized. The haggling was over route certainty. Regulars quizzed the driver before getting in. Which stops would he actually commit to? Would he take the detour? Would he switch routes if he spotted better fares down the road? The exchange was not hostile. It was a ritual. And it told me the unresolved job was reliability, with price already settled.
Second: the web of informal guarantees. Seasoned commuters had built their own reliability systems. They knew which drivers to trust and which routes had a backup. Many had quiet carpool arrangements with coworkers. People could navigate the informal system fine. The catch was that navigating it took local knowledge newcomers did not have. Reliability existed. It just was not a product. It was a privilege of established relationships.
Third: the emotional tax of uncertainty. The thing no later survey or interview ever surfaced was the anxiety. Nothing dramatic. A chronic low hum, a calculation running in the background all day. Will this work today? Do I have a fallback? How late can I afford to be? That anxiety showed up in posture, in the way people checked their phones, in how often they glanced at departure times that did not exist. You never see it in an interview room.
The Limits of Empathy as a Method
Discovery frameworks talk about empathy as if it were a technique you perform through careful listening and good questions. I think that is a category error.
The empathy that produces real product insight is lived before it is understood. Ask a commuter how unreliable transit feels and you will get an answer. You will not know what the answer means until you have stood there yourself when the vehicle never came and the whole day has to be recalculated on the spot.
Structured research is not useless. It is essential for validating at scale, for reaching users you cannot embed with, for catching your own confirmation bias. The point is that it works best after you already carry a lived understanding of the problem. Frameworks sharpen the picture. They do not paint it.
Embed first. Watch without an agenda. Build hypotheses from what you saw. Then validate with structured research. That order, and never the reverse.
Discovery in Markets Without Product Vocabulary
Building for people who have never used your category of product carries its own challenge. In Addis Ababa we were not replacing a transit app. We were introducing structured, subscription commuting to people who had never lived it. They had no words for what they wanted, because the thing they wanted did not yet exist.
This is where "what would make this better" falls apart. Better than what? Better than the informal minibus is a bar almost anything clears. The question that mattered was different. What would it mean to have this job done reliably, every day, for the rest of your working life? That points at an entirely different product.
In a market with no product vocabulary, asking users what they want is the wrong move. The work is to understand the job deeply enough to name what they would want if they believed it were possible. That skill leans on embedded observation far more than interview technique.
What This Changes About How I Approach Discovery Now
I approach discovery differently than I did before Kabba. A few things I do consistently:
- I use the product before I talk to anyone about it. Real use for its actual job, over weeks, not a quick beta pass. You cannot ask the right questions until you have hit the right problems yourself.
- I keep observation and interviews apart. Watching someone use a product and asking them about it are different acts, and doing them at once corrupts both. I run one, then the other, then synthesize.
- I weigh what people do over what they say. When behavior and stated preference disagree, behavior wins every time. People optimize for what they actually value, whatever they tell you they value.
- I hold my findings loosely until I have validated them at scale. The minibus observations were right, but they were one person's read from one vantage point. Validation at scale catches where your embedded experience does not generalize.
The Part That Doesn't Show Up in Job Descriptions
Discovery is hard to test for in interviews and harder still to teach, because the parts that matter are not methodological. They are dispositional. Genuine curiosity about people unlike you, patience with ambiguity, and the willingness to be wrong about what you were sure you understood.
Riding the minibus was not a research technique. It was a commitment to understanding a problem on its own terms, in its own context, before forcing a framework onto it. The insight that drove Kabba's product, the real job and the commitment architecture behind it, came out of that. No template would have produced it.
The best product work I have seen starts with someone who cared enough about the problem to live inside it before trying to solve it. No process gets you there. You just have to choose it.