Every PM Has a Vision.
The Hard Part Is Making It Visible.

The Ticket-Writing Trap

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.

A luxury handbag is not a single product. It is 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.

See the Difference

Below is a traditional luxury PDP: dropdown menus, spec tables, a static image. Then the configurator I built. Same product, same components. A completely different way of shopping.

How I Actually Built This

Three rounds. One session. Every prompt below is real.

Round 1: "It works. Nobody would buy from it."

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 are designing something.

Round 2: "Now it feels like something worth $3,200."

Round 3: "The details that create confidence."

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.

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.

The prototype replaced none of their work. It gave everyone a shared starting point.

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 is the entire gap.

The question is not whether PMs should learn to build. The question is whether you are willing to show your vision instead of just describing it.