The Customer Solution Brief (Post 5 of 10)
The product roadmap planning cycle is one of the most reliably frustrating recurring events in a scaling B2B SaaS company. The people in the room usually aren’t the issue. The inputs they’re working with are fundamentally incomplete for the decisions that need to be made. Feature requests arrive from multiple directions, with sales flagging what prospects asked for, customer success escalating what accounts need, and product leadership asserting what the market requires, and there’s rarely a common framework for evaluating which requests actually belong on the roadmap.
The most common response to this is to add more process. A structured intake form. A scoring matrix. A customer advisory board. These help at the margin, but they don’t solve the underlying problem. The underlying problem is that without a clear definition of which customer types the company is building for, there’s no principled basis for deciding which requests align with the strategy and which are one-off asks from accounts that don’t represent the future of the business.
The Customer Solution Brief changes this, because it establishes the customer-grounded context that makes existing processes work better.
Feature Requests Without a Brief
Consider what actually happens when a feature request lands in product without a brief to evaluate it against. A sales rep flags that three enterprise prospects in the last quarter asked for a specific reporting capability. The rep believes this feature is costing deals. Product acknowledges the signal. The debate begins: how many customers actually need this? Is this a niche ask or a broad requirement? Does it fit the product vision? Who makes the call?
These debates are difficult because the question being asked is genuinely hard to answer without customer-type context. The three prospects who asked for the feature might be a distinct customer type with a legitimate structural need, or they might be outliers, accounts that fit the ICP by the numbers but represent a pattern of value creation the company hasn’t committed to building for. Without the brief, no one in the room has a reliable way to tell.
The conversation usually ends with a decision that satisfies the room but doesn’t actually answer the question: build a lightweight version, deprioritize but monitor, add it to the backlog. These are political outcomes masquerading as strategic ones. They’re what happens when decisions are made without the right frame.
What Changes with the Brief
When a feature request arrives in a company where the briefs are operational, the first question shifts from “should we build this?” to “which customer type is this for?” That question has a structured answer. The team can look at the briefs, identify whether the requesting customers fit a defined customer type, and evaluate the request against the value thesis and capability set for that type.
If the request fits a defined customer type and the capability supports the value thesis for that type, the case for building it is strong. If the request comes from accounts that fit the ICP but don’t match any defined customer type, that’s a different conversation: is this the beginning of a new customer type that warrants a new brief, or is it a signal that an existing brief needs refinement? If the request comes from accounts that are genuinely outside any customer type the company is building for, it means the account may not be the right fit, which has implications beyond the roadmap conversation.
This doesn’t make product prioritization frictionless, but it does replace circular debate with a tractable framework, one that shifts the question from “whose opinion about the customer wins” to “which customer type does this serve and does it fit the brief.” That’s a question the room can actually answer.
The Roadmap as a Customer-Type Portfolio
The most mature version of this approach treats the roadmap as a portfolio of investments across defined customer types. Each capability on the roadmap traces to a customer type and a section of that type’s brief, whether that’s the value thesis, the implementation guidance, or the success definition, and the roadmap conversation becomes a conversation about investment balance across the customer types the company has committed to serving.
This framing makes trade-offs visible in a way that the traditional roadmap conversation doesn’t. When the company is considering a significant investment in a capability that serves one customer type heavily but has limited applicability to others, the question becomes explicit: is this the right moment to weight this customer type, given the current pipeline, the current renewal picture, and the current competitive pressures in this segment? That’s a strategic conversation. It’s harder to have, but the outcome is much more likely to reflect actual priorities rather than whoever argued most effectively in the planning meeting.
It also changes the relationship between product and sales in a useful way. When sales brings feature requests to product and product can evaluate them against a shared customer-type framework, the conversation stops being adversarial, because both functions are working from the same framework to evaluate the same requests instead of talking past each other about who understands the customer better. When they disagree, they disagree about strategy, about which customer type to prioritize and which value thesis to invest in, rather than about whose read on the customer is correct.
The Capability Gap as a Product Signal
One of the less obvious benefits of the brief is that it creates a named gap between the capabilities the brief says matter for a customer type and the capabilities the product currently delivers, and that gap functions less like a flaw in the product and more like a roadmap in disguise.
Most companies maintain some version of a capability gap analysis, but it tends to be abstract, a list of features competitors have that the company doesn’t, or a list of things customers asked for that haven’t been built. When the gap analysis is grounded in briefs, it becomes specific: for this customer type, the value thesis depends on three capabilities, and the product delivers two of them fully, one partially, and one not at all. That’s a prioritization conversation with actual stakes attached.
The brief doesn’t replace product judgment and never will, but it gives product leadership a customer-grounded framework for exercising that judgment in a way the rest of the organization can understand and connect to its own work. When the roadmap is explained in terms of customer types and briefs rather than features and themes, the alignment across functions that every leadership team wants becomes achievable through a shared understanding of who the company is building for and why.
NextPeak Studio works with product and GTM leadership teams to establish customer-type frameworks and brief-driven roadmap processes at scaling B2B SaaS companies. If your roadmap debates feel like they’re repeating themselves, the frame is the problem.