Stop Hiring a Two-for-One Unicorn - ProductFTW #72

Now that I’ve written a post about the difference between product, program and project roles, I’ve started to notice how many job postings blur the line between a product owner (PO) and a product manager (PM). Titles aside, what these companies actually want is both: someone who can get in the trenches with engineers and write pixel-perfect tickets and someone who can define the long-term product strategy, talk to users, and steer the roadmap.

That’s not a product owner. That’s not a product manager. That’s a unicorn.

If you’re lucky enough to find one, they’re going to be expensive. So how do you know which one you need?

Ask yourself:

• Am I struggling to define what to build and why it matters?
  • You need a product manager.
• Do I have a clear roadmap, but struggle to move efficiently from idea to shipped product?
  • You need a product owner.
• Am I early-stage and can’t afford both?
  • Fine, but know what you’re asking for. You need someone senior with experience in both, someone who is comfortable bouncing between tactics and strategy. Most importantly, you need to give them the support to do it all without burning out.

If you’re not sure what your primary pain point is, you’re not ready to hire. Get clarity on where the bottleneck is. You don’t want to end up with someone great at roadmap planning who’s stuck chasing down tickets, or vice versa.

What Companies Think They Want

Let me describe the role I see posted over and over again.

• Own the backlog
• Run standups
• QA new features
• Write user stories and acceptance criteria
• Be the voice of the customer
• Define the product strategy
• Conduct user research
• Collaborate with design
• Prioritize work against business goals
• Report on KPIs
• Align stakeholders

In other words, be a PM, a PO, a designer, a researcher, a business analyst, a scrum master, and a QA tester all in one person.

To be fair, this is often what early-stage startups need. They don’t have the headcount for separate roles. They need someone who can go deep and go wide. Someone who can write the tickets, manage delivery, and think big at the same time.

Unfortunately, it’s not sustainable unless you find someone with two very different skill sets. Someone who knows how to timebox. Someone who doesn’t get overwhelmed when juggling competing priorities. Someone who is equally comfortable writing SQL and talking to customers. That person exists, but there aren’t many of them, and they aren’t cheap.

What a Product Owner Does

Let’s be clear. A traditional product owner is a delivery role. It’s focused on execution. They live close to the engineering team, and their day-to-day is about translating ideas into buildable, testable chunks.

Typical product owner responsibilities:

• Maintain the backlog
• Refine tickets
• Write user stories and test cases
• Make tradeoffs with engineering
• Accept or reject completed work
• Help with UAT and QA
• Unblock devs

They’re essential in organizations where the PM is more outward-facing. Especially when PMs don’t have the time or patience to get deep into implementation details. POs make sure the dev team keeps moving. They’re not usually doing customer interviews or prioritizing the roadmap based on business objectives. They’re focused on what’s next, not what’s next quarter.

A good example of when a PO shines: an engineering team mid-sprint hits an ambiguous edge case in a transaction flow. Nobody knows what the expected behavior should be. The PO steps in, makes the call, updates the acceptance criteria, and the team keeps moving. They don’t pause to conduct a customer discovery session or update the strategy doc. They make a fast and informed decision so the sprint doesn't stall.

What a Product Manager Does

On the flip side, product managers are meant to own outcomes. They’re responsible for figuring out what to build, why it matters, and how to align it with user needs and business goals.

Typical PM responsibilities:

• Set product vision and goals
• Define and manage the roadmap
• Talk to users, stakeholders, and execs
• Write product briefs
• Define success metrics
• Prioritize features based on impact
• Work with design to shape the solution

Can a PM write tickets and run standups? Absolutely. Many of us have done that, especially in small teams. Unfortunately, not every PM wants to do that, and not every PM is good at it. The bigger point is, it’s a different job. The skills that make someone a strong strategic thinker are not always the same ones that make them detail-obsessed and delivery-focused.

A good example of when a PM shines: a new card program is seeing strong top-of-funnel interest, but applications aren't converting. A PM digs into the data, talks to users, and realizes people are abandoning the flow because they don't want to risk a hard pull on their credit if they're not confident they'll get approved. They write the brief, align leadership, and hand it off to design and engineering to build a pre-qualification flow. That's the main job, figuring out what's worth building and why.

The Two for One Trap

Here's the problem. If you're hiring for a product manager and you really want a PO-style delivery partner, you'll get someone who can help your dev team ship, but they probably won't help you define a long-term strategy. If you hire a PM and expect them to own the tickets too, you might get pushback, or worse, half-baked delivery work because they're focused on higher-level outcomes.

A scenario that plays out more than people admit: a startup hires a strong strategic PM, someone with great instincts, sharp prioritization skills, and executive presence. Six months in, the engineering team is frustrated. Tickets are vague. Sprints are chaotic. The PM is doing brilliant roadmap work, but nobody has refined the backlog, and the devs are constantly waiting for clarity. The company assumes the PM is underperforming. In reality, they hired the wrong role for the problem they had.

The reverse happens too. A company hires an execution-focused PO who is incredible at running clean sprints and keeping the team unblocked. A year in, leadership is frustrated because there's no clear product direction. Features are shipping, but there's no coherent strategy tying them together. Again, not a performance problem. A role definition problem.

The two-for-one is a great deal if you can find the right person. Most people lean heavily toward one side. Either they're the planner and strategist type who can wrangle execs and define big bets, or they're the execution-focused doer who loves being on Slack with the engineering team all day, making sure tickets are airtight.

Let's be real. Context switching between those modes is intense. It's not just task switching. It's brain switching. You go from writing a product strategy memo to hopping into Figma comments to catching a regression bug in staging. That's a lot of mental load. If you're not careful, you end up being mediocre at both jobs.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.

Part of the Product Management Leadership & Career Guide — ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.