product_plan

We failed.

After 6 months poring over the code quality and refining the design of our mobile app, my partner and I finally launched it in the app store and the downloads started coming in.

Then after a few days, BOOM. We got punched in the face by reality. No users returned to the app. This was a devastating shock, since most people we spoke to were excited about the idea. Our app allowed you to take photos and ask questions to learn about what you were looking at. It had all the traits of the most-hyped startup trends that year: mobile, social, local. It was early 2011.

Frustrated and determined to find out why no one was using our app, I decided to interview iPhone users who took a lot of photographs to understand if they had visual questions to post. After a few rounds of interviews, where they walked me through their photos, it soon became clear that I had built my product under a crucial, and faulty assumption; I had assumed that people actually had questions about the things they took photos of! What I learned was that these people were often in familiar environments where nothing new piqued their curiosity. Even when they did take photos of something that was interesting, it didn’t bother them enough to exert the extra effort needed to find out more information.The root cause of our failed launch finally dawned on me. The failure wasn’t due to a poorly designed solution; our app simply didn’t solve for a real human need. I had been working under an assumption that we had never validated.

The key to building products users want

Why did it take so long for me to realize I was building a solution for a problem that didn’t exist? Besides the various confirmation biases that often plague entrepreneurs, many fail to recognize these pitfalls early on because they are not taking the time to quickly test risky assumptions before jumping into the thrill of building.

By testing the value of the product, and other assumptions continuously throughout the product development process, entrepreneurs multiply the chances their businesses will acquire a passionate group of engaged customers faster.

Identifying assumptions

An assumption can be any number of things – a user behavior, mentality, or action that needs to be accurate in order for the solution to be viable. The riskiest assumption is the assumption that’s most core to the viability of the business and most unknown, meaning there is little or no data collected that supports the validity of the assumption. Testing the riskiest assumption at the very start of the project reduces the time it takes to find the biggest flaws in an idea and increase the speed at which we can find a better, more viable alternative.

In my example, the riskiest assumption to test early on would’ve been: people have questions to ask about their photos. That is eventually what I went back to test, after my partner and I gave up our salaries and put in months of labor. Testing the riskiest assumption is difficult for many to do and, very often, teams will succumb to hindsight biases and subjective arguing. To mitigate this problem, entrepreneurs need a way to list out their assumptions for any new idea, run an effective experiment, and hold each other accountable to the results.

Testing the riskiest assumption

There are many ways for teams to define and agree on what they’re testing up front. The pain of my failure led me and my co-founder at Javelin, Trevor Owens, to create the Experiment Board, which helps entrepreneurs to do this in a systematic way. Writing down the riskiest assumption focuses team efforts on testing the most important aspect of the business first. Once the riskiest assumption is validated, the team can move on to testing the next riskiest assumption.

One key benefit of the Experiment Board is its ability to help entrepreneurs and teams focus on customer problems and assumptions, rather than jumping into solutions. The steps it brings users through are the same steps an entrepreneur should take with any new business idea:

  1. Identify the customer segments, and the problem being solved.
  2. Brainstorm a list of assumptions.
  3. Determine how the team will know if an assumption is valid.

Validate before building

Let’s see how this works with a case study from Tarikh, founder of Seen.co, a past Lean Startup Machine winner who went on to raise money from Dave Tisch and other top investors.

Continuous Validation

Once an entrepreneur has validated that there is a real customer problem to solve for, the next step is to test how much the solution is worth for the customer. Will they pay, pre-order, or give up something of value to use the service? This measure of demand can be easily tested through a pitch experiment. You can do this with a simple landing page and some Google ads (and yes, we’ve created a tool to help you do just this, it’s called QuickMVP).

The process of identifying and testing assumptions should be ongoing when building a startup. Attend an upcoming Lean Startup Machine in your city (LSM Boston is happening June 6-8; register here), to learn the process and avoid wasting time and money building things people don’t want. Trust me, I learned the hard way.

Register for the Boston Lean Startup Machine on June 6 to 8.

This is a guest post by Grace Ng, Co-Founder of Javelin.com & Lean Startup Machine (LSM), the world’s leading Lean Startup workshop. LSM Boston is this weekend June 6th to 8th 2014 and tickets are almost sold out, get yours here and use the code “onstartups” for a 30% discount.