Comments (0)

By Patrick Vlaskovits, March 4, 2010 5:29 pm

I attended the most recent Startup2Startup event and after the presentation, the discussion turned to how one might define Product-Market Fit and what might serve as a proxy for Product-Market Fit, given various types of business models.

The Sean Ellis 40% rule-of-thumb was quickly invoked as were other ideas.  However, I thought it worthwhile to share one insight that came from an experienced start-up entrepreneur at the table.  While we were talking about triangulating on the various signals available to an entrepreneur as to what constitutes Product-Market Fit, he recounted a story — really an accidental natural experiment — on how he unequivocally learned his start-up hadn’t achieved Product-Market Fit.

To wit, his site had gone down for a few hours, and he hadn’t known about it.  In the interim, there had been nothing but silence.  None of his users had squawked or had made it publicly known that the site was down and they were angry/frustrated/furious/going to switch providers/fed-up-with-this etc., etc.

This lack of frustration/noise is a data-point.  In this case, it meant his start-up had a ways to go on iterating to finding Product-Market Fit.

As a contrast, we might choose to look at what happens when Twitter goes down.

So, for the more intrepid of you out there, perhaps try “accidentally unplugging” your servers and see what happens.  (Clearly, this has significant risks such as alienating users, but it may be a useful signal to know when you don’ t have Product-Market Fit, if you were wondering.)

BTW, I believe Dave McClure has advocated a very similar idea with regard to features.  If I recall correctly, he suggests removing features from a web app and waiting to hear if users complain loudly.  The intensity of the complaint is likely correlated with the usefulness of the feature.

Comments (1)

By brantcooper, February 16, 2010 10:22 am

Minimally viable, a product evolved:
Early it was pliable,
Target market try-able;
few features, but reliable
In what makes it buy-able: problem is resolved.

Comments (14)

By brantcooper, February 10, 2010 6:03 pm

I hear two schools of thoughts regarding the use of automated surveys: some prefer open text fields, others prefer buttons.

Assume you were asked to take a customer survey for a product you use or are considering using.  The survey is short (fewer than 10 questions) and completely voluntary.

 Loading ...

(For those that prefer text fields, my apologies.) Please let me know why you prefer one over the other in comments.

Comments (8)

By brantcooper, February 9, 2010 1:36 pm

Lean is not about the funding you take,

The size of your sales force, the money you make.

Lean is not how much money you spend,

That you like your product and so does your friend.

To test your guess and iterate,

To kill your favorite feature your customers hate,

To exercise ideas, removing the sheen,

That is what makes a startup lean.

Comments (3)

By brantcooper, February 3, 2010 12:10 pm

Because of the overwhelming response and great feedback for the the Customer Development image I recently shared, I decided to share another from our upcoming book. Please let me know what you think.

Figure 2. Ries' Lean Startup: Customer and product development interrelatedness

*CPS = Customer-Problem-Solution

As shown in Figure 2, customer development and product development are two distinct, but interrelated and iterative processes. As Eric Ries describes, the Customer Development team works on testing the problem-customer-solution assumptions, while the Product Development team tackles the solution.  The product development process receives input from customers indirectly through customer development, and (in the web world) directly through measurement of product usage.  The product development process actively iterates on the product, releasing new or different functionality directly to the customer as quickly as possible.

The customer development process receives input from customers indirectly through product development reports on feature usage, but also directly from customer development processes and analytics.  The customer development process iterates on core business assumptions, product functionality, and acquisition and conversion assumptions, resulting in updated hypotheses, honed messaging, positioning, marketing tactics, and feature requirements.

In the Customer Discovery context, a lean startup is not one that necessarily uses lean manufacturing precepts per se, but rather one that uses fast, iterative development practices in conjunction with customer development methodologies in order to:

1)       Validate core hypotheses (customer-problem-solution),

2)       Produce an MVP,

3)       Achieve Product-Market fit,

4)       Produce a development and marketing roadmap for scaling.

Creating a proper iteration loop requires you to predefine success and failure for each stage, and a means to measure your progress.  For example, in the web-based world, Dave McClure’s AARRR metrics (Acquisition, Activation, Retention, Referral, Revenue) might be applied to measure the stages from concept to product-market fit.

(BTW, if you are interested in being notified when the book is published, sign up here.)