Back to Blog

How to Frame a Project Before You Build It

Learn how to frame projects using Shape Up’s “Framing” method — a simple process to define problems, outcomes, and boundaries before you start building.

Posted by

Why So Many Projects Go Off the Rails

If you’re building an app, you know the feeling. You get a spark of an idea and immediately start putting it into action — sketching screens, handing it to a team member, or hiring an agency to get started.

It feels productive at first… until it isn’t.

Somewhere between idea and execution, clarity disappears. Everyone’s building, but no one’s fully sure where the project starts, where it ends, or what success really means.

That’s where Framing comes in.

What is Framing

Framing is a simple but powerful technique for defining a project before you build it.

It comes from Ryan Singer, author of Shape Up and former product leader at Basecamp, who spent two decades shaping software with small, focused teams.

Framing helps you:

  • Draw clear boundaries around a project
  • Separate problems from solutions
  • Define measurable outcomes
  • Prevent scope creep
  • Communicate clearly across your team

Start by Framing the Problem

Before diving into features or solutions, pause to ask the right questions.

This is where you uncover the real reason you’re doing the work.

Ask things like:

  • What’s not working the way it should?
  • Where is time being wasted or duplicated?
  • What’s the friction behind this request?
  • Why now — what’s changed that makes this a priority?
  • Who feels the most pain — users, clients, or the team?
  • If we fix this, what would look or feel different?
  • Are we solving one problem or several smaller ones?

When you slow down to frame the problem, you often realize the real challenge is deeper (and smaller) than it first appeared.

Define Outcomes, Not Solutions

Once you’ve framed the problem, define what success looks like — in plain language.

This is where most teams jump too quickly into “solutions.” They say things like “we need a new dashboard” or “we need an app.”

But those are solutions, not outcomes.

Instead, describe what you’ll be able to do or measure when the problem is solved.

Example outcomes:

  • Cut onboarding from 10 steps down to 4
  • Generate reports instantly instead of weekly
  • Eliminate duplicate data entry
  • Reduce client response time from 48 hours to 12

Clarify What’s Not Included

Once you’ve written out the problems and outcomes, the next step is to define what’s not part of this project.

This is the simplest way to prevent scope creep — and the most overlooked.

When you clearly state what’s out of bounds, everything else becomes clearer.

Examples:

  • No mobile version for this release
  • No UI redesign required
  • No analytics integration (that’s a separate project)

Set an Appetite Instead of an Estimate

Instead of asking “how long will this take?”, ask “how much time are we willing to invest?”

That’s called setting an appetite, and it’s one of the most useful principles in Shape Up.

We frame projects around 1, 2, 4, or 6-week appetites — fixed timeboxes that set healthy limits and expectations.

There’s usually a one-week version of any idea, and a four-week version of the same thing. Knowing your appetite upfront helps you right-size ambition and effort.

Document It Clearly

When you’re done defining the Problem, Outcomes, Not Doing, and Appetite, write everything down in a single Notion document (or whatever your team uses).

Keep it simple, conversational, and free of technical jargon.

Anyone — developer, designer, or stakeholder — should be able to read it top to bottom and instantly understand what’s being built and why.

This becomes your Framing Doc, the foundation for every project.

At our agency, no build starts until the framing document is approved. It saves us time, reduces miscommunication, and prevents expensive mid-project resets.

Why Framing Works

Framing forces clarity before action. It’s a pause that speeds you up later.

When the whole team knows the why, what, and where it stops, execution becomes smoother, faster, and far less stressful.

It works because it:

  • Surfaces assumptions early
  • Aligns teams on goals and trade-offs
  • Eliminates ambiguity
  • Prevents wasted effort and scope creep
  • Makes handoffs cleaner between design, dev, and QA

Use Framing Beyond Product Development

Framing isn’t just for software. You can use it anywhere you need clarity:

  • Marketing campaigns
  • Sales process redesigns
  • Operational improvements
  • Hiring plans

Key Takeaways

  • Frame before you build — clarity saves both time and money.
  • Focus on problems and outcomes, not features.
  • Define what’s not included to prevent scope creep.
  • Set a fixed appetite to right-size ambition.
  • Write it all down — one clear doc beats ten meetings.

It’s about starting smarter, so everything after moves faster.

Learn More