Guide 01 / Choose a Segment
Choose one segment for your next outbound test
You have a use case that works. The risk now is not that you lack options; it is that you keep all of them open. This guide helps you commit to a single segment for a single experiment, and write down why before you spend a week on it.
Start with the use case, not the market
This guide assumes you already have a proven use case: at least some customers use your product for a specific job and keep using it. If that is not true, a segment choice will not rescue you, and the honest next experiment is about the product, not outreach.
Write the use case as a sentence a customer would recognize: “We use it to do X when Y happens.” Avoid category words like platform or solution. If you cannot name the moment (the Y), you are not ready to choose a segment, because the segment is the set of companies where that moment happens often enough to hurt.
Then list the customers you already have. Do not generalize yet. Note, for each, what they were doing before, what triggered the purchase, and who actually signed. Those three facts are the raw material for everything that follows.
What counts as a segment
For this working method, define a segment more narrowly than an industry. “Healthcare” alone is too broad to explain the test. Look for a group of companies you can list by name, with a plausible shared trigger and similar buying roles. A practical check: could you build a manageable list, and would the same opening sentence make sense to every company? This is a test design preference, not a source-established requirement.
Three cuts tend to produce segments that are narrow enough to test:
- By trigger. Companies that just changed something: a new compliance obligation, a first ops hire, a migration, a funding stage that adds reporting duties.
- By workflow. Companies that run a particular process by hand today, visible from job posts, public tooling, or their own descriptions of how they work.
- By role structure. Companies with a specific team shape, such as a lone finance lead with no analyst, where your product fills a gap.
Evidence of behavior beats stated preference
When you decide why a segment might care, lean on what people did, not what they said they might do. Strategyzer’s write-up on customer jobs, pains and gains makes this argument directly: it frames past behavior as better evidence than opinion when you describe what customers are trying to get done.
As a practical hypothesis, put something observable in the trigger field: a job post, a changed filing, a tool they installed, or something a current customer actually did before buying. “They probably struggle with reporting” is a guess. A dated record of a customer's actual hiring and purchase sequence is something you can check. Even a real sequence would not establish that the hire caused the purchase.
Score three candidates, then pick one
A practical starting point is three candidate segments, to make comparison manageable. Three is not a scientifically established optimum. For each, answer four questions in a sentence rather than inventing a numerical score:
- Reachability. Can you build a manageable list of named companies with a plausible contact at each?
- Trigger visibility. Can you see the trigger from outside, or are you guessing?
- Proximity to proof. Which current customers actually resemble this segment?
- Cost of being wrong. If the reply is silence, which uncertainties will remain?
Keep the fourth question explicit. Silence is ambiguous even with a visible trigger: delivery, timing, contact selection and the message remain possible explanations. Do not call silence proof that a segment has no need. Prefer a test where you can check those competing explanations, and record what you still cannot distinguish.
Choose the segment with the best combination of reachability and proximity to proof. Break ties by picking the one where the trigger is most visible. Then stop deliberating: the other two candidates go in a file, not in your head.
Write the hypothesis in one breath
A usable hypothesis has four parts: the segment, the trigger, the claim, and the observation that would count against you. Template: “[Segment] that [trigger] will [respond to a specific offer] because [behavior you have seen].” Notice there is no number of meetings in it. A hypothesis is a claim about the world, not a quota.
Founder-run outreach is the counter-option worth naming here. Many teams reach for outsourcing the moment sales feels uncomfortable. A Reddit r/SaaS thread on technical founders and sales shows founders describing missed follow-ups, delayed demos and unclear targeting. Those are anecdotes from self-selected posters, not representative data, and they do not show that outsourcing fixes anything. A founder-run routine of one segment, one message and a fixed review day is a legitimate alternative, and for a first test it keeps the learning in the building.
Set the decision rule before you send
The decision rule says what you will do under each outcome, written while you are still neutral. Name a send window, a minimum amount of evidence, and three branches: continue, change one variable, or drop the segment. The rule exists so that a weak week does not become a story about bad luck, and a good week does not become a story about destiny.
Keep it boring and specific. If the rule needs a paragraph, the experiment is too large.
Next step
Take your chosen segment and the hypothesis sentence into the buyer map. You will need to know who feels the problem, who champions a change, and who controls the budget before you write a single message.
Sources for this guide
- Kurt Bostelaar, “How to capture customer jobs, pains & gains that aren’t subjective,” Strategyzer, July 25, 2016. Used for the past-behavior principle only.
- A Reddit r/SaaS thread on technical founders and sales. Anecdotal; no author or date is attributed here.