Product Task
Turn an incoming feature request into a product decision
A proposed implementation is being treated as the requirement before the underlying workflow failure is clear.
“This is costing me product capacity while one requested implementation is treated as the only answer.”
The result you need
Record a build, defer, decline, or research decision tied to the evidenced workflow problem.
What is happening now
Where the work gets stuck
An entrepreneur in residence, founder, or product lead has received a feature request from a user, prospect, or colleague.
- When it starts
- The request is moving towards the core product without a recorded problem decision.
- What makes it difficult
- One proposed implementation can absorb scope even when a smaller response or no product change would address the workflow.
- What progress looks like
- The request links to existing evidence, identifies the workflow failure, compares responses, and records the decision and consequence.
What to try next
Review the problem and response behind a feature request
Choose a build, defer, decline, or research response tied to the existing evidence and product boundary.
Before you act
Check these limits
- Send new interviewing or observation work to Customer Research.
- Keep commercial commitments visible without treating them as product evidence.
- Do not claim that one request represents a market.
Sources
Check the research behind this advice
Read the sources before relying on a claim or recommendation.