How I work

Complex products

Complex products usually combine two kinds of work: tasks that can be repeated and judgment that depends on context. My job is to separate the two: what the product should automate, what the user should still control, and where the interface needs to make uncertainty visible.

Three requests to the research workspace routed by confidence: a specific one goes straight to a proposed outline, a vague one gets suggested templates, and a two-word one gets the full brief

Observe

Start with the work, not the requested feature

I try to understand how people complete the task before deciding what the product should do. That usually means watching:

what information they collect
where they switch tools
what they repeat
what requires judgment
where mistakes become expensive

At S&P Global, analysts did not simply “write reports.” They investigated claims, assessed new information, and synthesized evidence into publishable research. At SBI, consultants combined repeatable data assembly with judgment about growth opportunities and recommendations.

Those differences shaped the products more than the original feature requests did.

Separate

Automate the repeatable work, preserve the judgment

Not every manual step is a problem. Some work is slow because the system is weak. Other work is slow because a person is making an important decision. I try to distinguish between them.

At SBI, data collection, formatting, and report assembly could be made more systematic. The recommendation itself still needed expert judgment. At S&P Global, AI could generate a report quickly, but analysts still needed control over structure, evidence, and the final edit.

The goal is not maximum automation.

The goal is removing work that does not benefit from human judgment.

Phase

Introduce automation in stages

Complex workflows rarely improve by replacing everything at once. I prefer to automate one layer, observe how people use it, and then decide what should happen next.

At S&P Global, report generation (opens in a new tab) evolved from one-shot output to a structured brief, then confidence-based routing, then integrated research. At SBI, individual consulting workflows became software first. Their outputs were connected later into a broader growth-planning experience.

The growth roadmap inside SBI’s platform

Three tools, one plan

Each phase answers a smaller question and reduces the cost of being wrong.

Control

Make correction cheaper than regeneration

Automation is useful only when people can recover when it is wrong. I design intervention points before expensive work happens. That may mean:

approving an outline before generating a report
editing a recommendation before it affects a plan
reviewing low-confidence output instead of every output
exposing assumptions before a calculation is accepted

At S&P Global, I intentionally added steps before full report generation because correcting an outline was cheaper than repairing a complete report.

For expert work, speed matters less when correction is expensive.

Interface

Use the interface that fits the decision

Chat is useful when the task is open-ended. It is weaker when users need to compare options, inspect data, change several parameters, or understand system state. I use different interaction models depending on the work:

Chat for exploration and ambiguous intent
Structured inputs when specific information is required
Tables and dashboards for comparison and inspection
Editable artifacts when users need to refine output
Automation when the decision is predictable enough to remove from the interface

The goal is not to make everything conversational. The goal is to choose the least complicated interface that still gives the user enough control.

Trust

Make evidence and uncertainty visible

In expert products, a polished answer is not enough. People need to understand:

where information came from
whether it was calculated or inferred
what the system is uncertain about
what still needs review

At S&P Global, sources were attached directly to claims and results distinguished between sourced, estimated, and needs-review states.

A report being edited, with writing help offered on a selected sentence, and the assistant beside it showing its rationale and the steps it worked through

Reasoning beside the report

The interface should help users decide where to trust the system and where to intervene.

Measure

Measure the workflow, not just the feature

A feature can work technically without improving the job around it. I look for changes such as:

fewer manual steps
less duplicated work
shorter cycle time
fewer context switches
faster correction
increased reuse

At SBI (opens in a new tab), I compared median cycle time for comparable Jira stories before and after the shared foundation, leaving out backend-only work, incidents and unusually large initiatives. Comparable UI work moved 30% faster.

When clean behavioral metrics are not available, I separate what I observed from what I can actually measure. I would rather show limited evidence clearly than assign an unsupported percentage to the work.