I attended the Lean Startup Circle at 1871 last week. As always with Chicago events, it was great and I benefited tremendously from hearing other entrepreneurs discuss their processes for product development. One very important lesson from the lean startup philosophy is the concept of testing your product hypothesis early, often and as inexpensively as possible. While this may sound obvious, I find that its application by entrepreneurs who are developing a concept is often done in hindsight rather than at the outset. Using my own experience developing PhilterIt, I have had a few insights.
Any product starts with an idea. And most first-time entrepreneurs, or aspirational entrepreneurs, are very guarded about that light bulb spark that sets their hearts pounding. I know I was. My insight for PhilterIt was that our inboxes, structurally, are ill-equipped to manage the various types and heavy volumes of communication received daily. My proposed solution was to recreate the inbox into a visual dashboard of icons - for example all Groupon behind a Groupon icon or all TechCrunch newsletters in a TechCrunch icon.
When my co-founders and I explored this concept prior to development, we did the three things any founding team might be expected to do: we whiteboarded our concept extensively; we researched the competitive landscape to see if any similar product existed; and we spoke to/surveyed users to understand their existing habits, pain points and needs. Once we were comfortable with the output, we developed a prototype, raised some angel funding and got down to development.
What’s missing from this story, though, is product testing. We never tested our concept with real users. That was the missing link. We understood user pain, we loved our solution, and we knew it did not exist, but we did not figure out a way to get actual and quantifiable feedback on our solution as early as possible. Only once we’d developed and launched our alpha did we get our first users to try it out and give us their thoughts.
So why didn’t we test it earlier? Two reasons: the first is that we didn’t want anyone to know or steal our idea; the second is that we didn’t know how to test a product that didn’t exist. On the first point, I’ll be brief, since this can be the topic of another blog post (and has been written about extensively). No one will steal your idea, especially your friends and family. Perhaps AMD can steal an idea from Intel. But not us peons with no resources, no team, no money, etc. Again, this is a separate topic I’ll address another time. But on the second point, that is where we weren’t creative enough early enough.
Our entire premise is to rethink the inbox from a visual perspective. The simple way to test this would be to sit someone at a desk, give them a laptop with mouse and keyboard, and then tape a piece of paper over the screen with our interface. Then we ask them to tell us, verbally, what actions they would expect to take. If they “click” on an icon, we put another piece of paper with what they would expect to see. Wash, rinse ,repeat. Now, does this exercise validate or refute our entire concept? No, of course not. But what it does is give us valuable feedback on our design and approach (and perhaps even method of use) that would inform our future development. And the cost would have been some free coffee (for the testers) and a couple of sheets of paper. In fact, most of the early feedback from our alpha was in regards to user confusion with our design rather than the benefits of our product. We likely could have mitigated this confusion had we tested out our user flow more effectively earlier on.
The lesson here is that the startup process is an unending series of hypotheses and iterations. Ultimately, a product must be built, fully, to have a dedicated user base. But how that product gets built, how those hypotheses are tested, and how resources are expended are up to the entrepreneurial team. We are really pleased with how PhilterIt has progressed, and we continue to attract new users who are loving the experience and giving us great feedback. We also take heed of this early lesson as we contemplate and release new features.
Does anyone else have any interesting stories of quick and inexpensive product/concept testing?