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.
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 glanceConnected the working practice into one model: decision gates, roles, readiness criteria, release and post-release outcome review.
Sixteen detailed stages are organized into five clear phases. The model is in use and separates business value, technical readiness and actual outcome review.
The point is to stop a weak initiative before several teams spend time on it.
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.
Business value vs technical readiness
The model clarifies ownership.
Business
Owns value, priority and continuation.
Engineering
Owns feasibility, technical risk and implementation.
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.
Five phases across a 16-stage process
The five phases organize the detailed flow; they do not replace the 16 stages.
Qualify
Problem, value and continue/reshape/stop decision.
Design
Discovery, options, constraints and unknowns.
Ready
Risks, requirements and Definition of Ready.
Deliver
Implementation, UAT, release and Definition of Done.
Evaluate
Actual outcome, economics and next decision.
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?
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.
My contribution
The process was developed collectively. I structured the practice into phases, decision gates, roles, readiness criteria and post-release evaluation.
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.
Facing a similar challenge?
Tell me where SEO is blocked by product, engineering or data.