From Design to Product: What a Design Background Actually Gives You as a PM

A wireframe cannot contain a vague requirement

You can write "the user reviews their policy details" in a document and everyone will nod. You cannot draw it. The moment you open Figma you have to decide which fields appear, what happens when one is missing, what the empty state says, and where the user goes if they disagree with what they see.

That habit carried straight into product. Every PRD I write now, and I've written 20+ across our three platforms, gets stress-tested the same way a screen does: what's on it, what's missing, what breaks. Ambiguity survives in prose. It dies in a layout.

Cognitive load is a product metric, not a design one

When we redesigned the Letsurety application journey, the goal wasn't a prettier form. It was to reduce how much a customer had to hold in their head to get through it. The outcome was that a single application could return up to five insurance quotes instead of sending someone through the process five times.

That's a business result that came out of a design question. Insurance is full of these. The complexity is real, it's regulatory, and you can't delete it, but you can decide who carries it. Good product work in this space is mostly about moving complexity off the customer and into the system.

Designers already know how to be told no

The part of design that prepared me most for product management was the review cycle. You put work in front of engineering, business, and clients, and you defend it or you change it. You learn quickly that the strongest version of your idea is the one that has already survived three people trying to kill it.

Stakeholder alignment as a PM is the same loop with higher stakes. When I led the HDFC Motor Insurance integration, half the work was defining rollover, break-in, and used-car journeys, and the other half was getting business, engineering, and the insurer to agree that those definitions were the ones we'd build.

What design doesn't teach you

It doesn't teach you to say no to good ideas. Designers are trained to explore; PMs are trained to cut. That was the hardest adjustment. A roadmap isn't a list of things worth doing, it's a list of things worth doing *now*, and everything you add pushes something else out.

It also doesn't teach you APIs. I had to learn to read a Swagger spec, understand what a payload can and can't carry, and write acceptance criteria an engineer doesn't have to translate. That's the part where design ends and product begins.

If you're a designer thinking about the move: you're closer than you think. You already know how to sit between users, business, and engineering. You just have to start being accountable for the outcome, not the artefact.