Turning Ambiguity Into Executable Direction

These requests sound like direction. Often, they are only the beginning.

• Modernize the platform.
• Improve the customer experience.
• Create the roadmap.
• Define the future state.

The work behind them may still contain incomplete evidence, competing stakeholder needs, changing scope, technical constraints, regulatory requirements, and different assumptions about what success actually means. In situations like that, the problem is not simply creating a roadmap. It is creating enough shared understanding that people can make the decisions a roadmap depends on. That has been a recurring pattern in my product and transformation work.

Teams rarely begin with all the clarity they need. They build it.

Research clarifies the problem. Stakeholder discussion exposes competing priorities. Prototypes make abstract choices visible. Constraints reveal what is feasible. Review helps turn disagreement into decisions. Over time, uncertainty becomes something people can act on. That is how I think about strategy at its most practical:

Strategy does not remove uncertainty. It creates enough clarity to move forward.

The Roadmap Is Usually Not the First Problem

When an organization asks for a roadmap, it is tempting to begin organizing features, phases, and dates. But a roadmap built before the underlying choices are clear can create the appearance of certainty without much real direction.

Before sequencing begins, a few things need to become clearer:

• What problem are we solving?
• For whom?
• Which capabilities actually matter?
• What constraints shape the answer?
• Where are the real tradeoffs?
• Which decisions are already made, and which are still open?

Until those questions are clearer, a roadmap may simply organize ambiguity. I saw this clearly in work for SMBC, where a legacy global cash and treasury management platform needed a future direction. The environment was complex. The platform supported cash management, payments, account services, reporting, security, fraud controls, and customer workflows across international markets. The client also had limited current-state documentation and continued to expand the requested scope. The work could not begin with a neat feature list.

We had to create a clearer picture of the problem first.

Different Evidence Reduces Different Uncertainty

The SMBC work included a review of 15 competing platforms, assessment of roughly 130 capabilities, identification of more than 120 usability challenges, business-requirements workshops, stakeholder interviews, subject-matter-expert involvement, and five iterative prototype cycles.

Those activities were not interchangeable. Competitive analysis helped establish what customers might reasonably expect from a modern treasury platform. Capability analysis made the scope more concrete. Usability findings exposed where the existing experience created friction.

Business workshops surfaced requirements and priorities. Banking and fraud specialists added context that a design team could not infer on its own. Prototypes made the emerging direction visible enough for people to react to it.

Each step reduced a different kind of uncertainty.

That matters because strategy work can look inefficient when viewed only as a sequence of workshops, research activities, and artifacts. The value is not in the artifacts themselves. It is in the decisions those activities make possible.

Evidence Has to Become a Decision

Collecting information is not the same as creating direction. Eventually, the work has to converge.

At SMBC, one useful example came from fraud expertise. A fraud subject-matter expert raised concern about new or changed transfer information. That insight changed the emerging product concept. The team developed a contact and address-book capability that could expose differences between current account information and historical transfer patterns. The point was not simply that an SME had provided another requirement.

The new information changed the direction.

That is the part of strategy work I find most important. Research, analytics, stakeholder input, competitive findings, and technical constraints all matter. But they become valuable when they help answer a practical question:

What should we do differently because we now know this?

If nothing changes, the evidence may have informed the team. It has not necessarily changed the strategy.

Constraints Belong in the Strategy

Constraints are sometimes treated as problems to resolve after the strategy is complete. In practice, they often shape the strategy itself.

I saw that in work for Prudential Financial. The organization wanted to modernize a portal used by financial professionals and insurance brokers, while also navigating a migration from a legacy content platform to a new web-content-management environment. That meant the future state could not be designed independently of migration. Legacy content, entitlement rules, business continuity, technology limitations, and content governance all shaped what was realistic.

The strategy had to improve the experience while remaining grounded in how the organization could actually get there. The resulting direction included capabilities around search, task-based navigation, personalization, entitlement visibility, content governance, alerts, and integrations. The roadmap also had to account for the migration path.

That did not weaken the strategy. It made it executable.

A strategy that ignores real constraints may look ambitious. It is often just incomplete.

Clarity Requires Tradeoffs

Ambiguity persists when every request remains equally important. Stakeholders often arrive with legitimate needs. Business leaders want growth. Customers want simplicity. Operations wants efficiency. Technology teams need feasibility. Risk and compliance teams need controls. Different groups may all be correct from where they sit. The work is not to prove one of them wrong. It is to make the tradeoffs visible enough that the organization can choose.

At SMBC, the structured review process helped with that. Work moved through documented discussion, internal design review, subject-matter-expert review, and client review. That sequence created places for the right people to influence the work without reopening every decision at every stage. It also helped control expanding scope.

Endless inclusion is not the same as alignment.

At some point, choices have to hold long enough for execution to begin.

When every request remains equally important, nothing is actually prioritized.

Execution Can Begin Before Every Question Is Answered

There is a temptation to think discovery ends and delivery begins. Real transformation work is often less tidy.

At Edgepark Medical Supplies, discovery and delivery overlapped. The experience team entered early to understand customer journeys, operational needs, future workflows, product capabilities, and priorities. As enough definition emerged, broader delivery resources were brought in.

Business-analysis requirements, stories, sprint definition, workflow decisions, and implementation priorities could begin taking shape while some discovery was still continuing. That overlap was useful. Waiting until every question had been resolved would have delayed execution unnecessarily. Starting delivery before enough was understood would have created a different problem.

The practical challenge was finding the point where the work was clear enough for additional teams to move. This is why I think executable direction is a better goal than perfect certainty.

The Roadmap Comes Later Than People Think

A roadmap is valuable because it organizes choices over time. But by the time a good roadmap appears, much of the difficult strategic work has already happened:

• the problem is clearer;
• important capabilities have been identified;
• constraints are visible;
• tradeoffs have been made;
• dependencies have emerged;
• stakeholders have reacted to something concrete.

The roadmap gives those decisions sequence. It does not create them from nothing. This is also why roadmaps should change when the underlying understanding changes. Changing a roadmap because new evidence alters the strategy is not failure. That is learning. Changing it constantly because the organization never made the underlying choices is something else.

The first is learning. The second is drift.

Strategy Does Not Remove Uncertainty

The SMBC work ended with a validated future-state direction and delivery handoff. I did not remain through production implementation. That boundary matters.

The value of the work was creating enough definition for the planned development effort to move forward: clearer capabilities, workflows, priorities, prototypes, scope decisions, and alignment across business, banking, fraud, and technology participants. The same principle appeared differently at Prudential, where the concept and roadmap were validated and handed into delivery within the realities of a major platform migration.

At Edgepark, enough clarity was created early for delivery to begin while discovery continued, rather than forcing an artificial boundary between thinking and execution.

Those experiences have shaped how I think about ambiguous work:

• understand the problem well enough to expose the real choices;
• make those choices concrete enough to define capabilities, workflows, and priorities;
• build enough confidence to move into execution;
• keep learning as the work moves forward.

Organizations rarely begin with the clarity they need to execute.

The work is creating it progressively, honestly, and with enough discipline to move forward before every uncertainty is gone.