When they start talking about metrics, many of them aren’t clear about what they are measuring or whether it is the right thing to measure. This is a frequent problem, and I’ve seen it in different situations.

When I asked to them: “Why is this important? Help me understand your decision” The answer wasn’t clear.

Therefore, I realized that this is not always clear. Before asking, “Which metrics should I use?”, I first need to figure out what I should do, why I should do it and then how I will know whether my decision achieved the intended result. That last part is where metrics come in. To figure out the first two parts (what to do and why) you will require you to use your communication skills.

And, this made me think about my own experience. When you’re ramping up a product or a team, you still need to prioritise opportunities and manage stakeholders. When you are already working in a company, many things are happening at once, and you also need to understand how to approach and manage those different demands.

It took me some time to understand that, whether it’s an interview case or a real-life situation, I am constantly managing people’s expectations.

In real life, stakeholders frequently don’t have all the answers you need either. They have a request, a deadline and usually a reason they haven’t said out loud yet.

So how do you communicate, organise and manage everything?

Here are some questions I think are important to ask, whether in a real-life situation or an interview:

• Why are they asking for this?
• What’s the intention behind it?
• If I do that, what happens next?
• Which risks are we taking, and how can we mitigate them?
• Is there anything I can’t see but should? Who else should I talk to in order to understand more?
• How can I organise the decision to make sure everyone is aligned and on the same page?

None of these questions is about the solution. They all come before it. You need to understand the business, legal and compliance requirements, market positioning, company systems and so on.

What a prioritisation conversation looks like

Let’s imagine this situation below: Four stakeholders, four requests, all of them defensible.

• The Head of Customer Support stopped the PM in the office to say how important it was to have a live chat.
• The CFO sent an email with a list of bugs in the billing software.
• The Chief Innovation Officer, the person who hired the PM, wanted modern payment methods and new channels.
• The CMO wanted a back office so that small shops could sell through our platform, like a marketplace. She had been asking for it for a long time and already had everything defined.

Every one of those was aligned with a business objective. That is what makes it hard. If they weren’t aligned, saying no would be easy.

That’s why this demands communication and negotiation skills from a PM. In my current context, I like to use RICE and GUT most of the time.

RICE stands for Reach, Impact, Confidence and Effort. Reach and Impact can be estimated with support from Business and Marketing, as well as product data and research. They can help us understand how many people or events could be affected during a given period and what value the solution might create, for instance, how much it could effect each person in relation to the desired outcome.

Confidence shows how confident the team is in these estimates based on the evidence available. Effort is the total amount of work the team believes will be required to develop the solution.

There’s no 100% right answer, but the exercise helps everyone think about the needs and possible solutions. When a stakeholder has to explain the Reach and Impact of something, or when I can show the estimates to them, it’s much easier for them to realise on their own that some features may not be that important. Nobody has to be given a blunt “no” in a meeting full of people.

Adding a GUT matrix makes that conversation even easier. GUT is quite common in Brazil: Gravity, Urgency and Tendecy. It helps separate what is important from what is urgent, which is one of the conversations I have most often in traditional companies, where everything arrives already labelled as urgent.

RICE helps me discuss what may be worth doing, while GUT helps me examine what might not be able to wait.

Now, going back to the scenario above:

Four stakeholders, four requests, all of them defensible. We can start by comparing the requests. I’d use RICE first:

The bugs were already mapped, which gave us more confidence in the estimate, and they required the least Effort on the list. The payment methods request was the most expensive because it meant building an app.

Then GUT:

For GUT, each problem receives a score from 1 to 5 for Gravity, Urgency and Tendency. The three scores are then multiplied.

Now look at what happens. The billing bugs win both by a distance: they reach the most people, they were the cheapest thing to fix, and if customers can’t pay, the problem gets worse every week. The marketplace comes second on both. And the live chat, which was the request that arrived most insistently and in person, is last on both. Here it’s not about being right or wrong. The Head of CS isn’t necessarily wrong, but the reach is low and it isn’t urgent, so it doesn’t make sense to prioritize it right now.

In my experience, using this kind of methodology gives you reasons to say yes or no.

You can explain your decision with numbers and measure the results later. And if it doesn’t work, having made these estimates can help you identify that earlier, which can keep costs lower than they would be if you developed everything before pivoting to something different.

One important thing to mention is that the scores came from what we knew at that moment, and this disclaimer matters because in this case it’s the reason we need more Discovery: is the marketplace what the users really need?

That’s why I tell mentees who are always asking about metrics to first ask the right questions, whether in an interview or in their job. This helps you clarify the outcome, decide what should be prioritised and identify which metrics will show whether the decision worked.

Other frameworks you might find interesting

RICE and GUT are what I reach for, but they are not the only options:

• MoSCoW — sorts requirements into must have, should have, could have and won’t have. Easy to run live in a room, and useful exactly when you are agreeing what goes into the MVP. The weak spot is the “won’t have” bucket, which tends to stay vague.
• Kano — classifies features as basics, performance or delighters, based on customer satisfaction. This is the one that tells you what people simply expect versus what will actually make them happy, but it needs real survey data to work properly.
• Value vs. effort — a 2x2 ranking ideas by probable value against implementation cost. Quick, visual, no calculation. A good first framework for a team still building confidence in its estimates.
• Cost of delay — puts a number on what it costs the business to not do something yet. Useful when the argument is about sequencing rather than about scope.

👉 P.S. about Risks and Mitigation, which I mentioned above: it is worth knowing, but it isn’t a prioritization framework. It’s an action plan. Keep it, just don’t use it to decide what gets built.

Communication as part of Priorisation

In real life you’ll probably have more stakeholders and meetings and sometimes less time to decide. So, while making these decisions, you can share a dated document in which the trade-offs are clear. I usually create a PRD and a FigJam board with more information for the team — which helps to communicate the decisions and make sure everyone is on the same page! These documents are supposed to be updated and shared, keeping them alive and visible to everyone who needs to be in the loop it’s important.

People accept decisions much better when they watched them being made and can still follow the progress. Don’t forget that communication is key.

Finally, what I have learnt along the way is that no one in the room is against you or your product. Everyone has something to gain, they just arrive asking for different things. None of that is hostility. It’s closer to “I have a pain and I need you to listen to me.”

Very often the request they brought is not the need behind it, and there is a cheaper way to give them what they came for. That’s why those first questions matter so much: why are they asking this, and what’s the intention behind it? The answer is usually what lets you say no to the feature and still say yes to the person.

References:

• Six product prioritization frameworks and how to pick the right one — Atlassian. Covers RICE, Kano, MoSCoW, value vs. effort, opportunity scoring and cost of delay, with the pros and cons of each.
• RICE prioritization matrix — Lucidspark. A ready-made template with the scoring scales spelled out, including impact from 0.25 to 3 and effort in person-months.
• Stakeholder Management: The Ultimate Guide — Simply Stakeholders. Long, but useful on stakeholder mapping and on why managing stakeholders isn’t the same as controlling them.
• Integrating risk analysis and prioritization: a practitioner’s tool — Jimmie L. West, PMI. How to score risks across several impact factors instead of a single 2x2.
• 3 Types of Risk and Impact Assessments, and When to Use Them — Trustible. Written for AI governance specifically, but the idea of escalating tiers of assessment travels well.
• The 12 Best PRD Template Resources — Figr. A roundup of PRD templates if you want somewhere to start.
• Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value — Teresa Torres (2021).

Originally published at https://carolthume.substack.com on September 17, 2026.

A while ago, at Productized, I kept hearing speakers talk about launching features faster, with new integrations, new workflows, new everything and then having adoption problems. Something like: “Users aren’t sticking around.”

And one thing stuck in my mind: “This is such a Product-market fit problem.”

Just to be clear, low adoption of one feature doesn’t automatically mean that the whole product lacks product-market fit. It could also be related to onboarding, communication, timing, or even the feature itself. But it is still a signal that something might not be aligned, and that we need to investigate it.

Everyone wants AI, and we, as PMs, are being pushed to do more than write about products or talk to stakeholders and development teams. Now, we must iterate, co-create, sketch a product, create prototypes, and iterate with colleagues and users. We can now use AI not only as generative AI but also for vibe coding and so on. And we are craving it. We want to do it!

However, it might be tricky sometimes if we’re launching features without understanding whether they solve a problem customers actually have or whether they are aligned with a business outcome. We can have Go-to-market (GTM) speed, but we also need a GTM strategy aligned with Product-market fit (PMF). We can optimise for launch speeding without forgetting about launch success.

Last month, I was writing about context before development. GTM is more than a launch plan; it is strategy combined with execution and measurement. And I see three problems that we might be facing:

1. Getting too attached to the idea: We can get too attached to the idea, the product, the discovery process, etc., and lose the right timing to launch it. If we want something to be too perfect, we can lose sight of the idea of the product: delivering value.
2. Launching something fast that doesn’t solve anything: The other problem is launching something fast that doesn’t solve anything. In this case, we also don’t have value.
3. Solving a user problem that’s not connected to business outcomes: What can be tricky is that sometimes we are solving a user or customer problem, but it’s not connected to a business outcome. We’re not being strategic enough. We may eventually develop something that only one person is using; a kind of vanity feature.

All three can fail for the same reason: a lack of alignment between the problem, the market, and the business. This can be a PMF problem, and without PMF, even a good GTM strategy might not create sustainable results.

When I first realised that GTM was more than a launch plan and that it connected strategy with execution and measurement; a new world opened up for me. Since then, I have understood that we can move faster, but today I also see more clearly that we need to be sure about what we are building in the first place and why.

PMF and GTM are interconnected. While PMF provides evidence that a customer needs the product, GTM builds the process to reach the client. That’s why we need to identify opportunities and turn them into solutions aligned with Sales, Marketing, Product, etc. This way, we can create a feedback loop and scalability by ensuring that we are developing the right thing, at the right moment, for the right target, with the right strategy.

I have seen big companies make the mistake of launching a big product and calling it an “MVP,” with perfect marketing plan and a lot of money spent on it, only to hear from clients one month later that they would not use it.

What went wrong here? A lot of things, probably…

Basically, GTM defines who you are selling to and how you will stand out from competitors. The concept has strong roots in Marketing, but GTM is cross-functional. You have to know your market, value proposition, pricing, and so on. Do you know the rule of the 4 Ps?1

It can seem easy, but it’s not. For a successful GTM strategy, before everything, you have to have:

• Researched users (not assumptions)
• A defined market (not “everyone”)
• Business outcomes (not just features)
• Opportunities and hypotheses you can test
• Success metrics

Again, it doesn’t matter if you have a perfect launch if you were building the wrong product before it.

As this unfolds, it’s really common to see companies having Product Marketing Managers and Product Managers working together or even the PM working with the Marketing team when there is no PMM2. It’s cross-functional.

Although the objectives, KPIs, and day-to-day metrics will not be the same, the final result needs to be the same. That’s why we talk so much about a North Star in product teams.

Making sure PMF and GTM are aligned

Here’s what I learned the hard way: You can have perfect GTM execution and still fail if you don’t have PMF. And you can have PMF but never reach scale if your GTM doesn’t match your customer’s journey. So, how do you align them?

First, we can start with research and opportunities. You can go through the user journey, the job to be done, and everything else in Product that will help you answer:

“Are users using it in the first place?” After that, use metrics, such as the ones you can find below, to confirm what your product and users are telling you! If not, you may not have PMF yet. And scaling GTM right now is not a good idea.

Don’t forget to bring everyone together: Sales, Marketing, Business Owners, PMM, PM, and everyone else who matters. Here, you will establish metrics and goals.

One more important thing: Don’t forget that a product is never ready! You’ll keep iterating on it, getting feedback, improving it, and repeating the process over and over. Faster validation is also really important!

The vanity metrics trap

I remember when I started building products and how excited I was about downloads. At the time, I had been working as a PM for less than a year. My boss told me:

“Don’t forget that people can download it and never use it. They can also download it, delete it to free up storage space, and then reinstall it the next day.”

We always have those metrics we want to look at. They are nice, beautiful, and sometimes make our days better. Some of them are:

And since then, I have learned about vanity metrics and their trap!

We always have those metrics we want to look at. They are nice, beautiful, and sometimes make our days better. Some of them are:

• Downloads
• Sign-ups
• Visits
• Impressions and clicks
• Followers or subscribers who don’t engage
• Qualified leads who don’t buy

Here’s the thing: none of these alone tells you whether you have PMF. They can measure awareness or initial interest, but not stickiness. And you need stickiness to make GTM work.

Risks and mitigation

Other things that are important: know the risks and mitigations in case your launch causes problems. Sometimes we ignore this because it’s only an MVP: “something easy”, we might say.

However, we still need to be cautious. Make sure legal and compliance risks have been checked. Nowadays, with AI, data, and regulations such as GDPR and the EU AI Act, we must consider data protection and intellectual property. Depending on the company and sector, rules such as NIS2 may also apply. This needs to be evaluated case by case with the appropriate specialists.

Keep these things in mind:

• Why: Why are we building it, and for whom?
• How: Am I delivering value through this product or feature?
• Market readiness: Does this already exist? Is it a blue ocean or a crowded market? How are competitors positioned? What do customers actually think about this need?
• Team capacity: Does everyone have enough context? Are Product, Engineering, Sales, Marketing aligned on the same goals before launch?
• Competitive window: Is there a moment I need to catch, or can I take my time?
• Customer readiness: Are customers ready to adopt this now, or am I too early?
• Seasonal factors: Are there seasonal trends that could help or hurt the launch?

The reality

Finally, for some of the products I helped launch, I wasn’t working in a structured company, so I learned many things by doing. For others, I was in a well-structured company, but the products were so complex that we missed the best time to launch because there was so much bureaucracy. What I can say is that product sense will help you here.

I believe that starting by understanding why you are building something (the context) and carrying that understanding through to the launch makes things easier when you have enough information and data.

However, I don’t want to be the buzzkill: many times, you will not feel comfortable enough or prepared enough. And it’s part of the game!

That’s why good research, context, hypotheses, product sense, and consistent metrics are what will give you the confidence you need to either continue improving the product you launched or kill it or pivot it when needed.

Don’t be afraid of doing it again. Pivoting a solution is nothing new, and now, with AI, it can be even cheaper than keeping a product or feature in the market and continuing to spend money without getting returns. Of course, for that, keep it small. Remember what an MVP is for…

Because, in the end, launching faster is only an advantage when we are building the right thing for the right people and learning fast enough to change direction when we are not.

👉 Want to go one step further? Keep reading: I’ve put together some metrics that can help you understand whether your GTM is actually working, along with practical steps to better connect PMF and GTM throughout your product launch. :)

Which metrics should guide your GTM?

There are five core metrics worth tracking3. I learned about these from different sources, but here’s how I think about them as a PM:

1. Customer Acquisition Cost (CAC)

What it is: How much you spend (Marketing + Sales) to acquire one customer.

Why care: CAC helps you identify whether your product story is strong or whether you’re asking the market to fill in the gaps. We often say that a high CAC can be a red flag that your product positioning is unclear. If someone-such as Marketing or Sales-has to work hard to explain what you do, your product might not be differentiated enough. However, a high CAC can have other causes too, such as wrong targeting, an expensive sales process, or the type of market you are in.

Target: It must align with your customer’s lifetime value (LTV). If you’re spending too much money to acquire clients and their return is not high, the maths is not working.

2. Lifetime Value (LTV)

What it is: The estimated total value a business expects to earn from a customer throughout their relationship. Depending on the formula and business model, it may be based on revenue or gross profit.

Why care: It considers the customer lifecycle, including purchases and interactions. It helps you understand the value that a single customer brings to the product. Usually, CAC and LTV are analysed together. Bringing in a new client is usually more expensive than keeping one with you. Keep this in mind during the entire product lifecycle-that’s why the engagement rate is so important.

3. CAC Payback Period and Churn

What it is: The number of months it takes until that customer’s gross profit covers what you spent acquiring them.

Why care: Imagine you’re building a B2B SaaS. The company spends $2,400 on ads and Marketing to acquire one client. That client pays $100 per month, giving you $80 in gross profit. Here’s the formula:

Meaning that, it would take 30 months just to recover what the company spent acquiring this customer. From month 31, the acquisition cost has been recovered, although other operating costs still need to be considered.

Why I mention churn:

Well, if that customer churns before the CAC has been recovered, the deal may never pay off. You may never become profitable from that client. That’s why starting with a simple product that solves one problem at a time, and working on growth afterwards, can be a useful strategy. You must show value quickly to acquire clients. If your solution is delivering value at the right moment (product-market fit), then your churn is possibly lower.

4. Net Revenue Retention (NNR)

What it is: Revenue from existing customers, including upgrades, downgrades, and churn, compared with the previous period. You analyse the monthly or annual recurring revenue from your existing customers, then add new revenue from upsells, cross-sells, and upgrades from those customers. Finally, you subtract the revenue lost from downgrades, cancellations, or non-renewals.

Why care: When your NRR is above 100%, it means that revenue from your existing customer base is expanding. For recurring-revenue products, this can be one of the strongest signals of PMF. It’s not only about acquisition; it’s also about whether the product keeps delivering value.

Example calculation:

• Starting MRR: $100,000
• Expansion (upgrades): $8,000
• Contraction (downgrades): $2,000
• Churn (cancellations): $5,000

5. Opportunity Win Rate:

What it is: The percentage of qualified sales opportunities that are successfully closed.

The number will change across different industries, so I suggest that you take a deeper look at your specific case.

Why care: A low win rate may mean that the targeting is wrong, that Sales is talking to the wrong people, or that the product doesn’t match what was promised. This is your feedback loop. It shows how well the product is being sold and helps operations teams predict revenue. It may also help diagnose issues related to lead qualification, pricing, and competitors.

Formula:

The number will change across diferent industries, so I suggest that you take a deeper look at your specific case.

5 Steps to Align PMF and GTM

1. Validate PMF before you scale GTM

Before you spend big on acquisition, ask: Are customers asking for this without being prompted? Are they sticky? Are they referring others? If not, you may not have PMF yet. Scale GTM too early, and you’re just amplifying a broken product.

2. Use GTM metrics to validate PMF signals

Your GTM metrics (CAC, payback, NRR, and win rate) should confirm what your product metrics (retention, engagement, and activation) are telling you. If your product metrics say “sticky” but your GTM metrics say “high churn,” something is misaligned. Investigate what is behind the contradiction.

3. Align PMM, Marketing and Product on the same hypothesis

Don’t let Product build one thing while PMM and Marketing sell something different. Before launch, all three should agree: “We’re solving X problem for Y customer, and we’ll know we’ve succeeded when Z metric moves.” Same hypothesis, different levers.

4. Use your GTM launch as a test, not a celebration

Treat the launch as a test of your PMF hypothesis. Watch the metrics. If the CAC payback period is 30 months and churn is high, you might need to pause acquisition and investigate. If the win rate is 10%, your product might not match the promise. Understand whether the problem is the product, the pitch, the target, or something else.

5. Iterate both together

PMF and GTM are not purely sequential. They can evolve in parallel. You can validate PMF with a small group, test GTM assumptions with that group, learn, refine the product, refine the GTM, and repeat all over again.

Fast product iteration + fast GTM iteration = faster validation

References

• 9 KPIs every revenue team needs to measure GTM strategy success
• Stripe: What is a go-to-market strategy?
• LTV — Customer Lifetime Value: Calculation and Practical Applications
• Go To Market Fit vs. Product Market Fit with Ted Blosser
• European Commission: AI Act
• European Commission: NIS2 Directive
• What Are the 4 Ps of Marketing?

1The four Ps of marketing describe the key decisions businesses make to bring a product to market: Product, Price, Place and Promotion

2As I mentioned in my previous articles, those areas are related, and everyone needs to work closely to achieve the same goal.

3The definitions and formulas below are based on established GTM concepts and the sources listed in the References section.

Originally published at https://carolthume.substack.com on August 31, 2026.

So, I decided to write about the misconceptions surrounding Product Management positions. I have also noticed an issue with AI PM roles in the market, but I decided not to write about it at this moment.

For this article, I first want to clarify what I consider each of these roles to be. Afterwards, in a different article, I’ll draw a parallel between Product and Marketing, discuss some gaps from a PM’s perspective, and explain why I believe that, In today’s AI landscape, where we’re building solutions quickly, we should ponder product perception through a go-to-market perspective.

Product Manager (PM)

So, the market woke up one day and said: “Why not look at strategy? Business? Why are we building this stuff in the first place? Should we pivot the solution or even kill it?” Well… It wasn’t quite like that, although sometimes this is how we hear the story. However, Product Management started in the 1930s. They called the role the “Brand Man”, a justification to hire more people, but not only that. The concept proposed by Neil H. McElroy described someone responsible for branding; from tracking sales to managing the product (not a digital one back then ;)), as well as advertising, promotions, pricing, clients’ needs and pain points, etc. Have you ever thought about how similar Product Management is to Marketing? I have, and the day I figured it out was a turning point for me. I could finally understand the roots and connect some dots.

If you want to know more about the beginnings of Product Management, I strongly recommend reading this article. It explains everything you need to know!

When Product Management moved into tech, it started within waterfall product-development processes and often reported to Marketing or Technology. While Marketing focused on the brand, Product Management was focused on the product’s value and its development — giving business requirement to engineers and waiting for the product to be completed. Years later, when the Agile Manifesto was created in 2001, we saw the evolution in the PM role, with closer collaboration with users and the engineer team becoming increasingly important. The game changer came when we started discussing questions such as: Why are we building it this way? Are we delivering value?

When we read books by authors such as Marty Cagan and Teresa Torres, as well as Brazilian Product references such as Joca Torres and Eduardo Magalhães (who was my professor at Tera and from whom I learnt a lot), we find deep dives into Product Management, Design & UX, Strategy & Product Vision, Marketing & Sales, Growth, Product Teams and so on… From them, we can notice that Product Management as a discipline has always been connect to Marketing to some extent. Yet, there’re people working alongside PMs who still have no idea what a PM does. They know about meetings and alignments (I’m pretty sure of that) but the value or the significance of the role is sometimes lost amid the process and buzzwords surrounding it.

Here’s where I want to go with this explanation. A PM doesn’t necessarily need to excel at Marketing. At the beginning of their careers, we tend to say that PMs can be more generalist. Therefore, that’s why we see so many people from Business Administration and Marketing becoming Product Managers.

I truly believe (perhaps because of my background) that it’s easier for those with experience in these areas to understand market needs and business outcomes and to talk to Product Designers about research, empathy maps, customers’ pain points, and personas. These disciplines also exist within Marketing. Have you ever read Blue Ocean Strategy or created a Business Model Canvas? Probably. In the end, to put it simply, it is all connected to Marketing. Of course, I’m simplifying it. We also have PMs who, throughout their careers, will specialise in UX, IT, AI (as many do nowadays ) and so on. They’ll rely on their peers to take a deeper dive into Marketing needs, and at some point, Marketing will probably become a stakeholder supporting a product decision.

What I would like to make clear here is that, although Marketing and Product Management have always been connected, I feel that, at some point, things became overcomplicated.

Product Owner (PO)

To explain the PO position, in my opinion, we need to look back at the agile era, when Scrum was created. I’m referring to agile methods and the Agile Manifesto.

The Product Owner was the person responsible for clarifying what was supposed to be developed, checking the roadmap, timelines, backlog prioritisation, development risks, and mitigation strategies.

If you notice, I’m mainly talking about delivery. It’s not only delivery, of course. Although the PO role is frequently interpreted as delivery-focused, the Scrum accountability also includes maximizing value and providing clarity about the Product Goal.

However, when the PO role was created, it was introduced as part of the Scrum Methodology. The intention was to deliver important things faster while maximizing value and managing the Product Goal and its backlog.

See how Scrum.org defines the Product Owner role:

“As a member of the Scrum Team, the Product Owner provides clarity to the team about a product’s vision and goal. All work is derived and prioritized based on the Product Goal in order to deliver value to all stakeholders including those within their organization and all users both inside and out.

The Product Owner is accountable for effective Product Backlog management, which includes:

- Developing and explicitly communicating the Product Goal

- Creating and clearly communicating Product Backlog Items

- Ordering Product Backlog Items

- Ensuring that the Product Backlog is transparent, visible and understood

The Product Owner may do this work or delegate the responsibility to others on the Scrum Team. Regardless of who does the work, the Product Owner remains accountable for it being accomplished and for the value delivered.”

— What Is a Product Owner?, Scrum.org

From this perspective, with the PM being responsible for strategy and the product life cycle, they may also fulfil the PO accountabilities in a company that follows Scrum. Therefore, they ensure that the strategy and tactical plan are clear and use the Scrum framework to plan delivery while maintaining value for both the business and users.

Some companies have both roles working together: the PO focuses on the backlog and delivery, while the PM focuses on strategy and business outcomes.

The images below illustrate that. The first represents the PO and PM as separate positions, while the second shows the PM also fulfilling the PO role.

Joca Torres in his article: Product Owner Misconception #3, argues that separating a PO who focuses only on the backlog and delivery from a PM who focuses on strategy and business can create silos, misaligned objectives, and fragmented customer experiences.

As an alternative, he suggests either having one Product Manager responsible for both the business and digital aspects of the product or, when the complexity and workload require two people, replacing the PO/PM structure with a Product Manager and a Business Manager. The Product Manager would focus more on the digital aspects, while the Business Manager would focus more on the business aspects.

However, dividing the responsibilities should not mean dividing ownership of the product outcome:

“For this reason, they are both responsible for product vision and strategy, competitor analysis, market analysis, problem discovery, solution discovery, and product delivery.” — Joca Torres, Product Owner Misconception #3: Do They Focus on Execution While Product Managers Focus on Strategy?

This distinction makes sense to me because it clarifies who focuses on the digital and business aspects without separating the product vision and strategy. Both people should work towards the same objectives and collaborate throughout the product life cycle.

An Additional Note on Project Management

Both then and now, we have also had the Project Manager role, which I consider similar to the PO role in certain aspects. However, the PO is typically focused on ongoing product value, whereas the Project Manager manages one or more temporary projects with defined scopes, budgets, and schedules. Both may consider risks, dependencies, and mitigation strategies, but their primary responsibilities are different.

👉 If you’re interested in learning more about the Product Owner role, Joca Torres has written a three-part series about common PO misconceptions:

• Product Owner Misconception #1: Is It Just a Product Management Career Step?
• Product Owner Misconception #2: Are They Managed by Product Managers?
• Product Owner Misconception #3: Do They Focus on Execution While Product Managers Focus on Strategy?

Product Marketing Manager (PMM)

Finally, we can discuss the PMM position. If we now have PMs who understand business and Marketing and are concerned with value, user needs and fast delivery, why do we also have the Product Marketing Management position?

As I said at the begging, Product and Marketing have always been closely connected. It is also important for the business and sales teams to ensure that they are selling the product to the right target audience, at the right price, while accounting for costs. In addition, we need to conduct research alongside product designers / researchers. We also need to understand segmentation and target audiences, positioning and messaging, pricing, go-to-market strategy, rollout, launch planning, sales enablement, adoption, retention, and expansion, for instance. It seems like too much for one person, doesn’t it?

The PMM is someone we can consider from the beginning to the end of the process. In my view, they are the best person to bridge the gap between the product that was built and its target market, but that’s not all. They might participate from the begging as well.

When I say that I want to write about go-to-market strategies and AI in the future, I’m also considering PMMs as some of the people behind these initiatives. They work cross-functionally with Product, Growth, Sales, and Customer Success, helping teams connect product decisions with market needs. Their role may include conducting competitor analysis, supporting acquisition and adoption strategies, and monitoring pre- and post-launch performance through metrics such as qualified leads, conversion, adoption, and engagement.

It’s an important position that you’ll usually see working alongside other different product roles. PMMs and PMs can both study pain points, while one will look at data usage and the other at buyer perception, for instance. Features are another example: the PM is concerned with valuable features, and the PMM, beyond that, is also concerned with how their benefits will be positioned and communicated to the market.

It’s an area of intersection, and what we have also seen in the market is that some companies have chosen to combine responsibilities. In 2023, for example, Airbnb took a different approach by combining Product Management and Product Marketing. Senior PMs moved into Product Marketing positions, while many other Product Management responsibilities were reclassified as Program Management.

👉 If you’re interested in this position or are already a PMM, several books explore the product marketing role in greater depth. I did some research, and my conclusion is that this book below could strengthen your understanding of the PMM role and might be helpful for people who want to elevate its position within their organisations.

If you read it, please let me know your thoughts! I’ve also included in the sources a website called Product Marketing Alliance, which has a list of other books you might find useful. This one is as #2 on their list.

Different Needs, Clearer Product Accountabilities

So, why not split these responsibilities into different positions for different needs? Does our company use Scrum or another Agile framework with a similar role and want to make sure we are working towards a shared Product Goal? A PO may help. We need to be careful not to create a separate role focused only on execution, though, as this can disconnect delivery decisions from product strategy and business outcomes. You might also have a PM taking on both roles, as I mentioned before.

Do we want someone to work throughout the entire process, focusing on why and how, without using a framework that requires a PO? Generalist PMs are here. Do we need someone focused on Growth? Perhaps a Growth PM is what we need. Do we need someone with a stronger technical background? We have Technical Product Managers (TPMs), and so on. Or do we want someone to focus on pricing, launching campaigns, and target audiences? Perhaps a PMM is the one we need here!

Therefore, it’s important to consider the product life cycle and the company’s needs and then understand which profile should be hired. This is better than either expecting one person to do everything or hiring someone with one expectation but, at the end of the day, giving that person completely different responsibilities.

My Final Thoughts

So, to answer the question raised at the beginning of my article: why are PM, PO, and PMM roles interpreted differently?

I truly believe it depends on the company.

In my opinion, and this is where we might disagree, I only see the need for a PO role when a company or department uses Scrum or another framework that includes this role. Otherwise, I don’t think it is required to introduce a role that originated in a specific framework simply because the company follows Agile principles more broadly.

Adding to that, I want to make it clear that I’m not saying there’s only one path to follow: a PM, PO, or PMM can take on these responsibilities individually, or the responsibilities can be split among them. However, when responsibilities are divided, everyone should contribute to the product vision and strategy and work towards shared objectives. Otherwise, separating strategy from execution may create darkness rather than clarity.

Also, one thing to mention is that it depends on how the person performing the role sees themselves. My goal in writing this is to help clarify these different possibilities and thereby empower those who don’t see themselves in a particular product role to become aware that another product role could be a better fit for their current situation.

👉 P.S. To see what a Programme Management role can look like in practice, here’s a current Program Manager position within Airbnb’s Community Support organisation.

A Typical Day:

Lead complex cross-functional teams and manage multiple programs simultaneously, ensuring successful delivery while navigating ambiguous situations.

Collaborate closely with executive leadership to establish and maintain strategic alignment, communicate project status, and manage expectations.

Develop and execute program plans and schedules to achieve targeted performance metrics that align with executive-level expectations.

Be curious, anticipate and navigate obstacles and skillfully negotiate changes with cross-functional stakeholders at every stage from early concept through to launch.

Assess business and organization risk to make trade-off recommendations.

Close the loop — track and measure your outcomes and adapt and learn quickly from failure.

Champions CS Program Management Office (PMO) defined ways of working to drive intended outcomes and provide transparency.

Independently produces and revises documents and presentations that are executive ready.

👋 Thank you for reading all the way to the end!

🎯 Stay tuned! Next week, we’ll talk about how advances in AI have impacted go-to-market strategy.

Sources:

• Matriz BCG: um guia prático para priorização de produtos
• The history and evolution of product management
• “Neil H. McElroy.” Wikipedia, Wikimedia Foundation, [4 June 2026, at 05:17 (UTC)], [https://en.wikipedia.org/wiki/Neil_H._McElroy].
• What is a Product Owner?
• Product Owner (PO) VS Product Manager (PM)
• Product Owner Misconception #1: Is It Just a Product Management Career Step?
• Product Owner Misconception #2: Are They Managed by Product Managers?
• Product Owner Misconception #3: Do They Focus on Execution While Product Managers Focus on Strategy?
• Product Owner vs Project Manager: What’s the Difference?
• “Program Manager, Community Support.” Airbnb career website, [https://careers.airbnb.com/positions/7927169/].
• The Product Marketing Manager Handbook: A detailed review of product marketing
• Top 100+ product marketing books:Your definitive guide

So, I’m starting an August Series. Once a week, I’ll share practical lessons from my work in Product Management so that we can discuss them and learn together.

This week’s topic is AI in product research.

As a Product Manager, I’ve always loved research. It’s the stage when we can really roll up our sleeves, explore an opportunity, and connect with people from business, marketing, product, design, engineering, and as many relevant areas as possible.

It’s also the moment when we can investigate and better understand the user problem, and connect business strategy with product decisions, understanding not only the user needs but also the business outcome the product needs to deliver.

This stage is essential for understanding what needs to be built, and whether anything needs to be built at all.

AI is helping us move faster. But lately, I’ve noticed the same concern coming up in very different conversations (both at Productized and in the mentoring programme where I’m a mentor):

We’re building more than ever, but we’re still shipping solutions people don’t use.

We finally overcame the “research is slow and expensive” phase, since AI can help us do it cheaper and faster. However, that doesn’t mean we can set it aside. We still need to understand the why’s, connecting them to the opportunities and problems that need to be solved. AI is now an ally, not a replacement.

So, where does AI actually help during discovery?

In my opinion, it starts with context. Imagine that AI is a really fast car. If we don’t have the right direction, we will go anywhere fast, but not necessarily to where we want to go. Context is the direction.

Understanding the intended business outcomes, market context, and wider strategy is crucial before we begin exploring solutions.

Before the research begins, I align to stakeholders to understand:

• The goal and expected business outcome
• What success looks like
• What is already known through documentation, previous research, and data

Then, using the AI tools available in my company, I analyse and connect relevant information from sources such as Figma, Confluence, research notes, and our repositories.

This helps me:

• Organise what we know VS. what we think we know
• Identify gaps and contradictions
• Draft better hypotheses and interview questions
• Explore potential risks and questions for the team

In practice, I can share some ways that I’m using it, already.

Let’s imagine a double diamond:

First Phase: Discovery

The first phase of the double diamond is Discovery. Here, AI can help us feed in customer feedback and transcripts, and collect survey data to rapidly summarise topics. We’re not making assumptions here, so in this phase Copilot and its Research Agent support me by identifying and clustering pain points, user needs, and business needs, creating personas, and helping me use “How Might We” statements to generate more ideas.

Second Phase: Define

In the second phase, where we want to converge, AI can support us by collecting ideas, testing feedback, and organising documentation. It’s here that AI helps us turn insights from Discovery into a clear and concise problem statement. After the problem statement, I also like to write down some assumptions.

I like to use Copilot Chat and its Research Agent to support me to set of hypothesis cards. So, the team aligns on what we’re assuming and what we need to validate (instead of jumping straight to solutions).

Here’s a prompt I often use with Copilot Chat to generate a first draft:

“Using only the context below, create 3–5 hypothesis cards. For each card include: We believe…, If we…, Then…, Because (evidence from the notes), We’ll know it’s true when (measurable signal), How to test (smallest test), and Top assumptions/risks. If information is missing, write UNKNOWN and list the question to validate it.”

In one recent initiative, a Product Designer and I created our first hypotheses and wireframes in just five days, using only existing information and this prompt.

First Phase: Develop

Once the first diamond is done, we’ll start the first phase of the second one. We used AI in Figma to turn our hypotheses into draft flows and early wireframes, and GitHub Copilot to surface technical constraints early. As a result, we walked into our trio session with a short discovery brief, a prioritised question list, and a first wireframe to critique.

Because GitHub Copilot can draw on repository context, it also helped us have a better conversation with engineering: the right questions to ask, the constraints to consider, and the risks to investigate, not by making decisions for us, but by helping us start with more context.

Here are some of the questions we brought to the team and you can also use:

• From a technical perspective, are these hypotheses clear, or are we missing important assumptions?
• Is the proposed flow technically feasible? Which systems, integrations, or architectural changes might it require?
• What is the smallest version we could build or test to validate our riskiest assumptions?
• What is essential for the MVP, and what could be postponed until a later iteration?
• What technical risks or unknowns should we investigate?
• How confident are we in the feasibility of this approach, and what would help us increase that confidence?

Remember that the Develop phase is where we want to have a range of ideas. We want to prototype and test them with users whenever it’s possible (this could be another post). We want everyone on the team to embrace the product, failures, and learnings so that we can refine it and finally Deliver it.

Second Phase: Deliver

The deliver, and last, phase of the double diamond might be also supported by AI, but in this case it can help us connect to repos, write PRDs, stories, epics, and so on. I think it deserves a new post.

Coming back to Product Research and AI…

AI doesn’t do discovery for us.

We still need to:

• Talk to users and stakeholders
• Challenge our assumptions
• Interpret what we learn
• Make trade-offs with Design and Engineering

From there, we can organize what comes from desk research, review any existing qualitative and quantitative studies, identify gaps and contradictions, and define what still needs to be investigated.

I’m a big fan of Teresa Torres’s Product Trio approach because technology shouldn’t enter the conversation only after a solution has already been designed. For me, the real win isn’t simply moving faster, it’s building together.

It’s about bringing business, research, design, and engineering closer together so that we build the right thing at the right time, not just the next thing.

After experiencing AI in my work, my conclusion is simple: AI helps us synthesize and iterate faster without losing sight of why we’re doing it in the first place. That said, speed is only useful once the direction (context) is clear.

My next post will be about product marketing and go-to-market strategy — because speed without adoption is just output.

What do you think? Are we getting better at building products or only faster?

References:

• Torres, Teresa. Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value. 2021.
• Bitesize Learning. “The Double Diamond Design Process, Explained.”