What to include in your first software release

A first release has to be useful enough for people to try, while leaving room to learn from how they use it. Defining that boundary is a product decision as much as a technical one.

Identify what you need to learn

State the question the release should help answer. It might concern willingness to pay, repeated use or whether the product improves a particular task.

“Customers can complete a booking without assistance” is more useful than “the booking feature works”. It identifies a behaviour you can observe.

Prioritise complete user tasks

Identify the steps needed for someone to receive the core benefit of the product. Then separate supporting requirements from features that could wait.

A small feature list is only useful if it still supports a complete experience. Account recovery, accessibility or clear error handling may matter more to that experience than an additional headline feature.

Consider manual work deliberately

Some administrative tasks can be handled manually while volumes are low. That can help clarify the process before investing in automation.

Include the staff time, access requirements and consequences of errors in that decision. Manual work still needs appropriate controls, particularly where it involves customer information or payments.

Account for what happens after launch

The first release needs to be operated as well as built. Consider hosting, support, maintenance and the services it depends on.

Technical choices should suit the current scope while making likely changes understandable. That does not require building every possible future feature in advance.

Learn from actual use

Observe whether people can complete the intended tasks and where they need help. Compare what happens with the question you set out to answer.

That evidence can guide the next investment: improve the core experience, add a missing capability or reconsider the product assumption.

To discuss a first release, tell us about your product.