Live discussion guide
Talk through Magnet without turning the meeting into homework.
Use this while the room talks. Tap milestones when the group has covered, locked, parked, or rejected the point. The recording can carry the details later.
The goal is not to fill in fields. The goal is to leave with enough shared clarity for a visual prototype brief.
0
/ 0 covered
Start with the thesis, then move only as deep as the conversation needs.
covered
locked
parked
Jump to section
Orientation
Flow
Conversation
Screens
Rules
Parking lot
Continue or rethink
Close
Guide path
Orientation Flow Conversation Screens Rules Parking lot Judgment Close
Orient the room around one loop.
Magnet works when the buyer want creates qualified seller action. Keep every decision close to that loop.
Prototype standard: can someone understand the buyer want, matched item, seller offer, and buyer response without a long explanation?
First
Agree on the thesis Buyer-intent marketplace, not swipe shopping.
Then
Pick one story One buyer, one want, one seller, a few sample items.
Always
Protect the boundary No live payment, no broad marketplace operations, no future feature sprawl.
Use a loose meeting flow.
Move through the path, but do not force every question if the decision is already clear.
5 min
Reset the purpose This is a visual proof-of-concept meeting.
10 min
Define Magnet Choose the sentence a tester should remember.
15 min
Choose the story Lock the category, want, seller, and sample items.
25 min
Walk the screens Buyer path, seller path, and visible rules.
15 min
Set the tone Decide what the app should feel like and avoid.
10 min
Judge the next step Name continue signals, rethink signals, and owners.
Guide the talk with a few real decisions.
Each block has one natural prompt and a small set of milestones. Tap only what meaningfully changes the prototype brief.
Define Magnet
Every screen depends on the product thesis.
If someone sees the prototype for 30 seconds, what should they think Magnet does?
Is the buyer want still the center?
Is the seller value qualified demand?
Should the prototype avoid visible "Tinder for shopping" positioning?
Product thesis is sayable The room can explain Magnet without defaulting to swipe shopping. Buyer promise is clear Set what you want and let it find you. Seller value is clear Qualified buyer interest beats random traffic. Positioning guardrail is named The prototype should not read as a generic marketplace with swiping.
Choose the story
A prototype needs one clean example.
Whose problem are we showing, and what are they trying to find?
Should watches stay the primary story?
What must-have and dealbreaker details matter?
Why is this easier than checking marketplaces manually?
Category is locked Watches stay first, or the replacement category is explicit. Buyer want is specific Budget, condition, must-haves, and dealbreakers are concrete. Seller example exists One seller has enough inventory to make the offer moment believable. Sample items are named Three to five listings can carry the whole walkthrough.
Set the visual tone
This is direction for mockups, not final brand identity.
If we generate app screens, what should they feel like in one glance?
Collector tool, clean marketplace, shopping assistant, or social app?
Calm and trustworthy, or playful and swipe-heavy?
What should the product absolutely avoid looking like?
Three tone words are locked Suggested: simple, trustworthy, intent-driven. Magnet cues are intentional Navy, red, and blue are brand energy, not decoration everywhere. Anti-references are named The team knows what would make the prototype feel wrong. Trust level is set The interface should feel safe enough to show seller contact.
Agree on screens before anyone designs.
The first prototype should show both sides because the seller offer moment is what makes Magnet more than saved search with cards.
Buyer path
Welcome: "Set what you want. Let it find you."
Create Want: category, budget, must-haves, dealbreakers.
Wants: active wants and match counts.
Matches: matched items with reasons.
Match Detail: photos, price, seller, Interested action.
Interest Confirmation: clear note that this is not a purchase.
Offer Response: accept intent, counter, decline, ask a question.
Chat: conversation tied to one item and offer.
Seller path
Sell Dashboard: listings and interested buyers.
Listing Detail: item information and matched wants.
Buyer Lead: why this buyer is a fit.
Offer Composer: price, note, expiration, shipping note.
Seller Chat: conversation after interest or offer.
Trust Action: block, report, revoke access.
Buyer path is enough The group can walk it without backend explanation. Seller path proves the loop The seller has a reason to respond to demand. Offer moment is visible The prototype shows what happens after buyer interest. Screen scope is stable No extra pages are needed to judge the core loop.
Make trust rules impossible to miss.
These are comprehension safeguards. If testers misunderstand them, the prototype is not ready to judge.
Interest is not purchase Interested means the buyer wants to hear from the seller.
Seller contact is gated Seller offers unlock only after buyer interest.
Offers are no-money Accepting an offer is intent inside the mockup, not checkout.
Chat has context Each conversation stays tied to one item, one want, and one offer.
Buyer can stop contact Block and report controls must be visible enough to build trust.
Match reasons matter Cards should explain why an item appeared.
Contact rule is locked Seller cannot cold-message buyers in the prototype. No-money boundary is locked The prototype avoids implying checkout or payment protection.
Keep future work out of the room.
Park anything that does not help judge the buyer want to seller offer loop.
The phrase to keep using: does this matter for a simple visual proof of concept?
Real checkout, payment provider choice, escrow, refunds, and insurance.
Shipping labels, returns, taxes, and live marketplace operations.
Full account settings, admin tooling, and moderation workflows.
Multi-category marketplace breadth beyond the chosen example.
AI assistant branding, premium plans, or monetization packaging.
Final legal structure, ownership, equity, or patent decisions.
Payments are parked Only prototype language is discussed. Marketplace breadth is parked The first prototype stays narrow enough to judge.
Decide what would make the idea worth continuing.
A pretty prototype is not enough. The team needs a shared standard for what reaction justifies the next round.
Continue if
The buyer want feels easier than saved searches.
Match cards feel relevant and explain themselves.
The seller offer moment feels useful, not spammy.
The no-payment boundary is clear.
The prototype creates a real "I want to see more" reaction.
Rethink if
The concept only feels interesting because of swiping.
The seller side feels weak or unnecessary.
The buyer cannot tell what happens after showing interest.
The app feels unsafe, scam-prone, or too vague.
The product reads as a generic marketplace with a swipe layer.
Continue signals are named The team knows what positive reaction matters. Rethink signals are named The team knows what would invalidate this direction.
Close with a clear recording, not a form.
Before ending, read back what feels locked, what is parked, who owns the next artifact, and which docs should receive the transcript synthesis.
The meeting is successful when someone can commission one coherent visual prototype without re-litigating the core idea.
Readback happened Locked, parked, rejected, and owner-assigned decisions were said aloud. Next owner is named Prototype brief, visual build, and transcript synthesis have owners. Canonical docs are named The team knows where the synthesized updates should land. Stop condition is clear If a topic does not change story, screens, rules, or tone, it stays parked.