How to define a useful first version

Describe the beginning and the end

For a service portal, a first journey could begin when a client sends a request and end when they approve a proposal and see the project status. A general-purpose CRM, billing system and document editor are separate ambitions.

Name the actors and decisions. Who prepares the proposal? Who may approve it? What happens when it is rejected? A written journey makes missing responsibilities easier to spot than a screen list.

Use three scope lists

Put each proposed capability into one of three groups: needed for the first outcome, required to operate safely, or deferred. The second group matters: backups, permissions and a recovery process may be invisible in a demo but necessary for production.

Core journey: request, proposal, approval and status.
Production needs: access control, validation, monitoring and agreed recovery procedures.
Later: advanced reporting, additional roles and integrations that do not block the first outcome.

Choose what can remain manual

A first release can leave occasional work with a person if the responsibility is explicit. For example, a team member might prepare the proposal while the portal handles review and status. Manual work should have an owner and a visible queue.

Do not describe simulated integrations as implemented features. If the demo uses sample data, record which connections still need API access, technical investigation or a commercial agreement.

Write acceptance criteria in ordinary language

‘The portal is finished’ is difficult to verify. ‘A client can approve the latest proposal, the team can see that approval, and an older proposal cannot replace it’ names an observable result.

Add the important failure condition. If a submission fails, does the user keep their text? If someone repeats an action, can it create duplicate work? The expected behaviour belongs in the paid-stage scope.

Keep changes tied to the outcome

When a new idea appears, ask whether the first user can still complete the agreed task without it. If yes, put it in a later stage. If no, explain what changed and revisit the scope, estimate and acceptance criteria together.