# Plan and deliver product work

Use an accepted product definition, established defect, requirement or consequential findings
from [diagnosis](diagnose.md). A request to fix known broken continuation does not
require a new market study or complete PRD. Preserve applicable approvals and
follow [working together](collaboration.md) for meaningful intermediate results.

## Choose work worth doing

For a consequential prioritization, compare the strongest candidate with its
strongest alternative: who encounters the problem, the supported mechanism,
plausible recoverable value, confidence, effort, cost and risk. Use ranges or
qualitative comparisons when data is sparse; do not invent uplift or multiply
unrelated cohort rates. The largest percentage drop or most dramatic bug does
not automatically deserve priority. Handle urgent safety/privacy risks on their
own merits, not as an invented conversion explanation.

Name why the choice advances the goal now and what could reverse the ranking.
Distinguish a product change from the cheaper check needed to justify it. Fixable
bugs alone do not justify endless investment; [evaluate](evaluate.md) whether
the current direction still merits another commitment.

## Make the accepted work executable

In the existing plan, record the concrete creation or change, affected path, evidence and
expected benefit, dependencies, owner and appropriate verification/checkpoint.
Identify what can happen now and what is conditional. Missing inputs block only
dependent decisions, with a bounded resolution path. Keep important secondary
findings with their disposition rather than losing them during compression.

For a first release, use the whole result and quality agreed in [value](value.md),
with the applicable [offer](offer.md) and [experience](experience.md). Split work
into coherent outcomes and real dependencies, not a universal sequence of UX,
Auth, Product and Billing stages. Preserve nonvisual requirements and deferred scope;
an attractive screen does not replace the behavior behind it. Do not promote optional
features into launch requirements just because they share an interface.

For an uncertain improvement, state the hypothesis, relevant cohort/outcome,
baseline where available, affordable scope and decision conditions before results.
Choose an observation that can distinguish the proposed mechanism, not just an
aggregate that may move for unrelated reasons. Keep technical acceptance distinct
from the observation of customer impact.
Select timing and limits from the product and buying cycle, not universal weekly
or sample thresholds. A repair to broken execution starts a new interpretable
measurement period; it does not validate earlier faulty evidence.

Check consequential calculations, source claims, counterevidence, feasibility
and the reason the choice beats alternatives before presenting the plan. Correct
substantive problems; no separate reviewer persona, finding quota or document
pack is required.

## Carry through and verify

Use `egbe-os-product-build` for an agreed bounded repair or planned implementation;
it routes auth, payment and analytics work to their owning skills. Use `egbe-os-git`
and `egbe-os-deploy` when integration or a serving release is needed.
Continue the existing product and architecture when there is one; build a suitable
foundation for a new product. Do not broaden a repair into a new business decision. Changes to the
promise or accepted behavior return to the affected requirement and founder decision.

Verify the promised outcome at the level it depends on: code evidence where
sufficient, and the real serving journey where necessary, including saved work
and relevant integrations. A page deployed or checkout opened is not proof that
the customer received the result. Preserve remaining gaps and continuation using
EGBE's handoff rule. Then use [evaluation](evaluate.md) for observed effect; a
technically complete repair need not wait for enough customers to prove growth.

Make review repeatable for the founder: where to try it, what outcome to expect,
what access or human action is needed and which limits remain. A private token file
is not necessarily usable browser access. Keep concrete implementation progress and
evidence in the existing work record or `egbe-docs/development/<work-id>/`, without
creating a new master plan or losing the approvals and scope recorded under EGBE.