Customer discovery is typically framed as a research methodology. The goal is to identify potential customers, understand their problems, and validate whether a proposed solution addresses those problems. The tools are well established: customer interviews, observation, surveys, prototype testing. The output is a set of findings that inform product decisions.
Framed this way, customer discovery produces a specific kind of knowledge — data about what individual customers say they need, why they need it, and how much they would pay for it. This knowledge is useful. It is also incomplete in a way that produces consistently predictable product failures.
The gap is the system.
Every customer is embedded in a system: their organization, their community, their supply chain, their regulatory environment, their economic constraints. The problems they experience are produced by that system. The solutions they have tried and abandoned were constrained by that system. The behavior change a new product requires will succeed or fail based on whether it works within that system or requires the system to change. A customer discovery process that focuses on the individual customer and their stated problem produces solutions that address the symptom without understanding the system. The symptom shifts, or the solution creates a new symptom elsewhere, or the behavior change required to use the product is impossible within the system constraints the customer operates under. The product gets built, customers try it, and it does not stick — not because the product is wrong, but because the system was never mapped.
This article is about how to do customer discovery differently: how to approach it as a systems problem, what specific methods surface system-level understanding that interviews alone do not, and what that changes in practice for how product decisions get made.
Why "Listen to the Customer" Is Incomplete Advice
The dominant correction to bad product decisions is "talk to more customers." Founders who build the wrong thing are told they did not do enough discovery. This is true often enough to be plausible and wrong often enough to be dangerous. The failure is frequently not a quantity of discovery problem. It is a level of discovery problem.
A customer interview, however well conducted, returns the customer's account of their own experience. That account is filtered through what the customer is aware of, what they can articulate, and what they have already adapted to the point of no longer noticing. The customer is a reliable witness to their felt pain and an unreliable witness to its cause, because the cause usually lives in the structure around them — in the incentives of other actors, in constraints they have stopped questioning, in a history of failed fixes they were not party to.
So a founder can run fifty interviews, synthesize them rigorously, and still build a symptom-level product, because fifty accounts of the same symptom do not add up to an account of the mechanism that produces it. More interviews sharpen the description of the pain. They do not, on their own, surface the structure. The correction is not more discovery at the same level. It is discovery at a different level — the level of the system.
The Systems Framework for Customer Discovery
The framing that makes the difference is this: before mapping the customer's problem, map the customer's system.
A system, for this purpose, is the set of actors, relationships, incentives, constraints, and flows that produce the customer's current behavior. The customer is not making decisions in isolation. They are making decisions within a structure that shapes what is possible, what is costly, and what they are already optimized for. Understanding that structure requires answering a different set of questions than standard discovery asks.
Who else is in this system, and what are their incentives? A smallholder farmer making a procurement decision is not operating alone. They are operating within a web of relationships — input suppliers, cooperative officers, buyers, lenders, neighbors whose decisions they observe — and each of these actors has incentives that shape the farmer's options. A product that requires the farmer to change behavior in a way that conflicts with a powerful actor's incentives will fail to achieve adoption even if the farmer genuinely wants it to succeed. The farmer's "yes" is not sufficient; the system around the farmer has to permit the change.
What is the current system optimized for? Every system is optimized for something, even when the optimization is inefficient by some external standard. A cooperative procurement process that looks inefficient from the outside may be optimized for trust (only transacting with known counterparties), or for risk management (spreading purchases across multiple sources), or for social obligation (buying from members even when non-members offer better prices). Understanding what the system actually optimizes for tells you what a successful product must be compatible with — and what it must not threaten.
Where does the system produce the problem, and what maintains it? The felt pain a customer articulates in an interview is usually a symptom. The structural cause — the mechanism in the system that produces the symptom — is what must be addressed for the solution to hold. If the structural cause is not identified, the product treats the symptom and the system manufactures a new one. A useful test: if this product worked perfectly, what in the system would have to stop producing the problem, and is that thing actually within the product's reach?
What have previous solutions tried to change, and why did they fail? Every market has a history of failed solutions, and the failures are not random. They cluster around specific system constraints the previous designers did not account for. Understanding the failure history of a market is one of the highest-value activities in customer discovery, and it is almost never done — which is exactly why it carries so much signal.
The Methods That Surface System-Level Understanding
Standard discovery methods — interviews, surveys, prototype tests — are designed to elicit individual customer perspectives. They are not designed to surface system dynamics. Supplementing them with methods built for the system level produces a different quality of insight. Four methods do most of the work.
Process observation over surveys. Observing how customers actually do the work — not how they describe doing it — reveals system constraints that are invisible in interview data. Customers do not describe their workarounds in detail, because the workarounds have become automatic. They do not flag the constraints they have adapted to, because the adaptation feels like the natural order of things. Process observation makes the workarounds and adaptations visible, and workarounds are where the highest-value product opportunities live.
When the Bayanihan Harvest team was doing early customer discovery with agricultural cooperatives, the interviews produced a standard set of stated needs: better price transparency, simpler logistics coordination, more reliable buyer relationships. Process observation revealed something more specific. Cooperative purchasing committees were spending significant time in unstructured deliberation before every collective procurement decision, because there was no shared reference point — no agreed framework for evaluating purchase options that the committee could anchor to. The stated problem was coordination. The system-level problem was the absence of a decision reference that made deliberation efficient. Those are different products, and only one of them addresses the mechanism.
Ecosystem mapping over individual interviews alone. Before interviewing individual customers, map the ecosystem: who are all the actors in this system, what does each one want, and how do their incentives interact? This map becomes the frame within which individual interviews are interpreted. Without the map, an interview response is just a data point. With the map, the same response reveals where the customer sits in the system and how the system's constraints shaped their answer. The map turns isolated quotes into positions on a structure.
Competitor usage analysis. The customers using current solutions — even inadequate ones — are telling you which system constraints are non-negotiable. They have already filtered out solutions that demanded system changes the system could not make. The tools they have settled on, however poor, are compatible with the system as it currently operates. Understanding what those tools require the customer to give up — and they almost always require giving something up — tells you where the system has flexibility and where it does not. An ugly, persistent incumbent is a map of the system's hard constraints.
Failed solution archaeology. Before conducting a single customer interview, research the full history of attempted solutions in this market. Talk to the people who built them. Read the post-mortems if they exist. The consistent patterns in why previous solutions failed are the most important data in the discovery process: they tell you which system constraints broke previous products and which assumptions you must specifically avoid. This method is rarely used because it requires engaging with failure directly, which is uncomfortable. But the failed-solution history of a market is the most compressed form of system knowledge available. It contains, in distilled form, every hard-won discovery that previous builders paid for with time and capital.
The reason failed-solution archaeology outperforms fresh interviews is that failures encode the system's resistance more honestly than customers can describe it. A customer can tell you they did not adopt a previous product, but they will rationalize the reason — it was too expensive, it was confusing, the timing was wrong. The actual reason is usually structural and invisible to the customer: the product required a coordination step the system could not sustain, or it threatened an actor whose cooperation was load-bearing, or it assumed a behavior change the system's incentives quietly punished. The builder who lived through the failure, if you can find them, often does not know the structural reason either — but the pattern across several failures does. When three previous products in a market all died at the same point in the adoption curve, that point marks a system constraint, and the constraint is the single most valuable thing you can know before you build.
How System-Level Understanding Changes Product Decisions
The product decisions that come out of a systems-framed discovery process are substantively different from those that come out of a symptom-focused one. The difference shows up in four specific places.
Feature prioritization shifts toward system compatibility over feature completeness. A product designed from symptom-focused discovery tends to be feature-complete against a list of stated customer needs. A product designed from systems discovery tends to be deliberately minimal in features but carefully built to be compatible with the constraints of the system it will be deployed into. The second product is more likely to achieve adoption, because it asks less of the system. Completeness is measured against the customer's wishlist; compatibility is measured against the system's tolerances — and the system, not the wishlist, decides adoption.
Behavior change assumptions become explicit constraints. Every product requires behavior change from someone in the system. Systems-framed discovery makes those requirements explicit and tests them against the system's demonstrated capacity for change. If a required behavior change conflicts with a structural incentive, the product design is adjusted before the product is built — not after it ships and fails to gain adoption. The behavior change a product depends on is treated as a design input with a cost, not as a thing customers will simply do once the product is good enough.
Distribution strategy is designed around system actors, not just end users. In most systems, the end user's adoption decision is influenced — sometimes determined — by other actors. A product adopted by a cooperative member still needs the cooperative officer not to block it. A product adopted by a smallholder farmer still needs to be compatible with the input supplier's business model. Systems-framed discovery identifies these influencing actors and their incentives, so distribution can be designed to work with them rather than around them. The actors who can veto adoption are mapped as carefully as the actors who initiate it.
Success metrics become system-level, not user-level. A user who reports liking the product but keeps using the old system is not a successful outcome. Systems-framed discovery defines success in terms of actual system behavior change — are the actors in the system making different decisions because the product exists? — rather than satisfaction metrics that do not translate into behavior change. Liking is cheap. The metric that matters is whether the system now routes through the product instead of around it.
The Systems Framing Applied to Bayanihan Harvest
Bayanihan Harvest is built on a systems analysis of agricultural cooperative procurement in the Philippines, not a user-needs analysis of individual farmers.
The user-needs analysis would have produced a procurement transparency product: show farmers the current market price for their inputs, let them compare suppliers, and let them make more informed purchasing decisions. This is the product interviews suggest farmers want. It is also a product that would have failed, because it addresses the wrong level of the system. It treats the farmer as the unit of decision and information asymmetry as the binding constraint — and both of those are symptoms.
The systems analysis revealed that the binding constraint was not information asymmetry at the individual farmer level. It was coordination cost at the cooperative level. Cooperative purchasing committees were capable of achieving better collective outcomes than individual purchasing, but the coordination required to get there — the deliberation, the consensus building, the logistics alignment — was expensive enough that cooperatives consistently defaulted to decentralized individual purchasing that was individually sub-optimal. The system was not short of information. It was short of a cheap way to coordinate.
The product intervention was therefore designed at the system level: reduce the coordination cost of collective purchasing decisions by providing a shared decision reference, a structured deliberation protocol, and logistics coordination infrastructure the cooperative officer can operate without requiring a full member assembly. The individual farmer is a user of this system, but the system-level intervention is with the cooperative officer and the collective decision process. This is a different product from what interviews would have produced, and the difference is not cosmetic — it is the difference between addressing the mechanism and addressing the symptom.
Each element of the intervention maps to a specific finding from the system map rather than to a stated need. The shared decision reference exists because the system map showed that deliberation was expensive precisely because there was no common anchor — committees re-argued the evaluation criteria every cycle. The structured deliberation protocol exists because the map showed the coordination cost was procedural, not informational: the committee did not lack data, it lacked an agreed sequence for converting data into a decision. And the choice to route operation through the cooperative officer rather than the individual member exists because the map identified the officer as the actor with both the authority to run a collective process and the incentive to reduce its cost — the load-bearing node in the system, not the most numerous one. A transparency product aimed at farmers would have added information to a system that was not constrained by information, and the system would have routed around it. The intervention aimed at the coordination mechanism because that was where the map said the constraint actually lived.
Where Systems Discovery Becomes Costly
The systems frame is not free, and it is not always the right call. Mapping a system takes more time, more actors, and more tolerance for complexity than running a batch of user interviews. For a venture under acute time or capital pressure, the additional weeks of system mapping can be the difference between launching and not, and there are markets where the system is simple enough that symptom-level discovery is genuinely sufficient — a single decision-maker, no influencing actors, no history of failed solutions to read. In those cases, the heavier method is over-engineering.
There is also a real failure mode in the other direction: analysis that never converges. A system can always be mapped in more detail, and a founder temperamentally inclined toward structure can spend the venture's runway perfecting the map instead of testing an intervention. The systems frame is a means of producing better hypotheses faster, not a license to defer the bet indefinitely. The discipline is knowing when the map is good enough to act on — when you have identified the binding constraint and the actors who can block change — and then moving. The cost of staying at the system level too long is the same as the cost of never getting there: a product that never ships.
What You Can Adopt This Week
You do not need to adopt the whole method to get most of its value. Adopt one rule: before acting on any customer discovery finding, ask what system mechanism produces this finding, and whether the proposed intervention addresses the mechanism or the symptom.
If the answer is the symptom, the product decision may be premature. It may be worth the additional time to understand the system well enough to address the mechanism — because that is the intervention that produces durable behavior change rather than a temporary response the system routes around. Run this check against your three most recent product decisions. The ones where you cannot name the mechanism, only the symptom, are the ones most likely to under-perform in the market.
Customer discovery is not a research methodology. It is a hypothesis generation process about systems. The hypotheses worth acting on are the ones about system mechanisms, not surface-level symptoms — and getting to them requires mapping the system first. That is the work most customer discovery processes skip, and it is the work that decides whether the product sticks.
Continue in this series
This piece is part of The Indie Operator's Complete Guide to Running a Venture Portfolio, my systematic guide to venture building and modular architecture. Related reading:
- The Venture Failure Modes That Have Nothing to Do With the Product
- Venture Building in the Philippines: What the Standard Playbook Misses
- Digital Products That Sell Because They Solve a Real Problem
- Portfolio Governance: Running Multiple Ventures Without Losing Coherence
See how this plays out in practice across my portfolio of ventures.
