What Should You Bring to an MVP Discovery Workshop?
Most of the advice about MVP discovery workshops focuses on what happens once you’re in the room — the agenda, the questions, the tone. Less gets said about the ten minutes before that: what you should actually have open on your laptop, printed out, or sitting in a shared folder when the session starts.
This isn’t about the format of the workshop itself. For that, see what founders should expect walking into one or a session-by-session breakdown of what should happen once you’re there. This post is narrower and more literal: a packing list. What should be in front of you, physically or digitally, before the conversation starts.
None of it needs to be polished. A workshop is built to work with rough material — the mistake founders make isn’t showing up under-prepared with messy notes, it’s showing up with nothing at all and trying to reconstruct months of thinking from memory in real time.
Existing Research or Interview Notes
If you’ve talked to any potential customers, even informally, bring whatever you wrote down. That includes:
- Notes from customer or user interviews, however unstructured
- Survey responses, even a small batch
- Screenshots or summaries of relevant conversations, DMs, or emails
- Any waitlist sign-up data or expressed interest you can point to
The goal isn’t to prove your idea is validated. It’s to give the team something real to anchor the problem statement to, instead of working purely from your description of what you believe customers want. If you genuinely have none of this yet, that’s worth saying out loud at the start rather than improvising answers that sound more certain than they are.
Prior Wireframes or Sketches
Anything visual you’ve already made helps enormously, even if it’s rough:
- Napkin sketches or whiteboard photos
- Wireframes from Figma, Balsamiq, or similar tools
- Screenshots of apps you mocked something up in
- An old prototype, even an abandoned one
These don’t need to represent the final product. Their value is showing how you’ve already been thinking about layout and flow, so the workshop can build on that thinking instead of starting from a blank page — or gently redirect it if the sketches reveal assumptions worth questioning.
A Rough Budget Number
You don’t need a fixed, final figure, but you should have a range in mind before the session starts. Vague answers like “whatever it takes” or “as cheap as possible” don’t give the team anything to scope against. A number — even a wide one, even one you’re not fully committed to — lets discovery produce a scope that’s actually buildable within your constraints, rather than one that gets rebuilt from scratch later once real cost estimates surface.
A Must-Have vs Nice-to-Have Feature List
If you’ve already started listing features, sort them roughly into three buckets before the workshop:
- Must-have — the product doesn’t work without it
- Nice-to-have — genuinely useful, but the product survives without it at launch
- Later — a good idea for a future version, not this one
This doesn’t need to be final. Part of what a discovery workshop does is pressure-test exactly this sorting — some things you thought were must-haves usually get challenged. But arriving with a first pass saves time that would otherwise go to building the list from scratch in the room.
Brand Assets, If They Exist
If you already have a logo, color palette, font choices, or any existing brand guidelines, bring them along, even in unfinished form. This isn’t about finalizing visual design in a discovery session — it’s about giving the team context on tone and direction, so early design conversations aren’t happening in a vacuum. If nothing exists yet, that’s fine too; just be ready to say so.
Competitor Examples You Like or Dislike
Screenshots or links to two or three products whose look, feel, or specific features you admire — and one or two you specifically want to avoid resembling — are often more useful than a paragraph of written description. A concrete visual reference gets everyone aligned faster than trying to describe an interface in words.
Access to Any Existing User Data
If your product already has any users, even a small pilot group, bring access to relevant data: usage numbers, drop-off points, support tickets, or feedback threads. This is different from customer research notes — it’s live evidence of how real people are actually behaving with something that already exists, and it can reshape scope decisions in ways that opinions alone can’t.
The Workshop Packing List at a Glance
| Bring | Why It Helps |
|---|---|
| Customer research or interview notes | Anchors the problem statement to real evidence instead of assumption |
| Prior wireframes or sketches | Gives the team a starting point for flow and layout discussions |
| A rough budget number | Lets the team scope something that’s actually buildable within your constraints |
| Must-have vs nice-to-have feature list | Speeds up prioritization instead of starting the sort from zero |
| Brand assets (logo, colors, fonts) | Provides tone and direction context for early design conversations |
| Competitor examples you like or dislike | Gives a fast, concrete visual reference point |
| Access to existing user data | Grounds scope decisions in real behavior, not opinion |
What If You Don’t Have Everything on This List?
Most founders don’t walk in with all seven items, and that’s expected. A pre-launch idea with no users yet obviously has no usage data to bring. An idea that’s still purely conceptual might not have sketches or brand assets. What matters more than completeness is being upfront about the gaps. A good facilitator would rather hear “we haven’t validated this with real customers yet” than sit through the workshop treating an untested assumption as settled fact — the second version is what leads to expensive rework later.
If you’re still working out how ready your idea is before you even get to scheduling a workshop, it’s worth reading about what should happen before development starts in the broader discovery phase first, since some of what’s on this packing list is really an output of that earlier groundwork.
Bring What You Have, Not What You Wish You Had
The point of preparing for an MVP discovery workshop isn’t to arrive with a finished plan — if you had that, you wouldn’t need the session. It’s to arrive with enough raw material that the conversation can start from where you actually are, rather than from zero. Research notes, rough sketches, a budget range, a first-pass feature sort, brand assets, competitor references, and any existing data are the seven things worth gathering beforehand. Everything else — the hard prioritization calls, the trade-offs, the scope decisions — is what the workshop itself is for.
Ready to Walk Into Discovery Prepared?
MVPHUB runs structured MVP discovery workshops that turn your research, sketches, budget, and priorities into a scoped, buildable first release. Book a free consultation with MVPHUB to talk through what you have so far and what a discovery session with your team would actually look like.
Book a free consultation with MVPHUBFrequently Asked Questions
What should I bring to an MVP discovery workshop?
Bring any existing customer research or interview notes, prior sketches or wireframes, a rough budget number, a sorted list of must-have versus nice-to-have features if you have one, your brand assets, a few competitor examples you like or dislike, and access to any existing user data. None of it needs to be polished — raw notes are fine.
Do I need a finished feature list before the workshop?
No. A rough sort into must-have, nice-to-have, and later is far more useful than a fully ranked, finished list. The workshop exists partly to pressure-test and refine that sorting, not to rubber-stamp something you've already locked.
What if I don't have any customer research yet?
Say so plainly rather than improvising answers on the spot. A workshop can still run productively without formal research, but the facilitator needs to know upfront so they can plan around that gap and possibly flag where validation should happen before development starts.
Should I bring a budget number even if it's rough?
Yes. A rough range, even one you're not fully committed to, gives the team something real to scope against. Withholding it usually just means you get shown options that don't fit, which wastes the session's time.
What if I don't have brand assets yet?
Bring whatever exists, even if it's just a logo file or a couple of colors you're drawn to. If nothing exists yet, say that too — it just means visual identity becomes one more thing to figure out during or after discovery rather than something already settled.
Is it useful to bring competitor examples?
Very. Two or three products you like the feel of, and one or two you specifically want to avoid resembling, give the team a fast, concrete reference point that's often more useful than a page of written description.
What if my product doesn't have existing users or data yet?
That's normal for a pre-launch idea. If you do have any data — a waitlist, a spreadsheet of survey responses, even informal notes from conversations — bring it. If there's genuinely nothing yet, the workshop simply treats user assumptions as open questions to test rather than facts to build from.
How much should I prepare versus leave for the workshop itself?
Prepare the raw material — research, sketches, numbers, examples — but don't try to have every decision made beforehand. Sorting through open questions together is a large part of what the session is for; arriving over-prepared with everything locked can actually make the conversation less useful.
