My book, Designing Data-Intensive Applications, was published by O’Reilly in March 2017.
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:
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:
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.