Why Product Care Needs Its Own Line
Fides was the Roman mythological goddess of trust and kept promises. Her temple on the Capitoline was where Rome stored its treaties. Not the negotiations, the finished agreements, on bronze, in the open, where anyone could go and check what had actually been promised.
The myth was clear that a promise nobody can verify isn't really a promise. It's a sentiment, and sentiments quietly change shape over time to suit whoever is remembering them.
Product managers (PMs) make the same kind of promise at launch. The launch is the hero: it gets the announcement, the internal credit, the celebration. Product care gets none of that, even though it is the same customer-product promise, still being kept or quietly broken.
That promise wasn't invented at launch. It was set much earlier, in the part of the Stage-Gate® where the business case was built, where the problem to be solved and the product promise are defined. The customer has no bronze tablet to check it against, only their own experience of whether the product keeps working the way it was described. Which means the only durable record of the promise is an internal one: whether keeping it shows up anywhere as committed, funded work. When it doesn't, brand trust erodes.
The problem: real product care should have a place to live
Three separate accounts report the same workflow gap. The pattern is real, confirmed, and everyone in the room agrees it's not just one unhappy customer. The report gets a nod in the portfolio meeting. Then the work happens anyway, informally, absorbed by whoever has capacity that week, never counted against anyone's plan and never visible in the portfolio view.
That especially happens when there's no line on any roadmap for keeping the promises the product was sold on. No business would say out loud that it has no plan for the customers it already has. Most never have to because the roadmap says it for them. New platform work has a bucket, a score, a rank. Product care has none of that, and without clearly defined resources, it may not get the prioritization that loyal customers deserve.
The framework: giving product care a real line, not just a nod
The portfolio review is in two weeks. Six new-platform bets are ranked and scored against each other inside their own funded bucket, exactly as they should be. The confirmed reagent lot variability fix and the workflow gap three accounts already flagged aren't in any bucket. They have no bucket of their own, so they get raised as exceptions, argued case by case against work that already has a number attached. That's an argument product care rarely wins.
This is where sizing the split matters directly. A bucket is simply a pre-agreed share of the R&D budget reserved for one type of work. Product care shouldn't be a claimant on someone else's bucket, it should have a permanent, sized bucket of its own, decided at the same time as every other split, the way the bucket-sizing framework already handles project types. A bucket that exists means product care items compete against each other, on their own merits.
There's a second reason, beyond fairness in the competition. Cooper made this point about process rather than budget, but the mechanism is the same. He noted that when smaller projects sat outside the Stage-Gate process, each looked individually minor while collectively consuming the bulk of development resources (Cooper, 2008). Unbucketed product care behaves the same way: until it has a line, nobody can say what it actually costs.
It's worth being precise about what this bucket isn't. Product care isn't a fourth horizon competing for a slot next to the Horizon 1, 2, and 3 bets covered in the roadmap-building post. The roadmap highlights which new bets earn a place in the next 12 to 18 months. The product care plan focuses on what you keep doing for the customers who already bought the launched product. They answer different questions.
What goes in the bucket looks different depending on what you sell. For a reagent or kit line it's lot-to-lot variability work, protocol revisions, and updated application notes. For an instrument or platform, it's sustaining engineering, the term most hardware organizations actually use: firmware updates, consumable requalification when a supplier changes a component, service parts availability across an installed base that will outlive the current platform by years. Same argument in both cases, very different line items, and if you sell both, each product line needs its own sized product care share rather than one shared pool, since the instrument tail will otherwise quietly consume the reagent line's capacity.
The PM's job here isn't building the fix, that's R&D's job entirely. It's making the obligation visible enough, sized enough, and tracked separately enough, that a VP of R&D can actually defend giving it dedicated engineering time, the same way they'd defend headcount for any funded roadmap line. If product care never appears as a real, sized item, no VP can protect capacity for it against six ranked new-platform bets that already have a number attached.
Budget isn't the only currency here. A team that gets recognized for launches and stays invisible for product care will keep optimizing for launches, regardless of how the buckets are drawn. The PM's job includes making sure product care work gets named and credited the same way a new product introduction would be, in the same reviews, to the same audience. A brand doesn't survive on new launches alone. It survives on customers who still trust the last thing they bought.
Doesn't protecting a dedicated product care line just create competition with new development, robbing one priority to fund another? Yes, and that tension is real, not something to argue away. The answer isn't pretending the trade-off doesn't exist. It's the VP of R&D actively managing capacity so sustaining engineering gets real, protected time, the same discipline any funded bucket already requires elsewhere in the portfolio. That's a resourcing decision for R&D leadership to make. What the PM defends isn't the process, it's the position: that this product is one that customers can trust a year after they bought it. That claim is either something the roadmap protects on purpose, or something the business quietly stops being able to make.
The takeaway
Rome put its promises on bronze and left them where anyone could check them. The point wasn't ceremony; it was that a promise with no record is only as durable as the memory of whoever made it. Your launch promise has no bronze tablet. It has a roadmap, and either product care appears on it as a real, sized line, or the promise stays a sentiment that quietly changes shape until the customer notices before you do.
