Pruning the orchard.

Walk through an apple orchard in February and you'll see something that looks a lot like vandalism. A grower on a ladder, cutting branches off healthy trees. Live branches, some of which bore fruit last fall.

They do it every winter. A tree left alone grows in every direction. The canopy fills in, the middle goes dark, and the tree spreads its strength across so many branches that the apples come out small and few. Cut a good share of it away and sun reaches the inside, the sap goes to fewer places, and next fall's fruit is better. The grower is deciding where the tree's strength goes.

Big companies almost never do this. They plant constantly: new products, new programs, new initiatives with a launch email and an executive sponsor. They cut only what's clearly dead, and sometimes not even that. The orchard gets more crowded every year, a little less productive each season, and nobody can point to the branch that did it.

Two ways to neglect an orchard

The obvious one is never pruning. The other is easier to miss: planting a new row every spring while last year's trees never get the water they need to bear.

When I wrote a capability framework for product managers, one line in it was about exactly this. Resist new work until what you've already shipped has delivered its potential. And make the cost of underused product as clear as the cost of not building.

That second sentence is the one most companies get backwards. Everyone can describe the cost of not building: the competitor who ships first, the deal you lose without the feature. Almost nobody puts a number on the product that's already live and half used. It doesn't show up anywhere. It just sits there taking sun.

The other line in that framework was about who owns it. Shipped product stays your job after the launch. Whoever leads the product (I'd call that person the strategic lead) owns its adoption, its outcomes, and the call to invest further or move on. That call is the pruning decision. If nobody owns it, nobody makes it.

Nobody wants to hold the shears

Things that should end keep going for reasons that make sense one at a time.

Someone's career is attached. The product was a director's big bet three years ago. Ending it reads like a verdict on them, so it doesn't end. It doesn't get investment either. It just persists.

A few customers love it. There's always a handful, and some of them are large and loud. Nobody wants to be the one who tells a big account the thing they use is going away.

It's already paid for. The build is done, so keeping it feels free. That's sunk cost in a nicer coat.

And it's still bearing a little fruit. This is the hard one. A failing product is easy to cut. A product making a modest, steady amount of money, growing slowly or not at all, looks like a reason to keep going. It's the branch most worth a hard look, because nothing will ever force the question.

What a small branch actually costs

The case for keeping a small product counts its fruit and forgets its shade.

Say a product brings in a steady amount and has four people on it. On paper, fine. Now count what else it takes.

More people than the four. The support agents who have to know how it works, the security team that reviews it, the sales engineers who get asked about it on calls. Every product has a halo of partial attention around its official headcount.

Roadmap drag. This is the expensive one. Every time the main product changes (a new login system, a new data model, new pricing), someone has to ask what it does to the small product. Often the answer is "we can't ship this until we fix that." Now the small branch is shading the big one.

Add it up and a product that looks mildly profitable in its own numbers can be expensive for the company. Its own P&L is fine. The cost is everything it keeps the rest of the tree from doing.

Prune every winter

Growers don't prune when they get around to it. They prune in winter, every winter, while the tree is dormant and the cuts heal clean. You want the same thing: a pruning review on the calendar once a year, with the criteria written down before anyone looks at a specific product. Agree on them in advance, so the review is about the orchard and nobody has to defend their own branch.

• Has it had a real chance? Did anyone drive its adoption, or did it ship and get left alone?
• Is it growing, or holding steady on customers who'd stay anyway?
• Does it share customers, data or code with the products you're betting on, or pull the other way?
• What does it block on the main roadmap?
• If you weren't already running it, would you start it today?

The first question protects the young trees. Plenty of products look weak because nobody ever tended them. The last question is the one people don't want to answer out loud. Ask it anyway.

Then sort into three piles: invest to get the full harvest, keep as it is on purpose, or retire. The middle pile is fine. It just has to be a choice someone made this winter, with a reason written next to it.

How to make the cut

A bad cut tears the bark and lets rot in. A bad product retirement does the same thing to customer trust.

Give it an owner, one person whose job is to end it well. If the retirement is everyone's side task, it stalls half done, which is worse than keeping it or ending it.

Give real notice. Customers can handle an ending. They can't handle a surprise. Tell them early, tell them why, and pick a date that doesn't move. Give them somewhere to go: a path into your main product, a partner who'll take them, or at the very least their data in a format they can use.

Move the people on purpose. The whole point was to put strength where the fruit will be best. If the team scatters to whatever had open seats, you've cut the branch and wasted the sap.