Watch
Shaping in a Nutshell
In under twenty minutes, the author of Shape Up explains setting an appetite, narrowing a raw request to the real problem and naming no-gos before any building starts.
Framing the Problem
Mistakes to catch in review
A CSV export button with column pickers built for a request whose real need was the same monthly report sent to an accountant.
An admin panel, a plugin system or a login flow added to a small tool because the brief never said what was out of bounds.
A real-time sync engine built when users only needed a nightly import, because the brief described a feature instead of the problem.
Working out who has the problem, what outcome would solve it, and what is deliberately out of scope, before any solution is on the table.
Topics
- Users and the Jobs They Need Done
- Identifying who has the problem and what they are actually trying to accomplish when they reach for software.
- Outcomes Over Features
- Stating success as a change in the world, such as fewer failed payments or faster onboarding, so solutions can be compared against it.
- Scope and Non-Goals
- Writing down what the work will not do, which is the cheapest way to stop an agent from expanding the task.
- Build, Buy or Skip
- Deciding whether the problem needs new software at all, or an existing product, a script or a change in process.
- Constraints
- Budget, deadlines, regulations, existing systems and team skills that decide which solutions are acceptable.
You understand it when you can
- Write a one-paragraph problem statement that names the user, the problem, the desired outcome and at least two non-goals.
- Take a vague request and list the questions you would need answered before building anything.
- Explain which existing tool or process a new feature replaces, and why someone would switch.
Drill
An agent was asked to 'add export so customers can get their data' and produced a spec for a CSV button with column pickers and date filters. The support tickets behind the request say customers' accountants need the same report every month; find what the spec misses and rewrite the problem statement with two non-goals.
Start here
Watch
Introduction to Modern Product Discovery - Teresa Torres
Keynote on starting from a desired outcome and mapping the opportunities behind it, so a feature request like 'add export' gets traced back to the need it serves.
Revisiting "Jobs to Be Done" Clay Christensen | HBR IdeaCast
Christensen explains that customers 'hire' a product to get a job done in a specific circumstance, which is the question to ask before designing a feature.
Read
Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value
Shows how to state an outcome, build an opportunity solution tree from customer interviews and compare candidate solutions against that outcome instead of against a feature list.
Shape Up: Stop Running in Circles and Ship Work that Matters
Its shaping chapters teach how to turn a vague request into a bounded pitch with an appetite, a problem statement, rabbit holes and explicit no-gos.
Competing Against Luck: The Story of Innovation and Customer Choice
The book-length treatment of jobs-to-be-done, including how to find which existing product or workaround a new solution has to replace.
Primary sources
Reference
Shape Up, Chapter 3: Set Boundaries
Explains setting a fixed appetite, narrowing down the problem and responding to a raw idea without committing to it, which is the core of the scope-and-non-goals topic.
Paper
Know Your Customers' "Jobs to Be Done" (Harvard Business Review, 2016)
Christensen and co-authors define a job as progress a person wants in a particular circumstance, with the functional, social and emotional dimensions a problem statement should capture.