Product Discovery
Identify the process owner before choosing software
Software cannot settle an unresolved question about who owns a business process. Identify decision rights across departments, exceptions, and ongoing operations before comparing products or delegating requirements to a vendor.
When several departments share a workflow, each may expect software to make the others respond. A tool can route tasks, but the buyer still needs an agreed authority for rules, exceptions, and unresolved handoffs. Without that agreement, product selection risks automating a dispute instead of improving the process.
Find the decisions that cross boundaries
Map the journey from the first business request to its final outcome. GOV.UK discovery guidance recommends understanding the wider journey and learning from other teams involved.[1] Include offline work and the person who receives the consequences of a failed handoff.
Ask who can change the rules, accept an exception, and settle a conflict between local objectives. The person who administers a tool may not have that authority. A senior sponsor may approve funding without having time to manage routine process decisions.
Write an authority statement before a role chart
Describe the owner’s scope in plain language. Identify the process boundary, decisions the owner can make, and issues that require escalation. Specify who provides operational evidence and who substitutes when the owner is unavailable.
Do not confuse process ownership with a named delivery role. In Scrum, the Product Owner is accountable for product value and effective Product Backlog management.[5] That definition does not automatically grant authority over every department’s operating policies. Confirm how those responsibilities connect in your organization.
Hypothetical example: onboarding a business account
A hypothetical wholesaler wants one system for account onboarding. Sales wants rapid activation, finance wants a review before credit access, and operations needs a valid delivery address. The workshop initially produces three incompatible definitions of ready.
The sponsor appoints a process owner who can agree the activation boundary with those departments. The resulting rule separates a provisional account from an account allowed to place credit orders. Only then does the team compare how products support the agreed states and exceptions.
Check whether ownership is usable
A name in a presentation is not enough. Ask the proposed owner to resolve a realistic disagreement before making a major software commitment.
- Define the starting event and final outcome within the owner’s scope.
- State authority for rules, exceptions, and cross-team priorities.
- Name an escalation route for decisions outside that authority.
- Assign operational reporting and a substitute decision-maker.
- Confirm who owns the process after the delivery team leaves.
Recognize the cost of centralized authority
One owner can become a bottleneck if every routine decision requires personal approval. Delegate repeatable decisions within clear limits. Reserve cross-team changes and disputed exceptions for the accountable owner.
Some organizations cannot grant all authority to one person. In that case, record the governance arrangement and its expected response conditions. Delay product commitments that depend on unresolved policy. Clear limits are more useful than an impressive title with no practical decision rights.
