It’s not easy to find a co-founder and even if you’ve found one it can be confusing to know whether they are the ‘one’. At EF team building is a vital part of what we do. We know that the co-founder dating stuff is bullshit, but there are ways to find co-founders that are as smart, determined and committed as you are. The most important stage that people forget about is that you need to test your potential co-founding relationship, in the same way you would test a product idea. This post is about how we encourage the EF guys to build and test teams and hopefully will give you some pointers on how to build your own co-founding team.
HOW TO FORM A SOLID TEAM, STEP BY STEP
First up, I don’t want to mislead you guys. There is no magic formula. If there was, I would create a magic algorithm and tell you who your ideal co-founder would be. We’ve tried things like that, and it doesn’t work.
That said we have learnt a lot from the last two years at EF where we take individuals pre-team and pre-idea and over 6 months help them build products that turn into startups. I want to lift the lid on some of the things we have learnt about how to make sure you’re in a co-founding team where 1+1==3.
The EF team have now helped 60 or so teams to form and split, or form and succeed. We have a unique insight into this as no one goes as early stage as we do. It’s not easy and it can be a very emotional process, but there are some simple steps you can take to make an informed choice about who you work with.
The main indicator of early team success is productivity; productivity is traction for teams. Good teams can build stuff and sell stuff from day 1. Bad teams make excuses for why that didn’t happen.
STEP 1: PERSON + IDEA
Once you have found a potential co-founder, you need to agree from the beginning what you will work on.
The ideal position is to be working with someone who has a strong shared interest with you, who has skills that complement yours and where you have a strong respect for each other.
What works when finding your co-founder:
- You are a team of 2: At EF, we support teams of >2 very rarely. Building teams of three can seem attractive. If you can’t decide between two people, why not cofound with them both? It’s not that simple. Each co-founder needs to have a strong relationship with each co-founder. In our experience, in a three this often isn’t the case. Someone is usually making a compromise and although that may seem ok in the short term, this doesn’t lead to harmonious founding teams in the long term. What’s more, ideation as a three can be harder. It’s much more likely that someone is working on an idea that they aren’t really interested in. It can also make it harder to even agree on what idea to pursue in the first place.
- You’re both building something you really care about: The industry, the problem or the technology really excites you. You see the potential for this being something you want to be part of for the long term. It is either driven by an obsession with building or improving a piece of tech, or obsession driven where you are scratching an itch you have had for a long time. Ask yourself the question, would you apply to be an employee at the startup you’re building? If the answer is no, it might be worth having a think about whether you care about what you’re doing.
- You have complementary skills: As a team, you have, or can quickly acquire the skills needed to build the product you want to build (technical or otherwise).
- You respect each other: You respect each others skills and talents and you trust each other to deliver. This may be last on the list, but without this, don’t bother.
What doesn’t work:
- Trying to crowdsource an idea you are both interested in. We have seen this time and time again — two potential co-founders who get on really well, have complementary skills and want to work together. They hit a wall when they can’t agree on an idea they want to work on and they never get past this hurdle. They try to compromise and work on something neither of them really cares about. This is a waste of time and effort. Make sure you have a genuine shared interest in an industry or technology.
- Working together because you can’t find anyone else: When you feel you can’t find anyone in the world to work with you, it’s often better to start work by yourself and make progress on a product you want to build, rather than wasting your time co-founding with someone you don’t see a future with. If you build a product that has promise, it is highly likely you will be able to build a team at a later date (see my post on team building mindsets for more context.)
You shouldn’t be compromising on the idea and team. If you are compromising on day 1, remember that will still be a compromise in year 10.
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 max/min 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 etc, 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.
STEP 3: GET TRACTION
Either concurrently with building, or once the MVP has been built, show us that someone wants what you are building.
Traction is showing that you are building something people want. It is a potential user/customer giving up a valuable resource to engage with you/your product. In the very early days of your startup, this is likely to be time (someone will spend an hour with you to talk about your product, will spend time watching a video, etc.).
In the first 14 days of a startup, traction may look like one of the following:
- Signups after seeing a product demonstration (this could be a video/mock up or basic version)
- >10 potential customers that you have spoken to who are currently actively seeking for your solution, or who are hacking together their own substandard solution
- Users engaging with the product at least once (even once shows that they have an interest in the problem you are solving even if you aren’t there yet with the solution)
- A handful of users who are keen to give feedback and help you develop the product
- Meetings set up with corporates who are willing to give their time to discuss your product
Getting no traction can be an indicator that the idea/product/solution is wrong, but this can be an important way of learning. If you haven’t learnt anything from your attempts to get traction, you need to re-examine the idea and the team.
STEP 4: REGROUP AND REVIEW
Productivity is all that matters. After two weeks working together, we want to see that you have made significant progress. At EF, if within two weeks you cannot show us something that you have built, or traction for the product, we will strongly advise you to no longer work in that team. Productivity that leads to progress is the strongest signal of a team that will function well.
The only thing that matters with a team is your level of productivity; productivity is traction for teams. Happy teams that build good startups are productive from day 1. They don’t get lost in thinking and strategising, they treat every day like a time-limited hackathon and they get shit done. If you can’t do this from day 1, you won’t magically be able to on day 100. If you don’t think your team is productive and making progress, it’s time to think about a new co-founder.
Be honest with each other, don’t kid yourselves If you have worries about the team or aren’t happy with your productivity, raise this sooner rather than later with your team — it may not save your team, but if that’s the case, it’s the best outcome for everyone.