Problem Framing, Customer Segments and Stakeholders

Frame the problem before expanding the solution

A useful problem statement is not a broad slogan such as “booking is difficult.” It connects a defined group with a clear context and an observable behavior or outcome. A practical structure is: Who experiences the situation? When or where does it occur? What do they do now? What undesirable outcome appears? What do we still not know? This structure does not prove causation, but it prevents observation from being mixed with interpretation and clarifies what should be learned next.

An initial segment is not “everyone who might buy”

An initial segment supports learning when it groups people around a context that is relevant to the problem. Age or occupation alone may not be enough. In our case, “independent tutors who personally manage a relatively high number of changing appointments each week” may be more useful for learning than “all tutors.” If later evidence shows that appointment volume does not change the problem, we revise the segment. Segmentation here is a working hypothesis for grouping similar situations, not a final market boundary.

When describing a segment, ask: What behavior or condition makes the problem more likely? Does the person coordinate personally or through an assistant? Are appointments stable or frequently changed? Is the customer an individual or an organization? These questions make later interviews more comparable. They do not justify excluding people simply because they do not match the founder’s mental image; the criterion should relate logically to the problem, not to convenience or bias.

User, customer, payer, and stakeholder

In a venture, these roles may be combined or separated. A user interacts with the product or service. A customer is the party making the purchase or contracting decision in the situation being studied. A payer bears the payment when that role is separate. A stakeholder can influence the decision or be affected by it. These are practical case roles, not universal legal or accounting definitions; in an institutional contract, local rules may define responsibilities more precisely.

Observation is not a proven cause

If a tutor says, “I forgot to update one appointment last week,” that is an observation about an event. When we say, “the cause is too many tools,” we have moved to an interpretation that needs evidence. The cause could instead be unusual workload, unclear responsibility for updating, or a problem with a single tool. Record the observation and interpretation on separate lines. This habit makes it easier to design a question or test that distinguishes competing explanations rather than building around the first plausible story.

Good problem framing does not make us “certain” about the problem; it makes us more precise about what we claim and what we need to learn. When we move to interviews, we can choose whom to speak with and why, and interpret answers in light of role and context rather than averaging unlike opinions into one meaningless result.