Digital product discovery: what to decide before development

Start with the user’s completed task

A digital product brief should describe what somebody is trying to finish. “We need a customer portal” says little about that task. “Customers need to submit a request, supply evidence and see what happens next” gives a team something to design and test.

Choose a few important journeys and map their start, finish and exception states. Include the work done by administrators and support staff. A polished customer screen can still leave the operations team copying information between systems behind the scenes.

Bring the system of record into discovery

Identify where each important fact belongs. Customer identity, payment status, service progress and uploaded evidence may live in different systems. Decide which source is authoritative and how the product should behave when sources disagree.

Sketch the data flow before commissioning a large interface. Check whether the required APIs, permissions and environments are available. If an integration cannot be tested yet, record that as a delivery dependency rather than assuming it will work later.

Prototype decisions, not just screens

Use prototypes to test whether people understand the service. Can they tell what is required, what has been saved and what happens next? Can a manager distinguish an action they can perform from one that needs another team? Ask people to complete a task instead of asking whether they like the design.

For an AI-enabled product, show uncertainty and review states in the prototype. A draft, an approved action and a completed action should not look interchangeable. Decide how a person corrects the output and whether that correction changes a business record.

Write acceptance criteria before estimating

A useful acceptance statement names a user, an action and an observable result. For example: an authorised account manager can view the customer's open requests, while a manager from another customer cannot. Add error states, such as an upload failure or a session expiring before submission.

These examples help expose differences in scope between estimates. One supplier may include permission testing and another may quote only the visible screens. Ask each team to identify exclusions and external dependencies explicitly.

Make the first release coherent

A first release should let a defined audience finish a useful journey. Removing half the steps to reduce the estimate may create an incomplete service that still needs manual rescue. Instead, reduce the number of audiences, workflow variations or integrations while keeping the selected journey understandable.

Discovery should produce a prioritised brief, a tested experience direction, system boundaries and a delivery plan with assumptions. It should also identify decisions that remain open. That makes it easier to review new requests without losing the original purpose of the product.

AI Labs technology delivery turns this work into scoped implementation. See build or buy AI software when choosing between an existing product and a custom build.