Skip to content
Dmitry FabushevHEAD OF SEO
← All cases/Initiative governance
In operating use

Initiatives: separate business value from development readiness

Ideas with very different levels of maturity entered the same queue, so several teams could start spending time before three basic questions were answered: is it worth doing, is it ready for development, and how will success be judged? We formalized the route from idea to post-release review.

Case at a glance
What was at stake

The later a weak hypothesis or unmanaged risk is discovered, the more expensive the return — by then product, engineering, QA and other teams are already involved.

What I owned

Connected the working practice into one model: decision gates, roles, readiness criteria, release and post-release outcome review.

Outcome

Sixteen detailed stages are organized into five clear phases. The model is in use and separates business value, technical readiness and actual outcome review.

From idea to outcome review
01Value→02Solution→03Ready→04Release→05Outcome

The point is to stop a weak initiative before several teams spend time on it.

Why this matters

The main saving is stopping a weak initiative before expensive delivery

When discovery, requirements and success criteria are mixed together, several teams can start spending time before the idea has proved its value. The process is not about adding stages; it creates early REJECT / REWORK / PROCEED points and forces the initiative back to actual outcomes after release.

Key decision
04

Business value vs technical readiness

The model clarifies ownership.

Business

Owns value, priority and continuation.

Engineering

Owns feasibility, technical risk and implementation.

01

Where the process broke down

The backlog mixed early ideas with implementation-ready work. Technical discussion could begin before the organization had agreed why the initiative mattered or how success would be judged.

02

Five phases across a 16-stage process

The five phases organize the detailed flow; they do not replace the 16 stages.

01

Qualify

Problem, value and continue/reshape/stop decision.

02

Design

Discovery, options, constraints and unknowns.

03

Ready

Risks, requirements and Definition of Ready.

04

Deliver

Implementation, UAT, release and Definition of Done.

05

Evaluate

Actual outcome, economics and next decision.

03

Questions that need separate decisions

Value, feasibility and outcome are different questions.

Business value

Is the problem worth solving and how important is it?

Technical readiness

Are solution, dependencies, risks and acceptance criteria clear enough?

Post-release outcome

Did the initiative create the intended effect?

05

Where an initiative can stop before development

The point is not to drag every idea through 16 stages, but to create an early right to say “not ready” or “not worth building.”

Weak value → REJECT

If the problem does not justify the cost or priority, it should not become an engineering task.

Useful idea, weak solution → REWORK

Discovery sends the initiative back when requirements, dependencies, or success criteria are still unclear.

High risk → back or STOP

Financial, operational, architectural, security, or regulatory risk can push the initiative backward or stop it.

Ready → PROCEED

Only after requirements, risks, and readiness criteria are clear does the initiative earn the right to compete for engineering capacity.

06

My contribution

The process was developed collectively. I structured the practice into phases, decision gates, roles, readiness criteria and post-release evaluation.

07

The process does not end at release

After launch, expected value is compared with actual value — otherwise the company only knows that code shipped, not whether it was worth building.

Actual metrics

Check whether the expected user and business effect materialized.

Real cost

Compare actual CAPEX/OPEX and delivery effort with the original estimate.

Next decision

Scale, repair, stop, or start a new cycle using the evidence collected after release.

Context & measurement
Context
Cross-functional operating model · real organization
Scale / period
16 detailed stages · 5 phases · adopted operationally

What to measure next

The next useful measures are idea-to-ready time, rework rate and the number of initiatives stopped before development.

Initiative governance

Facing a similar challenge?

Tell me where SEO is blocked by product, engineering or data.

DiscussOther cases