The Lean Diaries: Starting a Product Innovation Lab

July 2, 2012 - Elisa Miller-Out

Over the past few months at Singlebrook, we’ve begun our Lab program. The goal is to create a profitable product business alongside our successful service business. We’ve been creating custom web and mobile applications for our clients for over six years now, so we’ve built up a great team and a strong Agile development process. However, creating a product business presents a whole new set of challenges for us and I thought I’d spend a little time documenting the process. One of the main goals of Lab is learning and our hope is that other startups can learn from our mistakes and successes alongside us.

Our team has lots of ideas for products we’d like to build. So many ideas, in fact, that one of our first challenges is figuring out which product we should tackle first. Which one has the best chance for success? We have very limited resources in terms of time and money, since at this point we’re bootstrapping the product business alongside our service business. We need to make sure that whatever we’re spending our time building has a good chance of becoming profitable in the near future.

We’ve gotten a lot of inspiration from the Lean Startup movement (hence the name “The Lean Diaries” for this blog series). The work of Eric Ries, Steve Blank, Ash Maurya and other thought leaders in the Lean Startup world has informed our Lab process so far. Each week we spend some time running Lean experiments on different product ideas to determine which ones we want to pursue first.

Since this is my first blog on this topic, I’ll attempt to summarize what we’ve done in Lab so far over the past few months. (I’ll try to blog more frequently from now on!) We’ve got one product that has already graduated from Lab and which we’re continuing to run Lean experiments on as we develop it further. It's currently in public beta: WhatCanI.Do.

Recently, within Lab, we brainstormed and examined some different problems, developed a list of product ideas and did some pitches on each to our team. Each pitch contained the following components:

  1. description of problem and solution
  2. revenue model
  3. competitive analysis
  4. feasibility
  5. potential to scale

We scored each component of the pitch and voted on the ideas. Based on the scores, we narrowed our idea list to the first three ideas that we would like to focus on. We’ve already eliminated two of the ideas based on our first experiments and are doing some customer development interviews on the third and exploring a potential pivot/expansion of the idea. 

Some Lessons Learned So Far:

  • When we first scored the pitches, we pursued the three product ideas with the best scores relative to the other product ideas that had been pitched. However, all of the scores could have been quite low and we may just have been picking the three best of several weak ideas. For future rounds of pitching we’re going to explore the idea of having a score threshold, so that we score each idea on its individual merits and only pursue the top three ideas that score above the threshold. If no ideas score above the threshold, then we’ll go back to the drawing board and come up with some new ideas.
  • When we brainstormed the first round of problems, we quickly realized that there were some problems with the problems, so to speak. Some of them were “wicked” problems that felt almost impossible to solve because of their magnitude and complexity. Some of the problems could not easily be solved using technology. We realized that we needed to find problems for which technology was one of the best solutions. Most importantly, many of the problems were not real, felt problems. They were problems that our team knew were out there in an abstract way, but none of us had felt the problem strongly enough to actively try to solve it. We realized that some of the best quality problems for a software solution would be problems that someone from our team or someone close to us had felt strongly enough that they had already examined the existing solutions and were actively struggling to find a new solution that worked. They might be creating workarounds or cobjobs in the absence of a solid solution to the problem.
  • Many of our first pitches were weak on competitive analysis. We realized that it was better to do more competitive analysis early on in the process. There are so many startups out there right now, that many of the ideas we come up with are already being pursued by someone else. There still might be opportunities to find a niche that no one is successfully pursuing, but it’s helpful to do some quality research first to identify that potential niche before pitching the idea.
  • It’s important to talk to potential customers as early in the process as possible. We may have thought something was a real, felt problem, but are discovering early on through our customer development interviews that the problem we originally identified is less important than we thought. We’re also discovering other more fertile problems to explore through that customer development process.
  • We've been practicing Lean methodologies and have learned some techniques that have already been helpful with our client projects, such as identifying key assumptions on which the success of the product rests early in the process and testing them out systematically.
  • Finally, what I’ve learned from writing this first blog entry is that it’s very difficult to cram several months worth of work and learning into one blog entry! I will attempt to blog more frequently in the future, so that I can focus more deeply on one or two issues.