I spent Saturday mentoring the latest Lean Startup Machine in NYC, and as always it was a great experience. I love how the weekend isn’t about hacking up a cool idea, but the much harder task of figuring out whether something is worth doing. The participants push themselves and their ideas, and there’s a strong vibe around learning and improving. Here are a few thoughts that emerged:
Someone asked me, “what is the hardest thing about doing lean startup?” For many, the hardest thing is ruthlessly questioning their exciting ideas, but that is table stakes and I wanted to go deeper. I think the hardest thing is switching to a mindset of running experiments, especially small, fast experiments. It takes practice and it is something that most people get better at over time. You commonly see teams where their first MVP took them months, the next one weeks, and the next one days (Exhibit A: Yipit).
One of the best things about mentoring LSM is seeing how small experiments can actually be (as in one-morning-long small) that still deliver actionable insights to drive decisions.
As always, I saw a bunch of teams that were getting reasonably positive responses to their tests, but were questioning if they should continue or pivot. In some cases, it was worth running more tests. For one in particular, the big red flag was that the potential customers were saying nice things about the new product idea, but they were clearly not feeling much pain over their current methods for solving the problem.
If current solutions are good enough, then expect a long battle ahead, unless you can dramatically undercut the current market price. It is damn hard to change behavior. However, I will note that fast-moving trends (such as the sudden prevalence of smartphones) can shake up behavior, so this is all very context dependent.
Dropbox is an interesting company to look at on this topic. Most of their early customers had tried various solutions and either given up or hacked out frustrating semi-solutions. Even though most industry observers might have said that the cloud storage market was already too crowded, the Dropbox team could look at people’s true behavior and see that the problem they were interested in had clearly not been solved.
Trevor asked me to walk participants through my 12 tips for customer development, but the one thing I forgot to stress was not to let the customer define the solution. Perhaps this is obvious, but the entrepreneur needs to have the vision to look deep into a problem and come up with the right solution. You don’t ask people what they want, but rather you study their behavior for what they do and what they need. As much as you can, get your interviewee talking about specific situations, not abstract feelings and concepts.
Josh Seiden gave some good, practical advice for what he called “dump and sort”, and I saw multiple teams using this to very good effect. Josh recommended that you write down your custdev observations on sticky notes or index cards — one observation for each — and then try to sort them into basic buckets or themes. It is important that you write down observations, not conclusions about what to do. If one observation needs to be in two buckets, then just copy the card.
Breaking everything down into discrete units and visually laying out everything in front of you can be a powerful exercise.
I would only add that you should try to keep in mind where the observations come from and see if this exercise can help you come up with relevant customer types. I don’t care if you do formal personas or not (ed. I personally don’t have a lot of patience for over-wrought persona write-ups), but you do want to explicitly try to understand and prioritize the different kinds of customers you are seeing.