Make trade-offs explicit when a useful new idea arrives during development.
Separate discovery from commitment
Learning something new during delivery is normal. The problem is accepting every request without discussing its effect. Record the proposed change, the user need and why it matters now. Distinguish a correction to agreed behaviour from a new capability. Both deserve attention, but they may have different implications for scope and planning.
Compare options
Ask whether the new request replaces lower-priority work, extends the release or belongs in a later phase. Include design, testing and support effort, not just coding. Explain dependencies and uncertainty. A small visible control can require substantial changes behind it, while a useful alternative may solve the same problem more simply.
Name the decision-maker
Give a responsible product owner or authorised client contact enough information to decide. Record the choice and updated assumptions. Avoid relying on an informal comment in a busy chat as the only record of a material change. Team members should be able to explain which version of the plan is current.
Keep the release goal visible
Review the remaining work against the original outcome. If the direction has genuinely changed, update the plan openly rather than preserve an obsolete deadline and hope. A change process should help the product learn while protecting the clarity needed to deliver something useful.
Your next working session.
- State the need
- Compare scope trade-offs
- Record the decision
Bring one real, anonymised example to the discussion. Work through the choices above with the person responsible for the outcome, record the unresolved questions and agree who will investigate them.
Elite Apps editorial · Practical planning guidance. Examples and diagrams are illustrative; implementation depends on your requirements. Technical and supplier guidance can change.
