In many SaaS companies, Product Managers decide what gets built, then Product Marketing Managers decide how to sell it. This sounds tidy on a slide. But in my experience across B2B technology businesses, that separation can slow go-to-market progress.
When PMM enters only after development, customer feedback can become a messaging problem to solve—even when it points to something deeper in the product experience.
The illusion of clean separation
PMs and PMMs draw from the same raw material: customer interviews, competitive intelligence, usage data and market movements. The difference lies in the questions they ask.
- PMs pursue product truth: what should change in the software to solve a functional problem?
- PMMs pursue market truth: how do customers describe that problem, evaluate alternatives and justify a purchase internally?
A capability can solve a functional problem while leaving customers uncertain about where it fits into their work. Bringing these perspectives together during discovery helps teams close that gap.
A new approach to discovery
At a fintech SaaS company serving debt recovery teams, we introduced advanced capabilities that we believed addressed needs identified during discovery. Yet early market-facing conversations revealed that prospects struggled to connect the functionality with their existing recovery workflows.
As the product marketer, I saw an adoption problem surfacing through market feedback. We brought those insights back into discovery and reconsidered onboarding, demonstrations and workflows.
The practical lesson was to give customers one complete task to follow. An illustrative reconstruction shows what that change involves.
A feature-led demo might move through a dashboard, configurable rules, communication options and reporting. Each capability makes sense individually, but the prospect has to assemble the operational story.
A workflow-led demo follows one customer account: understanding its status, identifying an appropriate next action, showing where human review is required and recording the outcome. The sequence makes the responsibilities of the software and the recovery team explicit.
The change is specific: organise the demonstration around a recognisable task, with a clear beginning and end. That same task can become the starting point for onboarding.
What was the result?
The original experience exposed a gap between functional capability and customer understanding. The intervention aimed to make the product’s place in the recovery process easier to recognise.
I do not have reliable historical before-and-after figures, so I would not attribute a conversion uplift or shorter sales cycle to it.
The useful distinction is between showing that customers understand individual features and showing that they can explain how the product fits their work. For teams applying this approach, evidence should include progression to a scoped evaluation, completion of the first meaningful workflow and time to reach that outcome.
Qualitative feedback matters too, but it should be reported accurately. Questions about implementation and approval requirements can indicate practical engagement; they do not, by themselves, establish improved adoption.
What PMM does on a discovery call
PMM participation means testing the interpretation behind a customer request.
Consider an illustrative example. A prospect says: “We want more automation in our collections process.” The team could immediately interpret that as a request to automate additional actions.
A PMM can challenge the assumption by asking: “Which actions should happen automatically, and which still need someone’s review?”
The answer might reveal that the buyer’s priority is consistent execution within agreed controls. That would change the next step: the team would explore review points, exceptions and responsibilities alongside automation.
The PMM’s contribution is to clarify the desired outcome before a request becomes a feature or a market promise. Hearing the answer together gives PM and PMM a shared basis for decisions, without losing the context in a later summary.
Messaging friction as a strategic signal
The effort required to explain a product can reveal unresolved decisions beneath the messaging.
An increasingly technical or conditional value proposition may indicate that the target customer is too broad, the core outcome is unclear or the narrative does not match the customer’s understanding of the problem.
This is where the atomic unit of value becomes useful: the smallest complete outcome a customer recognises as valuable.
In a debt recovery workflow, an example would be helping a specialist identify, review and record an appropriate next action for a customer account.
A dashboard supplies information. Rules inform a proposed action. A review step provides control. Together, they support a complete task. That outcome gives discovery, demonstrations and onboarding a common focus.
What an unstable product definition looks like
On one launch, Sales struggled to articulate the customer outcome despite training. We paused the rollout and revisited the positioning.
The exact historical descriptions are unavailable, but an illustrative example explains the instability. One salesperson might describe an offering as “collections automation”, another as “customer engagement” and another as “workflow management”. Each description could reflect a capability while creating different expectations about the buyer and primary use case.
An illustrative before statement is:
A platform for automating collections and improving engagement.
A more specific formulation is:
A digital debt recovery solution that helps teams manage customer journeys through configurable workflows and customer communication.
The second statement identifies the task and operating approach more clearly. These are illustrative formulations, not the original positioning statements.
The important work happens before the wording: agreeing whom the product serves, which outcome leads and what the offering can support.
My role—and who decides
My contribution as a PMM was to bring customer interpretation and go-to-market implications into product discussions: where prospects were confused, which expectations the narrative created and what might obstruct adoption.
I cannot reliably identify the final decision-maker for the historical launch. The decision model I advocate is explicit: Product owns scope and technical feasibility; PMM owns positioning within those boundaries; a designated launch owner resolves cross-functional readiness decisions.
When the perspectives conflict, the discussion should make the consequence concrete. What expectation are we creating? Can the experience fulfil it? What needs to change before launch?
Launch readiness as a stress test
A launch tests whether the product promise can travel across the organisation.
Can Sales explain the outcome? Can Customer Success help users reach it? Can Support describe the boundaries? Does the demonstration show what the positioning promises?
Difficulty answering these questions may reveal an enablement gap, an unclear proposition or an experience that needs further work. More training helps when knowledge is missing. It cannot settle unresolved product decisions.
Structural alignment requires shared access to customer evidence, joint interpretation, PMM participation in discovery and early testing of the narrative against the experience.
Customers encounter one product, one promise and an outcome they expect to achieve. The PM–PMM overlap is where teams connect those elements—and where customer understanding can still change what gets built.
