Handling feature requests without letting them write the roadmap
The Product Leaders work group on routing, #now/#next/#later, overfitting to requests and keeping a settled plan from being reopened.
Updated
Give every request a home, rank only the near-term work, and judge each ask by the problem behind it and the segment it comes from rather than by how often it is repeated.
- Route requests by source. At Slack, Tamar Yehoshua ran separate channels for support escalations, enterprise gaps from the field and the community. A sales ops owner attached pipeline to each enterprise gap for a quarterly review with product leads. Yuhki Yamashita adds that each source is biased: support tickets lean dissatisfied, and Twitter is a vocal minority.
- Keep the problem, drop the proposed fix. Kevin Yien warns that teams overfit. In his hypothetical, a team ships 11 custom fields for customers worth 40% of revenue, and those customers churn anyway. He would write down the problem behind each request, weight it by segment and ICP fit instead of volume, and, when a dozen requests are variations on "let me add a field", probably build one flexible primitive in place of a dozen point features. Tamar's Huddles at Slack came from the problem under customers' requests for video.
- Rank only what is close. At Foursquare, Noah Desai Weiss's team sorted requests into #now (2 to 4 weeks), #next (1 to 3 months) and #later, which needed no careful ranking. He would set a portfolio split up front so incremental requests can't crowd out bigger bets, and Tamar would protect capacity for reliability too.
- Make stakeholder priorities visible. Lane Shackleton runs major stakeholders through a $100 voting exercise, which leaves a record of each person's early stance. Kevin would require each row to state the problem, the segment and ICP fit, links to raw evidence, a count of distinct customers, and whether it is a segment-wide capability or a per-customer customization.
- Treat an accepted request as a hypothesis. Noah would ship the smallest version that tests it and decide quickly when a choice is easy to reverse. At Slack, pillars reviewed their own smaller features so exec reviews could spend their time on one-way doors and the overall portfolio.
Ask a follow-up
Product Leaders
Frequently Asked Questions
What goes into a good product strategy?
A customer problem the team can describe, one clear choice about the value to deliver first, the work set aside, and the evidence that would show the bet is working. It should let the team explain a specific 'no' to an important customer.
How do you tell a product strategy from a roadmap?
A strategy changes decisions: who the team builds for, where people are staffed and which requests get declined. Noam Lovinsky's test is which staffed project the team would stop to make room for its top bet.
How do you run customer interviews that change what you build?
Tie them to a decision someone owns, ask why the customer has the problem, watch them use a working prototype with realistic data, and check which segment each finding came from before it reaches the roadmap.
How do you scope an MVP?
Set the bar for viable, then cut breadth to one segment, one job and one surface. Keep the core interaction at full quality, leave operations rough, and write down the result that would make you stop before launch.
How do you tell whether a new feature worked?
Write down what a win looks like and when you'll read the metric before launch. Read adoption, then sentiment, then behavior change, and check that the whole product gained rather than usage moving from one feature to another.
How do product managers keep stakeholders aligned on scope?
Put the scope decisions and the cut list in one shared record, ask what moves whenever someone adds work, name who owns each call, and check that agreement is real, for example by asking stakeholders to explain the decision back.
How do you forecast delivery for a project full of unknowns?
Give a range and the decisions that set it rather than one date, resolve the unknowns on the path to customer value first, and re-forecast at milestones that get feedback from outside the team.
How is AI changing the way product teams are organized?
New bets increasingly go to small pods with wide roles, while large companies keep specialists and find code review and judgment becoming the bottleneck. Either way, someone on the team still has to push for the user.
What makes a product brief useful?
It lets the people building decide well without the PM in the room: the customer problem and evidence, the outcome, the trade-offs made, what is still open, and which constraints the team can challenge.
