Enshittification as Overproduction in Software, Part 1: Seeing Overproduction
As someone who has previously enshittified a product, I have a few things to say about this moment of mass enshittification…
First off, we’re giving up too soon. There seems to be collective resignation that companies will always screw the little guy, but I think that’s missing a key dynamic: most of what we’re seeing is incompetence, not malice. This post, the first of two, is about software makers’ common inability to perceive a decline of value in software. Together with the second post, we’ll see there’s a big space for improvement where users get better products and companies make more money. Win-win, don’t give up yet.
Some context on “enshittification”: the word is most commonly used for rapacious platform companies who jam their entitled, sweaty hands into our personal data. This is canonical enshittification, as coined by Cory Doctorow. Think Facebook. A platform company starts off giving us value, then milks us to satisfy corporate users, screws over the corporate users, and dies. Doctorow focuses on the complex cases, unpacking structural dynamics to make the case for deep structural solutions.
But it’s clearly not just the big social platforms that are enshittifying things. Bloat and decay are such a strong expectation of software products that it’s a surprise when it doesn’t happen. It was there when Jira abandoned user experience, it’s there in Evernote’s desperation, and it’s there in the hard-turn to large language models, like Co-Pilot.
The majority of product decline happens in products that are screwing up the transition to maturity. We are in a mass enshittification moment largely as a function of the number of businesses that were growth businesses until recently, many from pandemic times. To see this dynamic in action, let’s dive into a tale of enshittification, overproduction, and commitment escalation.
When I last e̶n̶s̶h̶i̶t̶t̶i̶f̶i̶e̶d̶ bloated* a product
*they stopped me before I got all the way. I think.
Some years back, I was in a mid-sized company and started product-managing a product that had been growing well. After the release of every significant new capability, revenue would sustainably bump. The need seemed clear, and each new feature gave oomph to our marketing. Increases happened predictably, release after release.
This worked until it didn’t.
The first sign the party was over was when a feature release didn’t give the expected revenue bump. We were left trying to understand, did we just make a bad choice of capability? Was our execution faulty? Was the market tapped out? We simply couldn’t tell; our sensing capability wasn’t up to it.
As product people will know, a very common play here is to go back to exploration mode to try to reestablish product-market fit. That’s what we did, adding capabilities, hoping to find growth again. Like many other software teams, we had a presumption that growth is there for the taking, we only had to find it.
The dynamic was similar — or maybe exactly the same — as the tendency to continue betting when you’re “in the losses,” or down money while gambling. In fact, people in general have a bias towards escalating commitment in this case. Rather than cut our losses, we double down, try to turn the situation around. In our product case, we were making bets that weren’t paying off, but we were learning so much each time. If the previous bet was justifiable, then the next one must be more justifiable, because we were that much better-informed.
We shipped what we thought would be crowd-pleasers, but they just added complexity. Because the use case was intermittent, the changes disoriented our users, making them feel dumb every time they picked it up again. None of these features “worked.” We never saw another feature-based revenue bump.
We did have some signals, though, that we were decreasing the value of the product with these bets. As we tried to reach new market, we heard existing users complain about paying for things they weren’t using. Sure, users sometimes see extra features as bonus value, but excess can also make the buyer feel like they’re paying for extras they don’t want, which leaves the product vulnerable to displacement, as described in Stop the Software Bloat.
New features weren’t returning us to growth, it never seemed logical to stop trying. How did we know that they weren’t staving off a greater decline? Why stop now when our hypotheses were getting better and more data-informed? And how would we feel if we stopped and our competitor took over, maybe even with the next thing on our backlog?
We had tons of ideas of things that might work, but there were personal reasons to keep going too. We knew that within our org, we had to show growth or the team would get dispersed to other places. There was no option within the operating model for sustainment. Instead, we kept overproducing.
Seeing overproduction
With physical goods, you can see overproduction. Heck, you can feel overproduction: it’s the thing you stub your toe on as it piles up on the factory floor. The cost of overproduction is clear in the money locked up in the materials, additional work managing the inventory, and warehousing costs. The pain is nicely tangible, easy to comprehend.
In software, overproduction isn’t always as easy to see; there’s no literal spare inventory. It might show up internally in work that’s blocked, say because of management approvals or a scarce skillset. But it exists externally too: overproduction is all the product changes you ship that don’t increase the benefit of the software to the users.
In the old days, it was hard to convince people that software overproduction even existed, especially that product and operational changes could decrease the value of a product. Luckily, now that Elon Musk has wrecked Twitter, everyone knows it’s possible. Of course, that still doesn’t make it easy to see negative value delivery in your own product.
In general, software product value can be hard to reason about, so let’s look at simplified case: a product with 3 features: square, circle, and triangle.
Let’s say we have three happy users. Everybody uses square and circle, but only Yellow and Green users use triangle.
Then we add in blob. Nobody uses blob. Nobody clicks the blob button; no prospective users even mention blob in their pre-purchase evaluation scorecard.
We can comfortably say that blob, unused, offers no benefit. If there’s no benefit, there can only be downside. This is the easy case, which of course, almost never happens. So the team takes out blob. Then they ship star.
Only one user, Blue, uses star. Is this feature valuable? The answer is that you definitely can’t tell from just this. Maybe star makes Blue more likely to keep paying, without decreasing the likelihood of Yellow and Green sticking with the product. Or maybe it makes Blue no more likely to pay and damages the experience of the other two. Or maybe its true impact will only appear in combination with other work that goes out in the product. Who knows?
If we are defining value as “propensity to pay,” then we could only be certain that a product change was valuable by calculating the lifetime value of all possible customers over two parallel futures, one with star and one without it. With no further product changes. Anything short of that is judgment and guesswork.
It’s rare to get something as clear-cut as the blob case above; most product changes are more like star, with ambiguous result. Because of this uncertainty, and because taking things out of a product is work, clutter accumulates, breezily excused by the prevailing optimism. Maybe some people find it useful! Maybe we’re ahead of the market!
This gets at the heart of why it is so hard to even see overproduction in software. It’s rarely clear-cut; the art of judging overproduction depends on having a solid value framework, rich signals on product usage and user perception, and a history in the market to give context in interpreting a mixed data picture. Even with all this, it’s still uncertain. It inherits all the challenges of forecasting, even though it seems like it’s about the past.
A solid value model was something we never achieved for the product in the story above. The team was moved to other things — I even took a stint in marketing to work on the demand side of this problem. But since then I’ve learned about where I went wrong and what good looks like.
The key is to develop a rich understanding of the impact of software changes before a slowdown. Just like effective development, understanding impact is a whole team sport. For a team to be good at at, they need some maturity in how they think about value (for example, an approach like John Cutler’s How to think about Bets, Success Metrics, and Roadmapping). It isn’t just one skillset either; it’s not just UX or Product closing the loop, it’s everybody. And if you thought QA was an outdated specialty, think again. QA is, at its very core, an evaluation practice.
Together, a skilled team can take good decisions to avoid the rot. The default, not taking evaluation seriously and embedding it into team operations, is that ever-more-desperate features accumulate and enshittify your product.
In Part 2, I’ll talk about switching into a value-protecting mode and the enabling a culture of quality.
Thanks to Carter Baxter for helpful edits and suggestions.
