(2024-02-08) Ayer Enshittification As Overproduction In Software

Elizabeth Ayer: Enshittification as Overproduction in Software. I have a few things to say about this moment of mass enshittification: most of what we’re seeing is incompetence, not malice. (Any sufficiently advanced ClueLessness is indistinguishable from Malice. But I think this article may be stretching the definition/context of enshittification.)

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.

When I last e̶n̶s̶h̶i̶t̶t̶i̶f̶i̶e̶d̶ bloated a product:*

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

until it didn’t

We were left trying to understand, did we just make a bad choice of capability?

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.

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

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.

we heard existing users complain about paying for things they weren’t using.

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? (Quit)

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. (Principal-Agent Problem)

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.

In software, overproduction isn’t always as easy to see

all the product changes you ship that don’t increase the benefit of the software to the users

Only one user, Blue, uses star. Is this feature valuable? The answer is that you definitely can’t tell from just this.

It’s rare to get something as clear-cut as the blob case above; most product changes are more like star, with ambiguous result

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.

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 product team sport.

Enshittification as Overproduction in Software, Part 2: Overproduction in the product lifecycle. 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 about testing riskiest hypotheses and finding a fit between product and a market

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

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

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.

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.

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”

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. (Cash Cow)

experimenting inside the mature product itself isn’t generally a great option.

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.

Lean thinking defines value as providing benefit to the customer; anything else is waste. — Eric Ries

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.

People often think of user experience as being primarily useful in growth stages, but it’s critical in the mature phase too

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

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.

it’s not surprising that teams disengage as the growth slows. What’s exciting about not producing?

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.

describing specifics of product 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

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.”

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.

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

Wherever “bias to action” is a value, deliberately killing ideas is not likely to get you promoted.