Are You Building The Right Product?
techcrunch.com
techcrunch.com
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.
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.
It is an exciting trade-off!
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.
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.
meta-feature is like a magic, which is behind the scene and plays a big role.
[1] http://blog.500startups.com/2011/07/13/cohort-metrics-for-st...
[2] http://www.startuplessonslearned.com/2008/09/one-line-split-...
[3] http://www.avc.com/a_vc/2009/10/the-cohort-analysis.html
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.
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.
Why are you adding features if they aren't increasing sales?
Why are you adding features if they aren't increasing retention?
How do you establish causality?
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.