This is the third and final part of the blog series that details my experience with lean startup methodology. I think this is a great framework (there comes out the MBA in me) for entrepreneurs who wants to quickly test their ideas.

Read example # 1 here and example # 2 here.

Example 3:

My co-founder, Amy Vaduthalakuzhy and I were scouting for business ideas last year. Based on our experience with Jobbertunity, we decided not to put any effort into building a product. Read about the lessons I learned from my previous failed startup.

Last year when we were brainstorming ideas, we read about how startups such as Postmates, Taskrabbit, etc. were disrupting the instant delivery market. We were excited by this opportunity and wanted to see if we can bring something to the market that would be disruptive and still be different from the existing services. We came up with an idea! We thought – why not use taxi drivers to deliver whatever people wanted delivered. Our differentiation was going to be number of taxi drivers that were available for delivery. While other startups built their own army of delivery guys (hiring, training etc.), we had tons of taxi drivers at our disposal.

Since our demand was already proven by companies such as Postmates, we focused on supply side (drivers for delivery) for this idea. Below were our 3 assumptions for a service that used taxi drivers as delivery guys –

1. Taxi drivers have a lot of idle time when they are circling around to find a passenger.
2. Taxi drivers would like to make extra money in their idle time. We based our price at $5 per delivery at par with other delivery services.
3. Trust will be a critical component to our delivery service, as taxi drivers will be apprehensive about accepting packages from strangers.

So instead of building a delivery app prototype and spending time to get a few drivers onboard to start the service, we decided to implement it without a product.

This is how we tested our hypotheses in a day. Amy and I wrapped packages of different sizes and weights, varying from a simple envelope to a big box (this was to test hypothesis # 3 regarding trust) and decided to hand them out physically to taxi drivers. We wanted at least 8 out of 10 taxi drivers to deliver our packages at a flat price of $5.

Amy approached taxis in the Castro area, while I flagged down cabs in the SOMA area. This is what we learned in 4 hours.

1. Taxi drivers drive 9-hour shifts and have tons of idle time. They spent a lot of time looking for passengers. However, we learned that they usually circle around the same area, rather than venturing out to other areas. Our plan was to use this idle time to deliver packages to other areas of the city, but clearly taxi drivers weren’t interested.
2. We had a few taxi drivers who were interested in delivering the package, but only for the fare that their meter would read, rather than a flat $5 per package. We even told them that there is no urgency in delivering the packages, and it was perfectly fine to deliver the package by end of the day. However, the taxi drivers did not know their schedule ahead of time and did not want to take on additional responsibility if they weren’t going to be around the place where the package was to be delivered.
3. Not even a single taxi driver asked about the contents of the package irrespective of its size and weight. The price and the distance were the deal breakers.

Eventually we got only 2 out of 10 taxi drivers to deliver, only because they were heading to the place where the package was supposed to be delivered. We quickly learned that we would get taxi drivers to deliver packages only if the price was higher i.e. at par to the price when they would actually have a passenger. And we wouldn’t get enough demand if we charged that high, especially with the existing services charging $5 per delivery. So we decided to drop the idea, as it was not a viable idea economically.

As you can see, rather than trying to get ourselves buried in developing an app as a MVP, we decided to get out of the building and test our idea. I am sure we saved ourselves tons of hours of work and disappointment by following this quick test.

A friend of mine, Abhas Art Agrawal, did a similar setup for his startup, Your Mechanic, which is a marketplace to bring together car mechanics and people who need mechanics to get their cars repaired. Before he got into Y Combinator, he contracted some mechanics on his own and then placed his service details and a phone number on Craigslist for people to call. When calls started trickling in from people who needed a mechanic, he decided to build a website. Rather than creating a website or a landing page or an app, he was able to quickly validate his idea.

Quick tip: I have recommended this to a bunch of my friends who had a marketplace idea (where two people come together to buy/sell products/services e.g. eBay, Fiverr, etc.). Instead of trying to build a website, you can use Google docs (spreadsheet) to test your idea. Put names of people who need the service and names of those who can provide the service and match them against each other manually. See if you get any traction. Or another option is to arrange one side of the equation by yourself (mechanics in case of yourmechanic.com) and find a way to reach out to your target customer providing this service (craigslist in case of yourmechanic.com). In my opinion, it is easier to arrange for supply (mechanics) and then try to attract the demand (people requiring mechanics).

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.

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”.

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.