With your starting models and risks prioritized, now you need to get ready to run experiments.
Before you start running your first set of experiments, it’s important to assemble the right team.
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 is mostly involved with “outside-the-building” activities such as interviewing customers, running usability tests, and so on.
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.
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. ...