The slides were immaculate, the platform diagram was a work of art and everyone is smiling and nodding. Then someone else asks:
“Who is this for, and why does it matter to them right now?”
In SMB land, this question is a flashlight. In enterprise, it’s a floodlight. You see buyers who never touch the product, teams who live in it, a platform no one truly ‘owns,’ and the workaround powering half the business.
If your team can’t answer that question in one sentence, you don’t have product strategy. You have momentum without aim.
Let’s fix that, and make it scale from SMB to enterprise.
The “Who & Why” Product Statement
For [target customer] who [statement of need/opportunity], the [product name] is a [category] that [core benefit/compelling reason to buy]; unlike [primary alternative], our product [primary differentiation].
This is your product vision, stripped to essentials: Who (audience) and Why (purpose + value). Get this right and everything downstream (pricing, roadmap, go-to-market) gets a lot easier.
First, declare the scope
Before you fill in the blanks, clearly define what this product statement is for:
- [Company]: brand-level north star (rarely useful for shipping decisions)
- [Portfolio]: a family of products (helps allocate bets)
- [Product]: a specific product/SKU (most common)
- [Platform]: shared capabilities for internal/external teams
Rule: the larger the scope, the more your “Who” becomes an internal customer (team/role), and the more your “Why” becomes a system outcome (throughput, risk, compliance, cost-to-serve).
What goes in (and what doesn’t)
- Who: Smallest real segment you can win. If you need “and,” you’re usually too broad.
- Need: The costly moment without you. Concrete beats poetic.
- Benefit: Outcome in customer words. If you can’t measure it within 90 days, it’s not your benefit.
- Alternative: Name what they actually use today (spreadsheets, status quo, a big competitor).
- Differentiation: One edge you can defend. Setup time, workflow ownership, accuracy, total cost. Pick one.
Be specific and realistic. “For enterprise companies” is not a who and “game changer” is neither measurable nor a differentiator.
Examples by scope (Steal These Patterns)
[Product] SMB Scheduling
For owner-operators who lose revenue to no-shows, “AcmeSlots” is a lightweight scheduler that auto-confirms and fills last-minute gaps; unlike bloated suites, it sets up in 10 minutes and can run entirely from your phone.
[Platform] Enterprise Localization
For global web teams who need production-ready translations without engineering bottlenecks, “AcmeTranslator” is a page-aware localization platform that ships in days; unlike generic MT plug-ins, it preserves layout context and lets teams approve copy without tickets.
[Team Capability] Data Platform (Internal Customers)
For analytics engineers who spend days stitching event data across tools, “AcmeEvents” is a governed event pipeline that standardizes schemas and guarantees delivery; unlike ad-hoc scripts, it enforces contracts, flags drift in real time, and prevents model breakages.
[Portfolio] Trust & Risk
For risk management teams who must onboard vendors without slowing launches, “AcmeSafety” is a third-party risk portfolio that unifies questionnaires, controls, and continuous monitoring; unlike one-off assessments, it proves control adherence and shortens approvals from weeks to days.
How I run this workshop
This isn’t my exact agenda but enough to get you started:
- Identify and Pick the Scope
- Focus on the specific coverage for this product statement: Company / Portfolio / Product / Platform / Team Capability
- Name the Who
- Look at the primary revenue-dense segment, the primary team with a job to be done, or find a clean way to encompass a specific known group. This is often the hardest part to get right.
- Write the Why
- Be realistic and look for those things that can be measured in 30–90 days, or name a specific outcome.
- Identify the specific Alternative
- The behavior you’re actually displacing (status quo, suite module, internal workaround)
- The Differentiator
- Not just easier to use, get specific. How exactly is this product different from the rest so that it wins.
- Test it and Commit
- Would 80% of customers nod their head?
- Does the current roadmap align with the who and why?
- Can sales pitch it in 30 seconds?
- What changes in the next 90 days if this is locked in?
Watch out for ambiguity
It’s tempting to circle too big a who and too vague a what. If your Who truly differs—buyer, team owner, or success metric—write a second statement. That isn’t a bad thing and it brings even more value in the long term. A forked product statement is a commitment to honest trade-offs and long-term focus. You might not fund that other segment today, but naming it keeps your roadmap from serving more than a single vision. Always label the scope so nobody confuses a team-level truth with a company vision.
Fork when the “Who” truly differs:
- Different economic buyer or admin owner (Procurement vs. Marketing vs. Security).
- Different primary user or success metric (ARR vs. audit pass rate vs. MTTR).
- Different deployment/integration center of gravity (Salesforce vs. ServiceNow or on-prem vs. SaaS).
- Different engagement/service model (self-serve PLG vs. CSM-managed/sales-assisted).
Don’t fork, fix when:
- It’s messaging drift, not a new audience.
- The ask is a feature preference (dark mode, export) within the same job-to-be-done.
- “Personas” are rebrands of the same user (e.g., “Analyst” vs. “Insights Lead”) with identical outcomes.
- Differentiation is tactical (e.g., “AI-powered”) rather than a new Who or Why.
Make forks explicit and governable:
- Publish a one-pager “Statement Index” with scope tags and owners.
- Map roadmap items to a single statement; deny items that try to straddle two.
- Review forks quarterly—merge or retire if evidence fades.
Examples
- [Product] AcmeSlots (SMB scheduling for owner-operators)
vs. [Portfolio] Acme Platform (franchise APIs for multi-location ops). - [Team Capability] Acme Events (governed event pipeline for Analytics Eng) vs. [Product] AcmeDashboards (self-serve dashboards for business users).
Make it real and commit
You spent the time to get here so put the scoped statement at the top of the roadmap, PRDs, design briefs, and internal docs. A great product statement makes teams decide faster and stay aligned. Call it out in your pitch decks, write marketing copy, replace your rotating hero headline with a stronger single callout.
Then review quarterly. Markets move and your product statement should too.