Prototype or Product? Scoping a Request Honestly

Every product team meets this request sooner or later: a new view, a new workflow, a new integration, wanted soon, on a platform that isn’t quite ready for it. Maybe the API it needs doesn’t exist yet, or doing it properly means work that’s already scheduled for later. “Yes” quietly pushes back everything you’ve already promised. “No” leaves a real need unmet. There’s usually a better answer in between.

Start with the need, not the feature

A feature request is often one possible solution to a problem. Ask what the person is trying to do and what’s slowing them down today. Quite often the platform already covers it in a slightly different shape, and a walkthrough or a small tweak is the fastest route to value.

When a prototype is the right answer

Sometimes the need is real and the existing route doesn’t fit. Then a prototype can be exactly the right step: it lets people try the idea, and it tells you what the production version actually needs. It only works if it’s honest:

• Say what it is. A prototype, built to learn, with its limits stated up front: what it does, what it doesn’t, and where it falls short of the rest of the platform.
• Keep it out of the critical path. It shouldn’t depend on shortcuts that other features will copy.
• Put the production version on the roadmap, with a trigger rather than a vague “later”, for example “when the backing API lands”. That turns it into planned work, not forgotten debt.
• Protect what’s already committed. Other people are waiting on work you agreed to. A prototype is sized so it doesn’t quietly delay theirs.

What makes this work

• Shape, not refusal. “Not as a production feature yet, but here’s what we can do now” keeps the conversation useful.
• Visible trade-offs. Debt agreed in the open is a plan; debt nobody wrote down is a surprise for someone later (Deloads Are Tech-Debt Sprints).
• Readiness as a shared check. Agreeing what “ready to build” means up front makes these conversations shorter (Definition of Ready).

The real danger isn’t the prototype. It’s the unlabelled one, which drifts into production by accident because nobody said what it was.

Related notes

From Statement of Work to Done: Requirements Both Ends Can Build From · Definition of Done