A first version is a decision about where to begin. The most useful starting point gives someone a complete, worthwhile experience while keeping the scope small enough to understand and finish.

Name the outcome before the features.

A feature list can grow quickly. A customer portal becomes messages, documents, bookings, payments, dashboards, and notifications before anyone has explained the original problem. Step back and describe what should become easier for the customer or team.

For example, ‘customers can find the current status of their request’ is a clearer starting point than ‘we need a portal.’ It gives the project a specific job and helps everyone decide which features serve that job.

Complete one useful journey.

Choose a path that a real person can follow from beginning to end. A booking experience needs more than a calendar: customers need to know what they’re booking, receive a confirmation, and understand how to ask for a change.

A smaller scope should still feel complete. You can begin with one service, one location, or one team. The important part is that the experience works within the boundaries you have chosen.

  • Who is the first version for?
  • What should they be able to finish?
  • What can the team handle manually at first?
  • What would make the first release useful on its own?

Keep the foundation clear.

Some choices deserve care early: how information is organized, who controls the accounts, how access works, and how the team will maintain the result. These are practical foundations, not a reason to build every possible future feature.

Document the assumptions behind the first release. If an integration is deferred or a process remains manual, make that visible. A clear limitation is easier to work with than a hidden promise about what the system already does.

Let the first release inform the next one.

After launch, listen for friction. Where do customers get stuck? What does the team still need to explain? Which manual steps have become a real burden? Those observations are more useful than expanding the roadmap because an idea sounds impressive.

A phased project makes room for this learning. Each release should stand on its own, improve something specific, and give the next decision a firmer basis. Ambition can stay large while the first commitment stays focused.