Good, fast, cheap—pick two

Product
2 min read

Building Software with Bread isn't for the faint of heart. You'll need to trust us with your business and we bring strong opinions to resource allocation for software development.

Good, fast, cheap—pick two

We’ve seen various shapes of this phrase over the past 15 years. We love it. Not because it’s a fundamental truth, of course decision making can be more complicated than this (morality!!), but because it’s a simple, easily applied, flexible, and thought provoking framework for resource allocation.

The best performing people we’ve worked with, whether they realize it or not, are able to assemble the right combination for their circumstance based on an accurate estimation of what is in fact good, or fast, or cheap.

If you’re a founder, executive, product owner, manager, engineer, designer, account exec etc. and your company has a mechanism for autonomy or accountability—resource allocation is really your only job.

Every situation calls for a different implementation of this framework.

There’s an elephant in the room:

Move fast and break things

This is a statement about resource management. People used to love it. Maybe they still do. We never did. We read it as "be fast at all cost". It's attractive when you don’t understand the repercussions of the thing you’re breaking or when learning feels more important than lighting money on fire. It can work. But I think it's missing the "good" or "cheap" directive. Moving fast can be costly (think expedited shipping) and it could mean sacrificing quality. Those two outcomes matter and there should be guidance based on what your company / market can tolerate.

If you work with Bread, we’re going to try to steer you in one of two directions.

As a pre-profit business (startup) your goal is to make good bets and stay alive.

As a post-profit business your trying to make big/thoughtful bets quickly.

Bread is in the business of good and fast. Good and fast win over time and apply to a business at any stage. We try to unlock “cheap” through speed, repetition and the economies of scale.

Cheap is relative. Our economy is a figment of the 10th century imagination. Money is pliable. Time is unrecoverable. Quality is timeless. — Me, Yesterday

We recognize it’s not the only way to get things done, but it’s how we do things for two simple reasons:

  1. We want to learn quickly (fast)
  2. We want to test product improvements, not product parity (good)

Yes, this involves spending more early on. We prefer this to standing witness to a product's slow death.

This is the rubric we take into every project, be it our own, or yours—it works.

How to get good—

  • Write down who your product is for
  • Write down what your product is supposed to do
  • Write down the performance benchmark for your market
  • Build small testable versions of your product early
  • Don't skip baseline requirements (e.g. user management, etc.)
  • Build the baseline quickly—leverage off the shelf tools
  • Focus on features that help you beat the benchmark
  • Think about monetization from the start

How to be fast—

  • Choose your tools wisely
  • Talk to customers after every release—create feedback loops
  • Create a culture of accountability
  • Take bets on resourcing and process improvements

How to unlock cheap—

  • Be realistic about your market
  • Model your business
  • Productize repeatable portions of process
  • Remove unnecessary process or bureaucracy

If you've done these things, you should always have a sense of how you're performing—even if you're pre-revenue.

You know it's good is when—

  • The product does the job people ask of it
  • It performs faster or equal to market expectations
  • How to use the product is clear to its users
  • There’s a clear path to monetization

You’re moving fast when—

  • You’re releasing new or modified features every 2 - 4 weeks

Your product is cheap if—

  • Your target software margins are +100% i.e cheap to you
  • Your target COGs are lower than competitors i.e. cheap to them

This is how we measure cheap. If you want to treat software development like a commodity and measure it based on global wage rates, go for it. But the result will be a commodity product.