I spent the first few years of my career thinking my job was to make things look good and work well. That was it. Design the thing, hand it off, repeat.
Then I worked with a PM who kept asking me questions I couldn’t answer. “Why does this matter to the business?” “What happens if we don’t build this?” “Who are we actually solving for here?”
I didn’t have answers. And that bothered me.
Principal designers sit at a different level than most people expect. You’re not just the most senior person making screens. You’re shaping what gets built, what gets prioritized, and sometimes what gets killed. That requires thinking well beyond the design.
I remember a roadmap review where a feature I’d spent weeks on got cut. My first instinct was frustration. But when I actually listened to the business reasoning, I realized the feature solved a problem that wasn’t hurting us the way I thought it was. The PM had context I didn’t have. That was on me.
After that I started showing up to those conversations differently. I asked “why are we doing this?” before I touched anything. I tried to understand what the product was measured against — not just user satisfaction, but revenue, retention, whatever the business actually cared about. I treated roadmap conversations as design conversations. Because they are. What doesn’t get prioritized doesn’t get built. That’s a design outcome too.
None of this means you stop designing. It means you understand the full context your work lives in. That context is what separates a principal designer from a very good senior designer.
The best PMs I’ve worked with think like designers. The best principal designers I know think like PMs. That’s not a coincidence.