Enshittification as Overproduction in Software, Part 2: Overproduction in the product lifecycle
Part 1: Seeing Overproduction talked about why it is so hard to see overproduction in software from the inside. This post picks the story up to discuss when software becomes especially vulnerable to overproduction and what can keep it in check.
Assessing value is truly a hard problem, so it’s not surprising that people half-ass it. Unfortunately, you can only get away with a half-baked approach until you can’t. And by that time, you’ll wish you had started preparing earlier.
Overproduction is never a good thing, but its impact changes over the lifetime of a software product. In the earliest stages, when nobody’s using the product yet, overproduction doesn’t damage an existing business. Instead, it wastes runway, the time a team has to strike growth, so the trick is not to build too far ahead. In fact, somewhere in every successful product’s past was a time when all capabilities were overproduction, made for users who might or might not come.
Kent Beck calls this the “Explore” phase of his 3x model. Explore is the entry point to the later phases of “Expand” and “Extract” (which I to call “Sustain” for reasons that’ll be clear later). Explore is about testing riskiest hypotheses and finding a fit between product and a market. There’s a constant cycle of overproduction and throwing away, aka “failing fast.” The product has nothing to lose.
After Explore comes a time of growth, or Expand, when the pull is so strong from the market it’s hard to go far wrong. In Expand, the market is shouting, and the skill is managing the cacophony, selecting and sequencing work to meet the demand. The org’s culture gets baked in Expand. There may be some overproduction, but by and large, Expand feels like furious unblocking, where delivery excellence is key because the demand is strong.
But then the shouting noise starts to fade. Is it just a lull or has the tide turned? It’s so hard to tell when you’re in the middle of it. You’re only sure when the growth has undeniably slowed, when you’re well into the third phase, Sustain. In the meantime, our instinctive reaction is to produce more, as if this will somehow prove the quiet is not our fault.
By producing without demand, though, we lose valuable time we should be using to build skills, practices, and internal culture for a transition from fast shipping to balanced decision-making. It’s common for businesses to mistime the transition. Judging by the mass of overwrought products we end up using, the gear-shift usually happens late, and sometimes not at all.
The direct cost of overproduction in mature software
Overproduction — or making things that don’t give net benefit to users — can happen at any lifecycle stage. It’s just less harmful in Explore and less likely in Expand.
In Sustain, when you have a healthy product to overcomplicate, and happy users to alienate, you have a lot to lose by overproducing. Every experiment you run hoping to rekindle growth is a bet, where the stake is the existing value of the product. That stake is a small number in Explore and a large number in Sustain.
To visualize this, let’s look at the rough shape that product usage and revenue tend to take. The common pattern is one of fast-growth and slow decline that Jason Cohen (@asmartbear) calls the “Elephant Curve”:
People are more likely to ditch an enshittified product; that’s pretty much the colloquial definition of “enshittified.” Over time and all users, this makes the eventual decline steeper — makes the elephant sit down, if you will — which is incredibly wasteful. The area under that curve is money, so pushing the curve downwards literally costs money. You gotta keep that elephant on its feet.
This gets to the heart of why I don’t like “Extract” as the name of the third lifecycle stage (“Ex” pattern be damned); there is so much profit to be had from keeping value in the system as long as possible. The goal isn’t to get the value out, it’s to maximize dividends over time.
To preserve their own value, mature products should normally support experimentation in other parts of the business. They can contribute funding from profits or provide other assets like channel or technology. But experimenting inside the mature product itself isn’t generally a great option. It pays to be smart about where you explore and where you shore up.
An Extract phase sounds like it would encourage you to spend value down on new bets. And yes, I know VC- and shareholder-driven companies can push towards this, encouraging experimentation everywhere looking for a big score.
Between the expectations of funders and of cultures baked in the time of Expand, most orgs over-reward delivery and make it hard to Sustain. Individuals who are trying to keep the elephant on its feet, trying to do right by their company and customers, regularly get ground down by a culture of Expand amidst a wider societal bias against maintenance.
Instead of supporting sustainment, orgs often force maintenance heroes underground. I’m continually amazed by all the people out there propping up value for the company and for users, largely unrecognized. Sitting close to the delivery line, they can see the value of nudging up, rather than driving down, a mature product’s value over time.
Curbing overproduction through demand realism
Marxist theory holds that overproduction is unavoidable in a capitalist system, and I’m not here to argue. What’s important for us is that locally within the system, you absolutely can reduce overproduction.
The poster children of enshittification like Facebook are probably dead to us, but I still have hope for others. I think there are plenty of people are struggling to deliver sustainable value against relentless overexpectations of expansion.
The Lean manufacturing methodology speaks directly to how to control overproduction in manufacturing (see? definitely possible in capitalism). Importantly, it dispels the myth that value is maximized by having every part of the system maximally productive. As it turns out, maximizing by parts leads to overproduction and is hugely wasteful, not beneficial.
The Lean Startup gives this clear characterization:
Lean thinking defines value as providing benefit to the customer; anything else is waste. — Eric Ries
In particular, value is providing actual benefit, not just theoretical. It might be that the new car sitting on the lot will be valuable, but it has not provided benefit yet, or had the value “realized.” The Lean Startup focuses on maximizing learning and minimizing investment in the early stages, creating a Minimum Viable Product. The point of “minimum” is to avoid overproduction, and therefore waste.
Lean philosophy has another guiding principle, that overproduction is best controlled through the discipline of a pull-based production system. Don’t push stuff at the market; instead, find the customer need and use it to pull the right work from you.
Protecting the value under the elephant curve means fine-tuning software development to actual demand. To do this and avoid overproduction, teams need to be extremely well-informed and extremely realistic about the demand for new things.
People often think of user experience as being primarily useful in growth stages, but it’s critical in the mature phase too. Without really knowing your user base and assessing the effects of changes, production gets out of control. Fortunately, modern development teams are right there at the production and sensing front. Through user research and product analytics, they’re well positioned to keep overproduction in check.
When it comes to new, speculative bets on mature products, it’s only worth taking ideas all the way to production if they meet evaluation criteria along the way validating their benefit and invalidating their potential harm. Whether in beta or production, the team needs to be ready and willing to nix ideas that don’t meet the grade. If you’re not sure where to start, try really listening to naysayers and building their concerns into a repeatable set of evaluation questions.
The positive vision for mature products
Often, the transition to maturity is marked by an emphasis on what isn’t being done: fewer features, fewer team members, less demand, less opportunity to solve interesting problems. With this framing, it’s not surprising that teams disengage as the growth slows. What’s exciting about not producing?
It’s hard to feel like you’re personally making a difference by not doing. Leaders outside the team exert pressure to try everything to return the product to growth, and then when that fails, it’s all about efficiency and exit. Not a great work environment.
To avoid this, a product entering maturity needs a strong product vision as much as ever. A product vision for a mature product will set a context to avoid overproduction, but emphasizing the positive reasons why.
The software world has some good examples of visions that do this. Take the Google home page. How did it stay so empty? Google design leaders took an active decision to keep it “simple, uncluttered, colorful, friendly.”
Google is hardly the only product with strong, defensive principles. Take Signal, the secure messaging app. For Signal, it’s privacy. Signal CEO Meredith Whittaker writes, “Signal exists to provide people everywhere with a tool for real private communication. That’s our only goal, and we take it very seriously.” Or Obsidian, the notekeeping app which, when Evernote gutted its free tier, recently used its principles as a differentiator: Yours, Durable, Private, Malleable, Independent.
For two-sided platforms, Cory Doctorow, who coined “enshittification,” proposes two key defensive principles. The first, the “end-to-end principle,” is a commitment to deliver data only from willing senders to willing receivers. The other principle is a “right of exit,” or renouncing lock-in strategies, despite their tempting viability as an alternative to delivering value.
All of these are describing specifics of quality (formerly known by the soul-destroying term “non-functional requirements”). More generally, quality principles with strategic product value might include any of these attributes and more.
A strong vision for a mature product says which few types of quality the product is committed to and why
A quality-focused vision not only informs what improvements to consider, but also what types of evaluation to use in assessing benefit and potential harm. The key fact about Sustain is that it’s no longer a feature-focus but a quality focus that helps tune development to the user’s need.
Bear in mind that users of a mature product occupy a different emotional space than in earlier stages. Broadly, the feelings are Explore: “What’s this?” Expand: “OMG this is amazing,” and Extract: “This is part of my life, please don’t ruin it.” Whatever attributes of quality are most important to users and your product’s mission, this is the time to reassure your everyone by stating and living those principles.
A mature product team doesn’t have to feel like a death-march to product end-of-life. Instead, you can take inspiration from underground maintenance heroes and elevate the defense of quality.
Product-managing mature products
People in product roles, I beg you to pay attention here, given the influence you have on a team’s direction. Right now the evidence from declining products is that product management is overfocused on development, namely sequencing features and exploring shiny things, and underfocused on outcomes. We — I count myself among the product clan — are collectively prioritizing business fantasies of growth over commitment to real user needs, with long-term profitability as a casualty.
The critical time period is in that transition from “Expand” to “Sustain.” As product people, we need to
- Recognize the need for a mode-shift earlier
- Prioritize quality, especially as growth slows
- Understand depth of change needed for a culture of quality
- Shore up sensing mechanisms and learning infrastructure
- Set a clear, quality-led product vision
- Establish solid kill criteria and use them
- Make the case organization-wide for the value of Sustain work and role of mature products
As mentioned in Part 1 this isn’t a one-person responsibility, it’s a team sport. Nevertheless, buried in “understand the depth of change needed” is the truth that someone needs to lead a transition, not just for one team but across teams working on mature products. This isn’t a time to flow with the culture, it’s the time to step up and shape the culture.
Preserving quality against the prevailing culture
I don’t want to overplay the power that one person has when the org and society don’t support product sustainment.
That said, people are doing it, and we should take a moment to appreciate people who actively maintain mature products. If you’re maintaining things contrary to the prevailing org culture, I salute you, and if the culture supports you, I salute you all.
If you’re not there yet, though, please consider how bad enshittified products are for all of us, except possibly venture capitalists, who thrive on the churn. Delivering quality puts you on the side of product users, which is you. And your family. And friends.
The 1913 manual Sabotage: Its History, Philosophy & Function introduces a concept of “constructive sabotage,” resistance through overdelivering on quality, when you and your peers are the consumers:
As the idea of an injury to one being an injury to all sinks in more thoroughly we shall see products sabotaged in a different manner — constructively.
The workers are coming to see that their class is the one to whom adulterated food, shoddy clothing and rotten materials are sold, and by refusing to adulterate products they not only destroy the employers’ profits but safeguard their own lives as well. -Walker C. Smith
With physical products, constructive sabotage eats into corporate profits, but in software with a near-zero cost of materials and the elephant-shaped revenue graph, you are likely to increase your employer’s profits. This means that in software, constructive sabotage is a lousy weapon of class warfare. But this also makes it a viable option for the regular worker who just wants to make better things. That’s what gives me hope here.
Without materials scarcity, there’s plenty of space where customer and corporate interests align. Like Choose Boring Technology, my dream is utterly banal and obtainable: companies that deliver boringly good products year in and year out, and make good money doing it.
If my theory is right, user and business interests can align to have a meaningful impact on enshittification, especially in the mass of smaller products that shape our working life. But this will only happen by us developing stronger Sustain tactics. In particular, software team members would need to diversify, stop being one-trick growth ponies and take on the responsibility to stop overproducing things users don’t want. Less backlog management, more understanding of outcomes and drivers. Less ship-and-forget, more evaluation. Fewer features, better quality.
Technologists — especially product people — have unfortunate incentives to stay bad at sustaining products. The upsides of maintenance aren’t very visible, but the downsides sure are. Wherever “bias to action” is a value, deliberately killing ideas is not likely to get you promoted. Many human factors described in this post and Part 1 freeze organizations’ behavior in Expand.
But the consequences of being bad at sustainment are now completely obvious in widespread enshittification. For all of us in software, this is the right time to rethink our position and learn to sustain quality for the long haul.
Anti-enshittification reading list
The links from this post and a few more pieces that informed it:
Cory Doctorow (aka @pluralistic) An Audacious Plan to Halt the Internet’s Ensh*ttification. Excellent. Foundational.
John Cutler How to think about Bets, Success Metrics, and Roadmapping. Yes, it’s a messy google doc. But it contains a lot of good thinking condensed about dialing into user need.
Annie Duke Quit. A good read on when to stop. Led me to Knee Deep in the Big Muddy on escalating commitment.
Peter Coffin The Vibeonomics of Enshittification I don’t reject this, just believe it’s less responsible for enshittification than he does. Same with Andrew Kelley’s Why Can’t We Have Nice Software?
Prasad Ramakrishnan Stop the software bloat: slim down your SaaS. An IT lens on sprawl and bloat.
Eliyahu Goldratt Standing on the shoulders of giants. Author of The Goal on overproduction and pull-based production systems.
Kent Beck 3x Explore, Expand, Extract. Superb introduction to software lifecycle phases.
BCG The Real Rules of Growth and Profits in Software. A similar tale to Beck’s, but through a more familiar, exec-friendly lens.
Jason Cohen The Elephant in the room: the myth of exponential hypergrowth. The elephant curve, backed by various companies’ data.
Eric Ries The Lean Startup. This book did a great job promoting “validated learning” as a measure of production, but maybe also has a lot to answer for in promoting an “experiment everywhere” mentality.
Sabotage: Its History, Philosophy & Function, where “constructive sabotage” came from. Via this review of Breaking Things at Work.
