It was 3:47 PM on a Thursday. The product team at one of the big tech companies had spent six weeks defining their new AI-powered workflow tool. Roadmap? Done. Feature spec? Finalized. Stakeholder buy-in? Check. But when the lead product manager stood up to present the "target user" slide, the room went quiet.
“We’re building for knowledge workers who need to automate repetitive tasks.”
A pause. Then the VP of Product leaned forward.
“That’s everyone from lawyers to marketers to engineers,” she said. “Which one are we actually shipping to first?”
The room froze. No one had an answer.
This scene plays out weekly across Silicon Valley. Teams ship products designed for “everyone,” only to land with a thud. Adoption stalls. Retention flatlines. And leadership starts asking: Who the hell are we building this for?
Here’s the truth: choosing your initial user segment isn’t step three. It’s step zero. And if you get it wrong, nothing else matters.
The “Who” Decision Happens in the Debrief — Not the Workshop
Most teams treat user segmentation like a checkbox. They run a workshop, whiteboard a few personas, and move on. But in high-performing orgs, the real decision happens weeks later — in the debrief.
I was in one last month. The product lead had just presented the first round of user interviews. Eight sessions. Target: mid-level operations managers at SaaS companies.
“Three of them said they’d pay $50/month,” she said. “But two of those were using Zapier already. The other two? They manually copy-paste data between systems because their IT won’t approve new tools. They said any automation would save them 10 hours a week.”
The head of engineering raised a hand. “So the ones using Zapier are our buyers, but the ones doing manual work are our real pain point?”
“Exactly,” said the PM. “But the manual workers don’t control budgets.”
Silence. Then the VP leaned in.
“Then our GTM strategy is wrong. We’re pitching to budget-holders. But the people who feel the pain don’t have purchasing power. So we need to design for the manual workers, but make it easy for a director to say yes.”
That was the pivot. Not in a persona doc. In a 20-minute debrief where real data collided with incentive structures.
Insight #1: Your first user segment isn’t defined by job title — it’s defined by asymmetric pain.
It’s not who could benefit. It’s who will scream if you don’t launch. And that pain needs to be uneven — worse for some than others. That imbalance creates urgency. And urgency drives adoption.
We ran the numbers. The ops managers doing manual data entry spent 12–15 hours weekly on repetitive tasks. The ones using Zapier? Maybe 2–3 hours optimizing workflows. Same role. Vastly different pain levels.
So we narrowed. Not “ops managers.” Ops managers at Series B–D SaaS companies with <5 automation tools approved. That specificity became our beachhead.
Because vague segments create vague products. Specific segments force trade-offs. And trade-offs build focus.
The Hiring Committee Test: A Litmus for Real Focus
Here’s a test I use in every product kickoff: Could you hire someone based on this user definition?
Most can’t. “Knowledge workers” isn’t a job description. “People who want to be more productive” isn’t a resume.
But this is:
“Hiring: Operations Specialist at a 100–300 person tech company. Spends >10 hours/week moving data between CRMs, spreadsheets, and support tools. Cannot install new software without manager approval. Willing to use workarounds (e.g., personal Gmail, unofficial scripts) to get work done.”
That’s unambiguous. You could post that on LinkedIn and get 200 applicants.
More importantly, you could build a product for them.
I ran this test with a team building a debugging tool. Their initial segment? “Backend engineers at fast-growing startups.”
Sounds good. Until you ask: would you hire someone based on that?
No. Too broad. “Backend engineer” could mean anything from a senior architect to a junior on-call responder.
So we drilled:
- Who gets paged at 2 AM when the API fails?
- Who can’t fix it because logs are scattered across seven systems?
- Who’s under pressure to ship features but spends 40% of their time firefighting?
Ah. Now we’re talking.
New version:
“Hiring: Mid-level backend engineer at a startup scaling past 1M DAUs. On rotation for backend incidents. Uses at least 3 logging tools. Spent ≥20 hours last month diagnosing production issues. Frustrated by lack of ownership and fragmented tooling.”
Now we have focus.
And with focus, velocity.
The team shipped a unified log viewer in six weeks — not because they worked harder, but because they didn’t waste time debating edge cases for frontend devs or site reliability engineers.
Insight #2: If your user segment can’t survive a hiring committee review, it’s not specific enough.
Real segments have behaviors, constraints, and incentives. They’re not demographics. They’re ecosystems.
And ecosystems have gatekeepers.
Stakeholder Mapping Isn’t Fluff — It’s Strategy
One of the most underrated moves in product? Stakeholder mapping. Not the consultant-style org chart. The real one. The who controls what map.
I sat in on a meeting last quarter where a team was launching a collaboration tool for remote teams. Their “user” was the individual contributor. But adoption was stuck.
“People say they love the prototype,” the PM said. “But they’re not signing up.”
“Who approves software purchases?” I asked.
“Their manager.”
“And does the manager see value?”
“Not really. The tool helps the IC save time, but the manager doesn’t get anything out of it.”
There it was. The misalignment.
The team went back and redesigned the dashboard. Not just showing individual activity, but team-level insights: “Your team saved 17 hours this week on status updates.” “90% of tasks are moving faster through review.”
Suddenly, managers had a reason to approve it.
Adoption jumped 3.2x in two weeks.
Insight #3: The user and the buyer are often different — and ignoring that kills products.
We see this in enterprise. We see it in consumer. We even see it in open source.
- Parents use educational apps. But they don’t download them. Kids do.
- Doctors use clinical tools. But hospitals buy them.
- Engineers use developer tools. But CTOs approve budgets.
If your value proposition doesn’t align across both, you die in pilot purgatory.
The fix? Map the stakeholder web early.
Draw three circles:
- Primary user — Who feels the pain?
- Decision maker — Who controls access or budget?
- Influencer — Who shapes opinions?
Then ask: what does each one need to say yes?
For the ops tool team, it looked like this:
- User (Ops Specialist): “This saves me 10 hours a week.”
- Decision Maker (Director of Ops): “This reduces risk and audit issues.”
- Influencer (IT Security): “This doesn’t create shadow IT risks.”
They built three onboarding flows. Three value propositions. One product.
Result? 78% conversion from free trial to paid — well above the 45% benchmark for B2B SaaS.
The “Five Whys” of User Selection
Most teams pick user segments based on market size. “There are 5M knowledge workers — huge TAM!”
Wrong approach.
Market size doesn’t matter if you can’t reach them, convert them, or retain them.
Better to ask: Why this user? And then keep asking why.
I use a technique I call the Five Whys of User Selection. Here’s how it played out with a team building a no-code analytics tool.
Q1: Why this user segment?
“We’re targeting analytics engineers at mid-sized tech companies.”
Q2: Why them?
“Because they bridge data and product teams, and they’re overwhelmed with ad-hoc requests.”
Q3: Why focus on overwhelmed ones?
“Because they’re actively looking for tools to reduce manual work. Others are comfortable with SQL and existing BI tools.”
Q4: Why not just target all data teams?
“Because the non-overwhelmed ones won’t feel urgency. And the overwhelmed ones will become evangelists if we solve their pain.”
Q5: Why does that matter?
“Because we need early adopters who will give feedback, tolerate bugs, and refer others. Comfortable users won’t do that.”
Boom. Now you have a strategy, not a demographic.
This line of questioning exposed something critical: they weren’t just solving a workflow problem. They were solving a career stress problem. Analytics engineers who can’t scale their output get passed over for promotions.
So the real value wasn’t “faster queries.” It was “look like a rockstar during review season.”
That shifted the entire messaging and feature roadmap.
They added workload analytics: “You’ve automated 67% of your recurring requests.” And team impact: “Your changes saved the product team 42 hours of waiting.”
Features that didn’t exist in the original spec.
The takeaway: Your user segment isn’t static. It evolves as you learn.
And it should be tied to a behavioral trigger — not just a job title.
- It’s not “marketers.” It’s marketers who are manually resizing 50 images a week for social.
- It’s not “developers.” It’s developers who’ve had to explain a production outage to their CEO.
- It’s not “teachers.” It’s teachers grading 150 essays on weekends.
Find the trigger. Build for the moment. Then expand.
The Counter-Intuitive Truth: Smaller Segments Win
Here’s what most founders and PMs refuse to believe: smaller is faster.
I worked with a team that had a great AI meeting tool. Early feedback was strong. But growth stalled at 15,000 MAUs.
Their segment? “Remote teams who run a lot of meetings.”
Vague. So we narrowed.
We analyzed usage data. Found a cluster: engineering leads at pre-IPO startups. They ran 2–3 standups daily, 10+ cross-team syncs weekly, and were drowning in Jira updates.
So we rebuilt the onboarding for them. Added engineering-specific templates. Integrated with GitHub. Made action items auto-create tickets.
We didn’t just tweak the product. We changed the landing page. The ads. The outbound emails.
Result: 4.1x increase in activation rate. 68% higher retention at Day 30. And — crucially — 5.3x more referrals from that segment.
Why? Because they saw themselves in the product. Not as “a remote worker,” but as “an eng lead who hates follow-up emails.”
Then we expanded. But only after proving the model.
This is the pattern: narrow to accelerate, then scale with confidence.
Most teams do the opposite. They start broad, get mediocre results, and wonder why they can’t gain momentum.
But momentum comes from resonance. And resonance comes from specificity.
FAQ: Real Questions from Product Teams
Q: What if our leadership insists on targeting a broad market for investor reasons?
A: Give them the beachhead strategy. “We’re starting with X because they have the highest pain and fastest adoption. Once we dominate there, we expand to Y and Z. Here’s the data from our pilot: 82% of respondents said they’d pay, and 60% converted in the trial.” Investors fund focus, not fantasy.
Q: How do we pick between two strong segments?
A: Run a 2-week validation sprint. Pick 5 users from each. Show them a prototype. Ask: “If we launched this tomorrow, would you use it? Why or why not?” The segment with stronger emotional response wins. (Bonus: record the sessions. Play the “I need this now” clip in your next stakeholder meeting.)
Q: Isn’t narrowing risky? What if we miss a bigger opportunity?
A: The real risk is building something nobody loves. You can expand later. You can’t resuscitate a dead product. Start where the fire is. Then bring the water.
Q: How small is too small?
A: If you can’t find 1,000 people who fit your segment and have the problem, it’s too small. If you can, it’s a beachhead. One team started with “frontend engineers at YC startups using React who’ve shipped a design system.” Less than 2,000 people. They got acquired in 14 months.
Q: What if the user and buyer are in different companies?
A: Then you’re in a two-sided market. Think marketplace dynamics. Who has the stronger incentive to join first? Usually, it’s the side with more pain. Focus there. Create value. Then use that to pull in the other side. (See: Slack’s early strategy with small teams, not IT departments.)
Final Thought: Who Are You Really Building For?
Next time you’re in a roadmap meeting, don’t ask: “Who is this for?”
Ask: “Whose job will this make dramatically easier?”
“Who will tell their team about this unprompted?”
“Who will panic if we shut it down?”
Find that person. Name them. Write their job description.
Then build like their success depends on it.
Because it does.
And so does yours.