I frequently see a similar question in some of my PM Slack groups: if AI reduces the cost of building software, do companies still need to pick or focus on a target segment?
In product management, a target user segment is a specific, defined group of users or customers with a common need that the product is designed to serve. Instead of building a product for “everyone,” a Product Manager (PM) narrows focus to a subset of the market that shares similar characteristics, needs, pain points, or behaviors.
Defining a target segment ensures the product solves problems for a highly motivated group of users, preventing wasted engineering resources on features nobody wants.
Take a growing B2B company with three promising requests. One prospect wants a new channel (say updates over Teams), another needs a different workflow, and a third asks for a different user experience.
A few years ago, engineering capacity forced a choice among them. With coding agents, the team may be able to build all three. So, should it?
I would still say no, or at least not yet, because building the feature was only the part of the commitment that used to be scarce.
When the sales team brings a request, it might look like a feature, but it is up to PMs to decide whether the request serves existing user segments or opens into a new user segment.
A new channel usually brings a buyer you have not previously sold to, and that buyer needs their own demo and their own proof of value. When you build a different workflow (say you bring agents into the workflow), then you serve a different job, so the team gets judged on new success metrics and against a new set of competitors. A different deployment model or user experience triggers its own review and integration work, and it often needs a separate sales motion.
AI cut the cost of writing the code, but it did not reduce the cost to:
Get a prospect to believe the product works for their job
Build the demo, integration, and reference story so the sales team can reuse it
Support the edge cases once the deal goes live
Offer a coherent roadmap that a team can explain without a footnote
If the company accepts all requests without thinking about the impact, then it will drift into different segments. Sales will now carry different stories. Similarly, support will manage unrelated sets of edge cases, and the team will spend the next quarter switching context when it could have made one workflow better than the alternatives.
Competitors can also copy features faster now. When a competitor can reproduce your dashboard in a sprint, the key difference comes from how well you truly understand your users’ needs and how well you serve the job-to-be-done for them.
This is why it is important for PMs to make your product positioning (how you want customers to perceive you) clear to Sales and the rest of the company. The team can then use it as a filter before it builds a requested feature.
A one-sentence test for each request
Before treating a request as roadmap input, write your current position in one sentence:
We help [buyer/user] do [job] better than [alternative], proven by [outcome].
Then put the each of the incoming sales/customer feature requests next to the above sentence.
Same buyer, same job, better proof: build it. Most of the AI speed should be applied here, so your team can iterate faster and double down on your target segment.
Same buyer, adjacent job: sequence it. You need to evaluate whether you are done or want to pause the current job-to-be-done before you open a new job for your target segment. This should be done after some thinking about the opportunities, users’s needs etc.
Different buyer, different job, or a different way of buying: treat it as a new segment and decide it at that level, outside the feature backlog.
If you cannot write the above sentence, then you do not have a position yet, and building all three requests - just because your team can - will not get you anywhere.
Saying No
As a Product Manager, it is your job to say No. However, when you can clearly articulate the rule and framework, then Saying no becomes lot easier to the prospects.
When you identify requests that belong to other segments, log them clearly as new segment bets and assign an owner and a review date, so your teams and stakeholders know how you are thinking about this.
Before you say yes to a sales or customer request, try to answer these five questions:
Who is the buyer, and is it the buyer you already sell to?
What does success look like in the first 30 days, in their metric?
What demo, integration, and security review does this add?
Can the current sales story work well with this, or does it need a new one?
What will you stop doing to pay for the added support and roadmap work?
When you answer these questions and realize that solving your users’ or sales ask takes you away from your current buyer and sales story, then you are choosing either a new or an adjacent market, and you should run the request through the same review lens as you would use for entering a new segment.
When engineering capacity used to be common constraint, product teams didn’t having to explicitly make such decisions. With coding agents, the product teams must now make it on purpose.
I encourage the product teams to dig deep into the segment you already serve, and open up an adjacent or a new segment only after you have validation that you have differentiated value and a path to a repeatable sales motion in this new target segment.