What the signal is worth.
A request arrives, then another framed a bit differently. Finding the commonality is not the hard part. Deciding what that commonality is evidence of, and whether it supports what you are about to spend, is where the work is.
One of these cases is a pattern I read correctly when it looked like three separate asks. The other is a pattern I read wrong when it looked airtight. Both are decisions made under real constraints, with the evidence that was actually available at the time.
01 · The request
What we were asked to do
Let a person register an object they own, or register themself into a program, with the office that keeps the official record. Once registered, nobody could make a change to that record without their say-so.
One customer asked for it. It was in a contract. It was one build.
02 · The pattern
What was going on elsewhere
While we were scoping that, two more requests were making their way through the company on separate tracks. Different customers, different ways in. Each one would have been built from scratch for that customer alone.
They arrived one at a time and looked like three unrelated features. I saw the shared shape right away.
Each request looked like a special case because of how it arrived and how customer-facing teams framed it. They were special cases only due to what got registered and how it was handled afterward. Underneath, they sat on the same foundational capabilities. That, plus knowing the industry would keep bringing us more of these, made this a place to think strategically and long term.
I had three of these in hand and a shape steady enough to set up rather than rebuild.
03 · Product judgment
The call I made
I’m harder on building a framework than anything else that crosses my desk. A framework pushes back delivery of value. Getting customers something useful quickly is the job.
Frameworks do pay off and help a product scale. The return lands later than the tactical fix does. But the long tail of the work keeps delivering value to the business and every customer who comes after. It also spares my team from rebuilding the same thing three ways and making the system carry the complexity that creates.
The question is whether what the business gains is worth what the customer waits for. The framework has to prove it. Most don’t. That’s why frameworks, which are typically larger in scope and slower to deliver, lose to whatever is on fire this week. More often than not, that’s the right decision and, occasionally, an expensive one.
This one proved it because the customer wasn’t waiting or frustrated by continued workarounds. The program we owed shipped when we said it would. What changed is that the next one didn’t need to be built at all.
I ran product for the suite, so I didn’t ask permission. I made the case and the decision, got people on board, and drove it. The evidence was sitting in three separate queues, and leaving it there was costing my team time and the company money.
04 · Outcome
What we shipped
A base capability: sign one person up or a group, verify them against a record we trust, then apply whatever special handling that program calls for when something happens. The first program ran on it. The ones that came after got set up instead of built.
01 · The request
What came in
Escalations had reached concerning volume, and they arrived from more than one direction. Customers raised them directly through support or to anyone who’d listen. Frontline associates raised them on customers’ behalf. They were consistent enough to read as one problem: the reporting module was broken, and the system was missing features people needed to finish their work.
That was the request as it reached me. Fix reporting. Fill the gaps in transaction management, which is what reporting draws from.
02 · The pattern
What the tickets showed
I pulled 12 months of accounting- and reporting-related tickets, everything logged by customers directly or indirectly. Around 170 of them. I used AI to interrogate the set for commonality, which is work it’s good at. It holds all of it at once and shows me where the same complaint appears in different words.
The analysis was clean and it pointed at the system. Financial adjustments were stored one way, edited another, and surfaced in reporting a third, with gaps or bugs in all three. I was certain we needed to rework the whole path, from how the data sits in the database through the interface to what comes out in a report.
So I sketched the straw man. Multiple phases, two to three teams, dependencies running in every direction, and no realistic full delivery inside 12 months. Too big to fund as written, so I started cutting it into increments so relief could land sooner.
That is where it stalled. My product owner and engineering lead were respectfully resistant, and they could not point at hard data. What they had was a daily line of questions from support about how the product worked. And it was not only support. Working command of the system was thin across the organization, in more places than anyone had accounted for. Their read was that those questions were not the kind people ask about a broken system. They were the kind people ask about a system they have not learned yet.
For weeks, I heard that as friction between teams. In the moment, I had 170 tickets and a pattern. They had a feeling.
The dataset only held what people escalated. Nobody opens a ticket to say they do not understand the screen in front of them.
03 · Product judgment
What changed my mind
Other work took priority and the conversation went quiet for about six weeks. When I picked it back up I repulled the numbers, expecting the case to have gotten stronger. Accounting and reporting tickets had dropped, and the drop was in the most recent month.
Support had restructured while I was not looking. They placed a superuser on the team to absorb the daily questions and build the team’s own fluency. I had no part in it and did not know it happened. My product owner and engineering lead did.
One month of movement, one explanation offered alongside it, no control for release timing or seasonality or the other work in flight. That is thinner than what I act on. I took it as a directional indicator, and it pointed at people and process rather than technology.
What made thin evidence sufficient was the asymmetry. On one side, a year of structural investment across three teams, justified by a pattern drawn from a dataset I now knew was incomplete. On the other, a fix already deployed, already paid for by another team, already showing movement. When the cheap thing is in the field and working, the expensive thing has to earn the year.
The system did not have the functional gaps I was certain it had. It had an interface that required real training before anyone could work it fluently. That is still a product problem. It is a different one, and rewriting the transaction path does not solve it.
Two people with no dataset read it before I did. Not because they were more analytical. Because they were closer, in the daily traffic of a team that was struggling, where the signal was in what people asked out loud. That signal never becomes a ticket.
04 · Outcome
What I decided
I suspended the refactor. Not killed, suspended, with the analysis intact for whenever the case gets made properly.
The evidence for a structural investment was not there. Comprehension difficulty was not specific to financial adjustments. It ran through the system, which meant a rewrite of the transaction path would have spent a year fixing one instance of a problem that lived everywhere.
It went where things go when they are real but not yet fundable: flagged, monitored, waiting for the pattern to establish well enough to justify what it costs. The straw man had already broken into increments. Those stayed on the shelf, ready.
