Showing posts with label lean. Show all posts
Showing posts with label lean. Show all posts

Saturday, June 16, 2012

Metrics to understand cause and effects (aka "impact")

As Eric Ries pointed out: only those metrics that help you in making decision matter; the others are "vanity" metrics.
Actionable metrics help you to understand the progress of your business. In particular they help you in understanding the impact of your decisions, being design or marketing decisions.
In order to do so in a systematic way, you need to first understand the dynamics of the customer behavior, also known as the customer life cycle. Many examples are given for eCommerce since metrics are easily implementable through Web Analytics. However, also in other types of business this can be done effectively.
I would like to provide here an example which is different than eCommerce and that I am trying to experiment myself.
As a consultant, I provide an stretegic advisory service to startups so that they can successfully implement the Lean Startup approach for boostrapping their business or introduce new products. I provide them with an "external" perspective to their business so that they can start validating their business model's hypotheses right from the beginning and not when it is too late.


What are my Business Model hypotheses?
1. Startup's founder need a different approach to business development;
2. Even if they know about Lean Startup they need someone who guide them through the process;
3. They are willing to pay a relatively small fee to get a "one-man advisory board".

Of course, it is not possible to validate this kind of hypothesis with Web Analytics. Moreover, I need to turn qualitative feedback into quantitiatve performance indicators.
In order to test hypothesis 1, I started talking to individual startup founders in order to understand where they were struggling in business development. Actually, a recurrent pattern was that they are not able to plan on the long term and be able to convince investor in financing their ideas. Therefore, if they want to persevere, they need to find a way to self-sustain and rapidly start sellign something. In that respect, I am gathering evidences that the standard approach, i.e. the Business Plan, is perceived as an "unavoidable evil" that founders have to do in order to be considered by incubators, advisors, early investors, etc. In other words, they don't see a value in doing it but just a perfect waste of time.
In testing hypotehsis 2,  I discovered that Lean Startup idea is gaining field over mainstream approaches to business development. In the same way as it happens in software development with Agile methods, Lean Startup is seen as "common sense" for business development. People believe that the principles of Lean Startup are very reasonable, but they ask questions about how they can implement them. Following the analogy with Agile SW development, I believe that a "Master of ceremonies" (e.g. as a SCRUM master) is essential. In Lean Startup, startups need someone who help them keeping on track by avoiding falling into their own "reality distortion field". Founders believe they are right until they launch their product and realize they weren't. And this often happens too late to recover.  Founders need to change their mindset and attitude towards failure and experimentation. So far, the recurrent pattern is that often consultant are hired to confirm the company's strategy and if the consultants provide negative feedback they are probably fired.  As an advisor, I am supposed to challenge the founders and their business models so that unvalidated hypotheses will emerge very early in the process. The question is, am I able to change the founders' mindset and move them out of their comfort zone? This is exactly the hypothesis I am trying to validate.
Finally, in order to test hypothesis 3, I figure out one possible approach. In consulting/advising, the most appreciate currency is referral. Once people start appraising your skills, you will get customers in no time. Therefore, I considered useless to start charging money for my MVP and I proposed my first 10 customers a win-win deal: I will provide my service for 4 weeks provided that you will accept to write a public endorsement in case of satisfaction. After the 4 weeks, they will decide if they want to continue or not on a subscription basis and for a price which will be established according to their perceived value. I don't know if this approach will work or not. After all the MVP is not just the Lean Startup Model, but also my skills as an adviser. I consider this as a very explorative metric where I am trying to figure out the "real" value I can offer to my customers. On its results, I will be able to decide if a price and a marketing strategy, or even to target a different market segment.
In summary, for a metric to be actionable one needs to:
1. Gather insights on the customers needs and wants and in particular select the "must to have" features from "nice to have" features.
2. Understand the impact of your decision in the development of your business. Not only in cases where it is going to work, but also in the (very probable) cases where it doesn't.
3. Realize what is the perceived value of your product/service. In one market segment, customers might consider your product as a "must to have" but only for a specific price range, while it could be completely different story for another market segment.
These elements can be elicited, in my opinion, for any type of busines, product and market. In that sense, I believe that the Lean Startup model is a universal model. My long-term objective is to provide an empirical proof of this universality.
      Vincenzo Pallotta, Strategic Adviser at LeanStart, Geneva, Switzerland.

How to design a Minimal Viable Product

While it is pretty clear that a Minimal Viable Product (MVP) enables validated learning through its adoption by early adopters, it is not clear enough what it actually is.

Even Eric Ries seems to be very vague on what actually constitues an MVP. He says that essentially a MVP is a learning tool that we can use to learn about the targeted customers needs from early adopters providing them with the minimal set of features that they accept to find in your product.

Minimum Viable Product

View more presentations from Eric Ries

But now the question is how to figure out the minimal set of features? In order words, how do I know the needs adn wants of early adopters?

This might seem an chicken-and-egg problem, but there might be a way out.

First of all, WHERE do I find early adopters. Well, of course it depends on the type of product, but high chances are that you find in place where the people talk about simiar products (e.g. discussion forums).

Second, HOW I select the features for building my MVP? Here is my 2 cents about the topic. You can follow these simple steps:

  1. It is very likely that your product is similar to existing products. If it is the case, you can select the most similar one and list all the features of this product.
  2. Once you have listed these features, select those that your product will share with it and add those features that will differentiate your product from the selected one.
  3. Now (and this is the hard part), start to remove features. Once you removed a feature, ask yourself, is the resulting product still something "acceptable"? You iterate this removal process until you reach a situation where removing any of the remained feature will make the product "unacceptable". 

One suggestion, to improve the process is the following: for each feature you want to remove, ask yourself what is the value of this feature to the user/customer and try to understand what is its contirbution to the overall perceived value. You might even rank them beforehand and start removing them from the lowest valued features up.

Notice that this is about "features" of your product and it does not tell you if you have to implement them into a real functional prototype. This process leads to the design of a product that is the "cheapest" to build because only contains the features that define the "substance" of the product.

Building it or not is another story. Namely, it fundamentally depends on what resources you have. If you can afford to build a real instance of your MVP, that's great because you can directly sell it to your early adopters. But sometimes (often?) this is not possible. In this case, you can tell your early adopters about the "design" of your MVP and ask them for feedback or, even better, to support its development. In times of economical recession, maybe this is the way to go and there are a lot of successful cases of crowdfunding out there such as KickStarter.

My personal suggestions are:

Don't be afraid to eliminate "vanity" features from your MVP as long as it represent your vision. There will be time to reintroduce them later.

Dont' be afraid to ask your early adopters to pre-order your product. Sales are the only reliable indicator that people really want what you offer to them. If your MVP requires an effort that you cannot afford, ask your potential customer to help building it. After all, this is a win-win situation because they will eventually have what they were looking for. 

Don't ask investors to help you in building your MVP. Investors are not customers and basically they are interested in their return on investment and company ownership. Always be aware that with an MVP you are running an experiment that allows you to learn what the market really wants. Inverstors are not interested in experiments that have a high chance to fail.

Make several versions of the same MVP and split test. There is a high chance that you made a mistake in selecting the relevant features.

Listen your potential customers and ask them to help you in designing the MVP: they know better than you what they want.

Vincenzo Pallotta, Strategic Adviser at LeanStart Geneva.

 

Monday, May 21, 2012

Startup status does not last forever!

Reading this post on the reasons why Path and Flipboard are no longer adopting the Lean Startup model, my intuition tells me that the true reason is because they are no longer startups.

It probably does not make sense to stay lean when you need to scale. Scaling is a big effort that require a heck of resources. When a company decides to scale, it can no longer afford to make pivots. Yes, because there is a committment on the infrastructure which renders even small changes extremely expensive.

This means that when you decide to scale, you must do it right. And to do it right you need to have learned everything about your business. 

So, I believe that Lean Startup has its own scope and it is a mistake to try to apply where it is not appropriate.

Friday, May 11, 2012

Lean vs Fat startup debate: an argumentative analysis

From this video, Mr. Ben Horowitz has pointed out three alleged flaws of the Lean Startup Model:

1. It presumes when you have achieved product-market fit. The supporting example was about measuring success of products over time. iPods did not sell as fast as iPhones, and on that basis Apple should not have introduced other iPod models after iPhone. 

This argument is flawed because, first Apple is not a startup. Second, and most importantly, Lean Startup never said that one should use metrics from another products to assess the product-market fit of a product. In the example, exactly because of the risk of cannibalizing iPods, Apple decided to introduce new models (i.e. to do a pivot, as Lean Startup suggests).

2. Lean Startup presumes that once you have product-market fit you can't loose it. The supporting example, is Netscape that once had the product-market fit, but lose it when Microsoft included Internet Explorer in the OS.

Again, the fallacy resides on the fact that Netscape was not a startup. But more importantly, this was not a problem with customers needs, but rather than an external factor that forced the users to accept Microsoft policies/strategies. Horowitz points out that they "did not have the luxury to address the issue in the Lean Startup way". That's not a "luxury", is a rational way to adopt if a company cannot afford to splash milions for crashing new product development. Actually, it is the Fat way a luxury that startups cannot afford. In such a case, Lean provide a way to achieve decent results with a fraction of "Fat" resources.

3. Lean startup implies or assume that there is no competition. What if prior achieving product-market fit, even if the market is large, a scary competition appears. The supporting example is taken from VMWare who take care to invest money in order to be ahead of open-source competitors like Xen and big scary competitors such as Microsoft.

The argument is obviously fallacious because, first not even VMWare was a startup, but secondly because if crashing massive resources to gain competitive advantage works well, this does not necessarily mean that Lean doesn't. When it is not possible to deploy brute force to deal with competitors, Lean offers smart tools (like David and Goliath). One idea is to elicit niches where competitors are weak or not considering so that the startup can avoid direct competition and possibly erode the main market. Lean Startup is in that sense compatible with the work of Christensen's work on disruptive technology and emergent markets. 

The problem with Horowitz is not business skills; it's LOGIC. He provided three fallacious arguments against Lean Startup. I also believe that Lean is not universal and there are many contexts where it does not apply well (e.g. large established companies for mainstream products). Also, Lean Startup advocates that once the business scales, the conditions change and probably the methodology is no longer applicable.

Besides, a Fat startup model has several problems, among which "premature scaling". Horowitz was unable to explain how the Fat model could be beneficial for startups as he showed only Big Companies examples.

On the other hand, the Willson's argument was much clearer and plausible:

"Wilson’s argument focused more on how to maximize the probability that entrepreneurs will get favorable exits. He boils down the formula to: (Founder’s Stake) x (Probability of an exit) x (Size of the exit). Wilson says to focus on the first two variables. Accepting more funding will dilute the founder’s stake, but it isn’t going to proportionally increase the probability of an exit (which is based on far more factors). In other words, it hurts the likelihood of a favorable outcome (at least from the entrepreneur’s perspective). Likewise, he says investors are looking to mitigate risk, which is why investing small amounts when a company is young is in their interest."

However, he only focused on one of the many benefits of the Lean Startup model: the reduced need of initial resources. Lean Startup is a comprehensive methodology that make sense for startups (possibly with a few exceptions), and it has several facets. 

My personal opinion is that Lean Startup can help startups in finding the right direction towards a sustainable, profitable business model by incorporating failure in the product and market development process. Failure becomes a learning event, which allow the startup to "rule out" the failing paths (or pruning, to use a Computer Science terminology, the "dead branches" of the business opportunity search tree) very early in the process.