3 examples that will get you off the couch to test your ideas – Part 2

This is the second post in a 3 part series. The intent of these posts is to give you enough examples where you feel comfortable to start executing your ideas with simple tools that are easily available. I sincerely hope this inspires all of you to execute your ideas and, at the least, start testing your assumptions regarding the problem and the solution.

Please read example #1 here and I will put example # 3 in a later post.

Example 2:

I was in Austin last year to participate in the Lean Startup Weekend. The concept of such workshops is to form a team, come up with an idea and quickly test problem, solution & customer assumptions over the weekend by talking to prospective customers. I decided to team up with a startup that wanted to help busy parents by providing an easy-to-use online calendar for their kids’ activities. This calendar would be an aggregation of their kids’ schedules from schools, after-school activities and weekend games/events.

The startup had already learned a little about lean startup methodology before this workshop and had put up a landing page for parents to sign up for their service. While this works some times, it is very difficult to attract users to your landing page. I recommend talking directly to your customers first and understanding their main pain point. A landing page can be a great tool once you have validated at least your assumptions about the problem and the solution.

We used an online tool named Validation Board, to systematically test our hypotheses regarding the problem, the solution and the target customer.

Quick Tip: You can also use excel to put together a tracking tool for your validated and invalidated assumptions.

We started with validating our customer and problem hypotheses. Without validating these two, we wouldn’t know what our solution would look like. So we decided not to focus too much on the solution. We used the five whys technique to get to the root cause of our customers’ problems. Then we decided to work on our problem hypothesis (our riskiest assumption).

Problem hypothesis # 1: “Parents are wasting time organizing kids event schedules, hence looking for a solution.”

As you can see, we had a strict minimum success criteria that at least 9 out of 10 parents will give us $1 to solve this problem. I have talked about minimum success criteria in my previous post.

validation board version 1

So, with this assumption, we set out to find parents that we could talk to. These were our findings –

  1. Parents did not have any problem with organizing schedules on paper and then put it up on the fridge.
  2. Some parents even said that they loved doing this activity with their kids, with colored pens.
  3. Some parents also loved showing off the schedule on a fridge since it was easily accessible and they could share with family members.

While we found that our initial hypothesis was invalidated immediately, we probed more to understand the pain points around kids’ activities. That’s when we hit the jackpot.

Every parent mentioned that they spent a lot of time driving kids from one place to another for activities and would rather have someone do it for them. While the main games/events were important for them to attend, they wanted someone to chauffer their kids for practice games.

Problem hypothesis # 1 invalidated.

That’s when we changed our problem hypothesis. This time we were confident about our problem, so we decided to test out our solution.

Problem hypothesis # 2: “Parents wasted time driving kids to the activities”.

Solution hypothesis # 1:  “Shared van with a driver that will pick up and drop off the kids for games/practice”.

When we went out to test this problem and solution hypothesis, our problem hypothesis was validated with 100% of parents expressing their pain regarding driving kids to activities.

However, our solution was dismissed as parents expressed their concern with trusting the drivers. Our solution of providing a van service to drive kids around would need a lot of work to prove trustworthy. So we killed that solution.

Problem hypothesis # 2 validated & solution hypothesis # 1 invalidated.

We actually stopped our experiments at this stage as the weekend was over, but we identified the next solution based on what we learned from parents during our second run.

Solution hypothesis # 2: Carpooling app as a solution for parents within the same neighborhood to coordinate car-pooling.

For this solution to be viable, we needed to have enough parents in the same vicinity whose kids went to similar events. So we identified the next riskiest assumption to be – “There should be enough kids in the same vicinity/neighborhood that go to same activity to build a car-pooling app for parents”.

validation board version 2

As you can see, within 2 days, we were able to validate and invalidate many assumptions. The ones invalidated were thrown out, but they told us what features we need not build in the product. The ones validated gave us a clear picture what we needed to build in the app to make it successful. For example, as you can see in the validated column, the product required kid meals as part of the solution, which meant we would need to create a feature to let parents share dietary requirements for their kids to the parents responsible for carpooling at any given day.

We were selected as winners out of 9 teams at the Lean Startup Weekend. I highly recommend going to a lean startup workshop at a location near you.

This example clearly shows how an initial idea was changed completely based on interactions with target customer and learning from that customer.

Quick tip: If you are in Austin, you have to try the southern style barbeque at Salt Lick.

Advertisements

3 examples that will get you off the couch to test your ideas – Part 1

In my previous post, I listed the steps that you can take to start executing your ideas. In this post, I will give you examples on how to easily test ideas without investing too much time, energy and money in making a prototype.

I will talk about my own examples when I tested and validated/invalidated my ideas. While my earlier post talked about validating all parts of a business model, this post will focus mainly on validating problem and solution hypotheses.

I will post example 2 and example 3 as separate posts later.

Example 1:

We always faced a challenge when we were trying to find quality leads for Talentology. We had heard about content marketing and how blogs and content creation in the public domain such as Quora can get you quality leads. We weren’t investing in writing a blog yet, but we decided to answer relevant questions on Quora to showcase our expertise. But during the process, we realized that trying to find relevant questions on Quora wasn’t easy. This was primarily because of two reasons:

  • There is no easy way on Quora to track what questions were dismissed or answered earlier. Mostly, I would revisit the same question multiple times to realize that I had already answered or dismissed that question, thus wasting time.
  • There is also no easy way on Quora to know what questions, out of a long list of questions, you should answer first since you don’t have an immediate knowledge of how many people have viewed the question and how many people are following the question. I wanted to answer popular questions that were viewed and followed by a lot of people. You get this information only when you click on each question one by one. You can see how this can get tiring when you are going through 300+ questions for just one keyword. I had 10 more such keywords that I wanted to search questions for on Quora. That puts it at 3000+ questions.

Image

I soon realized that there should be other startups out there that might be facing the same problem. I decided to work on a side project that would help Talentology as well. I wanted to build a quick solution that would list questions along with the number of views and followers that each question has. I got in touch with a few startups to validate my assumptions. These startups were already answering questions on Quora to get traffic to their website.

I manually copied list of questions from Quora in to excel for keywords that aligned with the businesses that these startups were in. I also clicked on each question and copied the number of views and followers for these questions manually into this excel. Then, I shot an email to these startups sharing a preview of this excel to see how many of them would be interested to pay to get the entire listing. I also offered to provide new questions for these keywords on a weekly basis.

qsnag excel

Soon enough, I got 3 startups paying me a monthly subscription to get relevant questions from Quora in an easily digestible format. The payment was a huge validation for the idea.

However, it started proving difficult to manually copy questions from Quora for 20 keywords (~3000 questions) across these 3 startups. I decided to create a web scrapper that would scrape the information for me. I decided to automate this part only when my manual solution started breaking down. I was still providing the questions in an excel at this point.

After I did this for a couple of weekends, it was difficult to manually keep a tab of all versions of my excel files that I created. My customers were also asking for ability to track these questions and mark them as answered or dismissed on a website rather than in excel. That’s when I decided to put it on a website which you can check at qsnag.com.

Please note that I could have put this excel on a google doc with a password, and that would have sufficed at this point. However, I wanted to learn Ruby on Rails for a long time, so I used this opportunity to learn a new programming language. I will write about my experience with Ruby on Rails in a later post.

I was able to validate my problem and solution hypotheses by using a low fidelity MVP i.e. excel. The startups were open-minded to accept this solution, as I was solving a painful problem that they had. I don’t know if this is a multi-million dollar idea in itself, as I would have to validate other parts of business model (as detailed here in my previous post). As of now, it looks more of a product feature, rather than a business by itself. I would love to see this feature on Quora, as it will help businesses to participate easily on Quora.

Hope this example inspires you to build a quick manual solution that you can use to validate your idea. Now you wouldn’t have an excuse to not execute your idea.

Quick tip: Try to do everything manually initially. Don’t invest any time or money in building a product, until you cannot do it manually anymore, which is a good problem to have. This will happen when you have too many customers or it takes too long to do a certain thing manually.

6 step guide to start executing your awesome ideas

I have been a culprit of discussing a lot of ideas, without ever executing them. And now I understand the reason why.

6 years ago when I heard a garbage truck backing up right below my bedroom window every Sunday at 4 AM, I had an epiphany (pun intended!) – there should be a rating on each apartment rather than the entire apartment complex as a whole. This time I was adamant that I was going to execute it. At this point, I hadn’t really built any websites, but I had done tons of programming (C++) and databases (don’t worry if you don’t know what databases are, I am going to talk about it in a future post), but no websites. So I naturally started sketching out the database design for this idea. I thought I was at the least executing, but I never went beyond that stage since I didn’t know how to design or make a website. My efforts stalled. I think this is the single most common reason why ideas remain as ideas and never get executed. A lot of people think the next step after you have an idea is building a website/product, but most of us don’t know how to do it.

So here is your next step. Drop all the tools and hammers, laptops and website for dummies books. You don’t need them at this point. You don’t need to build a product right away. What you need is a structured approach to know if you need to build the product in the first place. That structured approach is lean startup methodology.

What the hell is lean startup methodology?

At the core, lean startup methodology is all about validating each guess that you have about your startup and learning as you invalidate some of these guesses to change your assumptions and keep moving on.

Steve Blank, Eric Reis, Ash Maurya and all proponents of lean startup say that your startup is nothing more than a collection of guesses.

  1. You have a guess about a problem that your customers are facing (problems)
  2. You have a guess about the solution that will solve that problem (solutions)
  3. You have a guess about who your customer is (customer segments)
  4. You have a guess about where you are going to find this customer (channels)
  5. You have a guess about what value your product will provide (unique value proposition)
  6. You have a guess about how you will make money (revenue)
  7. You have a guess about how much it will cost you to make the product and get customers (cost)
  8. & 9. You haven’t even started thinking about who to partner with (partners) and how you are going to prevent competition from trashing you (unfair advantage).

That’s right, there are too many guesses! You can see here that I have mapped out 9 areas that should work together to make your startup successful. These are all guesses and you need to work systematically to validate each guess. These 9 areas collectively is called business model canvas and you have to go through the process of validating/invalidating each guess or in scientific terms, hypothesis using data driven approach.

Quick Tip: Forget about writing a business plan, instead focus on validating assumptions in your business model

Here is an example of business model canvas of Facebook based on Alex Osterwalder canvas (Author of Business Model Generation). Every one of us should relate to this Facebook example.Image

As you can see, the business model is composed of 9 parts as mentioned before. Certain things are different here, solution is defined as key activities, and unfair advantage is defined as relationships. While the above business model canvas works well, I prefer Ash Maurya’s (author of Running Lean) version of business model that lists problems and solutions directly.

Here is an example of Ash Maurya’s business model canvas as comparison to the business model canvas shown above:Image

Image

Example using Ash’s business model canvas – Cloudfire, an easy way to share photos of young kids with family & friendsImage

(Click to enlarge)

OK! I get this. Where do I start?

If you have a business idea, take a crack at business model canvas (either version should work).  You can also build it online using Launch Lean Lab or Lean Canvas. Both have 30-day free trial period.

Step 1: Fill in problem, solution and customer segments

Write your top 3 problems, top 3 features that will solve this problem and customers you are targeting on this business model.

Step 2: Fill in remaining parts on the business model

Try to fill in other areas as much as you can, but don’t spend too much time. You will probably over-think this, but trust me, fill this out as quickly as you can.

Step 3: Validate your riskiest assumptions

Then focus on validating your riskiest assumptions. Start with problem statement, solution and customers. I feel these are the riskiest areas for most businesses, but they can be different for other businesses. While identifying your customer that you can talk to, make sure you really understand what your customer looks like. Is it a disgruntled mom with a baby stroller in one-hand and grocery bags in another, shopping at 3 PM at Wal-Mart when she would rather be doing Yoga? Yes, it should be that specific! This is called building customer persona in lean startup methodology. Learn here about how “Food on the Table” followed their initial customers to grocery store to understand them. I talk about my experience with Lean Startup Weekend in this post on how we went from being an online scheduler for kids’ activities to a car-sharing app for busy parents in just 2 days by validating/invalidating our problem and solution hypotheses.

Step 4: Iterate until you validate your riskiest assumptions

When you invalidate any of your guesses (i.e. your guess was wrong), you learn from what you hear, and then change your guess to this new finding. You haven’t validated this guess yet, so you should set out to validate this new guess now. This is called a pivot in lean startup methodology. For example, for an online shopping startup your guess might be that your target customer is young female between 20-30 who have disposable cash, and no time to buy clothes. After you got out of the building and talked to your target customer, you found that this is not your target customer, but almost everyone talked about how their moms will love it. Now your target customer has shifted to 40-55 year old female and you will have to validate all your hypotheses with this new customer segment. This is an example of customer pivot. I will write a separate post on what questions you can ask your target customer based on my experience with Jobbertunity.

Step 5: Build your first MVP

Once you get through validating your problem statement, solution overview and target customer, you can think about building a small prototype. Again, this prototype need not be programmed, you can use excel, Powerpoint, Photoshop, sketches etc. to show your user what the solution looks like. The idea is to get something in front of users to get their initial reaction and iterate on it. Big companies like Zappos and Groupon used low-fi MVP in their early days to validate their assumptions (see details below). I talk about how I used excel as a MVP and got 3 paying customers with this MVP in this post.

Zappos:

  • Took photographs at a local shoe shop and put the pictures online
  • Got emails from customers confirming orders (huge validation!)
  • Bought the shoes at the shop & shipped them physically

Groupon:

  • Launched a WordPress blog for a pizzeria coupon
  • Validated the idea through redeeming 20 pizza coupons

Step 6: Validate other assumptions on the business model

Finally, after going through these three areas – problem, solution and customer, which in itself will most probably change your business idea, you will have to start working on other areas. Again make sure to identify the riskiest assumptions and work on those first. For example, a startup, Outbox, that was set out to digitize physical mail went out of business because they underestimated partnering with USPS, which was the riskiest assumption in their business model. They validated the problem, got a lot of people to sign up and provided them the solution, but their riskiest assumption failed and they shut down after raising $5 million. The details are here. So make sure you identify the riskiest assumptions first.

This might feel like a lot of work, but believe me, if you take one step at a time and focus on 2-3 hypotheses that are your riskiest assumptions at a time, then you will see the progress.

One final thing – you need to build a business that’s profitable. So make sure you plan to make more money than it costs you to run the company. The general VC rule is that your life time value of a customer (money you will earn off one customer in his lifetime) should be more than 3 times the cost of acquiring that customer. Also you should recover your money that you spent to acquire a customer within 12 months of acquiring that customer (through the revenue you generate from that customer).

General recommendation

When you conduct an experiment to validate/invalidate your assumptions, have a strict discipline. Decide on what will determine if the experiment was successful or not. Don’t budge on the success criteria. It’s called minimum success criteria in lean startup methodology. I have discussed an example of minimum success criteria in my previous post. For example, if you decide, 70% of people you talk to should rate the problem as “very painful”, and if you get only 65% people, your experiment has failed. How do you come up with 70% as minimum success criteria? Well that’s something for you to figure out. You can say we will still be excited to work on this problem if at least 70% people say this is a “very painful” problem. That becomes your minimum success criteria. In practice, this will be a little difficult to determine, but you will get closer with a few initial mistakes.

Quick tip: Be careful about confirmation bias (thanks Bhal for suggesting) as you would get into the trap of looking at data to make yourself believe that you are seeing positive signs. That’s why I say above, stick to your minimum success criteria and don’t budge on it.

Books & Resources

Below are the books that I have referred to in my post. The books are arranged in order of detail that they provide. Business Model Generation gives you a 10,000 ft. level view of lean startup methodology, while Running Lean and Lean Analytics provide more of tactical advice. The resources below are online tools that you can use to build your business model canvas and measure the progress.Image

Hope this gives a start to everyone who hasn’t gone beyond the idea stage. Please leave a comment below if you want me to deep dive into any of the steps or if you want to brainstorm your business model with me.

Quick Tip: Some of these online resources need subscription beyond 30-day free trial. If you don’t want to pay, create a mock-up in excel or Powerpoint and you will be good to go.

4 things I learned from my failed startup

Image

I have wanted to write a blog about my startup experiences for a long time, especially the lessons I learned from my failures.

Before I learned about lean startup methodology, I tried a startup the old way. We built Jobbertunity, a website that helps students organize their job search online – think of it as a CRM tool for job seekers. This was born out of my own frustration of organizing my job search. Our philosophy was very simple – “Build and then build and then build some more and they will come.” For obvious and unfortunate reasons, the startup failed. While I learned a lot, I still wouldn’t have done it the right way next time. I hope lean startup methodology will, hopefully, make me a better entrepreneur and product manager in the future. I have tried to summarize lean startup methodology here.

Here are some of the lessons that I learned from my failed startup.

1. Focus on your customer’s main pain point

We knew what a minimum viable product was. So we hacked up a website quickly and put it in front of students at my school (Duke University). This is where we started on the wrong path. Without understanding what their main problem was, we presented them with a problem and asked them if the solution fit that problem. They only focused on the problem that we presented and what followed was a slew of features that were requested. And guess what, we built them as well. We wanted to make every user happy. This gave us a false hope of progress – no. of features built, no. of lines coded, etc. While we built new features, it did not amount to improved user acquisition or retention.  We failed miserably at our attempt and we wanted to do something else. Lean startup methodology was the buzz word in the tech space that every entrepreneur was talking about. So we decided to look into learn startup methodology to get out of the old mindset of “build and they will come”.

After learning about lean startup methodology, we decided to take a data driven approach to customer validation. We decided to meet a fresh set of students from other schools who haven’t used our product. We came up with a set of interview questions, which were aimed at understanding what the pain points were when it comes to job search and how they were solving it today. We decided that at least 80% of the students we interview should say that their main problem is organizing their job search for us to continue with our current idea. This is called minimum success criteria in lean startup terminology. Of the 20 students we interviewed who did not know our product, not even a single student talked about organizing as their main pain point. The top two pain points that were discovered using this process were 1. Not getting contacts to network with, in companies that they were applying to and 2. Filling out applicant details on every job application.

With this approach we learned about our user’s main pain point in one week rather than wasting our time building the wrong product for 4 months.

2. Listen but don’t implement every advice you get

You will hear this from every entrepreneur you will come across. When we started out Jobbertunity, we had a clear view of providing quality startup jobs for MBA students, but our vision got murky as we digested every piece of advice that we got, until we changed our product to organizational toolkit for job seekers. This is how it started. We wanted to get the career management center buy-in for our product, so that we could roll out our product to students easily. When we showed our initial half-baked prototype that provided jobs to students, we were quickly recommended to provide organization tools because that was the main problem for students according to the career management center’s view. While they might be right in their own respect, we should have taken it as another piece of advice, and tried to find it from students themselves. But, we took it as the truth as we held the career management to know-it-all source about students’ pain point when it comes to job search.

In hindsight, this was the single worst thing we might have done in the course of this startup. We started dividing our attention on two problems now, which consumed our time as we built features to solve both problems. While it seems like a dumb mistake now, it took us a while to realize it. We started off on a completely different path without learning and 6 months down the line, we were asking students to give us feedback on a completely wrong problem and an unnecessary solution.

I would recommend – listen to everyone and take everyone’s advice. But validate the advice that makes sense to you with your customer. They are the only ones to tell you about their pain point and what would solve their problem.

3. Tune out false positive signals

When we launched our product, we got positive feedback from students who listened to our idea. A lot of them even signed up to check us out. But after that it was a ghost town in Jobbertunityville. People would tell on our faces that our idea rocked just to be polite to us. I would have, most probably, done the same. We took this excitement as validation of our idea. Next, we took part in business plan competitions and we got tons of feedback there as well. We got a lot of positive comments from these competitions and we were in the final rounds and even winners in some of these competitions. While it was a great experience, and we learned a lot from this experience, we took it as another step to success.

We were not able to tune out these signals as false positive and treated them as successful milestones. And when the excitement and jubilation died down, we were left with the same product and the same users, who weren’t using our product.

My recommendation to avoid this would be to put a list of tangible milestones that adds value to the business. Please be aware that pushing more features or building an iPhone app should not be the only milestones, especially if its an early stage startup.

4. Measure, measure, measure

I admit that we did not get a grasp of our customer’s pain point. But if we would have measured everything that is happening on our website, we would have known pretty soon, what’s important and what’s not. Since our website was an organizational toolkit, job seekers used our website to track companies that they were interested in, maintain contacts that they wanted to network with (via LinkedIn API) and track jobs (via indeed.com API), in short, maintain progress for their job search. If we would have measured the right metrics such as how many people visited, how many signed up, how many added companies, contacts & jobs, and how many of them were coming back to maintain their progress, we would have got a pretty good view of what’s going wrong with our product. Instead, we decided to focus on getting as many people as possible, i.e. went after scaling the startup before we knew what’s working well and what’s not.

I would recommend looking at Dave McClure’s pirate metrics for startup – AARRR (Acquisition, Activation, Retention, Referral, Revenue). Someone from your company should be looking at these metrics everyday and figuring out what’s going wrong. This will also help you prioritize the right things depending on your goals for your company. While these pirate metrics are good starting point, there are many metrics that you need to look at within each one of them. For example, within retention metric, we could have looked at how many people came back to our website after their initial visit at the basic level, but we could have also tracked what they were doing when they were there, for example, how many added companies vs. contacts vs. jobs etc.

Overall, we made a lot of mistakes and learned a lot from these mistakes. Could we have been smarter? Maybe! I have realized one thing through this experience, people love to do what they are comfortable with. Engineers love programming, so their natural inclination is building a product. But focusing on what really matters and keeps your company alive is extremely important, even when you have to get out of your comfort zone. Hope this helps other entrepreneurs who are starting their journey on this new path.  Take a look at lean startup methodology before you start building a product. It will save you a lot of time and energy and will help you fail fast and learn faster. Here is a post on lean startup methodology and my experience with it.

Quick tip: Have an idea? Go to a coffee shop and talk to users who you think will use your product. Offer a coffee for their time. Don’t ask them what they think about your product or if they would pay for it. Instead, ask how big the problem is, how do they solve it today, and what do they do before and after solving the problem. You will be amazed at what you learn.