Shaping problems before you commit
The request lands in Slack on Tuesday: “Can we add group notifications?” By Thursday it is in the roadmap tool with a priority field, three stakeholder comments, and a one-line description that could mean almost anything. Nobody has agreed who it is for, what breaks without it, or whether it belongs in the product you are actually building. We are not short of opportunities. We are short of shaped problems.
That gap is where most of the expensive confusion lives – not in delivery, but in the work we skipped before delivery was ever a sensible question.
Discover first: widen before you narrow
I am a believer in the UK Design Council’s Double Diamond – not because the diagram is new, but because it names what should happen when. Discover before Define; diverge before you converge. That order looks obvious on a poster. In a live product team it blurs fast: a request is in the roadmap, someone has sketched a screen, and nobody can say whether you are still exploring or already deciding. Naming the phase gives the room permission for research and scepticism in Discover, not mock-ups and premature commitment.
The first phase is Discover: deliberately divergent. You are not choosing a solution yet. You are trying to see the situation from enough angles that you will not mistake a loud request for a real problem. That might mean observation, support themes, or asking when the pain shows up rather than what feature would fix it. A calendar request only becomes tractable when you ask what the customer was doing – driving to read a wall chart, not “lacking a calendar widget.” The insight is see free slots, not clone Outlook.
Discover is where you earn the right to be sceptical. Is this a problem for our core user, or a one-off from a friendly account? Is there evidence – behaviour, repetition, cost – or only enthusiasm? Does the pain connect to something we already claim to solve, or would it pull us into a new category we do not want to own?
Record what you learn as specifics: a story, a metric, a segment, a quote. Not “customers want X.” This person, this moment, this failure. Skip it and you will shape (or build) against a ghost.
What “shaping” adds: an opportunity that evolves
Shaping (from Basecamp’s Shape Up) turns a raw idea into something a team can commit time to. You can skip Shape Up’s betting table; roadmap and planning conversations are where the pitch earns its keep. Shaped work is rough, solved, and bounded – explicit about out-of-scope and what effort is worth. Not implementation. Not a polished spec.
Think of an opportunity in four layers; each deserves a different record.
1. Boundaries: who, how much, and what problem
Set boundaries first. On first contact, rarely yes or no – more often interesting, maybe someday – then size and fit: small fix, roadmap-scale initiative, or park until it shrinks? How much attention, calendar, and political cost?
That is not a detailed estimate. Boundaries start with what you will invest; the solution shrinks to fit. Fixed capacity, variable scope forces trade-offs you would otherwise defer.
Narrow the problem. “Redesign Files” is a grab-bag; “sharing multiple files takes too many steps in the client portal” is a problem you can shape. Permissions drama might collapse into a one-day archive warning once you understand the actual failure mode.
Record here: who benefits (and who does not), scope and effort limits, and a problem statement tight enough to test. Note strategic fit: does this strengthen the product we mean to be, or drift us toward a general-purpose tool for whoever shouted last?
2. Elements: what would we actually build?
Sketch elements – places, affordances, connections – on a whiteboard or in your product management tool. Rough notes and flows, not polished wireframes. “Group notifications” becomes discussable: notify a saved group, confirm, respect mute rules. Until you name pieces and links, you only have a label. Record: chosen approach and what you rejected.
3. Risks: is it buildable in the window we have?
De-risk: walk the flow, patch rabbit holes, declare no-gos. Ask technical peers can we deliver in the window we have? If success requires doubling scope or slipping the date, learn that before the sprint calendar locks. Record: rabbit holes, patches, out-of-scope cases, open questions.
4. Pitch: the handover record
When the concept is coherent, write a pitch – problem, scope and constraints, solution, rabbit holes, no-gos. It lets people without your context prioritise, and lets a team start without reconstructing weeks of whiteboard and product-tool history.
A pitch without a problem invites endless UI debate. A problem without a solution is unshaped work pushed down to the wrong level. You want both, so fit can be judged: right problem, right people, right scope, right time.
Record here: the full shaped package – not a ticket, a shaped commitment.
How this differs from a backlog item
A backlog line stores demand. A shaped problem stores judgment: what we understood, ruled out, and would count as done within agreed limits.
Ideas that die in shaping still win – clearer boundaries, a strategic “not us.” Ideas that jump straight to build learn the same facts under pressure, with more political cost.
A shaped pitch can look like a slim PRD on paper – problem, solution, scope – but the job is different. A classic PRD often aims to be the definition of done: detailed enough to plan, trace, and sign off. A pitch aims to be commit-ready: rough enough that the team still applies craft, bounded by scope and effort limits, and honest about rabbit holes and no-gos. Many PRDs describe scope first and discover the calendar later; shaping agrees the limits first and lets the design shrink to fit.
Pitch vs PRD (quick check)
PRD habit: exhaustive requirements, approval gates, team implements the spec.
Pitch habit: macro elements, explicit limits, room to trim during delivery.
Overlap: both beat a one-line ticket when they record why, who, and what’s out.
Mismatch: treating a pitch like a contract, or a PRD like a major commitment with no agreed boundaries.
Discover widens; shaping narrows. The first diamond and Shape Up rhyme: do not commit to solutions before commitment is meaningful.
A habit for this week
Pick one ticketed request. Ask:
- What story shows the problem (Discover)?
- What boundaries and narrowed problem would we accept?
- Can we name elements on a whiteboard or in the product tool before a design file?
- What would blow up the timeline if we are wrong?
- Could we write half a pitch and read it cold?
If you cannot get past (1), you do not have a shaped problem yet. You have a wanted feature. There is nothing wrong with parking it – softly, explicitly – until the record catches up with the ask.
When the room wants to jump to solutions, try:
“We are storing a request. I want us to shape the problem – who it is for, what it costs us strategically, and what we would commit to – before we pretend we have agreed what we are building.”
That is practice, not more process. It is the work that makes the rest of the process worth having.
