Cover by Ash Maurya

Safari, the world’s most comprehensive technology and business learning platform.

Find the exact information you need to solve a problem on the fly, or go deeper to master the technologies and skills you need to succeed

Start Free Trial

No credit card required

O'Reilly logo

Chapter 5. Get Ready to Experiment

With your starting models and risks prioritized, now you need to get ready to run experiments.

Assemble a Problem/Solution Team

Before you start running your first set of experiments, it’s important to assemble the right team.

Forget Traditional Departments

In a Lean Startup, traditional department labels like “Engineering,” “QA,” “Marketing,” and so forth can get in the way and create needless friction. Eric Ries instead recommends organizing around two teams, the Problem team and the Solution team.

The Problem team

The Problem team is mostly involved with “outside-the-building” activities such as interviewing customers, running usability tests, and so on.

The Solution team

The Solution team is mostly involved with “inside-the-building” activities such as writing code, running tests, deploying releases, and so on.

I say “mostly” because these teams need to be highly cross-functional with overlapping members. Also, interacting with customers is everyone’s responsibility.

While I agree with the logical distinction between Problem and Solution teams, at this stage of a product, you’re best served with having a single Problem/Solution team.

Start with the Smallest Team Possible, but No Smaller

The ideal Problem/Solution team size is two or three people.

There are many arguments for building your Release 1.0 (minimum viable product, or MVP) with a small team:

  • Communication is easier.

  • You build less.

  • You keep costs low.

I built CloudFire “mostly” as a single founder. ...

Find the exact information you need to solve a problem on the fly, or go deeper to master the technologies and skills you need to succeed

Start Free Trial

No credit card required