Running a Workshop for Startup Founders

Published by Martin Kleppmann on 17 Nov 2009.

I helped run a workshop organised by Joel Spolsky at the Business of Software conference last week. It was a very interesting experience, and in this post I’d like to share some of the ideas we had and things we learnt.

The workshop was aimed at startup founders and was centred around the topic of finding your first 100 customers. There were also two other workshops: one by Dharmesh Shah on marketing, and one by Joel Spolsky on product pricing. Three rotating groups of startup founders participated, and each workshop happened three times, so everyone got to go to each one.

I was to help Simon and Neil, who wanted to strike a tricky balance in their workshop: they wanted maximum interactivity for the participants, but also provide enough structure for the workshop to make it more than just a chat. Together with Amir, and with advice from Pam of Innovia Technology we came up with this workshop format:

• In a workshop of 20–24 people, allocate people into 6 teams of 3–4 people each. That’s the ideal team size: large enough to get an interesting discussion going, small enough to give everybody plenty of “airtime”.
• The 90 minute workshop is split into about 10 minutes introduction, 45 minutes work in the small teams and 25 minutes presentation of results and discussion. (Yes, the numbers don’t add up. Some time is always lost in general faffing.)
• Each team analyses the same product, but applies a different strategy. That way, when results are presented at the end, everybody is on the same page, but interesting discussion points arise from different teams taking quite different approaches to the same problem. Neil and Simon suggested using my startup’s product Go Test It as case study since it is one of the companies in their “accidental incubator”.
• To structure the group discussion, we give each team a worksheet with ten key questions. The worksheet is printed on large-format paper (about A1 poster size) so that it can be filled in with marker pens and all team members can sit around it easily.
• Neil, Simon, Amir and I rotate around the room as facilitators. We don’t just ask “is everything clear?”, but stay long enough with each team to get involved in the discussion. If we feel they are getting side-tracked or missing an important point, we inject suggestions to get them back on track.
• There should be enough time for team members to get to know each other; the workshop serves a networking purpose as well as an educational purpose.
• Participants should learn from each other and develop new ideas and insights through bouncing thoughts off each other, not just off Simon and Neil. The Business of Software conference attracts many bright and motivated people, and with the right framework in place, there is a potential for the workshop to be a lot more than the sum of its parts.

We had put a lot of thought into the worksheet beforehand, trying to make it a comprehensive but concise summary of the key ingredients to successfully marketing and selling a product. We found that it worked very well, but we had to be very careful at the same time: those boxes on the sheet, designed with open-ended questions to gently lead the direction of the discussion, could easily become a counterproductive limitation.

It’s strange how people fall into roles depending on the context: when faced with a worksheet and boxes to fill in, I could see some people instinctively falling back into a primary-school, do-what-the-teacher-wants-me-to-do kind of thinking. I don’t blame them; in a similar situation I would have probably behaved like that too. Fortunately, when we explicitly emphasised that we wanted people to brainstorm freely, to (literally) think outside of the box and not to take the questions too seriously, that barrier fell away and the ideas started flowing.

Some teams even redefined some of the questions, which is great – startups should always be questioning any apparent rules! But the worksheet was nevertheless helpful, because it gave a structure and a goal to each discussion, allowing the teams to maintain a swift pace and avoiding getting bogged down in minutiae.

As an aside, we asked each team to come up with a name for their team, and also to put their real names on the sheet. It’s a simple psychological trick which encourages the participants to take ownership of their work and thus care about it more.

Defining different teams’ strategies

We asked each team to consider Go Test It as a case study, and to examine different strategies for marketing and selling it. In principle, the technology is appropriate to any web development project, but the world of web development is too big as that we could market to all of it at once.

How do you segment the market and find a niche to focus on? Well, we came up with six different dimensions which you could use for segmentation:

• Segment by technology (e.g. using .NET, PHP, Rails, Django or Java on the server; and using jQuery, ext.js, YUI, Dojo etc. for the JavaScript)
• Segment by job role (e.g. developers, testers, user experience designers, web content managers, product managers)
• Segment by company type (e.g. agencies and outsourcing companies, startups, web-based software companies, non-software companies)
• Segment by company size (e.g. individual freelancers, <5 people, <20 people, enterprises)
• Segment by level of service (e.g. hands-off self-service, per-customer customisation, big consultancy projects)
• Segment by industry (people developing web sites e.g. for the finance sector, for healthcare, or for education)

We allocated one particular segmentation to each of the six teams, and asked each team to pick one particular segment based on their experience and interest. For example, we would allocate “segment by company type” and they might pick e-commerce retailers as their particular segment. That choice then determines their strategy for the rest of the session.

This approach of letting teams choose their own segments worked very well: there was of course some overlap between different teams’ results, but we also saw a broad spectrum of different approaches, including some really creative ideas. This allowed individuals to play to their strengths and bring in experience of their own businesses’ market segments, while at the same time keeping the workshop interesting and inclusive to everyone. I think we managed to strike a good balance here.

If I have a chance to run the workshop again, I think I will focus on improving the discussion phase of the workshop: potentially we could have made more of it by contrasting different approaches, and figuring out why some actions are appropriate to some strategies but not to others. Of course, you never know what the teams are going to come up with, so this is hard to plan in advance.

All in all, I think it was a very useful workshop for everyone, and the feedback we received was uniformly positive. If you have any thoughts, please leave a comment or drop me a note on Twitter.