# SaaS audience hypothesis and evidence worksheet

Use this worksheet to define whom to learn from and why. Keep unknowns visible. The example is fictional and does not establish demand.

## 1. Name the decision

- Definition owner:
- Version and date:
- Decision this definition supports:
- Current product or offer constraints:
- Review date or evidence that triggers a review:

## 2. Describe the workflow

- Job the customer wants to accomplish:
- Context in which it happens:
- Problem and consequences:
- Trigger for considering change:
- Current alternatives and why they persist:
- Result our product could provide:
- Most important uncertainty:

## 3. Separate the people involved

| Role | Who performs it | Relevant concern | Observed evidence | Unknown |
|---|---|---|---|---|
| User | Fill in | Fill in | Fill in | Fill in |
| Champion | Fill in | Fill in | Fill in | Fill in |
| Buyer | Fill in | Fill in | Fill in | Fill in |
| Reviewer | Fill in | Fill in | Fill in | Fill in |

One person may hold multiple roles. Titles are discovery clues, not proof of authority.

## 4. Classify audience criteria

| Criterion | Requirement, discovery filter, or temporary constraint | Why it matters | How to verify | Consequence if absent |
|---|---|---|---|---|
| Fill in | Fill in | Fill in | Fill in | Fill in |

List explicit disqualifiers separately. Avoid using a convenient search filter as a product requirement without evidence.

## 5. Keep the evidence ledger

| Claim | Original observation and source | Date | Interpretation | Contradicting evidence or limitation | Next question |
|---|---|---|---|---|---|
| Fill in | Fill in | Fill in | Fill in | Fill in | Fill in |

Record missing evidence as missing. Do not fill gaps with invented quotes or purchasing intent.

## 6. Compare candidate segments

Use supported qualitative judgments before adding numeric scores.

| Segment | Problem consequences | Product fit | Reachability | Buying obstacles | Delivery effort | Main uncertainty |
|---|---|---|---|---|---|---|
| Segment A | Fill in | Fill in | Fill in | Fill in | Fill in | Fill in |
| Segment B | Fill in | Fill in | Fill in | Fill in | Fill in | Fill in |

- Segment selected for the next test:
- Evidence supporting the choice:
- Alternatives retained for later:
- Conditions that would change the choice:

## 7. Write the hypothesis

“We are testing whether [people in a specific context] who encounter [problem or trigger] can achieve [result] with our product, provided [requirements]. We will initially reach them through [observable route].”

- Next test:
- Owner:
- Result to observe:
- Review condition:

## Fictional completed hypothesis

We are testing whether engineers investigating recurring API test failures can reach a useful diagnosis with our monitoring product, provided their test environment is supported. We will initially recruit through existing engineering relationships and relevant discussions we participate in. Integration compatibility is a requirement; company size is only a discovery filter until evidence shows that it changes product fit. Actual urgency and purchasing authority remain unknown.

## 8. Record revisions

| Version and date | Criterion changed | New evidence | Decision affected | Owner |
|---|---|---|---|---|
| Fill in | Fill in | Fill in | Fill in | Fill in |


---
Original resource by Jon Bishop. CC BY 4.0. Illustrative examples are not customer results.