Building stuff is cool. But there’s a time and a place for everything. And as we explained in the last article, learning should always be the first step in product development. That’s not well understood, even in lean circles.
What I’m about to say sounds crazy, but it happens all the time. Smart people, bitten by the entrepreneurial bug, read Lean Startup. Their minds are justifiably blown. They memorize the build-measure-learn diagram featured in the book and rush an MVP, simply because the “build” circle sits on top.
What they shoulda done instead is reread the book.
Building something — anything — just to get feedback is a perversion (giggle… sorry) of lean methodology. It’s certainly not what Steve Blank had in mind when he started teaching the concept years ago. Check out what he wrote in a recent blog post:
” …what you build needs to match the hypothesis you want to test. So instead of Build-Measure-Learn, the diagram for building minimal viable products in a Lean Startup looks like Hypotheses – Experiments – Tests – Insights.
You had a hypothesis when you started the work of customer learning. It was loose and undefined, more of an idea. While you were building empathy around the customers, no doubt, your hypothesis changed. Your MVP is the experiment part of your hypothesis. It will be tested. The MVP should provide you with deeper insight into your customer’s problems. It might will be crude and ugly-looking (like say… Craigslist) but it won’t be a random shot-in-the-dark.
We build this way to save time, money, and brain cells. And then, guided by how our customers respond to it, we build some more.
Behind the scenes
Here’s how the “build” step might look in real life. Let’s say we began our customer research talking to pet owners, hoping to find an opportunity within the $60 billion market Americans spend on their pets every year.
What we hear over and over is that dog owners feel excruciatingly guilty for leaving their dogs at home when they go off to work. In their minds, this makes them bad parents.
Our hypothesis — based on studying the data we’ve collected and continually asking “Why?” — is that some dog owners would pay to stop feeling guilty for “neglecting” their pets.
So we gather the team back at the lab. We pour over the data and run it through a business model canvas. While this is going on, team members are writing out their ideas on the whiteboard, diagramming what we know and where we might go. It’s not chaos, but with so many hand-drawn boxes, arrows, and notes it does look a lil’ like something out of a Marvel Universe book (minus the Thwacckkks! and Booommms!).
We stop and look at the two replies customers brought up most. The first, doggie daycare, is too expensive for about 90% of customers. The second, getting another dog, is too much work for about 70% of our customers.
Hmmm. At this point, we could change our focus to the 10% of customers with enough money to pay for doggie daycare and test our hypothesis with them. Or we could change our focus to the 30% of customers willing to put in the work to care for a second dog and test our hypothesis with them. But we don’t. We focus on the majority of dog owners who hate leaving their dogs alone but don’t have an affordable alternative.
So, we move on to the empathy maps. We draw up the quadrants. We hope to get real clear answers to this problem: Our users need a better way to ________ (part with their dogs each work day) BECAUSE ______ (the guilt hurts).
While our team is working through the colored sticky notes, inspiration strikes… from an outlier.
Straight from the horse’s mouth
We see that one of the customers, a divorced guy in his 50′s named Tony who works 60 hours a week as a mid-level accountant, mentioned virtual dogs. They were a craze in Japan at one time but never really took off in the U.S. “Nintendo treated the whole technology as a (bleepin’) joke… a cute thing to teach kids responsibility,” he said. “They never improved on that. The first time I saw it, I knew it had potential. It could’ve been my dog’s companion, especially when she got older and her balance got shaky. It could’ve made all that time she spent alone less miserable.”
The man’s pain (guilt feelings), love (for his dog), and anger (at big tech) all wrap around a solution that he’s thought about long and hard. On the surface, a virtual dog companion sounds a little ridiculous… stupid… trite… unrealistic… but also clever, effective, easy-to-use and viable.
Now will a single articulate response justify building an MVP? Uh-uh. But when that response sounds like what others might have said had they been as self-aware as this man, then it’s worth exploring. We go to the value proposition canvas and plug in our customer avatar. We prioritize their pains and gains. Since we can’t solve all our customer’s problems yet, we focus on the ones they care about most. This is our product roadmap. It’s the North Star of the design process.
The virtual dog companion idea is a go. The engineering and design team gets to work. They have a clear mandate on what to build, guided by a few select user stories. They obsess over the user’s experience the whole time, but not so much that they haggle over minutiae. The project manager keeps things moving with fairness, discipline, and a bias towards action.
Time to experiment
When the dust settles six weeks later, we have our MVP. It’s a single-screen animated dog who barks. It’s capable of keeping any dog company for twelve-hour stretches. When we bring it to our audience, they’ll be able to understand it… respond to it… try it… interact with it. Although we have a lot of ideas about cool new features, we’re holding off until we see how they like what’s been launched. The product is only as good as stressed-out dog owners think it is.
We’ve selected a subset of customers from our audience, based on psychographic information, for immediate, special attention. If we can get them to start using the virtual doggie companion, we can start tracking their usage and flow. That insight will determine how we improve the product.
So we reach out to them. We can do this because we grabbed their contact info during the learn phase. We might call them. We might send out emails with links to our product. Maybe we even go to their houses to set up the virtual companion for them. The point is, now that we’ve built our MVP, we don’t want anything — inertia, confusion, other options — to interfere with the quest for product-market fit. We’re putting our hypothesis (i.e., dog owners will pay for dog companionship) on the line.
The product we’ve developed was purposely easy to use. It’s also easy to share. To promote sharing, we’re offering unique incentives to these early customers. Of course we’re super excited to put the doggie companion out, but we have to keep our feelings in check. The last thing we wanna do is get high on vanity metrics.
Now back in the real world
No two product journeys are entirely alike. Every successful product was once a hypothesis that underwent an iteration (or 20). If there’s one constant in lean product development, it’s change. You’ll change customers (and markets). Your MVP will undergo multiple surgeries (it ain’t a prototype). So if it’s not obvious already, I’ll just say it: product development, the lean way, is not for the wimpy. The no-place-to-hide transparency of it has sent many budding creators scurrying back to the safety of corporate life.
However, when you arm yourself with the right questions, the right tools and the right team, suddenly the lean way ain’t so scary. In fact, you come to appreciate the raw honesty of it all. You appreciate how collaborations make for a better product and you don’t care who gets the credit. You begin to understand that when you do product development like this, you’re a helluva lot closer to reaching the finish line of product-market fit.
And that, amigo, is what we aim for with every client who partners with us. If you’ve hit a snag in your product development work, we invite you to contact us.