Great point. Paint shop pro comes to mind. People who weren't serious about graphic design who wanted pixel editing loved the early versions, and it became far less useful as time went on.
<< We divided our customers into cohorts, looking at the new customers who joined each day as a distinct group. Then we could ask, “How did today’s customers compare to yesterday’s?” And, much to our frustration, the conversion rates were almost exactly the same. It was easy to get conspiratorial. It felt like each group had set up a conference call with the previous group. “How many of you bought the product? One out of a hundred? OK, good, we’ll do that, too.” >>
This is so true. I've seen similar user behavior at almost every website I've worked on or built.
The good news is that it's hard to screw up your own website with new features. Also that despite how hard it is, many competing websites will add so many new (bad) features that eventually they will succeed in screwing up their website.
Sometimes I wonder if this is why Craigslist has "won" for so many years. Not in spite of having so many competitors adding new features, but because they have had so many competitors adding so many new (bad) features.
Never ignore the meta-features, the basic characteristics of your product. Performance, usability, robustness, security, etc. Consider how many real-world products are differentiated entirely on such features, the same is true in every domain, including software. An Audi does not typically have any stand out special gimmick at getting from point-A to point-B better than a Kia, but it differentiates itself through performance, luxury, reliability, image, etc.
Or consider an even simpler product: chef's knives. Does a higher end chef's knife have more features? Does it have a bottle opener, a pair of scissors, a little pocket for a foldable cutting board to fit in, or a tiny countdown clock to tell you when you should get your knife resharpened? No, it's just a hunk of metal attached to a handle and shaped correctly. And yet there is still such an enormous variety of designs, styles, and methods of construction as knife makers pursue perfection and try to compete against each other.
Knowing where to draw the line between a basic value proposition and extended features is crucial to success. I have this same dilemma. Users have been requesting features to one of my websites, but I am unsure if adding these features won't detract from the simplicity of the experience. Currently users do 10 pages a visit, which to me, tells me they understand the flow of using the website.
Another core insight is to differentiate your "users" into specific user types, or personas.
To really drive value, it helps to identify a specific user-type or persona that drive a lot of value for your site. For Dropbox, one persona might be a photographer who is using Dropbox to share huge photos with clients. To better serve that persona, maybe Dropbox could create a Gallery feature so that images in a Photos folder are automatically turned into a gallery that anyone can view without having to log into Dropbox. This is actually something that they did:
http://www.dropbox.com/help/18
By differentiating from general discussions of "users" into specific personas, you can really focus your customer development on superserving a specific user focus. That's a huge element of driving value creation through the lean methdology.
I wonder how many people use it. I didnt know it existed. They have built a platform with zero discoverability. Maybe they could dropbox sync a new features file into a folder sometimes...
Can someone please summarise the main methods of the Lean Startup Methodology? I keep reading a lot of high level posts like these, which sound like common sense to me, but I guess it's not, otherwise Eric wouldn't be writing a book.
I have pre-ordered his book, but if someone can explain the nuts and bolts of a few methods, that would help me appreciate the whole movement a lot more.
It's probably my ignorance, but right now, my personal Lean philosophy is simply "you make what you measure". For example, this month I really need to get a specific amount of recurring revenue coming in. So I have a nice big chart of revenue on my wall.
It's hard to summarize all this in just a few bullet points, but I've found that it's helpful to understand the history of Lean when digging into lean startups. The Lean Startup methodology has its roots in Lean Manufacturing:
http://en.wikipedia.org/wiki/Lean_manufacturing#Overview
Basically, both lean startups and lean manufacturing focus on eliminating waste. For lean manufacturing, it's usually assumed that you're making something that people want... so the focus is on making that product with a minimum of waste. For lean startups, it's often much less clear what you're supposed to make. So the lean startup methodology focuses on helping you make software that people actually want. Making software that people don't want = "waste" in the Lean verbiage.
"You make what you measure" is a useful first step towards embracing Lean. But as Eric points out, sometimes metrics go up regardless of what you do. How do you know if you're measuring the right metrics, and making software that people want? That's a core focus of the Lean Startup methodology.
Thanks for the slides, they are a bit more specific. I'm aware of the background philosophy. I'm just looking for specific answers to "How do you know if you're measuring the right metrics, and making software that people want?" spelled out, instead of the same underlying rhetoric again and again.
I know it's not as simple as just listing bullet points, but if we are talking Science, then it would be nice to see for example, how Bayes Theorem is applied, rather than repeating how important statistics are.
To be crude, because of all the constant theoretical chatter, I am skeptical of the Lean methodology, which is irnoic given it's supposed emphasis on experimentation.
I also feel it subtly instills more fear into developers by not letting you try crazy things which have a high risk of breaking stuff but also the biggest payoff.
In short, my hunch is that you can get an IMVU from lean, but you will never get a Facebook.
it is intentionally left vague, for the main reason, there is nothing that will work 100% of the time or a one size fits all. What you need to take away is more of make sure you understand your market/product/customers so you know what they want. Through experimentation ( building a product or feature based off of your expertise along with metrics of what your customers demand), you'll need to test, understand, and iterate, to determine what to do next. I don't even know if Eric Ries is/was a successful entrepreneur but he is considered a thought leader in practices made popular by himself and Steve Blank
Make the right decisions based on measuring and talking to people before you start building and waste time. Code is not progress. Decisions (based on facts) are progress.
Progress is: a greater conversion of people who hear about your product to people paying you money for your product. Note the present tense in "paying": retention is the root of success. So, measure your sales funnels and measure your retention.
Why are you adding features if they aren't increasing sales?
Why are you adding features if they aren't increasing retention?
>> Most product teams don’t know if they are making their product better or worse; that’s why customers feel a twinge of fear every time they have to update or upgrade.
CORRECTION: that's why most PRODUCT TEAMS also feel a twinge of fear when they update or upgrade. We get over that by committing small changes regularly, instead of waiting for major changes to be thrown down all at once and disrupt our users. Also, all new UI or design features we launch in an A/B testing environment, which tells us right away if something is wrong.
