Product teams are built to add things. Sprints roll, the backlog refills, the roadmap always has a next quarter. The machinery assumes that the right thing to do with a product is more of it, and that the right thing to do with a portfolio is to add another one.
The pull towards the new works at both levels. Inside a product, feature work crowds out the care of what already exists. Across a portfolio, the new product takes the attention, the best people and the executive interest, while the established products, which are usually the ones paying for all of it, are assumed to be fine until they are visibly not.
These are the same mistake at different scales. The fix is the same too: decide on purpose how much effort goes to building and how much to tending, and make the tending as visible as the building.
What tending means at portfolio level
Going to market is one job. Staying in the market is a different one, and it never finishes. It means checking that each product still fits the customers it was built for, because customers change and so do the alternatives available to them. It means noticing when the market moves and responding, rather than only responding when a deal is lost. It means retiring what no longer earns its place, and putting money into products that are quietly growing rather than loudly launching.
None of this has a launch date. That is why it rarely gets done.
How the new product takes everything
A launch has a date, a story and a sponsor. Keeping an established product fit for its market has none of those, so when the two compete for a person, a budget line or a slot on the board agenda, the launch wins by default.
The people who built the new product tend to move with it, because they know it and because it is interesting. The established products inherit whoever is left, and sometimes nobody in particular. Within a year the product that generates most of the revenue is the one with the least product thinking applied to it.
Board updates talk about launches and pipeline. Nobody presents a slide titled 'still fits, still growing', and so nobody is asked to show evidence for it. Meanwhile problems in mature products arrive slowly: a few points of churn, a slightly worse win rate, a competitor nobody rated. None of it makes the agenda until the numbers are large enough to need an explanation, by which point the fix is expensive.
Signs the portfolio is out of balance
An established product is losing share to a competitor who did nothing clever. They just kept paying attention.
Renewal conversations mention neglect, in whatever words customers use for it: 'nothing has changed', 'we don't hear from you', 'it feels old'.
Nobody can say when a given product last had its market fit checked, or what the check would consist of.
Every product in the portfolio is at a different stage of life, and all of them are reviewed in the same way, with the same template, at the same meeting.
The best product people are all on the newest thing, and have been for two years.
The portfolio has grown but the total number of customers has not.
Checking fit continuously
Product-market fit is usually treated as a milestone: something you reach, announce and then stop measuring. It is better treated as a condition that can be lost, and checked for the way you would check anything else that matters and moves slowly.
A short set of indicators per product is enough, provided someone owns the answer and looks at them every quarter:
Retention by cohort, so that a change in who you are winning shows up before it reaches the total.
Share of new customers coming to this product rather than to the newer ones, and whether that share is falling faster than you intended.
Usage of the core workflow, the thing the product was built to do, as a trend rather than a snapshot.
Win and loss reasons, in the customer's words, and whether the reasons have changed in the last year.
What customers ask for, and whether it still sounds like the product you built or like a different one.
The last of these is the most useful and the least measured. When the requests stop sounding like your product, the market has moved and you have not.
Setting the balance on purpose
Allocate across the portfolio before allocating within products. Decide what share of total product capacity the new product gets, write it down, and defend the remainder. If the split is never stated, the new product takes whatever it needs and the rest get what is left, which is the drift you are trying to stop.
Give mature products roadmaps. Even if a roadmap is mostly tending work, it should exist, be owned, and be reviewed in the same forum as the others. A product without a roadmap is a product nobody is thinking about.
Fund the new product against evidence of fit, in stages. Launch milestones measure effort. Retention, repeat use and win rate measure whether the market wants it. Release the next tranche of people and money when the second kind of evidence arrives, and be willing to hold it back when it does not.
Make responding to the market as visible as going to market. Report what you changed because customers or competitors moved: the feature you simplified, the pricing you adjusted, the integration you built because three deals asked for it. This is the work that keeps the revenue, and if it is not reported it will not be funded.
Review each product according to its stage. A two-year-old product and a twelve-year-old one need different questions. For the older one the questions are about fit, cost to serve and whether it should carry on as it is. Asking both about pipeline and feature velocity tells you very little about either.
Inside each product, the same again
The pattern repeats one level down. Within any single product, building has advocates: sales, customers, the CEO. Tending has none. A new feature is a story and a faster page is a number, and stories win planning meetings.
Tending is wider than fixing bugs. It covers performance, reliability, upgrades, removing features nobody uses, simplifying the paths people struggle with, improving onboarding for what already exists, and keeping the documentation true. Most of it is invisible on a roadmap and highly visible to customers.
The fix is the same as at portfolio level. Agree a share of capacity for tending at the same meeting where the roadmap is set, give it an owner and a backlog of its own, and let the share move with the product's age. Early products need mostly building. Mature ones often need the reverse, and a release that removes things is sometimes the most valuable one a mature product ever ships.
The signs are familiar too. Support load rising after releases rather than falling. Onboarding time growing. Recent features used by a shrinking fraction of accounts. Engineers spending more time on how features interact than on the features themselves.
Getting to market and responding to it
Getting to market is a project. Responding to the market is a habit. Most product functions are good at the first because it has a date, a team and a party at the end. The second has none of those, and it is where the revenue lives.
Decide the balance on purpose, write it down, and review it as the portfolio ages. Left alone, the new will always win.
Good portfolio management is taking care of all of it: the thing you are launching, the things that pay for it, and the gap between them.
