There’s a moment in every designer’s career when they realize the job isn’t just about making things look good ... it’s about making things work and be useful. I think that moment often hits you when you’re staring down a product roadmap of half-formed ideas. You are sitting there, trying to figure out what’s actually worth designing and how to approach it. It's in that moment that thinking like a product owner becomes not just helpful, but part of your career growth.

Moving Beyond the Interface

Product owners live at the intersection of the business, user needs, and technical feasibility. And honestly, good designers should too.

That doesn’t mean every designer needs to become a PM, or start writing Jira tickets. But it does mean shifting from a focus on features and screens to a focus on outcomes. When you start thinking in terms of user value, KPIs, market differentiation, engineering impact, and delivery timelines, your design decisions start carrying more weight throughout the org ... and getting more buy-in (every designer likes easier buy-in).

Why This Matters

Thinking like a product owner turns design from just a service into a full-blown partnership.

Designers who understand the broader context often earn more trust from engineering and the larger product teams. You become the person who’s not just pushing pixels, but doing so with purpose and understanding. But what does this mean? It means asking better questions: (this list is not exhaustive)

• What problem are we solving? (and why?)
• What’s the business impact? (and why?)
• How will we measure success?
• What are the engineering impacts of my work?
• Is this the right thing to build ... or is it just the next thing on the list?

When you start designing with questions like this in mind, you’re not just making it usable. You’re making it valuable.

Shifting Your Mindset

Thinking like a product owner isn’t about abandoning your design instincts. It’s about complementing them with a few new muscles.

Here are some mindset shifts I’ve found helpful:

• Outcomes first: Instead of the “how should this button look?” ask “what action are we trying to encourage here?”
• Progress over polish: Sometimes shipping a solid v1 is more important than a perfect v1. Know when to go deep and when to move fast. Start to understand how you can take on chunks of a larger vision and still solve problems for the user and business.
• Value first, beauty over time: A gorgeous interface is meaningless if it doesn’t solve a real problem. This was hard for me, as someone that grew up in my career during skeuomorphism, utility is the priority ... the magic and beauty can follow.

From the Field

On one healthcare project (sorry no names), the product team handed us a long list of “must-have” features. But once we mapped them to patient and provider pain points, we found major gaps ... and several “nice to haves” that didn’t map to anything. By reframing the conversation around outcomes and patient journeys, we helped re-scope the MVP and launch something smaller, faster, and far more useful out the gate. That only happened because the team stepped up to ask the same questions the product owner should have been asking the stakeholders. This isn't a shot at that person, it's just oversight and by having a team looking across those journeys and thinking like a product owner, only helped improve the product and helped that product owner on the next go around to dig deeper.

On another project, I worked with a designer who proactively brought usage data into design critiques. Instead of arguing subjective opinions, we were discussing user behaviors and business impact. That designer knew how to make an impact and helped raise up the rest of the team.

The Takeaway Here...

You don’t have to be a product owner, you're a designer. But the more you think like one, the more influence you’ll have ... and the better your work will be.

Designing in isolation leads to pretty things that look great on Dribbble, but doesn't move the needle. But when you step into the broader context of the product, you stop designing for yourself and stakeholders, and start designing with everyone. And frankly, that's when the real impact and magic happens.

Final note, I touched on it a little bit, the importance of considering engineering in your design process. That may be something I dig into further in another post, because at the end of the day one of my favorite disciplines on my teams to work with has always been engineering.

So, as always I'd love to hear from you. How has your experience shaped your approach to thinking like Product Owners as designers? Hit me up on LinkedIn!

Until the next volume, thanks for joining me. 
Andrew Preble