Notes on the problem, the framework, and the dollar.

There is a particular failure mode I see in technology programs, and I have committed it myself enough times to recognize the smell. A senior practitioner walks in, listens for ninety minutes, and announces the framework. RICE for prioritization. Scrum for delivery. OKRs for governance. RACI for ownership. The specific framework varies. The pattern doesn't. Half an hour after meeting the team, they have a method. Three months in, they discover the method was wrong for this team, this problem, this urgency.

Maslow's line (that to someone with only a hammer, everything looks like a nail) is usually quoted as a warning about technique. It is a deeper warning than that. It is a warning about what happens to your perception when your toolkit is small. You don't see the problem clearly. You see the part of the problem your one tool can act on. Everything else falls out of focus.

I have been building tools since 1991, and the most useful thing experience has given me isn't a bigger toolkit, though that's part of it. It is the patience not to pick a tool until I understand what the work actually requires.

Living with the problem statement

A common pattern in product and program management is to treat the problem statement as a starting line. You define it in week one and then you race. The teams I want to work with treat the problem statement as something to live with. Not to rush. Not to defend. To actually understand.

Most of what users and team leads describe in the first conversation is not the problem. It is the symptom that's hurting them today, framed in their language, anchored to whatever they were just trying to do. The real problem usually shows up around the third or fourth conversation: after they've corrected themselves twice, after they've contradicted what someone else on their team said, after they've shown you the spreadsheet they actually use instead of the one the system was built around.

The discipline I try to maintain is this: I am not allowed to define the problem until the team has, in their own words, told me three different versions of it and I have spent enough time in their workflow to know why each version was true and why none of them were complete. Until then, I am collecting. Not solving.

The cost of this patience is real. People want answers. Leaders want roadmaps. Velocity feels good. The cost of skipping it is worse. If you solve the wrong problem, the team gets a tool they don't use, the leadership gets a metric that didn't move, and you get to explain why the program with a green dashboard didn't deliver business outcome. I have had that conversation. It is not one I am eager to repeat.

When the framework follows the problem

Once the problem is genuinely understood, the framework is a much smaller decision. Sometimes Scrum is right. Sometimes the answer is Kanban with research spikes, for ML work where the timeline is unknowable because what the model can learn is unknowable. Sometimes the answer is a weekly review with no formal artifact at all, because the team is small and the institutional memory lives in three people's heads, and what they need is rhythm, not ceremony.

I have run programs that used Scrum for platform builds and Kanban for model experiments in the same week. RAID logs for risk-heavy regulatory work. Design sprints for ambiguous "what should we even build" questions. Weighted scoring models for prioritization where RICE was too crude for the trade-offs. None of these is the right answer in the abstract. Each is the right answer for a particular shape of problem.

The practitioners I trust are not the ones with the strongest opinions about methodology. They are the ones who have done the work in enough different shapes that they can match the method to the moment. That is not a thing you can read in a book. It is what experience actually buys you, after enough engagements where the wrong framework got applied for the wrong reason.

Now do the math

Once the problem is understood and the framework is chosen, there is one more discipline that separates good program management from talented program management. You quantify.

I get told regularly that a particular outcome cannot be quantified. I push back on this almost every time. In the work I do (financial services, data products, AI pipelines, regulatory programs), the data is there. The quality may be poor. The lineage may be murky. The signal may be deeply buried. But the data is there. I have built things by tracing the lineage of one number through six systems until I knew, with confidence, where it came from and what it meant. I have bet career years on the idea that the right number, found and verified, is worth the effort. It almost always has been.

A small example. A few years ago I inherited a team building a relationship-extraction model. The training accuracy was reported at seventy percent. The deployed accuracy was reported at twenty percent. The two numbers came from two different teams using two different definitions of accuracy on two different samples, and the gap between them had paralyzed the program. Before I could fix the model, I had to fix the metric. We rebuilt the scoring methodology with engineering, data science, and operations in the same room. Once the three teams agreed on what accuracy meant and how it would be measured, we could see what was actually wrong, and we could fix it. Six months later we were at eighty percent across eleven of twelve sectors. The lift was real, but it would not have been possible until the metric was honest.

Once you can trace a metric to dollars, you can argue for the work. Once you can't, you are pitching with adjectives.

Easy metrics are usually the wrong metrics. They got measured because they were measurable, not because they mattered. The useful metrics are often expensive to compute, hard to keep current, and politically uncomfortable because they reveal what the easy metrics were hiding. Sometimes the right metric is too expensive to be worth the calculation. Most of the time, the right metric is hard but worth it. Knowing the difference is most of the work.

A line I have used with leadership more than once, and one I will stand by: in financial services, if you cannot trace a program's outcome to dollars and cents, then either the metric you've chosen isn't right, or the outcome you're chasing isn't worth chasing. Neither is a comfortable conversation. Both are necessary.

On effort, and on outcome

There is a tendency, particularly among senior practitioners with strong technical backgrounds, to treat the elegance of the work as part of the deliverable. It isn't. The C-suite does not care that the model architecture was brilliant, that the team worked weekends, or that the migration was the largest absorbed by BlackRock that year. The C-suite cares whether the platform reduced operational risk, freed up FTEs, increased revenue per client, cut cycle time on a regulatory exercise. Outcome.

No one cares how much effort or intelligence went into a program. Only the outcome matters.

ROI assumptions need to be pressure-tested, ripped apart, defended with full understanding of what they assume and what could break them. The number you give a CFO is the number you should be willing to defend in a long, cold meeting six months later, when the number didn't come in where you said it would. If you can't defend it, don't quote it. If you can defend it, quote it boldly.

What I keep

So this is what I have, after a long time at it. I am not loyal to any particular framework. I am not impressed by methodology certifications, my own included. I am loyal to the problem, defined patiently, and to the metric, defined honestly. The frameworks come after both, and they vary by engagement.

Anyone who picks the framework first is selling. The work happens in the patience.

// DG