Like it or not, many of us are working in feature factories . We’re churning out feature after feature, trying to deliver on a roadmap. To some that’s just how it’s supposed to be, but for others Feature Factory became the banner term for all that’s wrong with traditional product development.
Why are we so divided? And who is right?
Systems theory and some historical perspective can help shed light, and perhaps also offer a view of the alternatives. It may sound a bit theoretical at first, but stay with me and I promise to make it relevant very quickly.
Here’s what a production unit, for example a factory, looks like from a systems theory perspective.
The function of the factory is to transform inputs—materials, parts, people, machines, etc—into outputs which are manufactured units. Invariably the factory produces also waste: leftover materials, bi-products such as heat and pollution, as well as defective units that don’t comply with the specifications.
The model immediately calls out some clear objectives (which have become the hallmarks of classic business management):
- Efficiency — Improving the ratio of output to input (aka doing more with less)
- Quality — Improving the ratio of output to waste
- Throughput — increasing manufacturing capacity to meet demand
Indeed the 20th century is a story of innovation in all of those. From Ford’s assembly lines to today’s robotic factories, we were able to greatly increase the throughput and quality of our plants, while reducing the cost of production, which led to the product affluence we’re experiencing today.
Enter The Feature Factory
Somewhere in the 1980s software started eating the world at an accelerated rate. Business executives found themselves managing companies that had a software department (which for some reason many call IT), or even managing a dedicated software company.
For these folks the factory model still held firm; They needed to create a software production unit (aka Delivery team) with clear inputs and outputs.
But there were some complications:
- In software there’s no “one right way” (a term coined by classic management theorist Frederick Winslow Taylor) to produce. Unlike production-line workers, software developers and UX designers cannot be told how to develop the software because each project is new and different; It’s their responsibility to figure this out. This meant hiring better-educated people and paying them higher salaries. Person-week became the most important unit of input.
- As the products became more technical and complex, managers found it hard to tell the developers exactly what to build. So a new role emerged—the Product Manager, or now the Product Owner, which from a classical management perspective is the person that translates the roadmaps into specifications that the “Delivery” team can consume.
With these two problems out of the way we were able to create the feature factory:
Now managers could go back to the important business of optimizing outputs to inputs. You can see the results all around you. Some optimizations such as cloud computing and pair-programming make sense. Others, such as open space, and performance appraisals have a more questionable impact. But perhaps the biggest productivity hack of all came from the engineers themselves. Agile development was invented to replace classic waterfall project management with a lightweight, iterative approach to creating software. However, consultants gradually learned that they can sell Agile better when they positioned it as a productivity booster — more code pushed to production in less time and effort. It was a massive success. Today I see a strong correlation between output-focus and heavy-handed implementations of Scrum and SAFe.
In my Lean Product Management courses we practice using principles, frameworks and tools that bring modern product management thinking into any org.
Secure your ticket for the next public workshop or contact me to organize an in-house workshop for your team.
Major Cracks in The Model
In theory the feature factory just makes sense. In practice it’s a very flawed model.
In a real factory every unit produced—every car, chair, or can of soda—creates some value: we can sell it and earn money. Hence more output equals more value.
When we’re developing software, the features we “produce” are not sold individually, but are rather added to an existing product (in this sense software development is more like city development than it is like car manufacture.) Each product change is supposed to create some incremental value—more transactions, more revenue, time savings, and so on, but these are hard to measure, and we often don’t measure them at all. In the spirit of our ancestor industries, we assume everything we choose to create is of value.
But is it?
In the past decade we started getting the answer. Companies who used A/B experiments to test their ideas learned that in the best case scenario only 1 in 3 ideas lead to any measurable improvement, and the common case is much lower— likely 10%-15% success rate.
But the bad news doesn’t end there. Every feature we launch costs us in multiple ways. In addition to the cost of development there’s also the cost of supporting and maintaining the new feature for its lifetime. In a feature factory the “workers” both produce the product and maintain it. Every addition to the product adds to the overall cost of maintenance and also complicates the codebase and the user interface, making future development that much slower and more cumbersome.
The conclusion of these two new factors is quite unintuitive. When most of what we produce is of no value, but everything is costing us in multiple ways, optimizing for higher throughput means producing more waste faster, at an ever growing cost (see this article for numerical examples). The classic path of optimizing for efficiency, quality, and throughput is sending companies down a slippery slope of producing bloated, hard-to-maintain, low-value products.
This fact is not a secret. It’s the reason for the growing rift between product organizations and traditionally-minded management. PMs, developers, and designers know that the feature factory model is horribly inadequate and wish to replace it with something better, while business-trained management persists in the age-old approach.
Join thousands of of product people who receive my newsletter to get articles like this (plus eBooks, templates and other resources) in your inbox.
The very best product companies use a different mental model altogether. They pursue goals, not roadmaps, and they optimize for outcomes, not features. They view their product organizations (which are almost always broken into semi-autonomous cross-functional product teams) not as code producers, but as value creators—value for the company and value for the customers. The modern product org produces not just outcomes but also domain knowledge—a critical resource for success.
This change entails even a bigger departure from the classical management approach. The product organization is no longer told what to do (as in a roadmap), but rather what to achieve (as in outcome-based goals). Delegation and trust play a key role.
The change goes both ways. The product org needs to stop viewing itself as a production unit (you’d be surprised how many do). Our job is no longer just to work heads-down developing features per a spec. The product org needs to produce traction towards the goals, and this traction needs to be communicated clearly to the rest of the company (which helps in creating trust). Experimentation and evidence play a major role.
(To get a sense of what this world looks like have a look at the GIST framework.)
Even more broadly, the classic siloing of management, development and business has to go away. As I’ve written before, our aim should be to break the walls and have the entire company work together towards shared goals—creating value for the company and for the customers.
Some forward-thinking managers I speak with truly desire switching to this model. But they’re held back by classic thinking. I see a lot of OKRs about boosting efficiency and improving productivity. Many CTOs see having developers work at 100% capacity as the prime goal and push their teams to deliver more story points per sprint. While there’s nothing wrong with any of these per se, they are at best second-order optimizations, and at worst major waste generators. The better optimization is pursuing a higher ratio of positive-value launches. If you embrace this goal, a lot of things that you do today will no longer make sense. It’s the first step in a long journey towards putting the antiquated feature factory model to rest.
Image: Alden Jewell