Keep the show on the road

Build is only the first part of the product lifecycle. It’s also where most product people live, work and get stuck.

Products and features exist to try to create or influence an outcome.

Search: to sell ads. Social media: to sell ads. AI: to take over your life and kill all humanity.

(When you look at it like that, bring back the bad old days of sponsored links. All is forgiven.)

But seriously. If we go with the product lifecycle doctrine, build is only the first part. It’s also where most product people live and work and get stuck, sadly.

The product lifecycle, honestly proportioned A timeline. A short box labelled Build leads by an arrow to a much longer box labelled Operate, which leads by an arrow to the word Retired. Above the Operate box a loop arrow is labelled “Persevere or pivot?”, repeating for as long as the product is operated. A note beneath the Build box reads “where most of us live and get stuck”. Build Operate Retired Persevere or pivot? where most of us live and get stuck
Build should be the short bit.

Once it’s built, and once your features are starting to be used, there’s a question you should strive to ask as quickly as possible.

Persevere or pivot?

Then you keep asking it, until the product is retired. It’s a close relative of the question Jason Fried asks about anything he’s finished — would I do it again? Same instinct. You’re just asking it about something that’s still running.

(Interesting side-bar. We say a product “is retired” rather than a product retires. It’s something that happens to it. It doesn’t just happen.)

But… entropy

After you build, after you finish creating the software and it’s doing what you want it to do, does the job stop?

Of course not.

Because… entropy. I’ve been here before on this very site — 100/100 across the board when I launched it, and then the scores quietly dropped without anything being consciously changed by me.

Even if it’s the most perfectly written piece of software, unless you maintain it, it will degrade over time. OS updates will come around. Security vulnerabilities will appear as the libraries you depend on are exploited. Life happens.

And neglect sends you a bill eventually. It once took me four hours to get back to the position where I could write a post. That’s on a personal site with one user and nothing at stake.

The main point I want to make is that the vast majority of features and products either don’t make it to the operating phase. Or, if they do, they are often neglected.

So who is thinking, talking and writing about how you keep the show on the road?

If you are, or if you follow anyone who is, please email me a link. I’d love to hear about it.

Managed decline

On the other side of the fence are the people who are essentially doing ‘product’ work, but it’s hidden underneath the guise of customer service or ops management.

The catch with that organisational model is that they have no access to get changes made.

So they essentially preside over managed decline, as the shiny thing they were haughtily given by the real product people either naturally degrades, or what customers really need shifts over time.

So what’s a guy to do with that situation?

Chances are that you’re not going to manage to rebuild the whole organisation in one quick move. So you need to do it brick by brick.

The secret is that the customer service people, the ops teams, need to become your best friends.

They know what’s needed. They know where the really obvious wins are. They also want the moon on a stick, so you need to exercise judgement. So talk to them all the time. Listen to them. Help them understand that the thing they told you about six months ago is getting sorted, but that seemingly obvious changes in big, highly regulated industries are slow!

Build up those relationships. Then, the next time you are hiring for a new product person, encourage the superstars in those teams to apply.

It’s often a brilliant chess move.

  • generally younger, enthusiastic and driven people inject great energy into your teams
  • they bring mountains of front line experience, so they won’t fall into the trap of making things that might solve the problem
  • the business maximises the value it generates from the same people (a weasel-worded way of saying they cost less!)

A win for everyone.

This isn’t just theory. I’ve done it. Several times.

It works.