It’s not all about conversion rate, secondary metrics matter

Most advice on optimisation still treats conversion rate like the scoreboard. It isn't. It's one signal, sometimes a useful one, but often an incomplete one that flatters weak decisions.

I've watched teams celebrate a lift in checkout completion while harming order quality, retention, or margin. The pattern is familiar. A variant gets more people through the door, everyone declares victory, and a few weeks later finance asks why revenue hasn't moved. That's why it’s not all about conversion rate, secondary metrics matter. If you lead product or growth, you need a broader view of success than a prettier dashboard line.

That broader view also exposes a common organisational problem. Teams blur the responsibilities of the Product Manager and the Product Owner, then wonder why strategy gets disconnected from execution. The PM and PO aren't interchangeable job titles. They operate at different altitudes, and that difference becomes obvious when you look at experimentation, business metrics, and decision-making under pressure.

Why Secondary Metrics Define Your Product's Success

The easiest way to challenge conversion-rate obsession is to look at what strong stores optimise for. In UK e-commerce, a Shopify UK benchmark report from 2024 found that top-performing stores achieved 25% higher revenue per visitor by optimising for AOV through upsell strategies, despite similar 2.5% to 3.2% conversion rates to industry averages, as discussed in this analysis of why conversion rate can mislead teams.

That should reset the conversation. If two stores convert at roughly the same rate, but one extracts more value from each visit, the better business isn't the one with the prettier conversion chart. It's the one with stronger economics.

What conversion rate hides

Conversion rate tells you whether people took a defined action. It doesn't tell you enough about:

• Order quality. A sale with a weaker basket can still count as a conversion.
• Revenue efficiency. Revenue per visitor often reflects business impact better than a bare completion event.
• Downstream behaviour. A user who converts once and never returns can make a test look stronger than it is.
• Audience quality. Lower-intent traffic can distort the metric in both directions.

A practical metrics discipline starts with selecting a primary outcome, then pairing it with guardrails and second-order measures. A useful primer on that mindset is Mastering Metrics for Product Managers, especially if your team still confuses activity metrics with outcome metrics.

For teams running experiments, this also changes how KPIs should be defined and measured. If your reporting still defaults to a single conversion event, it's worth reviewing how KPIs are measured across the journey rather than only at the last click.

Why this matters for PM and PO roles

Role clarity matters here.

A Product Manager should decide what success means in business terms. That includes trade-offs between conversion, order value, retention, and customer quality.

A Product Owner should make sure the team can ship, track, and support the work needed to measure those outcomes correctly.

If the PM defines success too narrowly, the team builds the wrong thing well. If the PO receives vague outcome language without operational detail, the team ships fast and learns little. Neither failure looks dramatic in sprint reviews. Both show up later in missed revenue and weak product decisions.

Area	Product Manager	Product Owner
Core question	Why are we building this?	How do we get this built well?
Main horizon	Market, customer, business outcome	Sprint, backlog, delivery flow
In experiments	Defines hypothesis and success criteria	Turns hypothesis into executable work
Metric bias to avoid	Obsessing over one top-line number	Optimising delivery without outcome context
Best contribution	Strategic judgement	Execution clarity

The Fundamental Difference Between Product Manager and Product Owner

The cleanest distinction is this: The Product Manager owns product direction. The Product Owner owns delivery decisions inside that direction.

People complicate this because, in practice, the roles overlap. They attend some of the same meetings. They both speak to engineers. They both care about customer outcomes. But overlap isn't sameness.

Strategy versus execution

The PM is the architect. They decide what kind of building needs to exist, why it matters, what problem it solves, and what trade-offs are acceptable.

The PO is closer to the construction foreman. They translate intent into an ordered plan, resolve ambiguity at delivery level, and make sure the team builds the right thing in the right sequence.

That doesn't make the PO subordinate in judgement. It means the judgement is different.

The PM asks:

• Which customer problem is worth solving now?
• What business outcome are we pursuing?
• Which market signals matter?
• What should we not build?

The PO asks:

• Is this ready for development?
• What has to be clarified before engineers start?
• Which dependencies or acceptance criteria are missing?
• What can fit into this sprint without causing avoidable churn?

The PM protects the product from becoming a feature list. The PO protects the team from building an incoherent one.

Where teams get confused

Confusion usually starts in one of three ways.

First, a company uses the titles loosely. One business calls someone a Product Owner when they are really acting as a PM with delivery responsibilities. Another hires a PM but expects them to write every ticket and run every scrum ceremony.

Second, the organisation is small. One person does both jobs for a while. That can work, but only if leaders recognise the tension rather than pretending it doesn't exist.

Third, the team judges both roles by output. If everyone gets rewarded for shipping volume, role distinctions flatten and business judgement weakens.

What each role owns

A simple mental model helps.

Product Manager ownership

The PM usually owns the larger frame:

• product vision
• market understanding
• business case
• prioritisation across opportunities
• definition of success at outcome level
• stakeholder alignment beyond the delivery team

Product Owner ownership

The PO usually owns the operational frame:

• backlog quality
• story clarity
• acceptance criteria
• sequencing and sprint readiness
• day-to-day development decisions
• communication with engineering during delivery

Why this distinction matters in real work

If the PM is weak, teams can become efficient at shipping work with little strategic value.

If the PO is weak, teams can have a sharp strategy and still miss deadlines, misbuild requirements, and collect noisy data because implementation was rushed or vague.

A healthy product organisation doesn't ask whether PM or PO is more important. It asks whether both roles are being used for the decisions they are designed to make.

A Detailed Side-by-Side Role Comparison

Early role confusion creates later metric confusion. Once you compare the jobs side by side, the difference becomes easier to manage.

Primary focus

The PM's centre of gravity is outside the sprint. They work from customer problems, market context, commercial goals, and long-term product position.

The PO's centre of gravity is inside the team. They work from requirements quality, sequencing, delivery confidence, and the practical reality of getting work done.

That difference changes the day.

A PM may spend the morning reviewing customer research, pressure-testing a growth opportunity, and aligning stakeholders on whether a pricing or onboarding change is worth testing.

A PO may spend that same morning refining stories, resolving edge cases with engineering, and making sure analytics events are accounted for before a release goes live.

Decision-making authority

A lot of conflict comes from unclear authority.

Decision area	Product Manager	Product Owner
Product vision	Leads	Informed and operationalises
Market opportunity	Leads	Supports with delivery feasibility
Prioritisation across themes	Leads	Shapes sequencing within team capacity
Story acceptance	Consulted	Leads
Sprint scope	Consulted	Leads with engineering input
Success definition	Leads	Ensures it can be instrumented and executed

The PM should not micromanage ticket wording as a default. The PO should not redefine strategic outcomes because a sprint feels crowded.

Practical rule: When the question is about business direction, the PM should have the stronger voice. When the question is about delivery readiness, the PO should.

Key stakeholders

The PM typically works across functions and levels. They spend more time with leadership, sales, marketing, customer success, analysts, and external market inputs.

The PO usually spends more concentrated time with the delivery unit. They stay close to engineering, QA, design, and the mechanics of release planning.

That doesn't mean PMs ignore engineering or POs never speak to customers. Good teams blur the edges productively. The point is where each role naturally anchors.

Success metrics

Many organisations accidentally reduce both jobs to the wrong scorecard.

The PM should be evaluated on business and customer outcomes. That might include revenue quality, retention, adoption, or whether the product is moving toward a strategic goal.

The PO should be evaluated on execution quality. That includes backlog health, release predictability, clarity of requirements, and whether the team can deliver work without wasteful churn.

Those are different scorecards because they answer different questions.

A useful example comes from customer values alignment. A 2025 UK e-commerce study reported that sites misaligned with consumer values such as sustainability, valued by a significant portion of UK shoppers, saw significantly lower repeat purchase rates despite higher initial conversion rates, leading to a reduced customer lifetime value. That finding matters because it shows how a PM's strategic choices shape secondary metrics far beyond the first conversion, as described in this piece on the values gap affecting conversion and retention.

A PO still matters in that scenario, but differently. Their contribution is making sure value-led messaging, page variants, tracking, and release sequencing are concrete enough for the team to ship properly.

Core skills

What strong PMs tend to do well

• Frame problems well. They don't jump from symptom to solution.
• Choose metrics carefully. They know a local lift can still be a bad business decision.
• Influence across functions. Most PM authority is earned through alignment, not hierarchy.
• Say no with reasoning. They protect focus.

What strong POs tend to do well

• Reduce ambiguity. Engineers know what's expected before they start.
• Keep scope honest. They stop hidden complexity from derailing commitments.
• Translate intent into detail. Not every strategic goal arrives in buildable form.
• Guard flow. They make sure handoffs don't create avoidable waste.

Tools reflect the difference

Tooling often reveals what the organisation thinks each role is for.

PMs spend more time in roadmapping, research, analytics, and synthesis tools. POs spend more time in backlog, delivery, QA, and team workflow systems. If you're comparing stacks, this overview of best tools for Product Managers is useful because it separates strategic tooling from pure execution tooling.

The trap is assuming tool ownership defines role ownership. It doesn't. A PM can live in Jira and still neglect strategy. A PO can review dashboards and still avoid accountability for backlog quality.

The most useful distinction

The PM is accountable for choosing the right hill.

The PO is accountable for helping the team climb it without wasting time, trust, or technical energy.

Who Runs A/B Tests in Practice

In mature teams, nobody sensible asks whether the PM or the PO "owns" all experimentation. That question is too blunt. Good tests move through both roles for different reasons.

The PM starts with the business problem

A strong experiment doesn't begin with "let's test a button colour". It begins with a business question.

For example, the PM may spot that too many buyers complete a first purchase with a weak basket. The strategic opportunity isn't "test a different CTA". It's "increase order quality without damaging customer experience".

That leads to a hypothesis such as introducing a more intelligent upsell moment, changing bundle messaging, or testing placement of post-add-to-cart prompts.

The PM's job here is to define:

• the problem worth solving
• the reason this experiment matters now
• the expected behavioural change
• the success criteria beyond a single conversion event

That final point matters. According to 2024 UK CRO benchmarks, UK Shopify stores saw a 15% to 22% Revenue Per Visitor uplift in variants where conversion rate dropped 5% but AOV rose 18% due to strategic upsell CTAs. That's exactly why a PM shouldn't let the team call a test "bad" just because the top-line conversion rate softened.

The PO turns the hypothesis into buildable work

Once the PM has framed the test, the PO's work becomes decisive.

They make the experiment executable. That means clarifying requirements, agreeing edge cases, coordinating with engineering and analytics, and ensuring the release doesn't create hidden risk.

A good PO will ask practical questions that protect learning:

• What events need to fire, and when?
• Which pages or segments are included?
• What counts as exposure?
• How will refunds, duplicate orders, or partial checkouts affect reporting?
• What needs QA before traffic is split?

At this point, many "data-driven" teams fail. They write a smart hypothesis, then ship a muddled implementation.

A test isn't rigorous because the hypothesis sounds clever. It's rigorous when the implementation and measurement match the decision you need to make.

Where tooling fits

An experimentation platform should support the role split, not blur it.

A PM needs to define goals beyond simple conversions and review business-facing outcomes such as revenue per variant, order value trends, and whether a result is worth operationalising.

A PO needs to know the implementation is lightweight, measurable, and unlikely to create performance or release headaches.

In that workflow, Otter A/B is one option teams use because it lets them set goals around purchases, average order value, revenue per variant, and revenue trends while using a frequentist testing approach. If your team is still debating testing methods, this explainer on the difference between Bayesian and frequentist testing is a useful reference before you standardise an experimentation process.

A realistic handoff

The cleanest handoff usually looks like this:

1. PM identifies opportunity The PM sees a business issue, not just a UI tweak.

2. PM defines success They specify primary and secondary metrics, plus what trade-off is acceptable.

3. PO operationalises the brief They convert intent into stories, acceptance criteria, analytics requirements, and sprint-ready scope.

4. Team ships and validates Engineering, design, and QA build and verify the experiment.

5. PM and PO review together The PM interprets business impact. The PO verifies whether the result is trustworthy enough to act on.

What doesn't work

Two patterns fail repeatedly.

One is the PM who drops a vague request into the backlog like "test cross-sell banner".

The other is the PO who treats the test as a delivery ticket without understanding what business trade-off the test is trying to resolve.

In both cases, the team can ship an experiment and still learn almost nothing useful.

Effective Collaboration Models for Product Teams

The best PM and PO partnerships look boring from the outside. That's a compliment. Work moves, decisions stick, and the team doesn't keep reopening the same arguments.

The integrated pair

In the strongest model, PM and PO work as a tight pair with distinct responsibilities and shared context.

The PM brings market reality, customer insight, and outcome framing. The PO brings delivery realism, scope discipline, and execution precision.

You can usually recognise this model quickly. The signs are behavioural:

• Joint refinement. The PM doesn't vanish after strategy work.
• Early challenge. The PO pushes back before the sprint, not during the build.
• Shared review of results. The PM doesn't interpret outcomes alone, and the PO doesn't ignore them.
• Continuous context flow. Each role understands enough of the other's world to spot risk early.

This model works particularly well in experimentation-heavy teams because test quality depends on both strategic framing and operational detail. When a team maps user behaviour and friction well, the handoff improves too. That's where resources like these customer journey map examples can help align product thinking with journey-level execution.

Good collaboration isn't about eliminating boundaries between PM and PO. It's about making those boundaries useful rather than rigid.

The siloed handoff

The anti-pattern is the handoff model.

The PM writes requirements, presents them once, and moves on. The PO receives them as if they were finished. Questions get answered late. Engineers fill gaps themselves. Analytics requirements become assumptions. The sprint completes, but the outcome is fuzzy.

This model creates a feature factory. Teams become productive at shipping outputs while losing confidence in whether the work mattered.

What it looks like in practice

Behaviour	Integrated pair	Siloed handoff
Backlog refinement	Shared and iterative	One-way and document-heavy
Metric definition	Agreed before build	Added late or skipped
Engineering context	Available early	Fragmented
Experiment review	Joint interpretation	Separate opinions after launch
Team morale	Higher trust, fewer surprises	More rework, more frustration

Why the silo breaks down

The failure isn't just operational. It's cultural.

The PM starts to think the job is complete once a requirement exists. The PO starts to think success means protecting sprint flow, even if the work isn't clearly tied to an outcome. Engineers lose context, so they optimise for completion. Designers get dragged into revision loops because the original problem was never framed tightly enough.

I've seen this happen most often when leaders talk about "giving agency" but create distance. True agency comes from shared context and clear accountability, not from throwing work over the wall and calling it autonomy.

Rituals that help

A few habits consistently improve the PM-PO partnership:

• Weekly outcome review. Not just status. Review what moved and what didn't.
• Pre-refinement alignment. PM and PO meet before backlog discussions with the wider team.
• Decision logs. Capture why a trade-off was made, not just what was decided.
• Experiment readiness checks. Before launch, confirm the metric logic, exposure rules, and rollback path.

None of this is glamorous. It is effective.

How to Structure and Hire for Your Product Organisation

Hiring gets easier once you stop treating PM and PO as interchangeable labels. Start with the problem your organisation has.

When to hire a Product Manager

Hire a PM when the business needs better strategic judgement.

That usually means you need someone to define opportunities, connect product work to business outcomes, make prioritisation trade-offs, and keep the roadmap anchored in customer and market reality.

A PM hire is often the right move when:

• Direction is fuzzy. The team ships, but nobody is sure what matters most.
• Stakeholders pull in different directions. Sales wants one thing, leadership another, and engineering a third.
• Metrics are shallow. The company talks about conversion but not enough about value, retention, or quality.
• Discovery is weak. Features enter development before the problem is properly understood.

When to hire a Product Owner

Hire a PO when strategy exists but delivery discipline doesn't.

This is the role that strengthens backlog quality, sprint readiness, requirement clarity, and the day-to-day mechanics of turning product intent into working software.

A PO hire is often the right move when:

• Engineers lack clarity. Stories arrive late or half-defined.
• Sprints are unstable. Scope changes constantly and confidence is low.
• Release quality is inconsistent. Bugs, missed edge cases, and tracking issues show up too often.
• The PM is drowning in delivery detail. Strategy time gets consumed by ticket grooming.

Interview signals that matter

For Product Manager candidates

Ask questions that reveal judgement:

• How did you decide that a promising request was the wrong thing to build?
• Tell me about a metric that looked positive but masked a business problem.
• How do you define success for an experiment when conversion rate and revenue move in different directions?

You're listening for prioritisation quality, commercial thinking, and comfort with trade-offs.

For Product Owner candidates

Ask questions that reveal operational sharpness:

• How do you know a backlog item is ready for engineering?
• Tell me about a release where requirements changed late. What did you do?
• How do you handle analytics or acceptance criteria when stakeholders are vague?

You're listening for clarity, sequencing, and delivery judgement.

The hybrid role in startups

In smaller companies, one person often covers both PM and PO responsibilities. That's normal. It can work for a while.

The risk isn't that the person is untalented. The risk is structural. Strategy work and execution work demand different cadences, and context switching between them creates drag.

If one person must do both, manage it deliberately:

• Separate horizons. Reserve time for strategy that can't be consumed by sprint admin.
• Make metrics explicit. Define outcome metrics and delivery metrics separately.
• Limit work in progress. Hybrid roles fail when everything becomes urgent.
• Use clear artefacts. Strategic briefs and delivery tickets shouldn't be the same document.

The point isn't to be purist about titles. It's to make sure the essential decisions have an owner.

Frequently Asked Questions About PM and PO Roles

Can one person be both a Product Manager and a Product Owner

Yes. Many smaller teams do this, especially early on.

The problem isn't legitimacy. It's bandwidth. One person can cover both roles if they can switch between strategic thinking and delivery detail without neglecting either. In practice, strategy usually loses unless leaders protect time for it.

Does the Product Owner role only exist in Scrum

The title is most closely associated with Scrum, but the underlying responsibilities show up in many delivery environments.

Even in teams that don't formally use Scrum, someone still needs to own backlog quality, requirement clarity, and day-to-day prioritisation with engineering. A company may call that person a PO, a delivery product lead, or something else.

How do these roles differ in B2B and B2C companies

The split stays broadly the same, but the context changes.

In B2B, PMs often spend more time with sales, account teams, and complex stakeholder requirements. POs may deal with more implementation nuance around permissions, workflows, and integrations.

In B2C, PMs often focus more on scale, behavioural patterns, monetisation, and lifecycle outcomes. POs may spend more time managing high-volume experience changes and experimentation logistics.

What is the typical path from PO to PM

It's a common path, but not an automatic one.

A PO moving into PM work needs to demonstrate more than delivery competence. They need stronger market thinking, better prioritisation across opportunities, and a clearer point of view on business outcomes. Some make that shift naturally. Others prefer staying closer to execution, which is equally valid.

Who should own experimentation results

The decision should be shared, but the interpretation differs by role.

The PM should answer whether the result changes product direction or business priorities. The PO should answer whether the result is operationally trustworthy and properly implemented. If only one role reviews experiments, teams usually miss either the business meaning or the execution caveat.

Which role should care more about secondary metrics

Both should care, but for different reasons.

The PM uses secondary metrics to judge whether a change improved the business, not just a local conversion event. The PO uses them to ensure the team has instrumented and released the work in a way that supports reliable decisions.

---

If your team is still judging tests by conversion rate alone, you're probably making smaller decisions than the business needs. Otter A/B helps teams measure experiments against outcomes like purchases, average order value, revenue per variant, and revenue trends, so PMs and POs can work from the same evidence instead of different dashboards.