Running a Workshop for Startup Founders
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
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
- 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.
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
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
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
- 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,
- 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
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
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
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.