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 method arrives before the second meeting does. 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. I read it as 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 for two decades and then some, and the most useful thing experience has given me, more than a bigger toolkit, is the patience not to pick a tool until I understand what the work 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 until they understand it.

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.

That patience costs something: people want answers, leaders want roadmaps, and velocity feels good. Skipping it costs more. 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, and the hard version of it is the one where nobody demands an explanation at all. The sponsor simply does not see a difference. Everything was delivered, the thing looks good, and the outcome either arrives long after anyone budgeted for it or never arrives. The more strategic the work, the longer that runs. What I told her, in that case, was that the arithmetic was right and the source data was sound, and that we might still be collecting the wrong thing to answer her question.

When the framework follows the problem

Once the problem is 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 hold their opinions about methodology loosely, because they have done the work in enough different shapes to match the method to the moment. Nobody learns that from a book. You learn it from 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, one discipline is left: quantify the outcome.

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 murky, the signal buried, but it exists. 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. That effort has almost always been worth it.

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. 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 wrong with the model, and fix it. Six months later we were at eighty percent across eleven of twelve sectors. None of it was 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.

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. The C-suite does not care that the model architecture was brilliant, that the team worked weekends, or that the migration was among 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.

No one cares how much effort or intelligence went into a program.

ROI assumptions need to be taken apart and 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 it didn't come in where you said it would. If you can't defend it, don't quote it.

Where my loyalty is

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.

// DG