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 are constrained by that system. The behavior change that 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 changes, or the solution creates a new symptom elsewhere in the system, or the behavior change required to use the solution is impossible within the system constraints that the customer is operating under. The product gets built, customers try it, and it doesn't 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 this means in practice for how product decisions get made.
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 the system requires answering a different set of questions than standard customer discovery.
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.
What is the current system optimized for? Every system is optimized for something, even if the optimization is inefficient by some external standard. A cooperative procurement system that appears 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 is actually optimized for tells you what a successful new product must be compatible with.
Where does the system produce the problem, and what maintains the problem? The felt pain that 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 work durably. If the structural cause is not identified, the solution addresses the symptom and the system produces a new one.
What have previous solutions tried to change, and why did they fail? Every market has a history of failed solutions. The failures are not random — they tend to cluster around specific system constraints that the solution 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.
The Methods That Surface System-Level Understanding
Standard customer 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 that specifically surface system-level understanding produces a different quality of insight.
Process observation over surveys. Observing how customers actually do the work — not how they describe doing the work — 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 that they have adapted to because the adaptation feels like the natural way of doing 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. The 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.
Ecosystem mapping over individual user interviews alone. Before interviewing individual customers, map the ecosystem: who are all the actors in this system, what do they each want, and how do their incentives interact? This map becomes the frame within which individual customer interviews are interpreted. Without the map, an interview response is just a data point. With the map, it reveals where the customer sits in the system and how the system constraints shape their answer.
Competitor usage analysis. The customers who are using current solutions — even inadequate ones — are giving you information about which system constraints are non-negotiable. They have already filtered out solutions that require system changes that the system cannot make. The solutions they are using, however inadequate, are compatible with the system as it currently operates. Understanding what those solutions require the customer to give up (because they almost always require giving something up) tells you where the system's flexibility is and where it is not.
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 need to 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, all the hard-won discoveries that previous builders paid for with time and capital.
How System-Level Understanding Changes Product Decisions
The product decisions that come out of a systems-framed customer discovery process are substantively different from those that come out of a symptom-focused process.
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 designed 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.
Behavior change assumptions become explicit constraints. Every product requires behavior change from someone in the system. Systems-framed discovery makes those behavior change requirements explicit and evaluates them against the system's demonstrated capacity for change. If the required behavior change conflicts with a structural incentive in the system, the product design is adjusted before the product is built — not after it is deployed and fails to achieve adoption.
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 in the system. A product adopted by a cooperative member still needs the cooperative officer to not 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 influencer actors and their incentives, so distribution strategy can be designed to work with them rather than around them.
The product's success metrics are system-level, not user-level. A user who reports that they like the product but continues to use 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 as a result of the product's presence? — rather than user satisfaction metrics that do not translate to behavior change.
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, allow them to compare suppliers, and let them make more informed purchasing decisions. This is the product that interviews suggest farmers want. It is also a product that would have failed, because it addresses the wrong level of the system.
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 achieve those outcomes — 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 product intervention was 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 that the cooperative officer could operate without requiring 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. It required understanding the system — who the actors are, what they are optimized for, where the coordination cost lives — before designing the intervention.
The Discipline of Staying at the System Level
The practical challenge of systems-framed customer discovery is that it is easier to revert to symptom-focused discovery, especially under time pressure. System mapping requires more time, more actors, and more tolerance for complexity than individual user interviews. The temptation to simplify — to treat the individual customer as the unit of analysis and their stated need as the problem to solve — is constant.
The discipline that maintains system-level thinking is a simple 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 required 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 that the system routes around.
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 just surface-level symptoms. Getting to those hypotheses requires mapping the system first — and that is the work that most customer discovery processes skip.