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." Most agencies skip it. They take the brief, build what's in it, and deliver something that technically works but doesn't move anything.

We call it shaping. We do it before and during every project. It is the reason our clients don't end up with software that nobody uses.

We shape all the time.

Jams team at the whiteboard during a shaping session

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. What are we building next? What's the real problem we're solving this cycle? What are the rabbit holes we're explicitly not going down? We whiteboard it, challenge it, and then build it.

Sometimes we're in the middle of a cycle and a new idea comes up. We take it to the whiteboard immediately.

Whiteboard outputs aren't documents. The output is clarity for everyone, an updated product spec, and a prototype to make sure we're aligned.

What happens in a shaping session

Simple: we open up a whiteboard and start discussing an idea.

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. We identify what's already clear and what's an assumption being treated as a fact. And we push back a lot.

The output

A rough concept, the main elements of the solution, and a short list of what we're explicitly not building. That's enough to make a decision.

The Jams shaping team

A lot of product work happens in Slack threads and documents.

That works for keeping records but not for deep thinking.

The whiteboard forces something different. It enables collaboration, group discussion, and coming up with the right thing together.

Every client we've worked with long-term has had that moment: something that looked clear in writing that turned into a completely different decision once we shaped it together.

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.

01

Shape

Define the problem. Identify what to build. Decide what we're explicitly not building.

02

Build

The team builds against the shaped scope. No scope creep. No rabbit holes.

03

Ship

Every cycle ends with something in production. Real users, real feedback, real data.

04

Learn

What did the data say? What do we shape differently next cycle? The loop starts again.

Stop requesting quotes from dev firms and let's actually start shaping your idea

Book a call and come with your ideas and pains. We map your business and figure out where AI moves the needle. You leave with a clear roadmap instead of a quote.

Book your free shaping session