Every PM has a vision. The hard part is making it visible.
I built a working luxury configurator in one session with AI. Here’s the problem it solved, the prompts behind it, and why this way of working matters.
Every PM has written this ticket: “Improve PDP experience. Shoppers confused by configuration options. Consider guided selection. P2.” It enters a backlog. Six weeks later, someone adds a carousel. Conversion barely moves. The ticket did its job. The product didn’t.
The ticket-writing trap
A luxury handbag isn’t a single product. It’s a silhouette, a leather, a hardware finish, and a personalization. Four choices that need to work together. But the product page treats them as a static SKU with dropdowns labeled “Noir Desire” and “Sahara Dreams.” The shopper is about to spend $3,200, and the page gives them less guidance than a fast food kiosk. The shopper has to become the integrator.
No ticket captures that problem clearly enough for a team to solve it well. The frustration is real but abstract. So I opened Claude and described a different approach: a configurator where the shopper builds their bag step by step, with a live visual that updates after every selection. One session later, I had a working prototype.
A ticket describes what should change. A prototype shows what it feels like when it does.
See the difference
Below is a traditional luxury product page: dropdown menus, spec tables, a static image. Then the configurator I built. Same product, same components. A completely different way of shopping.
The traditional page presents a static product and refers you to a “Client Advisor” when you’re confused. The configurator builds your bag alongside you. Four components, zero jargon. The shopper never had to decode “Ruthenium-Finish Metal (RHW).” They chose a shape that fit their life, a leather they could almost feel through the screen, hardware that matched, and a personal touch.
The prototype surfaced things that would have stayed theoretical in a requirements document. The step sequence broke one page into a few clear choices, which I expected to ease decision anxiety. The live preview made configuration feel like a creative act rather than data entry. The cross-sell strip matched accessories to the shopper’s selections, so add-ons could feel curated rather than pushed.
None of this proves a business outcome. What it does is compress the first learning loop. The questions that matter became visible in the same session the prototype was built: Does the step sequence work? Does the live visual reduce anxiety? Does cross-sell feel natural or forced?
How I actually built this
Three rounds. One session. Every prompt below is real.
Round 1: “It works. Nobody would buy from it.”
Prompt · Round 1
Build an interactive luxury handbag configurator for a fictional brand called Maison Aurel. The Sélène Bag collection. Shopper builds their bag piece by piece: Silhouette (Mini/Classic/Tote) > Leather > Hardware Finish > Personalization. Show a live visual that updates with each selection. Component pricing. Dark UI, high-end feel.
What came back: a working configurator with radio buttons and a grey box where the bag should be. Functionally correct. Looked like a SaaS product. Nobody spending $3,000 would trust this page.
This is what happens when you describe features instead of an experience. A shopper spending $3,200 doesn’t want a configurator. They want to feel like they’re designing something.
Round 2: “Now it feels like something worth $3,200.”
Prompt · Round 2
The visual needs to be a real SVG illustration of a handbag that updates: body and flap color change with leather selection. Clasp and chain color change with hardware. Bag shape changes with silhouette (mini is smaller, tote is wider/taller). Add quilted stitch lines for texture.
Replace radio buttons with tactile swatches. Leathers should be orbs with realistic gradients. Hardware should be metallic circles. Personalization should show icons with descriptions.
Accordion steps, not all visible at once. Gold checkmark on completion. Price builds component by component.
The AI didn’t decide to use an SVG bag illustration. I did, because luxury buyers need to see what they’re creating. The AI didn’t sequence leather before hardware. I did, because leather is the emotional anchor. The AI built the interface. I designed the decision architecture.
Round 3: “The details that create confidence.”
Prompt · Round 3
Three refinements:
1. Build summary at the bottom: every component, its name, individual price. Think of it like the bespoke order confirmation at a luxury atelier. The shopper should feel like they designed something, not just selected options.
2. Personalization should be visible on the bag. Monogram shows initials on the body. Scarf charm appears tied to the strap. Chain upgrade makes the strap visually longer.
3. Collection hero above the configurator with editorial serif typography. The shopper should feel like they landed on something curated by a creative director, not a product page.
The build summary turns “I configured something” into “I designed something and I understand exactly what I’m getting.” In luxury, the purchase is emotional. The summary makes it tangible.
Round 1 described features. Round 2 described experience. Round 3 described emotional outcome. That progression is the point. Your prototype is only as sharp as the product thinking behind the prompt.
The AI is the tool. The product thinking is the craft.
Navigating the dynamics
Building the prototype is the easy part. The harder question is how to use it without stepping on the teams whose craft brings it to production.
A prototype is a conversation starter. It gives every team the same thing to look at and pressure-test before anyone invests significant time. Without one, the PM writes a PRD, engineering pictures one thing, design pictures another, leadership pictures something else. The misalignment surfaces weeks later. A rough prototype makes the right questions visible earlier.
Once alignment happens, the prototype steps into the background. What follows is the process your organization already has in place.
Product operating model
Where prototyping lives: one tool inside Discovery. Every other phase stays exactly as it is.
- IdeationIdentify signals, pain points, and opportunities. Frame hypotheses worth exploring.
- DiscoveryResearch, prototype, align. The prototype lives here, as a conversation starter that brings clarity before committing resources.Prototype lives here
- DefinitionPRD written with shared context. Design specs and sprint planning grounded in what the team already aligned on.
- DevelopmentBuild, test, iterate. Technical gaps already found in Discovery. Fewer surprises, fewer rework cycles.
- Go-liveLaunch, measure, learn. The team ships with conviction because every phase started from shared understanding.
Inside Discovery: the teams align on the same thing
- UX and designLead the experienceApply research, craft, and expertise to shape the final product. The prototype is raw material for their process, not a constraint on it.
- EngineeringEvaluate feasibilityFlag risks and technical gaps early: “this part is straightforward, but that part needs an API we don’t have.” Conversations from sprint three now happen in week one.
- BrandGuide the identityThe prototype doesn’t set the visual direction. The brand team does, and their guidance brings the concept closer to home.
- LeadershipValidate directionDoes it match the outcome you expect? If yes, the team moves with shared conviction. If no, the course correction cost hours, not months.
The prototype replaced none of their work. It gave everyone a shared starting point.
The value of a prototype isn’t the prototype itself. It’s the clarity it creates before the organization commits resources.
Show it. Don’t describe it.
Every PM has a vision for how the product should work. The difference is whether anyone else can see it early enough to improve it. Not in a slide. Not in a ticket. In something they can touch, click, and react to. The configurator you just used exists because one PM opened a chat window and described what the shopping experience should feel like. That’s the entire gap.
The question isn’t whether PMs should learn to build. The question is whether you’re willing to show your vision instead of just describing it.
Your turn. Pick one problem your team has been debating in documents. Build a prototype. Share a URL instead of a slide.
First published in Skipper’s Field Guide, March 2026. Maison Aurel and Sélène are fictional; prices are illustrative.
