What a Discovery Workshop Actually Looks Like

The $1,500 spend, demystified. A composite founder walks through a real Discovery Workshop hour by hour — including the moment three features got cut, scope dropped from $58K to $34K, and the change request process replaced anxious Slack messages.

Why This Article Exists

The Discovery Workshop is the single most consequential interaction in the EB Pearls engagement — and the one most prospects are nervous about. "What happens in there? Is it just a sales call? Why $1,500 when other agencies offer free scoping?"

This guide answers those questions by walking through a real workshop hour by hour. You will see exactly what happens, what decisions get made, what gets cut, and what gets locked. If after reading this you decide the workshop is not for you — that is useful information. We would rather you skip a workshop you do not need than book one that disappoints.

A note on Theo: Theo is a composite character drawn from patterns we have observed across hundreds of Discovery Workshops. The product, decision moments, scope cuts, and outcomes described here reflect real scenarios — compressed into a single narrative.

Theo's Workshop: From $58K to $34K in Six Hours

Before the Workshop: Who's in the Room

The room matters. Too many people slows decision-making; too few removes essential context. We aim for 6-8 total — 3-4 from each side.

Hour 1 (9:00–10:00 AM): Context and Problem Framing

What Happens: The Founder Tells the Story

The first hour is yours. You present the problem, the user, the current solutions you have observed, and the business model. The team listens — and asks structured questions to test the depth of your understanding.

This is not a sales presentation. It is a problem interrogation. By 10:00 AM, the team should be able to describe your user better than you can — because they have asked the questions you have stopped asking yourself.

Whiteboard — Hour 1 Outputs

THE PROBLEM
→ Independent breweries waste 4-6 hrs/week on manual inventory tracking
→ Excel spreadsheets break at multiple location count
→ Suppliers email order forms; brewers re-enter data manually

THE USER
→ Head brewer (35-55 yrs, often founder of brewery)
→ Manages 1-3 venues, 8-25 staff, 50-200 SKUs
→ Already uses Xero for accounting, untappd for tap lists

THE BUSINESS MODEL
→ $149/month per venue (SaaS)
→ Theo has 4 pre-committed venues at this price

Decision moment: The strategist asked Theo: "What evidence do you have that brewers will pay $149/month?" Theo had pre-commitments from 4 venues — but only verbal. No paid deposits, no signed letters of intent. The strategist flagged this as a Riskiest Assumption: "Will brewers actually pay $149/month when the product is live, or only when it is free?"

Why this hour matters. Most agencies skip context. They take your feature list at face value and quote against it. The first hour of a real Discovery Workshop is about validating that the problem is worth solving and the user is worth building for — before anyone debates a single feature. According to IDEO's design thinking research, teams that spend 20-30% of project time on problem framing ship products with 2-3x better user-fit than teams that spend less than 10%.

Hour 2 (10:00–11:00 AM): User Flow Mapping

What Happens: Sticky Notes on the Whiteboard

Hour 2 is whiteboard time. The designer maps the complete user journey from first awareness to repeat engagement, using sticky notes for each touchpoint. You add what they miss. They add what you skipped.

This is where assumption gaps appear. Theo had assumed brewers would "obviously" want to scan barcodes for stock counts. The strategist asked: "What percentage of small breweries have barcode scanners?" Theo did not know. He had assumed 80%+. The designer mapped the alternative flow (manual stock entry) and tagged it as a parallel path until validated.

Whiteboard — User Flow Map (Brewer Journey)

[Awareness] hears about app from supplier rep
↓
[Sign-up] downloads, creates account (Stripe billing)
↓
[Onboarding] imports current inventory from Excel (CSV) ← FRICTION RISK
↓
[Daily use] stock count → ?? barcode scan OR manual entry
↓
[Reorder] auto-suggests reorder amounts → emails supplier
↓
[Retention] weekly waste report → cost-saving insights

OPEN QUESTIONS

→ % of breweries with barcode scanners?
→ CSV import — what column format do 
→ Supplier integration — manual or via API? 

Decision moment: The user flow surfaced two friction points Theo had not considered: the CSV import format (every brewery uses different column structures) and the supplier integration question (some suppliers have APIs, most do not). These would become design challenges in v1.

Hour 3 (11:00 AM–12:00 PM): Feature Inventory and Ruthless Prioritisation

What Happens: Every Feature Gets Debated

Hour 3 is the hour the workshop earns its fee. Every feature on the founder's list goes on the wall as a sticky note. Each one is debated. Each one is categorised: v1 must-have, v2 should-have, or cut entirely.

This is also the hour most founders find uncomfortable. We are about to tell you that features you have been planning for months are not worth building. Some founders push back. Some agree immediately. Theo did both — and almost walked out.

Whiteboard — Theo's 11 Features, Categorised

V1 MUST-HAVE (4 features)
✓ Inventory list with stock counts
✓ Manual stock adjustments (with barcode scan as enhancement)
✓ Reorder suggestions based on usage
✓ Stripe billing

V2 SHOULD-HAVE (4 features)

→ Multi-venue support
→ Supplier API integration
→ Weekly waste reports 
→ Xero integration support

CUT ENTIRELY (3 features)
✗ Recipe management ← THEO'S "HERO FEATURE"
✗ Customer-facing tap list
✗ Social media auto-posting

The Hero Feature Trap. Almost every founder has a "hero feature" — the differentiator they have been thinking about for months, the thing that will make their product special. In approximately 60% of Discovery Workshops we run, the hero feature is in the "cut entirely" or "defer to v2" category. Not because it is a bad feature. Because the riskiest assumption to test first is rarely the differentiator — it is the core. Theo's hero was recipe management. Priya's hero feature was the meal-plan customisation algorithm. Suki's hero feature was the AI tutor. In each case, the hero was deferred to v2. In each case, the v1 succeeded without it.

Decision moment: By 12:00 PM, Theo's list had gone from 11 features to 4 in v1 + 4 deferred + 3 cut. The estimated build cost dropped from $58K to approximately $34K. The strategist drew a line on the whiteboard: "This is your MVP. Anything else is a change request after launch."

Hour 4 (12:00–1:00 PM): Lunch + Riskiest Assumption Test™

What Happens: The Single Most Important Question

After a 30-minute lunch break (which is often where the most candid conversations happen), the team identifies the Riskiest Assumption Test™. This is the single assumption most likely to make or break your product. The MVP is designed to test it first.

Whiteboard — Riskiest Assumption

CANDIDATE 1: "Brewers will pay $149/month for inventory tracking"
→ Validated partially by 4 pre-commitments, but not paid deposits

CANDIDATE 2: "Brewers will use the app daily, not just once a week"
→ Critical for retention. If they only use it weekly, churn will be high.

CANDIDATE 3: "Brewers will input stock manually if barcode scanning is unavailable"
→ Without this, the product is unusable for ~60% of brewers without scanners.

RISKIEST: Candidate 2 — Daily use
→ If brewers use it weekly, retention drops below 50%, business model breaks
→ MVP designed to measure daily-active-use as the primary success metric

Why this matters: The Riskiest Assumption shapes the MVP. The success metric is no longer "does it work?" — it is "do brewers use it daily?" Analytics are instrumented around daily active use. The onboarding is designed to create daily habits. The 30-day post-launch review measures DAU/MAU, not just downloads.

Built to Last™ — P01: The Right Problem. The Riskiest Assumption Test™ is how P01 enters the build phase. It transforms "build the product" into "test the assumption that makes the product viable." If the assumption fails, you have lost 8 weeks — not 8 months. If it succeeds, every subsequent investment is grounded in evidence. Kai's $3K experiment that saved $38K is the framework in action.

Hour 5 (1:00–2:00 PM): Architecture and Technology Decisions

What Happens: Technology Decisions Made Quickly

This is the hour the senior engineer takes the lead. Technology recommendations are made in plain language, with the reasoning visible. You do not need to understand the code — you do need to understand the trade-offs.

Whiteboard — Technology Recommendations

PLATFORM: Cross-platform (React Native)
→ 62% iOS / 38% Android among target users
→ Cross-platform saves $14-18K vs dual native
→ No performance-critical features

BACKEND: Node.js + PostgreSQL on AWS
→ Proven, scalable, well-documented
→ No exotic database needs (relational data fits PostgreSQL)

AI: Defer to v2
→ "Smart reorder suggestions" can be rule-based in v1
→ AI/ML adds $9K with marginal value at current data scale
→ Architecture allows AI integration later without rebuild

ARCHITECTURE: Modular monolith
→ MVPs do not need microservices
→ Modular boundaries allow service extraction later if needed

Decision moment: Theo had assumed he needed native iOS (his target users "expected premium feel"). The engineer asked: "What proves that?" Theo had no evidence. The cross-platform decision saved $14K. The deferred AI decision saved another $9K — and the architecture decisions ensured both could be revisited later without rewrites. Anika's $25K tech-decision mistake is the cautionary tale of what happens when these decisions are made without discovery.

Hour 6 (2:00–3:00 PM): Timeline, Milestones, and Locked Scope

What Happens: The Locked Scope Document Takes Shape

The final hour translates the day's decisions into a structured timeline with milestones, demo cadence, and the formal change request process. The strategist drafts the Locked Scope Document outline on the whiteboard; the full written document arrives within 5 business days.

Whiteboard — Theo's 10-Week Sprint Plan

WEEK 1-2: Setup + design
→ Architecture, design system, account/auth flows
→ MILESTONE: Working sign-up + Stripe

WEEK 3-4: Sprint 1
→ Inventory list, manual stock adjustments
→ MILESTONE: Founder demo, friction-point feedback

WEEK 5-6: Sprint 2
→ Reorder engine (rule-based), basic email-to-supplier flow
→ MILESTONE: 2 pre-committed brewers tested

WEEK 7-8: Sprint 3
→ Analytics (12 events), edge cases, error handling
→ MILESTONE: All 4 brewers tested

WEEK 9: Testing + Production Readiness Review
WEEK 10: Launch + post-launch monitoring

The change request process: The strategist explained that any scope change after the Locked Scope Document is signed becomes a formal change request — written, priced, approved before work begins. "If you Slack us at midnight saying 'can we also add X?', the answer is 'send the change request and we will price it.' Not because we are rigid. Because uncontrolled scope is the leading cause of project failure."

The Locked Scope Document is yours. By the end of Hour 6, you have a verbal commitment. Within 5 business days, you receive: (1) the user flow map, (2) the feature priority matrix, (3) the Locked Scope Document, and (4) the Fixed-Price Proposal. If you decide we are not the right partner, you keep all four. The Locked Scope Document is yours to take to any agency. We do not own it. You paid for it.

Theo's Second Lesson: The Change Request Process Tested

Why the Change Request Process Exists. Uncontrolled scope is the leading cause of project failure. According to the PMI Pulse of the Profession report, scope creep affects 52% of projects globally — and is the second-largest cause of project failure after inadequate requirements. The Change Request Process is not bureaucracy. It is the discipline that prevents the project from drifting from $34K to $58K through 14 "small additions" that nobody wrote down. Every change request gets evaluated, priced, and either approved or deferred — visibly, formally, traceably.

What You Get for $1,500

This is the question every prospect asks: "Why $1,500 when other agencies do scoping for free?"

The financial incentive matters. An agency offering free scoping has a structural incentive to add features and inflate scope — because they only make money if you sign the proposal. A paid Discovery Workshop reverses this: we already have your $1,500. Our incentive is to produce the most accurate scope possible, including telling you to cut features. Mistake #4 in the developer selection guide — "no discovery process before coding" — costs founders $15K-$40K when agencies skip discovery to win deals faster.

The take-it-anywhere test. Here is the most candid promise we make: after the workshop, you can take the Locked Scope Document to any other agency in Sydney and get a competitive quote against it. We will not be offended. If a competitor builds your product better or cheaper using our scope document, that means we did our job. We would rather lose a deal to the right partner than win one and disappoint. The workshop has paid for itself either way.

Founder FAQ

The Founder's Edge

Theo arrived at the workshop with 11 features and a $58K budget. He left with 4 features, a $34K budget, a written scope document, and the clearest understanding of his own product he had ever had. The hero feature he had been planning for 6 months went on the cut list — and the v1 succeeded without it.

The $1,500 workshop fee is the smallest investment in the entire build process. It is also the highest-leverage. Every subsequent dollar — design, development, testing, launch — is spent more accurately because the first $1,500 was spent on getting the scope right.

The founders who waste $20K-$60K skip discovery. The founders who save it pay $1,500 for six hours of structured debate with people whose job is to tell them what to cut. The workshop is not a sales call. It is the work that prevents the wrong work.