Why Internal Ventures are Different from External Startups

Steve Blank

Henry Chesbrough is known as the father of Open Innovation and wrote  the book that defined the practice. Henry is the Faculty Director of the  Garwood Center for Corporate Innovation, at U.C. Berkeley in the Haas Business School.  Henry and I teach a corporate innovation class together.


Thanks to Steve for the opportunity to share my thoughts with you all.  This post follows directly on Steve’s earlier excellent post, Why Companies are not Startups.

The question of how corporations can be more innovative is one I have wrestled with for a long time.  For those who don’t know, I wrote the book Open Innovation in 2003, and followed it with Open Business Models in 2006, and Open Services Innovation in 2011.

More recently, Steve, Alexander Osterwalder and I have started sharing notes, ideas and insights on this problem.  We even ran an executive education course last…

View original post 1,162 more words


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


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

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.

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.


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.