Your Product May Be Running on Expired Assumptions

Products don't break. They rot. Breaking is easy. Breaking pages for someone at 2 am. Breaking shows up red on a status board and gets a postmortem and a fix. Rot is the other thing: the feature still works, the numbers still look fine, and the reason it ever worked stopped being true nine months ago. Nobody gets paged for that. I spent a chunk of my career working on systems that had to encode rules written by governments. Regulators change those rules on their own schedule, without asking whether your release train is convenient. The rule that was correct on Tuesday is quietly wrong on Wednesday, and nothing in your system knows. You find out because someone in a market you rarely think about files a complaint, or because a partner asks a question you can't answer. That job rewired how I look at product. Every feature is a rule encoded on top of a belief about the world. Regulators are just honest about the fact that beliefs expire. The rest of us pretend they don't. What actually rots Look at your own product with this lens for ten minutes and it gets uncomfortable. Your onboarding flow was tuned for how people behaved two years ago, when they were willing to sit through a five-step setup because everyone's setup was five steps. Your pricing tiers encode a competitive landscape and a set of rivals, some of whom have since pivoted, been acquired, or started giving away the thing you charge for in tier two. Your personas were written before people started asking a chatbot for a recommendation instead of opening four tabs and comparing. None of that is a bug. There is no ticket. There's no owner, because the person who made the call got promoted or left, and the belief they were acting on never got written down anywhere except in the shape of the feature itself. The dangerous version isn't when the metric drops. It's when the metric holds and the mechanism underneath it has already been swapped out. Conversion is flat, so the funnel is "fine," except the people converting are now a different group arriving for a different reason, and the copy that used to do the persuading is being ignored on the way past. You are collecting the same number while the machine that produces the number has been quietly replaced. That's not a win you can build on. That's a coincidence you're forecasting against. Dashboards are the wrong instrument for this I like dashboards. I have opinions about dashboards. They are also structurally incapable of catching this. A dashboard measures outcomes. Rot happens in the premises. There is no chart for "users no longer compare three options before buying" or "support volume no longer peaks on Monday because the workweek stopped being a workweek." Those were inputs to a decision, not outputs of a system, so they never got wired to anything. The gap is worse in AI-adjacent products, because the ground moves faster than the review cycle. A workflow you designed around the assumption that a developer would read your docs before integrating is now being consumed by an agent that never reads anything. A support flow built on the assumption that users describe their problem badly, so we should ask clarifying questions, now meets users who arrive with a well-structured problem statement because something else did the structuring for them. Same funnel. Different species walking through it. Instrumentation tells you what happened. It cannot tell you whether the story you told yourself about why it happens is still current. Give assumptions an expiry date The fix I've landed on is boring, which is why I think it works. When a feature ships, write down the beliefs it depends on. Not a doc. Three to five lines, in plain language, in the same place the spec lives. Users compare at least three options before choosing a plan. Support contacts peak Monday morning and taper by Thursday. Most integrators are humans reading documentation. Our mid tier is priced below the nearest alternative. Then date each one and give it a recheck interval. Pricing beliefs: six months. Competitive beliefs: three. Behavioral beliefs about how people shop or ask for help: six to twelve, shorter if your category is moving. Anything touching AI capability: three, and I'm probably being generous. Think food labeling, not architecture. The expiry date on milk isn't a guarantee it goes bad that morning. It's a prompt to smell it. You are not trying to predict when a belief dies. You're trying to make sure somebody checks before you build the next three features on top of it. The part that matters is that the belief becomes a written object with an owner and a date. Once it's written, it can be wrong, and someone can notice. Left unwritten, it's just "how the product works," and questioning it feels like questioning the roadmap. Reading rot when it looks like noise Regressions announce themselves. Rot shows up as a shape you have to squint at, and the squinting is the skill. Drift with no event. Conversion slides two percent a quarter for four quarters. Each quarter it's inside the noise band, each quarter someone attributes it to seasonality or a mix shift, and nobody ever gets to say "something changed on this date" because nothing did. A regression has a Tuesday. Rot doesn't. If you can't find the Tuesday, stop looking for a deploy and start looking at your premises. Support contacts rising on a solved flow. You fixed that flow. It's been fine for a year. Now tickets are creeping up and the tickets aren't about bugs, they're confusion. That's usually the flow being correct for a user who no longer exists. The people arriving now have different expectations, formed by whatever else they've been using since. A segment thinning out quietly. Total numbers are stable because one cohort is growing while another shrinks. Your aggregate hides the trade. The shrinking cohort is often the one your original assumptions were written about, which means your product is drifting away from its own design intent while the top-line dashboard applauds. A feature nobody has argued about in a year. Sounds like stability. Sometimes it's stability. Sometimes it means the people who understood why it exists have all rotated off, and it's now maintained by consensus rather than by reasoning. Consensus is not evidence. Fifteen minutes, once a quarter This is where most process ideas die, so let me be clear about how small this is. It's a quarter of an hour. Pull the assumption list for whatever you're about to invest in. Read each line out loud, because reading out loud makes stale things sound stale in a way that skimming does not. For each one, pick a bucket: still true, probably still true but nobody's checked, or we know this is no longer true and we've been building on it anyway. Only the third bucket generates work. The second bucket generates one lightweight question for whoever would actually know. No committee, no template, no artifact anyone has to maintain. If it starts producing a deck, you've built a process and it will die within two quarters. Half the value is just watching a room realize they've all been operating on a belief that nobody currently holds. That happens more than you'd expect, and it happens most often on the features everyone is proudest of, because those are the ones nobody thinks to reopen. The rules I used to maintain came with expiry dates attached by someone else. Your product assumptions come with expiry dates too. The only difference is that nobody's going to send you the notice.