Ideas reached us from everywhere: a customer request, an internal hunch, a support pattern. They almost always arrived in generic words. “Customers are frustrated with X.” “We should do something about Y.” Real problems (often mixed with solutions), described just clearly enough to be dangerous.
A few years back, we explored Shape Up to improve our delivery cadence. The idea of announcing a new feature or major improvement every six months was intriguing, so we gave it a try.
I’m not going to explain Shape Up here; I think the book is the best source.
Since then, I’ve spent much of my time shaping: finding solutions at the right level of abstraction. They needed to be specific enough to guide implementation without dictating its details.
The habit we leaned on was defining the problem clearly before proposing any solution: “What can’t customers do today, and how will we know when that’s fixed?” Grounding each piece in a real customer pain kept us honest. If we cut scope to something we could ship in one cycle, we kept learning instead of guessing. And making the tradeoffs explicit early meant we argued in a document, where arguing is cheap, instead of in a pull request, where it isn’t.
Most of that thinking went into a short document called a frame for each project: a page that said what we were solving, for whom, and how we’d know it worked.
The document had the following sections:
- What problems are we trying to solve?
- Who are the users, and what do they care about?
- What are the Jobs to Be Done?
- What will change when we’re done, and how will we know?
- What’s the appetite for this work?
Writing the frame first forced the vague parts to appear. I could then shape the work into a solution we could implement within the allotted time. I’d map the flows, the edge cases, and how the system actually behaved, so the constraints were visible before they became surprises.
I added an impact checklist to each shape to capture third-party dependencies, required legal reviews, API implications, fraud-management concerns, and other cross-cutting work.
None of this was heavy process. A frame is a page, not a phase. But separating the shaping from the building changed the rhythm of how we shipped. Mid-cycle changes dropped. Delivery got predictable enough to hold a monthly cadence without it slipping. Product and engineering spent less time realigning, because they’d aligned on the frame first.
It turned out to be harder than we thought to formulate problems without slipping into solutions. We caught ourselves a few times as solutions crept in, but the core move held up: decide what you’re building, and why, before you start building it.