4 ms·
The biggest problem with the lean startup stuff is it results in this ridiculous false dichotomy. There is no "top down" or "bottom up" thing. If you assume you
by gfodor 14y ago
The biggest problem with the lean startup stuff is it results in this ridiculous false dichotomy. There is no "top down" or "bottom up" thing. If you assume you are in one of these two buckets you already lose because you either are abandoning your creative thinking (bottom up) or abandoning listening to what customers are telling you (top down.) I realize the common retort to this is that all startups need to have top down thinking ("vision") but the bottom line is the lean startup philosophy is at the very least poorly communicated because the large takeaway from all the writing on it is that startups should simply perform customer development and let the market dictate most of the actions they take and the products they build.
It's always a matter of deciding when to ship and how much time and resources to commit between data collection points (ie, releases.) This is a higher order function and changes as well in reaction to how you explore the solution space. Different domains have different constraints as to how fast you can iterate. Tesla, for example, is forced to iterate much more slowly than your average social gaming app can. Shipping too early, or shipping too late can result in wildly different outcomes. Drawing the line correctly is a matter of experience, taste, common sense, and luck.
Everyone knows you should try to minimize waste. Everyone knows you should prefer iteration over big releases. The question is always what constitutes "viable". A car that has three tires is not viable, and would be a market failure. The fourth tire takes a little more effort but makes the difference between success and failure. The problem is it takes some intuition to know people need all four tires to be willing to pay for a car. It also takes intuition to know that the three-tired car being a failure does not mean you should throw in the towel. I don't care how many metrics you measure, you can't use metrics to determine where an asymptote is going to appear because it's not going to be a part of any logical predictive model. Disruption is just that, disruption, and usually comes about due to a synergy of several things that were previously unknown to have magical properties when combined. You generally can't hill climb to find to these things, unless you set your step size (alpha) to a "Goldilocks" value: not too large and not too small.
I understand the appeal of creating a mental framework and slapping a label on it to help people think about and communicate ideas clearly. I think there are definitely some important ideas contained in the lean startup philosophy. But in the interest of creating a conceptual framework of absolutes like any other dogma the lean startup philosophy has large gaps in it's methodology that fail to explain for the large number of startups that launched products that many people would consider well beyond "viable", but were successful because their definition of "viable" happened to be the right one.
- lmm 14y ago>If you assume you are in one of these two buckets you already lose because you either are abandoning your creative thinking (bottom up) or abandoning listening to what customers are telling you (top down.) I find I write better code when I deliberately abandon my creative thinking. It's counterintuitive but it works.
- gfodor 14y agoYes, but do you build better products? In my own experience success or failure is essentially non-correlated with applying deep creative thinking or raw hypothesis hill climbing. Both seem to work in different circumstances. The lean startup method claims that it's anti-correlated since you will fall into the trap of acting on poor assumptions. But guess what, sometimes your assumptions are right and you have a unique perspective to create something almost nobody else would think to. Also, in my experience it's the subset of successful products that involved more creative thinking that I am most proud of and look back on my time working on more positively. Hell, this is even true for some of the failures. The raw hypothesis driven successes were high-five worthy, but not pride-worthy (other than perhaps a pat on the back for demonstrating my faith in the Church of Science), and the failures tended to be fairly painful since the work itself was unrewarding intrinsically and the outcome was negative. Nothing is really worse than hacking out code in misery because, counter to your intuition and your gut, signals point to it potentially driving a metric up, and seeing it fail anyway. You have to resign yourself to the process and tell yourself that, despite being right, your intuition is meaningless -- not a fun exercise as a human. It turns out, in my experience, that the most successful creators are talented at both: trying lots of stuff and learning from their failures, but also having that sense of empathy, intuition, and taste to simply "not be wrong" more times than your average person. You can't A/B test your way to having an opinion. And you can't let an A/B test let you change your opinion on the things that matter.
- jasallen 14y agoI agree with both. I tend to have Red Days and Blue Days. Red Days are coding days, working from my plan, no creativity allowed - that's the enemy of lean code. Blue days are creative days, very little coding - maybe a bug fix if creative me says that bug is really impacting experience. These days I plan big picture, I talk to potential customers and testers. I draw big picture plans on the whiteboard that Red me will implement. Can break up a day too, but you can never ever be creative and engineer well at the same time. At least I can't, nor can most people I've observed.