Step 2: MVP the team as well as the product
Once you have agreed to work together, you need to decide what you are going to build and by when. You should be building an early version of your product (an MVP). You should decide on the timeframe e.g. a week and agree on what will be produced by then.
Before you get building, does everyone:
- know what they need to create and by when?
- have a clear idea of what good looks like (i.e., what is the maximum/minimum that needs to be done)?
- know when you will be working together physically and when you will update each other on progress?
Ideally, you should be updating each other regularly, either over Skype, or in person. There is no substitute for working in person and we expect all our EF teams to spend significant time working together in person, not just virtually (I know that remote working has worked for some very successful startups, but this is often where the co-founders have previously been very good friends/worked together before).
If you can’t make progress building or selling the product, the team won’t work. There will always be excuses for why something hasn’t been built, but largely these will always be excuses — do you want to work with someone who can’t get things done? Creating specific deadlines creates tension and tension is a useful way to test a nascent relationship — what’s this person like at 3am a day behind the deadline?
One way to think about it is to treat the team as a MVP. Running your team as hard as you can towards a goal is the only way you’re going to be able to test whether your team works well together. Productivity is traction for teams. It’s how you know you should keep going.
Building is important because it’s the closest approximation to real work before you have any clue whether your idea is any good.