Some time ago, car manufacturers built batches of cars based on speculative customer needs: Engine sizes, interiors, paint colours & the number of each.
Sales folk were left with the unenviable task of persuading customers that what was on the forecourt suited their needs.
Sales folk were left with the unenviable task of persuading customers that what was on the forecourt suited their needs.
Of course, market dynamics took effect, the cars wouldn't sell at a profit. Instead dealers had to run loss-making sales to clear out the old and the whole crazy cycle would start again.
Eventually, some manufacturers figured out that having such "inventory" lying around as the result of speculation about customer needs was foolish. They moved to a pull model where the customer expressed their needs first.
In turn they re-configured their manufacturing apparatus to satisfy those expressed needs in a just-in-time fashion. Over time they eliminated the hoarding of parts further upstream and extended their pull concept into suppliers, even helping them implement it.
Output measures became largely irrelevant except for purposes of determining that the flow across the line into the customers' hands was achieved in satisfactorily short time.
The vast majority of sw dev has yet to make this leap. Output with the consequent build-up of inventory (features, code, infrastructure) continues to be the focus albeit with a glaze of respectability in the form of purported A/B testing.
Sw dev does not focus on pull, instead thrashing through as many supposed experiments as possible in the apparent pursuit of learning. Typically though, these experiments fiddle with minor things or have rigged criteria that allow a feature to "succeed" regardless.
These orgs are, in fact, still feature factories just like old style car manufacturers. You can see this in the backlogs, the obsession with fast and frequent releases and the focus on output rather than serious investment in the surfacing of customer feedback.
A few simple questions reveal all:
(1) How frequently has your org withdrawn a feature from its product?
(2) How often has your org killed a product?
(3) How do you measure the success of a product or feature?
(1) How frequently has your org withdrawn a feature from its product?
(2) How often has your org killed a product?
(3) How do you measure the success of a product or feature?
Chances are (1) and (2) sit close to zero implying prediction of customer need is almost perfect and there's no need for A/B testing. It also hints of iterative improvement of a what is a guaranteed to be successful feature idea.
This of course is a nonsense if you assert that customer needs have to be discovered via rapid releasing. Either you're discovering which means throwing things away or you are merely indulging in "learning theatre".
Looking at (3), we see measures such as features shipped, experiments run, size of customer population, profit made and such. What you won't see is anything close to customer satisfaction or the lack thereof (eg measures of failure demand).
Simply: If your organisation has scant arrangement for something being substantially wrong in its judgements, it's a feature factory. Expect sweat, dis-satisfaction and stifled creativity. There are, of course, other options...
