Thoughts on #LeanCoffeeTO 29 – The Fast and the Focused
I went to my first-ever #LeanCoffeeTO this morning*, and it was, without a doubt, one of the most productive and meaningful startup-related conversations I've ever had the pleasure to be involved in. So, before I get into my thoughts, I should probably thank "The Leadership Team," and especially Mark Reale, who was the catalyst for my finally attending a session.
If anyone from this morning's meetup is reading, I'm sorry most of these notes are focused on my interpretations, not your situations. Since I'm new to the discussion, I found it easier to make sense of the back-and-forth by relating it to my own mental models and situations I've experienced.
1. Thought: Lean == CBT, not anti-depressants
There was a lot of talk in the beginning about the "science" of lean, and whether or not it could reliably produce results. This sparked my first meaningful thought of the morning: that lean is a process that must be followed, not a pill that will solve everything.
People who are diagnosed with Major Depression tend to be prescribed at least one of two solutions: engage in Cognitive-Behavioural Therapy (CBT) or something modelled after it, and/or take some anti-depressants. The former is a lengthy process that trains you to recognize your thoughts for what they are and disengage from your self-destructive habits. The latter is a pill that you pop.
Neither CBT nor anti-depressants are 100% successful, but I imagine that sustained effort in CBT (beyond a 12-week program) trends towards it, while continuing to take unresponsive drugs just doesn't. Further, CBT definitely protects against relapse much more than anti-depressants do.
Coming back to lean: it's a process. It's not 100% successful off the bat. But if you earnestly keep at it, you'll likely end up hitting your goals; you'll also be better protected against costly mistakes. If you see it as a magic pill, you're doing it wrong.
2. Customer development is a subset of user development
Adil, from My City Lives, subtly introduced the decoupling of these concepts. He's optimizing his current product for its users, as they're pursuing a two-sided business model.
In most cases, customer development is ideal: you want to find the people who will pay you for a product, then build the product to their specs to minimize waste. But two-sided business models – where users and/or their contributions are the valuable pieces (ex: Facebook, YouTube, Wordpress) – need to focus on the user first, since the only way to generate the value is to satisfy the users.
There is one caveat: a two-sided business that engages in user development before validating at least one way to derive value from the user base is ludicrous. I'm reminded of a friend who recently sold his startup – which still hadn't shipped product, but had secured and organized scarce resources – because he had engaged with many of the markets that could derive value from what he was building, and knew how to spin his user-centric product for them.
With the decoupling established, I started seeing customer development as a specific form of user development. With user development, you're trying to figure out how you can deliver value to your users. With customer development, you're trying to figure out what value you need to deliver in order to get paid.
Thinking of customers simply as transactions has always seemed self-destructive to me. Instead, focusing on them as a specific – and, without a doubt, the most important – subset of "users you bring smiles to" is a much more natural way for me to think.
3. Generating assumptions != validating assumptions
I had always considered "the problem interview" to be more of a validation process than a generation process, but I realize now I was mistaken. You don't have to go into a meeting with a clear enough idea of the product, then try to pivot around it. In fact, in the early stages, I realize now how self-destructive that can be.
Instead, Cameron and Max from Big Bang Technology gave a beautiful and concise description of the two possible interviews you could have:
- Problem interviews to generate assumptions. In these, you learn about a customer**'s existing behaviours and assumptions. The goal is to supplement all of your readings about a market segment and develop a full mental model of your customer.
- Solution interviews to validate assumptions. In these, you discuss your hypotheses (and maybe mockups/early prototypes) of your proposed solution with customers. The goal is initially to figure out what the end looks like, and becomes a process of correcting course as you approach it.
4. Market focus --> product focus --> market focus
Someone in the group was talking about scheduling software he was building for a specific niche. I stumbled across my words in an attempt to phrase the "Have you determined that this is the optimal niche for you? And if so, how did you do it?" question. Cameron rightly called me out that this comes from seeing elements of Moore's Crossing the Chasm (affiliate link) in case studies I've read and heard.
The conversation evolved into a "you need to pick a niche" talk, which is an element of what I was trying to get at, but not the question itself. Luckily (for me), someone whose name I didn't catch really clarified the two processes involved: market focus and product focus.
This guy stated that some people build lean companies with a product focus (product is king, how do we optimize our product for our customers?) while others take a market focus (markets are king, which market has an interesting and valuable problem for me to solve?).
What I've been coming to believe recently is that the strongest companies will first take a market focus to find a problem, then turn to a product focus to establish what the Minimum Viable Product (MVP) looks like, then turn back to market focus to test whether their niche is the optimal one.
The process would look something like this:
- Market focus. Talk to a bunch of markets: Fortune 500 IT directors, factory floor managers, concert promoters... basically, anyone you can get your hands on. Find a problem one of them would pay you to solve that you believe you can solve. Confirm with some other members of the niche.
- Product focus. Talk to your contacts in the niche, and maybe others like them. Find out what the MVP looks like, so you can start building. In an ideal world, build modularly.
- Market focus. While building, get back into exploring niches. Find out if any of them suffer from the same problem, and if the solution is even more valuable to them. For example, the factory floor managers may be willing to pay $10,000/year for your product, whereas the concert promoters who initially gave you the idea are only worth $5,000/year. You may have to shift your MVP a bit, but the difference in value generation should pay off handsomely.
The value in this approach prevents you from hitting local maxima, or from ignoring larger markets. You can eventually build the concert promoters' $5,000/year application if you want to, and chances are that that market shift would be a little easier to handle. Especially with all that extra cash...
5. How important is customer development after customers are engaged?
I don't have an example or a framework for this one yet, so this is going to be a little conceptual. Feel free to skip if that's not your bag.
At the end of the meeting, Mark pointed out that the group hasn't had a vision/re-orientation discussion in a while, and that it's about the time they assumed it would be beneficial to have such a discussion (it would be the group's third). Ultimately, the attendees thought that things were still going smoothly, so they didn't really need to.
Honestly, this struck me as a hypocritical approach: if customer validation is one of the pillars of lean, and these guys are the group's customers... why wouldn't they continue to ensure they're on the right track? Why wouldn't the group review its learnings from the past couple of months, and try to figure out what milestones they hit, and what the next few months should bring?
More broadly, how intent should a company be on check-ins with its customers? Obviously, you want to prove that you're generating value for them, however you do it. But once that value is established, should you continue checking in, even if all signs point to yes?
Not having these types of discussions in "the good times" seems like another contributor to hitting local maxima, and to the flatlining of a great company or product's growth. The best analogy I have is meditation: research into meditation's effects on well-being have shown that its effects directly correlate with a regular habit; this is why people are encouraged to practice regularly, not just when they're feeling good.
6. Conclusion
This was a long post, so thank you for making it this far. Since you've made it down here, I have a couple of questions for you:
- What am I wrong about?
- Was this interesting? If so, which of the above points would you like me to expand upon?
- Have you been thinking similar things? If so, what are your thoughts?
- If I write this type of content in the future, should I split it into different posts, or compile them as they are here? (Note: assume the actual content is exactly the same.)
---
*Admittedly, I did pass through for the last 10 minutes of a session a few weeks ago. But this was my first time for the full shebang.
**I used "customer" in this section to keep the talk relevant to current discussions. Obviously, these apply to user development, too. But let's see if that idea sticks, first...
