AdventureLab, part 1: 5 lessons on team building

This is part 1 of the AdventureLab series documenting the Technology Entrepreneurship course at Stanford. For more information about the series please see the introduction. For a list of all articles in this series please see the AdventureLab collection.

The first assignment's deadline was yesterday 6pm PST. Groups had to come up with their 5 worst and 5 best ideas for which they had to develop a business model canvas. The teams were initially formed by random selection and in a lot of cases yielded poor results. By far the biggest problem was lack of response from team mates, which is not surprising if you think about it in context.

One of the most difficult problems a startup has is converting users into paying customers. A lot of people sign up for free trials, but then never try the service. This is most likely what happened: people saw advertised a free course on entrepreneurship by the mighty Stanford and since they had nothing to lose they signed up thinking they'll follow along or something, but then didn't.

So a lot of people found themselves alone to complete the first assignment. There was some screaming and bashing on the forum, but fundamentally that's exactly what the assignment was designed for: separating active from passive students. The next challenge is starting today and new teams will be formed based on previous activity so everybody should get a better team.

But not all was bad. I for one was lucky enough to get 3 other active members and together we tried to bring the whole team to life which made for an interesting experience and some good lessons.

Top 5 lessons on team building

  1. Don't assume anything about your team mates, ask questions. There will be many occasions, especially at the beginning when you don't know each other well, to interpret things one way or the other. You want to treat those moments as an opportunity to ask questions and learn more about the others rather than to make assumptions and potentially create conflicts. People's character is also important to account for: some people are just shy and introvert and won't do well in the beginning even thought they are fantastic folks to work with.
  2. Establish some parameters of reference. You might tend to be frequently online and more responsive than someone else on the team so when you send out an email and get nothing back for 12hrs that gets on your nerves. You start to think others aren't committed, feel demotivated and that will show next time you have a conversation with them. The best way to fight that is to openly discuss expectations and set parameters of reference. It doesn't have to be written in stone, but you can approach your team mates in a call and mention you think it would help making progress if everybody could be more prompt in their replies.
  3. Be transparent about your work. There's nothing more engaging than seeing things evolving around you. If when you have some members not responding you cave in and isolate there are way fewer chances you'll get to bond and work together. Likewise if someone disappears for a while, maybe he or she got really busy at their job and is not just neglecting the grou. Having things in the open easily accessible will allow that person to catch up and still feel part of the team. Mailing list, wikis, social networks, code repositories  - they are all ways to keep a transparent account of what's going on.
  4. Be a reminder to the reminder. Following from 3. missing a meeting or a deadline can negatively impact relationships on a team, and sometimes the root cause is just a missed reminder. Of course there's a limit to what makes sense to do, but if you get a chance to send an email the day before a meeting just to remind folks of the upcoming event, I guarantee you the results will show.
  5. Not everybody first language is English. Most international meetups, conferences, courses etc, will be held in English and Venture Lab is no exception. Despite the international crowd some folks might not have a great command of English, especially when it comes to spoken language. This might make them shy away from a Skype call or worse they could misunderstand something important you said. This can heavily alienate those people and break your team apart. Because of that it's important to be always aware of who's in your group and strive to communicate things clearly at all time avoiding implicit content or cultural references. It can also be useful to use repetition, either in the same conversation, or a written follow up after the call.
  • Prof Eesley made a blog post on team building. You can find it here

Bonus tip

If you're reading this I'm confident sooner or later you'll be launching your startup. When it comes to pricing models, betas and so forth, the topic is so complicated there are books written about it. But in light of what we discussed at the beginning of this post you'll want to think hard if a freemium or free trials are the best solution for your product. Despite how popular those approaches are, these first few weeks are a proof of the problem with 'free users' and the issues with converting them to 'paying customers'. The alternative is to set up a barrier upfront, like the course has done with the first assignment, by for example asking for a credit card even tho you won't charge them until the trial period is over.

What is your top 1 lesson learned?

I've done my best to put together the top lessons learned in these two weeks, but with so many people and teams I'm sure there's a lot more I didn't get to. What is the one thing you learned from forming your team that others could benefit from knowing? Share it in the comments!

Don't miss the next part of this series, follow me on twitter for updates or subscribe to the RSS feed. Thanks!

Be part of Stanford's TE community

comments powered by Disqus