Discovery Workshop

Product Discovery Workshop

Book the workshop before you commit to the build — because the cheapest part of any software project is the week you spend getting the plan right, and the most expensive is the six months you spend building the wrong thing.

Most projects do not fail in the build. They fail in the scoping, when assumptions go unchallenged, stakeholders leave the kickoff with different mental models of what "done" means, and nobody checks whether the business goal actually requires what the spec says it requires. A product discovery workshop closes that gap before you spend a dollar on development. You leave with a clear, de-risked, build-ready plan — aligned stakeholders, a scoped backlog, and a delivery approach designed to run as Agent Loops rather than sit on a shelf. And the reason we can run a week this dense is that our own discovery work is itself agent-assisted: the transcription, the synthesis, the current-state diagramming and the first-pass backlog are produced by loops under our engineers' direction, which is what buys the hours back for the part that needs people in a room.

Facet has run discovery for clients across professional services, operations, healthcare, law and property management since 2014. If you are about to invest in a significant product or process build, book a scoping call before you write the first line of code.

Why hire a discovery partner?

Because aligned stakeholders and a scoped build plan are not what a kickoff meeting produces — they are what you build deliberately in a focused engagement. The reason to hire a discovery partner before a build is simple: the cost of discovering the wrong scope in week one is a conversation, and the cost of discovering it in month four is a rewrite.

Discovery eliminates the most expensive surprises

Going into a build without structured discovery is a bet that your assumptions about scope, stakeholder priorities and technical approach are correct. They rarely all are.

Scope that looked obvious becomes negotiable: when you write stories and acceptance criteria out loud, in a room with the people who will live with them, you surface contradictions that would otherwise have become change orders three months in.
Stakeholder alignment does not happen by accident: the CEO, the operations lead and the technical team routinely hold different definitions of success. Discovery exposes those gaps in a low-stakes setting rather than during a live production incident.
The build approach follows the business goal: a well-run discovery starts with the outcome you need and works backward to the simplest build that achieves it, rather than starting with the technology.
The operating model is designed in, not bolted on: the plan we produce is built to be executed as Agent Loops, so you are not getting a static specification. You are getting a build plan that already knows how the system will run after launch.

Action item: Before you talk to anyone, ask three stakeholders separately to write one sentence describing what the project must achieve. If you get three different sentences, discovery is not optional and the week will pay for itself in the first session.

We run our own discovery this way

Facet is not a consultancy describing agentic delivery from the outside. We run discovery on our own product work the same way we would run it on yours, which is the only reason we know where the week actually goes — including the discovery we run on our own product work before we build anything internally.

That matters here for a specific reason. Discovery has always been bottlenecked by reading and writing rather than by thinking. Someone has to transcribe eleven interviews, reconcile what three people said about the same process, read the existing system and documentation, diagram the current state, and then write a backlog where every story has acceptance criteria a builder and a reviewer would read the same way. That is days of work, it is what consultancies bill hourly for, and almost none of it is the part that requires judgment.

We put loops on that half. Our facilitators spend their time in the room, asking the follow-up question that changes the scope — while the synthesis, the diagramming, the first draft of every story and the traceability check that every backlog item maps to a stated business outcome happen in parallel rather than in the fortnight afterwards. That is why the readout lands at the end of the week instead of two weeks later, and why this is a fixed-scope engagement rather than an open-ended one you fund by the hour. We publish a full writeup of how the business runs on agents; until it goes live, the short version is that we ran this on our own backlog first and found the sharp edges there.

Humans stay in command. Loops read, synthesize and draft. A Facet engineer runs the interview, decides what the contradiction means, and owns every recommendation that reaches you.
Agent-produced work clears the same gates as human work. A story an agent drafted is reviewed, argued with and rewritten exactly like one a business analyst typed. There is no lighter standard because a model produced it.
We name the failure modes. A model summarizing an ambiguous interview will produce something plausible rather than flag the ambiguity, lose the thread across a long transcript, and be confident about both. That is precisely why synthesis is reviewed against the recording and why the readout puts contradictions in front of the room rather than resolving them quietly.
It shortens the calendar, not the thinking. The sessions are the same length. What disappears is the waiting between them.

What the loop actually does

The agent-absorbed half of a discovery is the high-volume reading, cross-referencing and drafting work — the part where being thorough matters more than being clever, and where a person doing it by hand is the reason discovery has historically taken a month.

Interview capture and synthesis. Every session transcribed, then cross-read against the others to surface where two people described the same process differently. Those contradictions are the single most valuable output of a discovery week, and finding them by hand is how they get missed.
Current-state reconstruction. Existing systems, documentation, tickets and data models read in full and assembled into a first-draft workflow map — including the workarounds and manual steps, which are where scope surprises live.
First-pass backlog drafting. User stories and acceptance criteria drafted from the agreed scope, in a consistent format, so the room spends its time arguing about the content rather than about the wording.
Traceability checking. Every backlog item checked against the stated business outcomes, and anything that traces to nothing gets flagged. This is a mechanical check that nobody ever has time to run, and it routinely removes a meaningful slice of proposed scope.
Automation candidate inventory. Each workflow in scope assessed for which steps are repetitive and checkable enough to run as a loop after launch, so the operating design is built from your real process rather than from a generic list.

What a person still decides

None of the above is a plan. It is the material a plan gets argued out of, and the arguing is the workshop.

What problem is actually being solved. The stated request and the real constraint are frequently different things, and telling them apart takes a facilitator who is willing to keep asking after the room has agreed.
Which contradiction wins. When operations and finance describe the same process differently, both are usually right about their own half. Deciding which definition the system will enforce is a business decision with consequences, not a data reconciliation.
What is in the first release. Cutting scope is the highest-value judgment in the week, it is unpleasant, and it needs someone in the room with the authority to make it stick.
Where a human gate belongs after launch. For each workflow we name what may run unattended, what needs sign-off, and what stays entirely manual. That line is a risk decision about your business, and we write it down rather than assume it.
Whether to build at all. Discovery sometimes concludes that the proposed build is not the right answer. That call is made by people, out loud, with the reasoning in writing.

What a product discovery workshop delivers

A well-run discovery does the diagnostic work most development engagements skip: interview the people closest to the problem, map the current workflow, find where the friction actually lives (often not where it appears), and translate business goals into a scoped, sequenced backlog a development team can execute without ambiguity.

The deliverables you leave with

A build-ready backlog: user stories, acceptance criteria and a sequenced delivery plan a development team can act on immediately, with no interpretation required.
A de-risked scope decision: the core must-have scope, the next-phase scope and the out-of-scope assumptions, so you know exactly what you are committing to and what you are deferring.
Aligned stakeholders: everyone who influences the build or lives with the outcome has seen the same plan, challenged it and signed off. That consensus is worth more than any document.
An Agent Loop operating design: the plan names which parts of the system will run as agentic workflows after launch, and which parts keep a human gate — so the build is designed to be run, not just shipped.
A build-versus-buy read on each piece of scope: which parts genuinely need custom software, which are a configuration of something you could license this week, and which are a process change with no software in them at all. Engineering leaders tend to want this section first, because it is the argument they will have to make internally either way.
A clear go/no-go decision point: discovery sometimes reveals the proposed build is not the right answer. That is a good outcome, and knowing it before the build saves far more than the workshop costs.

Facet's discovery approach

We run a structured week — typically two to five days depending on complexity and stakeholder count — organized around three questions: what problem are we actually solving, what is the minimum build that solves it, and how will it run in production. Every session ends with a written artifact, so nothing lives only in somebody's notes.

Stakeholder interviews: we talk to the people who will use the system, the people who will manage it and the people who will approve it — separately, so we get honest answers rather than conference-room consensus.
Current-state workflow map: we diagram how the work actually flows today, including the workarounds, the manual steps and the places information gets lost.
Goal-to-build traceability: every backlog item traces to a specific business outcome. If it cannot be traced, it does not belong in this build.
Agentic loop design: for each workflow in scope we identify what runs autonomously, what needs a human gate and what the feedback signal is, so the operating architecture is specified before a line of code is written.

How it works

Engagement structure

A discovery workshop is a paid, fixed-scope engagement — not a free sales call and not an open-ended consulting arrangement. It is scoped and quoted in writing before it starts, so the investment is bounded and the outcome is a concrete deliverable.

Week one: stakeholder interviews, current-state mapping, problem definition.
Week two, for larger engagements: story writing, scope negotiation, backlog sequencing, Agent Loop design.
Final session: readout with all stakeholders — a walkthrough of the scoped backlog, the delivery plan and the go/no-go recommendation.
Deliverables package: written backlog, workflow diagrams, Agent Loop operating design, and a summary suitable for taking to a board or an executive team.

What we need from you

Discovery only works if the right people are in the room: the stakeholders who understand the current workflow, the decision-makers who will approve the scope, and any technical leads accountable for the build. We do the diagnostic and synthesis work; you supply the knowledge of your business. That combination is what produces a plan that is actually executable.

What a successful discovery produces

Three measurable signals: a backlog that survives the first sprint without major scope change; stakeholder sign-off achieved before build kickoff rather than renegotiated mid-sprint; and a defined Agent Loop architecture, with its human gates named, for at least one workflow in scope.

Can you wire monitoring into the plan? Yes, and we treat it as a first-class design decision rather than an afterthought. Loop design during discovery specifies the feedback signals and alerts that will fire in production, so the build team knows from day one what the system must report and to whom.

The week that decides which build you are on

Most of this page argues that discovery protects you from an expensive mistake, which is true and is the smaller half of the case.

The larger half: designing the operating model in at the scoping stage is how a company stops shipping software and starts accumulating a capability. A build that launches with its loops, its human gates and its feedback signals already specified does not need a second project to make it autonomous — it arrives that way, and everything you build afterwards is cheaper because the pattern already exists. The second workflow inherits the loop design, the gate conventions and the traceability spine from the first. The third inherits them from both.

That is a week's decision, and it is available on the build you are scoping right now rather than the one after it. The teams moving fastest here are not the ones with the largest engineering headcount. They are the ones who stopped treating the operating model as something you bolt on once the thing works — and if you are the technical leader making that call, this is the cheapest place in the whole project to make it.

How could AI agents run the process you are about to build? Book the 45-minute scoping call. We walk the workflow you have in mind, rank the steps a loop could take over after launch, and give you a written view of whether a discovery workshop is the right next step — including "you do not need custom software for this" if that is the honest answer.

Where discovery leads

The plan is yours either way. Some clients hand the backlog to their own team and never speak to us again, which is a complete outcome. If you want it built or run, the path is a ladder rather than a package.

Requirements Engineering & Discovery — the deeper specification pass, once the decision to build is made and the scope is agreed. Discovery decides what; this decides exactly how.
Agentic Engineering — the build layer. Agents plan, build, check and improve under human command, against the backlog this workshop produced.
AI Managed Services — the run layer. A named Facet team keeps the system working and improving as your data, goals and edge cases move after launch.
Forward Deployed Engineering — a senior Facet engineer embeds with your team and transfers the method, if you would rather own the capability than buy the output.
Agentic Operating System — the same pattern installed across every operating area rather than one workflow.

Product discovery workshop FAQ

What is a product discovery workshop?

A product discovery workshop is a structured, facilitated engagement — typically one to two weeks — where a business and its technical partner align on what to build, why and how before development begins. The output is a build-ready backlog, a scoped delivery plan and signed-off stakeholder alignment.

It is a diagnostic, not a kickoff: a kickoff assumes you know what you are building. Discovery challenges that assumption and surfaces the gaps before they become change orders.
It produces actionable deliverables: user stories, acceptance criteria, workflow diagrams and a sequenced backlog — artifacts a development team executes, not a slide deck of recommendations.
It is bounded in time and cost: unlike open-ended consulting, it has a defined scope, a defined output and a fixed cost agreed before it starts.
It is the entry point to a build: discovery does not replace the build, it makes the build trustworthy. The backlog it produces is what the development engagement is scoped and contracted from.
At Facet it is agentic on both sides: the plan names which workflows will run as Agent Loops after launch, and the synthesis work inside the week is itself run by loops under our engineers' direction.
It sometimes produces a no-go: occasionally discovery reveals the proposed build is not the highest-leverage investment, or that the problem can be solved without custom software. A good discovery partner says so.

How is this different from a requirements engineering engagement?

They answer different questions and sit at different points in the lifecycle.

Discovery asks what we should build and why: it starts before the solution is defined, validates the problem, aligns stakeholders on success criteria and identifies the minimum build that achieves the goal.
Requirements engineering asks exactly how it should work: it comes after the decision to build and goes deep on functional specification, technical constraints, data models and integrations. It assumes the scope is known.
Discovery is faster and lighter: days to two weeks, against weeks to months for full requirements work on a complex system.
Discovery reduces the scope of requirements engineering: narrowing the solution space first means the specification work is aimed at the right system.
At Facet they are sequential, not interchangeable: discovery produces the go decision and the scoped backlog; requirements engineering deepens the specification within that agreed scope.
Where to start depends on where you are: if you are not sure what to build, start with discovery. If you know what to build and need to specify exactly how it works, you may be past it.

What does a product discovery workshop cost?

We do not publish a price list because scope varies significantly with complexity, stakeholder count and the number of workflows involved. What we can tell you is how the economics work.

It is scoped and quoted before it starts: unlike a retainer or a time-and-materials arrangement, you know what you are committing to in writing, in advance.
Focused single-process discovery is the entry point: one workflow, one team, one outcome, with a bounded stakeholder set and a defined output.
Larger engagements are quoted individually: multi-stakeholder, multi-workflow discoveries with a full readout and loop design are scoped on a brief call first.
Compare it to the alternative: a scope error caught in a discovery conversation costs a conversation. The same error found in month four of an active build costs a rewrite, and it arrives with a deadline attached.
It is often absorbed by the build contract: for clients who proceed to a development engagement with Facet, the discovery investment is factored into the overall engagement rather than added on top.

How long does a product discovery workshop take?

Duration depends on problem complexity and stakeholder count, and we design for the shortest week that produces a trustworthy plan.

Single-process discovery: two to three days. For a bounded problem and a small stakeholder set, we complete interviews, map the current state, write the backlog and run the readout in two to three focused days.
Multi-workflow or multi-stakeholder: one to two weeks. Interviews in week one, synthesis and story writing in week two, readout at the close.
We do not pad for its own sake: discovery ends when you have the deliverables. We have run effective discoveries in two days for focused problems and two weeks for complex ones.
The synthesis no longer sets the calendar: the transcription, diagramming and first-pass backlog run in parallel with the sessions rather than after them, which is why the readout lands at the end of the engagement rather than a fortnight later.
Remote-first: all sessions run remotely by default, with an onsite readout available if stakeholders prefer.

Does an agent sit in our interviews?

Not as a participant. Sessions are run by a Facet facilitator, recorded with your consent, and synthesized afterwards by loops under that facilitator's direction. Nothing an agent produces reaches you without a person having read it against the recording, and if your environment does not permit recording at all, we run the week manually and say so in the scope.

Start with the plan, not the build

Most organizations that regret a software investment do not regret what they built. They regret that they built it before they understood the problem. A product discovery workshop is the week that makes the next six months trustworthy.

Facet has run discovery across professional services, operations, healthcare administration, law and property management since 2014, and was named a CIOReview Top 10 Digital Transformation Services Company in 2021. We will not claim every engagement is a success — no honest firm does. What discovery is for is narrower and more checkable than that: you enter the build with a plan you can defend in a room, instead of a scope you are guessing at.

How could AI agents run the process you are about to build? Start with the 45-minute scoping call — no obligation and no proposal theater. You leave with a ranked view of which steps in your workflow a loop could take over after launch, where the human gates belong, and a written recommendation on whether a discovery workshop is the right next step.

Sometimes that recommendation is that it is not. If the honest finding is that an off-the-shelf tool and a process change solve your problem, or that the build you are planning should not happen at all, we will tell you that too — and it costs us the engagement, which is precisely why it is worth hearing.

Book a scoping call