Who Should Be in the Room for Custom Software Discovery?

A custom software discovery group should include the person who owns the business outcome, people who perform the work, the product decision-maker, a technical owner, and someone responsible for adoption. Not everyone attends every session, but each perspective needs a named representative and a clear decision right. Otherwise, discovery can produce polished requirements that fail in day-to-day operations.

Published September 28, 2026 · 9 minute read · By Essential Designs Team

Key takeaways

• Choose discovery participants by decisions and workflow knowledge, not title alone.
• Keep a small core team and invite specialists for defined questions.
• Separate people who advise, approve, operate and maintain the future system.
• Record unresolved disagreements and the person who can settle each one.
• Test requirements with frontline scenarios before scope is approved.

Why does the discovery team matter?

Software requirements are shaped by who is present. A leadership-only group may describe goals but miss the exceptions that frontline staff manage every day. A frontline-only group may improve the current workflow without addressing strategy, budget or ownership. A technology-only group may optimize architecture before the business has agreed on the outcome.

The goal is not a large committee. It is sufficient coverage of the decisions the project must make. A useful discovery process creates a shared picture of the current work, desired outcome, constraints, users, information, risks and measurable acceptance conditions.

Use five roles, even when one person fills two

Role	What this person contributes	Decision to clarify
Outcome owner	Business purpose, priority and funding context	Which outcome justifies the project?
Workflow representative	Real tasks, exceptions, workarounds and handoffs	What must work on an ordinary and difficult day?
Product decision-maker	Scope trade-offs, sequencing and acceptance	What belongs in the first usable release?
Technical owner	Systems, data, integrations and maintainability	What must the product connect to and live within?
Adoption owner	Training, rollout, support and operating change	How will the organization move from old to new?

In a small company, one person may fill several roles. Write the roles down anyway. The exercise exposes missing decisions and prevents the same executive from unconsciously answering for every user group.

Start with the outcome owner

The outcome owner explains why the organization is considering custom software instead of leaving the process alone, buying an existing product or improving the current tools. This person should name the business change, its importance and the boundaries of the investment.

Ask for an outcome that can guide trade-offs. “Build a portal” is a proposed solution. “Reduce the manual coordination required to onboard a new distributor while preserving approval controls” is a decision anchor. It leaves room to discover whether a portal, workflow automation or a smaller integration is the right response.

The outcome owner does not need to dictate every feature. Their responsibility is to resolve priority conflicts and confirm that the proposed scope still serves the original reason for the work.

Bring the people who perform the work

Frontline participants explain what happens between policy and reality. They know which fields are unavailable at the ideal time, which exceptions need a supervisor, which steps happen outside the official system, and which handoffs create delays.

Select representatives from materially different roles or locations rather than asking one manager to speak for everyone. Use concrete scenarios: a normal case, a rejected case, a correction, a rush request and a case that crosses departments. Ask participants to show artefacts they actually use, with private or confidential information removed.

Do not turn a workshop into a vote on every preference. The product decision-maker translates evidence into scope and records why a decision was made.

Name one product decision-maker

Discovery generates competing needs. The product decision-maker is accountable for ordering them, defining the first release and accepting documented trade-offs. They should have access to the outcome owner and enough authority to prevent every stakeholder request from becoming mandatory.

A decision log is useful here. For each material choice, record the question, options, evidence, decision, owner, date and condition that would reopen it. This preserves context when team members change and keeps later design reviews from relitigating settled questions without new evidence.

Include technology before scope hardens

The technical owner identifies systems of record, integration dependencies, data quality, hosting constraints, access needs and operational ownership. Their role is not to veto ideas with technical language. It is to explain consequences while options are still inexpensive to change.

For integrations, use an explicit event and field-ownership discussion rather than “sync these systems.” Our guide to an API integration contract provides a practical canvas. For replacement projects, pair discovery with a data migration acceptance plan.

Plan adoption during discovery

Software can pass its technical tests and still fail to become the normal way of working. The adoption owner identifies training groups, rollout constraints, internal support, policy changes, communications and transition periods. They also surface users who rarely attend project meetings but will experience the largest change.

Ask what old tool, spreadsheet or informal route must stop, who can authorize that change, and what fallback is acceptable during rollout. If the answer is “people can use either system,” duplicate processes may persist indefinitely.

The Essential Designs discovery participation map

Prepare this map before the first workshop:

1. Decision: List the decisions discovery must produce, such as outcome, release boundary, workflow, data ownership and rollout.
2. Evidence holder: Name the person who knows how each part works today.
3. Decision owner: Name the person who can approve the choice.
4. Affected groups: Identify users, customers or teams whose work changes.
5. Session: Invite only the people needed for that question, then publish the result to the broader group.
6. Gap: Record decisions with no owner or evidence source before drafting requirements.

This structure keeps the core team workable while preventing quiet stakeholders from appearing only after design or development has begun.

What should discovery produce?

A buyer should expect more than workshop notes. Useful outputs include a plain-language problem statement, user and workflow map, prioritized release scope, key data and integration decisions, assumptions, unresolved questions, acceptance scenarios, delivery risks and a recommendation for the next stage.

Our software requirements checklist can help evaluate whether the resulting brief is ready for estimation. Discovery should reduce uncertainty enough to make the next investment decision; it should not pretend every future detail is known.

Prepare for the first session

Choose the outcome owner and product decision-maker first. Ask them to name two people who perform the work and one person who will support the system after launch. Give each participant one real scenario to bring. Then list the decisions only that group can make.

Essential Designs helps organizations plan and build custom software around real operating workflows. To structure an upcoming discovery phase, talk with our team.

Sources and methodology

• UK Government Service Manual: How the discovery phase works, accessed September 28, 2026.
• W3C WAI: Involving users in web projects, accessed September 28, 2026.

This article is a buyer-side planning framework. The examples are illustrative and do not describe a named client engagement.