Before you start a digital product

Who is it for, and what changes?

Name the first users and the task the product should help them complete. Describe their current approach and why they would change it.

What needs to be true?

Record the business and technical assumptions behind the idea. Identify which uncertainties could change the decision to build.

What is the first useful scope?

Choose a complete workflow for a limited audience. Include the essential access, error handling and support that make it usable.

What does it depend on?

List the data, integrations, permissions, people and commercial decisions required to deliver. Assign responsibility for making them available.

How will you judge the result?

Agree what acceptance means and what evidence will guide further investment. Keep implementation testing separate from evidence about customer demand.

Who owns the product after launch?

Decide how feedback, incidents, maintenance and new priorities will be handled. A launch without ongoing responsibility leaves important work unfinished.

Give the team concrete starting material

Bring examples of the problem, the people affected and the work they need to complete. If a system already exists, include access to representative screens and records, documentation and the issues the team encounters. This material helps turn an idea into a scope that can be discussed.

Define the decision owner and the people who understand the workflow. Agree how they will resolve conflicting requirements and who can confirm the business rules.

Connect scope, dependencies and acceptance

Describe a complete first use case, including how it starts and ends. Identify the external systems, data sources, permissions and operational steps it depends on. Record which dependencies are available and which require investigation.

Write down the acceptance criteria alongside the scope. Include important exception cases and the evidence needed to show that the software behaves as agreed. The development team should perform implementation testing before asking the business to validate the workflow.

Prepare for the product to be used

Plan data migration, training, access and support before treating the release date as settled. Agree how issues will be reported and how the team will decide whether they require a correction or a later improvement.

Finally, define the next review after launch. Compare the result with the original problem and the experience of the users. A useful product plan includes the decisions and responsibilities that keep the software working as the business changes.

Explore the next step with Perspective Unity.