The Krisova 90-Day Production Path | Architecture-Led Go-to-Market

A product rarely fails to reach production because one team stopped working.

More often, work continues across product, engineering, cloud, data, security, design, operations, and specialist vendors while the complete production path remains unresolved.

Teams deliver features. Vendors complete milestones. New environments and integrations appear. Yet ownership is divided, important decisions remain open, and the production date continues to move.

The Krisova 90-Day Production Path is designed for this situation.

It is an architecture-led operating horizon for suitable products that need business priorities, technical decisions, teams, ownership, dependencies, security obligations, and production readiness to converge quickly.

It is not a universal promise that every product can reach production in 90 days. The horizon works only when the scope is focused, decision-makers are available, critical dependencies can be examined, and teams are prepared to act on consequential decisions.

Its purpose is to convert activity into convergence and convergence into a credible production outcome.

Activity creates outputs. Convergence creates a product. Production creates value.

Why a 90-day production horizon

A fixed horizon changes the quality of decision-making.

Without one, difficult architecture questions are often deferred. Scope expands. Temporary decisions become permanent. Dependencies remain hidden inside team plans. Production readiness is treated as something to address after implementation.

A focused 90-day horizon forces the organisation to decide:

which customer journey must reach production;
what must be true for that journey to operate;
which decisions are blocking it;
which capabilities belong in the product;
which foundations must be retained for the platform;
which work can be deferred;
who owns decisions across internal and vendor boundaries.

The objective is not to complete every desirable capability.

The objective is to establish one credible path from business intent to an operable product.

Execution can be distributed. Technical ownership cannot be fragmented.

When the path is appropriate

The 90-Day Production Path is suitable when the organisation can define a focused production objective.

Typical conditions include:

a product or production-critical journey already exists in some form;
technical work is active but not converging;
founders or executives need a credible route to market;
ownership is distributed across internal teams and vendors;
architecture decisions are delaying implementation;
duplicated work or unclear platform boundaries are increasing cost;
production obligations are being deferred;
a full-time CTO is absent, overloaded, unaffordable, or too distant from delivery;
leadership is willing to narrow scope and make decisions quickly.

The method works best where the organisation needs disciplined technical direction without creating a large consulting programme around it.

When it is not appropriate

A 90-day horizon is not credible in every situation.

It may be inappropriate when:

the business proposition remains fundamentally undefined;
there is no agreed customer or operational journey;
critical systems, teams, or dependencies cannot be accessed;
major procurement, regulatory, legal, or infrastructure constraints cannot be resolved within the period;
the target depends on substantial research or unproven technology;
leaders want a fixed date but are unwilling to reduce scope;
no one has authority to settle product-level technical decisions;
teams cannot commit the required implementation capacity;
the existing product requires fundamental replacement before any production path can be established.

In these cases, the first outcome may need to be a current-state assessment, architecture direction, or a revised production horizon rather than launch.

Preconditions

Before the path begins, five conditions should be established.

A defined business outcome

The organisation must identify the customer, operational, or market result that production is expected to enable.

This does not require a complete product strategy. It does require enough precision to distinguish essential work from attractive but non-critical scope.

Access to decision-makers

Founders, executives, product owners, and senior technical leaders must be available when decisions affect scope, risk, cost, or market timing.

Delayed decisions quickly consume a short production horizon.

Access to the current system

The architecture, code, environments, interfaces, vendor responsibilities, data flows, security constraints, and operational assumptions must be open to examination.

A production path cannot be built from status reports alone.

Committed delivery capacity

Internal and vendor teams must be able to implement agreed decisions during the horizon.

Architecture direction without delivery capacity creates another plan rather than production progress.

Authority to challenge existing choices

Some current decisions may need to be retained. Others may need to be revised or replaced.

The organisation must be prepared to change decisions that create duplication, cost, dependency, or unclear ownership.

The five-stage path

The stages are presented in sequence, but they are not isolated phases. Decisions made in one stage are tested and refined as implementation progresses.

1. Direction

Objective

Establish one production objective and one technical direction.

Core questions

Which customer or operational journey must work in production?
What business outcome does that journey enable?
What does “production” mean for this product?
What is explicitly outside the 90-day scope?
Who has authority to make product-level technical decisions?

Decisions required

production-critical journey;
release boundary;
accountable decision authority;
essential constraints;
exclusions and deferred scope.

Activities

align founders and executives on the target outcome;
review the current product and delivery position;
identify competing definitions of scope;
connect business priorities to technical consequences;
define the smallest credible production slice.

Outputs

agreed production objective;
defined production-critical journey;
initial scope boundary;
named technical decision ownership;
visible assumptions and constraints.

Exit conditions

The organisation can explain what must reach production, why it matters, who owns the technical outcome, and what is being deferred.

Common failure modes

treating every stakeholder priority as essential;
confusing a feature list with a production journey;
allowing several leaders to maintain different definitions of completion;
accepting a date without resolving scope.

Leadership responsibilities

Executives own the business priority and consequential trade-offs.

Architecture leadership translates those priorities into a technically credible production direction.

2. Bottleneck Removal

Objective

Expose and remove the constraints preventing teams from converging.

Core questions

Which decisions are blocking progress?
Which dependencies are hidden inside team or vendor plans?
Where is work duplicated?
Which unresolved assumptions require early validation?
Where is delivery waiting for ownership rather than implementation?

Decisions required

blocker priority;
dependency ownership;
work to stop;
assumptions to test;
issues requiring executive escalation.

Activities

separate architecture decisions from ordinary delivery tasks;
identify recurring hand-offs and unresolved dependencies;
examine duplicated capabilities and overlapping responsibilities;
test critical technical assumptions;
remove work that does not contribute to the production path.

Outputs

prioritised production blockers;
dependency map;
assigned owners;
decisions requiring immediate resolution;
reduced or stopped work.

Exit conditions

Critical blockers have accountable owners, decision dates, and an understood effect on production.

Common failure modes

adding resources without removing the constraint;
tracking blockers without settling the underlying decision;
treating cross-team architecture issues as project coordination;
allowing low-value work to continue because it was already planned.

Leadership responsibilities

Architecture leadership determines whether the constraint is technical, organisational, contractual, or scope-related.

Executives remove decision and priority barriers that delivery teams cannot resolve alone.

3. Architecture Decisions

Objective

Settle the high-consequence decisions that determine whether the product can reach production and continue beyond it.

Core questions

Which capabilities belong in the product?
Which belong in a shared platform?
Which system owns authoritative data?
Where should identity, access, workflow, and integration responsibilities sit?
Which components are temporary?
Which decisions would be expensive to reverse?
What must remain as a platform seed?
What can safely be deferred?

Decisions required

product and platform boundaries;
data ownership;
identity and access boundaries;
integration patterns;
security responsibilities;
temporary and enduring components;
build, buy, reuse, and defer choices.

Activities

review architecture against the production-critical journey;
challenge duplicated or overlapping capabilities;
establish explicit system boundaries;
identify irreversible or high-cost decisions;
retain only the platform foundations required for the next credible stage;
define technical obligations that must be implemented before production.

Outputs

coherent production architecture;
decision records;
explicit ownership boundaries;
retained platform seeds;
deferred capability list;
architecture obligations for implementation.

Exit conditions

Teams can implement against one architecture without repeatedly reopening foundational decisions.

Common failure modes

building a platform before the product need is proven;
embedding core business logic inside temporary integrations;
allowing vendors to define product boundaries independently;
retaining existing decisions only because work has already started;
deferring security, data, or support ownership until release.

Leadership responsibilities

Architecture leadership owns the coherence of the whole design.

Product and executive leaders approve business trade-offs where architecture decisions affect scope, cost, timing, or market value.

4. Delivery Alignment

Objective

Ensure internal and vendor teams implement one end-to-end product rather than several disconnected scopes.

Core questions

Who owns each interface and dependency?
What does complete delivery mean across teams?
How will architecture deviations be handled?
Which team owns cross-system failure?
How will security and operational requirements remain visible during implementation?

Decisions required

team and vendor responsibilities;
interface ownership;
dependency acceptance;
implementation sequence;
architecture review points;
end-to-end acceptance conditions.

Activities

align teams to the production-critical journey;
convert architecture decisions into executable work;
make hand-offs and responsibilities explicit;
review implementation consequences;
resolve deviations quickly;
prevent local optimisation from damaging the complete product.

Outputs

shared delivery priorities;
assigned interfaces and dependencies;
aligned internal and vendor responsibilities;
implementation decisions;
end-to-end acceptance criteria.

Exit conditions

Teams can demonstrate that their work contributes directly to the same production journey, architecture, and definition of completion.

Common failure modes

vendors meeting milestones while the complete journey remains unfinished;
teams optimising their own scope at the expense of the product;
architecture decisions remaining disconnected from delivery work;
unresolved dependencies being moved from one plan to another.

Leadership responsibilities

Delivery leaders manage execution within teams.

Architecture leadership owns convergence across teams, boundaries, and technical decisions.

5. Production Readiness

Objective

Establish evidence that the product can operate, fail, recover, be supported, and continue to change after launch.

Core questions

Does the critical journey work end to end?
What happens when access is denied or data is incomplete?
How does the product behave when integrations fail?
Can state be recovered safely?
Are monitoring, support, and escalation responsibilities clear?
Can the organisation explain what happened after an incident?
Can the product be deployed, rolled back, and changed predictably?

Decisions required

production acceptance;
risk acceptance or remediation;
support ownership;
release and rollback conditions;
monitoring and evidence requirements;
continuity and recovery responsibilities.

Activities

test successful and failed journeys;
validate identity, security, data, and integration controls;
exercise recovery and retry behaviour;
confirm monitoring and support ownership;
validate deployment and rollback;
close material production risks;
gather production evidence.

Outputs

production evidence;
unresolved risk decisions;
support and operating model;
release recommendation;
recovery and continuity responsibilities;
agreed post-production priorities.

Exit conditions

The organisation has evidence that the selected product slice is operable and that material risks have been resolved, accepted, or explicitly carried forward.

Common failure modes

testing only the successful journey;
treating monitoring as a substitute for recovery design;
completing a checklist without assigning operational ownership;
releasing with unresolved risks that no leader has accepted;
assuming vendor support agreements equal end-to-end product support.

Leadership responsibilities

Architecture leadership determines whether the evidence supports production confidence.

Executives own material business and risk acceptance decisions.

Indicative 90-day timeline

The exact sequence depends on context, but a typical horizon has three overlapping movements.

Weeks 1–3: Establish the production path

align on the business and customer outcome;
define the production-critical journey;
inspect the current architecture and delivery position;
expose bottlenecks and dependencies;
assign technical decision ownership;
narrow the release scope.

Weeks 4–8: Drive decision and delivery convergence

settle product and platform boundaries;
resolve data, identity, integration, and security decisions;
remove duplicated or low-value work;
align internal and vendor teams;
implement and validate the critical path;
resolve deviations as they appear.

Weeks 9–13: Prove operability

complete the end-to-end production journey;
test failure, recovery, support, and continuity;
validate monitoring, rollback, and production evidence;
close or explicitly accept material risks;
decide whether the product is ready for production, requires a controlled exception, or needs a revised horizon.

The timeline is an operating guide, not a rigid software-development lifecycle.

Readiness scorecard

A compact scorecard can assess six dimensions.

Dimension	Executive question
Direction	Is one production outcome agreed?
Ownership	Can consequential technical decisions be made quickly?
Architecture	Are product, platform, data, security, and integration boundaries explicit?
Delivery	Are internal and vendor teams converging on one journey?
Controls	Are security and operational obligations implemented?
Operability	Can the product operate, fail, recover, and be supported?

Each dimension can be assessed as:

Unresolved
Emerging
Credible

The public scorecard is intentionally simple. The underlying evaluation depends on the product, risk profile, architecture, and operating context.

Measurable indicators

Useful indicators include:

Number of unresolved production-blocking decisions.
Age of critical cross-team dependencies.
Percentage of the production-critical journey working end to end.
Number of duplicated or overlapping capabilities.
Percentage of critical interfaces with explicit ownership.
Number of material technical assumptions not yet validated.
Number of untested failure and recovery paths.
Number of production risks without accountable owners.
Time required to resolve architecture deviations.
Percentage of production-readiness evidence completed.

These indicators are more useful when they show whether the product is becoming operable, rather than merely whether teams are completing work.

An anonymised case pattern

In one focused engagement, several internal and vendor teams were active, but the production path remained unclear.

Technical direction was distributed. Similar capabilities were being implemented more than once. Dependencies were managed as delivery issues even when they required product-level architecture decisions.

The engagement narrowed the production objective, exposed the principal bottlenecks, challenged selected technical decisions, aligned team responsibilities, and retained only the platform foundations required for the next stage.

The product reached production within 90 days.

This result does not imply that every product can follow the same timeline. It shows what can become possible when decisions, scope, teams, and production obligations converge.

Krisova has supported more than three products through production. Its architecture and solution-design experience spans more than 100 use cases, including programmes involving large internal teams, multiple vendors, and several executive stakeholders.

Advice and ownership through implementation

The 90-Day Production Path is not completed when an architecture is approved.

Advice can define the direction.

Ownership ensures that the direction survives implementation.

That means remaining involved as decisions are translated into code, interfaces, infrastructure, security controls, operating responsibilities, and release evidence.

It means resolving deviations and cross-team dependencies when they arise.

It also means challenging decisions that are locally convenient but harmful to the complete production outcome.

Execution can be distributed. Technical ownership cannot be fragmented.

Visual-ready five-stage model

BUSINESS AND MARKET DIRECTION
            │
            ▼
1. DIRECTION
Define the production-critical outcome, scope and decision authority
            │
            ▼
2. BOTTLENECK REMOVAL
Expose dependencies, duplicated work and unresolved decisions
            │
            ▼
3. ARCHITECTURE DECISIONS
Settle product, platform, data, security and integration boundaries
            │
            ▼
4. DELIVERY ALIGNMENT
Align internal teams and vendors to one production architecture
            │
            ▼
5. PRODUCTION READINESS
Prove operability, recovery, support and production evidence
            │
            ▼
CREDIBLE PRODUCTION PATH
            │
            ▼
MARKET PROGRESS, OPERATIONAL VALUE AND THE NEXT PLATFORM STAGE

Across all five stages:

Decision ownership
Technical leadership
Architecture validation
Implementation accountability
Production evidence

Limitation and maturity

The Krisova 90-Day Production Path is an architecture-led operating method informed by production and multi-team delivery experience.

It is not a universal guarantee, a generic delivery framework, or a substitute for sufficient engineering capacity.

Its suitability depends on the existing product, scope, architecture, stakeholder access, dependencies, regulatory obligations, and the organisation’s willingness to make and implement consequential decisions.

The method will continue to evolve as additional production evidence and operating patterns are incorporated.

Executive diagnostic

Before adopting a 90-day production horizon, leaders should ask:

Can we define one production-critical customer or operational journey?
Is there one accountable authority for product-level technical decisions?
Can internal teams and vendors provide access to the systems, dependencies, and assumptions affecting production?
Are we willing to remove scope and stop work that does not contribute to the selected outcome?
Can architecture decisions be implemented during the horizon rather than deferred?
Are we prepared to test failure, recovery, support, and continuity—not only the successful journey?

A credible production horizon begins when the organisation is prepared to make these commitments.

Activity creates outputs. Convergence creates a product. Production creates value.