When I joined 37signals last year, I had been using Shape Up for four years, but I was eager to learn how shaping here differed from my own experience.
I wasn't disappointed! Jason and David share invaluable feedback during shaping and at the betting table, as do the programmers and designers who take a pitch and turn it into something real. Here are a few insights that have helped me be better at what I do.
What's the simplest thing that could work?
Narrow the problem. Narrow the solution. Repeat.
The bar for something being worth solving is high, but the bar for the solution is even higher. This is the piece that differs most from typical product development.
When building products, we're often drawn to complex, ambitious solutions. They're novel and make for a more interesting story.
Here, though, the simplest, quickest thing that solves the core problem is what's celebrated. We'll always choose a solution that gets us 80% there in a week versus 100% there in four.
Plus, the only way you can make that 20% trade-off is if you fully understand the core problem.
What’s going to be different?
There's no shortage of ideas for a product. We get hundreds of suggestions every week and are always thinking of things that could be added or improved. Product people have a natural propensity for change.
In an early conversation with Jason about an idea, he asked, "Sure, but why would we?"
In other words, yes, we could definitely do that—anything is possible! But why this thing? What's going to be different because of this change? What can you do that you couldn't do before? Are we just changing this because we can?
Pitch a problem, not a project
A pitch is a few paragraphs about a problem we should solve, an outline of the solution and unknowns, and a sketch or two about how it might work.
It's tempting to pitch a project, though. So, instead of the pitch focusing on one thing, it becomes a pitch for a set of loosely connected, but not interdependent, work. As long as a team is spending 2 weeks improving this aspect of to-do lists, let's also take a week to fix this other thing.
That may be a great set of work for a team, but we can decide that after the betting table. Instead, write two pitches and let each stand on its own.
Make the problem personal
A pitch should tell a compelling story. That story resonates more when it's personal.
Compare:
I wasn't disappointed! Jason and David share invaluable feedback during shaping and at the betting table, as do the programmers and designers who take a pitch and turn it into something real. Here are a few insights that have helped me be better at what I do.
What's the simplest thing that could work?
Narrow the problem. Narrow the solution. Repeat.
The bar for something being worth solving is high, but the bar for the solution is even higher. This is the piece that differs most from typical product development.
When building products, we're often drawn to complex, ambitious solutions. They're novel and make for a more interesting story.
Here, though, the simplest, quickest thing that solves the core problem is what's celebrated. We'll always choose a solution that gets us 80% there in a week versus 100% there in four.
Plus, the only way you can make that 20% trade-off is if you fully understand the core problem.
What’s going to be different?
There's no shortage of ideas for a product. We get hundreds of suggestions every week and are always thinking of things that could be added or improved. Product people have a natural propensity for change.
In an early conversation with Jason about an idea, he asked, "Sure, but why would we?"
In other words, yes, we could definitely do that—anything is possible! But why this thing? What's going to be different because of this change? What can you do that you couldn't do before? Are we just changing this because we can?
Pitch a problem, not a project
A pitch is a few paragraphs about a problem we should solve, an outline of the solution and unknowns, and a sketch or two about how it might work.
It's tempting to pitch a project, though. So, instead of the pitch focusing on one thing, it becomes a pitch for a set of loosely connected, but not interdependent, work. As long as a team is spending 2 weeks improving this aspect of to-do lists, let's also take a week to fix this other thing.
That may be a great set of work for a team, but we can decide that after the betting table. Instead, write two pitches and let each stand on its own.
Make the problem personal
A pitch should tell a compelling story. That story resonates more when it's personal.
Compare:
When a person lands on a to-do with a bunch of comments, they have to scroll through the same ones over and over to get to what's new.
With:
When you land on a to-do with a bunch of comments, you have to scroll through the same ones over and over to get to what's new.
Both capture a pain point, but the latter is less abstract—anyone reading the pitch can identify with the experience.
The customer perspective is highly valuable, of course. Better to quote directly from interviews and feedback and let them speak in their own words.
A pitch doesn’t have to answer every question
In a solid pitch, the problem and solution are clear and the biggest unknowns have been addressed. We're confident that there's a shippable solution possible within the appetite. The boundaries clarify what we're doing and what we're not doing.
You have to be specific about the edge cases and uncertainties, but it's okay to be vague about some of the solutions. A prescriptive pitch that attempts to put a bow on every loose end leaves little room for the team's creativity and ownership. Plus, they can make a better decision in the future because it will be informed by the hundreds of decisions they've made while building it.
If you're using Shape Up and have questions or feedback, drop me a note at my HEY address.