PRODUCTHEAD: Doomed to repeat their failures

the product mail #

every PRODUCTHEAD edition is online for you to refer back to

---

tl;dr

Software is never ‘done’ even if you choose to ignore it for a while

A ‘training wheels’ framework to get a team started should be treated as a throwaway experiment

Clarity is not the same as certainty, although it helps you manage the uncertainty

---

hello

The articles I read this week reminded me of the aphorism by philosopher George Santanaya: “Those who cannot remember the past are condemned to repeat it.”

Enough time has passed that we are collectively falling back on old habits, forgetting all the reasons why the old ways were a poor idea in the first place. I say ‘falling back’; many organisations never actually changed their ways of working, they just rebranded them.

It feels like I’m seeing more and more comments on LinkedIn and elsewhere yearning for the good ol’ days where software was specified completely up-front, and people got on with coding without pesky middle management (i.e. product managers) interfering or asking inconvenient questions. And look — there’s even a genAI that will write your product requirements document (PRD) for you! Progress!

Project mentality = manufactured certainty #

I get it, the manufactured certainty of a project mentality is attractive. Management wants a thing — it will be a wonderful thing. They specify the thing, the team says it will take so long and this amount of money to build. The team builds the thing. The project is a success because there’s now a thing. The team and senior management are rewarded for building the thing. The team moves on to the next thing.

Everyone glosses over that the thing was harder to build, cost 10 times the original budget, took 5 years instead of 1, didn’t really work, and even then wasn’t what the people using it needed in the first place. Why let such minor niggles snatch defeat from the jaws of victory? Let’s do a ‘phase 2’ — it will be a wonderful thing …

Certainty is great (when you have it) #

Life is simple when everything is known, certain and agreed.

When you’re building a skyscraper, you have all the architects’ plans, all those years of research done up-front, you know what materials you’re going to use, how strong they are, how much they weigh, how much you’re going to need, who’s going to supply them, and how much they’re going to cost. You know where you’re going to build, what kind of ground you’re going to be building on, and so on.

Architects have pretty sophisticated models for all of this, which approximate very closely to how things will behave in the real world. Providing the architects are competent and builders stick to the agreed plans and schedule, it is possible to eliminate most of the uncertainty from the build, but even then, not all. (That said, I’ve worked with house builders. They can and will conceive of increasingly inventive ways to f*** you up if you’re not watching them like a vengeful hawk.)

But with a skyscraper, you don’t suddenly go off-plan and decide to build a cantilevered swimming pool on the 42nd floor. (At least not successfully.)

Building software is entirely unlike building a skyscraper.

It is fundamentally hard to figure out what people need the software to do (rather than what they say they want). It is then challenging to figure out how to solve the problem. And you still have to square the circle of adequately solving the problem while still operating within — or working to shift — the various constraints of your organisation (available skills, resources, business model, profitability, investor relations etc.), and the pressures of a competitive market (window of opportunity, and so on).

Nuance, bias and perpetually changing user, business, economic and market contexts all muddy the waters. A static snapshot of something changing is only a representation of the moment in which it was captured. From that point on the two increasingly diverge.

During a software build, obstacles and unanticipated problems crop up. Components do not interact so well with each other, or suppliers unexpectedly decommission them. People change their minds, get distracted, make mistakes or assume something to be true that isn’t.

Believing you can specify everything up-front and never have to change it is like believing you can drive to work blindfolded, or deciding how you’re going to play several hands of poker before you’ve even seen the cards. You could be extraordinarily lucky, but the odds are overwhelmingly not in your favour.

Product management is still hard #

This is why product management is hard. Harder than people have glamorized it to be. This is why we rely on collaboration with experts in all the other disciplines. They use their expertise to do what is needed as we go along. They bring in as much relevant insight as possible, as frequently as needed, in order to allow us to adjust course in response. The product manager is there to keep everyone on the team moving in the same direction towards the same goal, while managing the shifting expectations, politics and gameplaying of senior management and stakeholders.

Even then, success is not assured — there will always be elements of uncertainty. People remain fallible. And these facts will always offend the sensibilities of those who refuse to acknowledge there is uncertainty in the first place.

I thought everyone had already learned these lessons. I think they may have been forgotten. Best we remind everyone. Again.

Speak to you soon,

Jock

---

Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it.

In the first stage of life the mind is frivolous and easily distracted; it misses progress by failing in consecutiveness and persistence. This is the condition of children and barbarians, in whom instinct has learned nothing from experience.

In a second stage men are docile to events, plastic to new habits and suggestions, yet able to graft them on original instincts, which they thus bring to fuller satisfaction. This is the plane of manhood and true progress.

Last comes a stage when retentiveness is exhausted and all that happens is at once forgotten; a vain, because unpractical, repetition of the past takes the place of plasticity and fertile readaptation. In a moving world readaptation is the price of longevity.

The hard shell, far from protecting the vital principle, condemns it to die down slowly and be gradually chilled; immortality in such a case must have been secured earlier, by giving birth to a generation plastic to the contemporary world and able to retain its lessons. Thus old age is as forgetful as youth, and more incorrigible; it displays the same inattentiveness to conditions; its memory becomes self-repeating and degenerates into an instinctive reaction, like a bird’s chirp.

— George Santayana, The Life of Reason: The Phases of Human Progress, Volume One — Reason in Common Sense (1905), p.284 (available on Project Gutenberg)

---

---

what to think about this week

Project vs product funding

A few months ago, I made a slide deck about the differences between funding technology as projects and funding them as products1. Every time I’ve shown it since then, people have asked me for a copy of the slides, so I thought I’d share them here in case they can be helpful more broadly. I also wrote up the narrative that goes along with them and included it in my Congressional testimony in January, so I’ve adapted that below. A link to the slides themselves is at the end.

Modernization shouldn’t even really be a thing at all

[Jennifer Pahlka / Eating Policy]

Why your product transformation will fail

Your product transformation will fail if:

You treat a transformation as a project. The track record for big projects is not good. The track record for formal transformation efforts is also not good. Is this because the companies that opt for this approach are less likely to succeed, or is it because the vehicle of a large project is somehow less likely to succeed?

Stop calling it a transformation

[John Cutler / The Beautiful Mess]

Clarity for product managers: Part 1, directional clarity

Clarity is crucial for our success and for ensuring satisfaction among the people we work with and for ourselves. This is because as product managers or product leaders, our work always involves collaboration. We can only be successful when we work well with others.

Clarity is a superpower for all product people

[Arne Kittler]

---

---

recent posts

Moving up to a CPO or VP Product role

Stepping up to a Chief Product Officer (CPO) or VP Product role doesn’t so much change what you do. Rather it amplifies everything. This guide lets you know what to expect.

Liberating and terrifying in equal measure

[I Manage Products]

I want to update my pricing strategy. Where do I start?

“My product currently has one tier of per-seat pricing for all customers. I want to change my pricing strategy to cater differently for SMEs and enterprise customers. Where do I start?”

A few pricing concepts to consider + further reading

[I Manage Products]

How do I make my product roadmap a better communication tool?

“My product roadmap is not getting the right information across to other people in my company. In particular, my customer success and marketing teams are struggling to plan their work for upcoming product releases. I’m also not sure how I can show my roadmap’s relationship to the half-yearly OKRs we set. How can I improve it?”

Your product roadmap is a communication tool

[I Manage Products]

PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from moving deeper into the fediverse.