The Customer Solution Brief (Post 4 of 10)
Most executive teams, when they sit down to define customer types for the first time, assume they already know what they’ll find. They expect the exercise to confirm what experienced people in the organization have always understood informally: that certain customers behave differently, buy differently, and succeed differently than others. What they don’t expect is how much the act of writing it down changes the conversation.
The Customer Solution Brief doesn’t start with the brief itself. It starts with the question that most companies have never answered formally: which distinct customer types actually exist inside the ICP? Getting that answer right is the prerequisite for everything else. Build briefs on top of poorly defined customer types and you’ll end up with artifacts that don’t map to the real patterns in your business. Get the customer types right and the briefs write themselves from the evidence already in the organization.
Start with the Divergence, Not the Average
The trap most companies fall into at this stage is averaging. They look at their customer base, identify the characteristics that most customers share, and use those as the definition of their customer type. This produces a customer type that describes the median customer reasonably well and no actual customer very well at all.
The right starting point is divergence. Where does your customer base split in ways that matter for how you sell, implement, or measure success? Not every dimension of variation is meaningful. Customers can vary in size, geography, tech stack, team structure, procurement process, and a dozen other ways without those differences changing what the product does for them or what value realization looks like. The question is specifically: where does variation in the customer produce variation in the value pattern?
A company selling a field operations platform might notice that their construction customers and their facilities management customers use the same core product. But the construction customer is trying to manage work across dozens of active job sites simultaneously, where the dominant problem is coordination across projects in various stages of completion. The facilities management customer is managing a fixed portfolio of assets and the dominant problem is scheduled maintenance compliance. Same product. Different core problem. Different value thesis. Different demo. Different success definition. These are two customer types, not one.
Four Dimensions That Usually Reveal the Split
Most customer type distinctions that matter for the brief cluster around four dimensions. These aren’t the only dimensions that produce meaningful splits, but they’re the ones worth examining first.
The first is the core problem. If two groups of customers inside the ICP are using the product to solve fundamentally different problems, they are almost certainly distinct customer types regardless of how similar they look on the outside. The test is whether you could use the same discovery conversation and the same demo flow with both groups and have both conversations land well. If the answer is no, you likely have two customer types.
The second is the buyer and the decision process. The person making the purchase decision and the dynamics of that decision process vary significantly across customer types in ways that matter for how you sell. A CFO-led purchase has a completely different evaluation framework than a department-head-led purchase, even if both buyers are inside the same ICP. If the economic buyer, the champion profile, and the evaluation criteria differ in ways that change the sales motion, that’s a meaningful dimension of customer type distinction.
The third is implementation complexity and configuration. Where do implementations look fundamentally different in scope, in configuration, in the integration requirements, in the stakeholders involved, in ways that aren’t simply explained by deal size or team size? If a medical device implementation consistently involves quality management system integration and a life sciences implementation consistently doesn’t, that’s a structural difference that the brief needs to reflect.
The fourth is the success definition. What does a healthy account look like at twelve months, and does that picture vary in ways that go beyond volume metrics? If the adoption pattern for one customer type is structurally different from another such as different workflows, different leading indicators, different expansion triggers, you have two customer types and you need two success definitions.
The Workshop That Makes It Real
The most effective way to identify customer types is a structured workshop with the people who know your customers best: experienced sales reps, implementation leads, and customer success managers. Not a product team exercise alone. Not a leadership offsite. The people who have spent the most time in front of customers and inside their accounts hold the pattern recognition that makes this work.
The workshop typically runs in three parts. The first part surfaces the patterns: participants map their five most and five least successful customers and articulate what made each one succeed or struggle, without prompting from a framework. The second part finds the clusters: facilitated analysis of the patterns surfaces the dimensions of variation that recur most consistently. The third part stress-tests the emerging customer types: for each proposed type, the group works through a discovery scenario, a demo approach, and a success picture to see whether those things hold together as a coherent pattern. Customer types that collapse under this test need to be redefined or merged.
The output of the workshop is typically a set of three to five proposed customer types, each described by the four dimensions above. These are not final briefs yet. They are the raw input from which the briefs are built.
From Customer Types to Briefs
Once the customer types are identified, the brief for each one is built from evidence already in the organization. Win stories from that customer type populate the value thesis and the sales motion. Implementation documentation from similar accounts populates the guidance section. Health data from the customer success team populates the success definition. The brief is mostly an exercise in making explicit what the organization already knows implicitly, in a form that can be shared, updated, and acted from.
The briefs should be reviewed by at least one senior person from each function: sales, product, implementation, and customer success, before being published as operating documents. Their job is not to approve the brief but to catch where the language doesn’t match their operational reality. A brief that customer success can’t recognize as describing their experience with that customer type is a brief that won’t be used.
The most important thing about building the first brief is that you finish it. It does not need to be perfect. It needs to be specific enough that sales can use it in a discovery conversation, product can reference it in a roadmap discussion, and customer success can compare an account’s trajectory against it. That bar is achievable in a matter of weeks. And once the first brief exists, the value of the second one becomes immediately apparent.
NextPeak Studio facilitates customer type identification and brief development with leadership teams at scaling B2B SaaS companies. If you’ve been running on informal customer knowledge and want to make it systematic and transferable, that’s precisely the work we do.