Most Startups are About Discovery

These days, thanks to Lean Startup thinking and Customer Development, we now know our biggest risk isn’t getting the software built, but validating that there are customers out there that want our product, and can use it. I’m going to call that stuff product discovery.

Now I suspect if you’re reading this, you’re familiar with Lean Startup’s build-measure-learn loop, but I’ll explain it anyway – from my perspective.

lean startup model
  1. Describe our big product idea (but recognize that it’s a hypothesis, we can’t assume people want it)
  2. Identify the riskiest assumptions hidden in our product idea (assumptions about who our customers are, and their needs, as well as assumptions about how they’d value and use our product)
  3. Separate out the few biggest assumptions (those that would sink your product if they weren’t correct)
  4. Identify an approach to validating those assumptions – your Minimum Viable Product Test (customers you could talk to, and potentially prototypes or examples they could engage with to validate your assumptions)
  5. Build your simple prototype (and write a few notes about how you’ll engage with customers to test your assumptions)
  6. Engage with customers to test your assumptions (pay attention to what you’ve learned as you do)
  7. Make sense of what you’ve learned, and rethink your big product idea
  8. Repeat steps 2-7 until you’re confident you’ve identified the smallest product you really need to build, or until you’re out of cash
There’s something very different about this process loop: the primary measure of progress during discovery isn’t delivery velocity, it’s learning velocity. And sadly, we can’t measure its features or stories completed. And, even worse, we can’t plan two weeks of it in detail because what we learn today can and should change what we do tomorrow. When you’re doing discovery right, it could look a little like this team at the Nordstrom Innovation Lab.
Notice the Nordstrom Lab still uses time-boxes, 1 week in this case. But, they didn’t start the time-box by predicting how much they’d deliver, but with learning goals in mind. Then they iterated around the build-measure-learn loop as fast as they could. What the Nordstrom team ended up with wasn’t really “high quality software” – it was more of a jankety prototype that worked well enough so that they could leave it behind and measure the stuff that mattered most: did sales people actually use the application? Did they actually sell more as a consequence? And, did Nordstrom customers like the experience of buying this way better? Honestly, the jury is still out on all those questions. Notice that you won’t see this application running in a Nordstrom store near you. But that’s not failure. It’s learning. In the words of my friend David Hussman:
“The difference between learning and failure is how much money you spend to do it.” — David Hussman @davidhussman
Discovery teams quickly figure out that what takes the longest time isn’t building working software, it’s getting time with customers in order to learn something that really slow you down. The Nordstrom team solves this problem by placing their small discovery team inside a teaming pool of customers that they could learn from. This allowed them to get around the learning loop many times a day. That’s a super-fast learning velocity. Keep the spirit of Agile, and discount the dogma If you’re in software development today, you really need to understand Agile development. But, if you’re a startup, be aware that common Agile practice is about predictable delivery and is best suited for the times when you’re confident you’re building the right thing. By using an Agile time-boxed development cycle, you can more predictably build it right. If you’re biggest risk is building the right thing, focus on building your learning muscles. Go back to original Agile values and principles. Remember that Scrum and Extreme Programming are good delivery approaches to using Agile thinking, but not the only approaches. As a team frequently ask yourselves these questions:
  1. Are we working together as a team collaboratively and effectively?
  2. Are we making our ideas visible fast so we can learn fast, whether it’s working software, or a simple paper prototype?
  3. Are we learning directly from our real customers, the people that will buy and use our product?
  4. Are we stopping frequently to take stock of what we’ve learned and to re-think our product idea, our plans, and the way we’re working?
Those four questions are what the manifesto really means from a startup’s perspective. Keep those basics in mind, forget all the other agile dogma you hear, and you’ll be using Agile right. This post is an excerpt from Common Agile Practice Isn’t For Startups. For the full post, please refer to Jeff Patton’s blog.   [author author_image=””]Jeff Patton is the glue that connects good product management and strategy, lean user experience and agile delivery practices together. He has authored numerous articles, essays and, most recently, a book, “User Story Mapping.” An independent consultant with a unique teaching and speaking style, he uses hand-drawings and engaging story telling to share his passion for product design.[/author]