Most software teams build first and figure out what it should have been later.
There is a discipline that sits between "we have a problem" and "let's build something." We call it shaping. We do it before and during every project.
We shape all the time.
We adopted shaping after reading 37signals' Shape Up. When we start a new project, we run longer shaping sessions. We sit with you, map the operation, identify what actually needs to exist, and define the first scope.
During the build: every cycle starts with a shaping session. We whiteboard it, challenge it, and then build it.
WHAT HAPPENS IN A SHAPING SESSION
Start with the problem. Not "we need a feature." What is the user actually trying to do, where does the current experience break, and what does success look like in concrete terms?
Draw it out. We poke holes in it and identify what's an assumption being treated as a fact.
The output: a rough concept, the main elements of the solution, and a short list of what we're explicitly not building.
AN ONGOING PRACTICE, NOT A PHASE
Most teams treat discovery as a checkbox at the start of a project. We treat shaping as a rhythm. The team builds what was shaped. We review what shipped, look at what the data says, and shape the next cycle based on what we learned.
