I’ve been the guy religiously arguing for pushing an early version of the product in front of users as soon as possible (as the saying goes, “if you’re not ashamed of your first version then you’ve released too late”), not in order to learn whether it’s a good product or not, but to learn details of what needs to be improved but also what doesn’t need to be improved (because nobody cares about / notices the “problem”).
A related debate has been about how much you should spec out your product before putting it before customers—Big Design Up Front vs. figure stuff out as we go along based on user feedback. I usually prefer the second, but have to admit that Big Design Up Front is probably the best (albeit less fun) approach. Part of that preference for improvisation is probably because of some halo effect around the fox approach or agile or XP or empiricism or something.
(probably paraphrasing this post a bit) So we probably have an issue where “we” (nerds) have plenty of warnings about trusting theory too much, but few warnings about trusting empiricism too much, so we’re bound to end up under-valuing theory. Especially once we start attaching identity labels (hedges vs foxes, scruffies vs. neats, hackers vs. architecture astronauts...).
It is worth considering that in other environments than this one, speaking directly to the point with calibrated confidence is not the persuasive tactic. Just get something in front of users is a not a complete statement of the optimal strategy, it is a rhetorical overreaction to insisting on millions of dollars and years worth of waterfall-model development before actually checking to see if anyone cares. When these ideas were first proposed, IBM had overwhelming market share in computing.
The big corporate model of product development was and is very good at producing a finished product, the problem is it doesn’t address whether anyone will buy it. This is solving the wrong problem—Big Design Up Front was mostly about how to use the corporation’s technical resources efficiently. Further, it is all-or-nothing; people either buy the finished product or they do not. This still looks like the basic case of good model or bad model, not one of no model at all.
There are two further things to consider: one, that IBM is generations of dominance ago clearly indicates the norm has moved a great deal from that time; two, IBM is still alive and still routinely criticized for the heavy, bureaucratic way it goes about business.
I’ve been the guy religiously arguing for pushing an early version of the product in front of users as soon as possible (as the saying goes, “if you’re not ashamed of your first version then you’ve released too late”), not in order to learn whether it’s a good product or not, but to learn details of what needs to be improved but also what doesn’t need to be improved (because nobody cares about / notices the “problem”).
A related debate has been about how much you should spec out your product before putting it before customers—Big Design Up Front vs. figure stuff out as we go along based on user feedback. I usually prefer the second, but have to admit that Big Design Up Front is probably the best (albeit less fun) approach. Part of that preference for improvisation is probably because of some halo effect around the fox approach or agile or XP or empiricism or something.
(probably paraphrasing this post a bit) So we probably have an issue where “we” (nerds) have plenty of warnings about trusting theory too much, but few warnings about trusting empiricism too much, so we’re bound to end up under-valuing theory. Especially once we start attaching identity labels (hedges vs foxes, scruffies vs. neats, hackers vs. architecture astronauts...).
It is worth considering that in other environments than this one, speaking directly to the point with calibrated confidence is not the persuasive tactic. Just get something in front of users is a not a complete statement of the optimal strategy, it is a rhetorical overreaction to insisting on millions of dollars and years worth of waterfall-model development before actually checking to see if anyone cares. When these ideas were first proposed, IBM had overwhelming market share in computing.
The big corporate model of product development was and is very good at producing a finished product, the problem is it doesn’t address whether anyone will buy it. This is solving the wrong problem—Big Design Up Front was mostly about how to use the corporation’s technical resources efficiently. Further, it is all-or-nothing; people either buy the finished product or they do not. This still looks like the basic case of good model or bad model, not one of no model at all.
There are two further things to consider: one, that IBM is generations of dominance ago clearly indicates the norm has moved a great deal from that time; two, IBM is still alive and still routinely criticized for the heavy, bureaucratic way it goes about business.