What growth marketing taught me about product management
The growth-marketing habits that make product managers better: start with user language, test the smallest useful bet, and measure what changes a decision.
Niels Kaspers
TL;DR
Growth marketing taught me that product decisions improve when they start with a real user problem, make one falsifiable bet, and measure a behavioral outcome—not when they start with a feature list.
Growth marketing taught me product management before I had the title.
Not because marketing is a shortcut to product. It is not. Product work has its own disciplines: shaping a coherent system, managing technical tradeoffs, and carrying responsibility after the launch.
But good growth work forces a useful kind of honesty. You have to name the user, state the behavior you want to change, make a bet small enough to test, and learn from the result. That is also the core of good product management.
My path ran from growth marketing into product leadership: experimentation work at NU.nl, product teams at Whisbi, then growth product work at Picsart. At Picsart, I helped build Quicktools to 10M monthly users and $1M ARR, while the wider web work connected acquisition, product surfaces, and conversion. The work repeatedly made the same lesson clear: a feature is not a strategy just because a team can build it.
The marketing skills that make product managers better
The useful crossover is not campaign language or a funnel diagram pasted into a roadmap. It is a set of operating habits.
Start with the language users already use
Marketing punishes vague positioning quickly. If you cannot describe the problem in words a user recognises, the landing page gets fuzzy, the paid message gets expensive, and the experiment produces ambiguous data.
Product teams have the same problem, but it can hide behind internal vocabulary. A roadmap says ‘improve activation.’ A user says ‘I do not know what to do after I sign up.’ Those are not equivalent starting points.
The ONS guidance on user needs makes the practical standard clear: use plain language, lead with what users need most, and avoid including information that does not serve that need. I use the same test before turning a problem into a product bet. Can I say what is hard for the person, in their words, without describing my preferred solution?
That discipline mattered when building product-led search surfaces too. How I built Quicktools from 0 to 10 million users was never just a traffic story. The useful work was connecting specific search intent to a tool that completed a real task.
Turn a feature request into a falsifiable bet
Growth work trains you to ask what would prove you wrong.
‘Add templates’ is a request. ‘If first-time users see three task-specific starting points, more of them will complete their first export without support’ is a bet. The second statement contains a user, a change, and an observable outcome. It can fail usefully.
This matters more now that AI can generate a convincing prototype before lunch. Fast output is valuable, but it can make an untested idea feel more legitimate than it is. The prototype should reduce uncertainty, not end the conversation.
For prioritisation, the GOV.UK Service Manual recommends grounding decisions in performance analysis, user research, and stakeholder input, rather than treating a backlog as a queue of feature requests. That is close to the growth mindset: do not ask only whether the idea is possible; ask what evidence says it is the next useful thing.
Care about distribution before the handoff
A product does not become useful when engineering merges it. It becomes useful when the right person can find it, understand it, and finish the job it was meant to support.
Growth marketing makes that difficult to ignore because distribution is part of the work from the beginning. What will this be called? Where will a person encounter it? What context do they need before they act? What promise can the product actually keep?
That is why I think product pages need more than a feature grid. In Why your product page needs a context layer, I made the case that the surrounding explanation should help a visitor understand when a product matters—not merely list what it contains.
For a PM, this changes discovery. Distribution questions are not a launch checklist. They are a way to find gaps in the product proposition early. If the team cannot name the moment of need or the route into the workflow, it may not understand the problem well enough yet.
Measure behavior, not activity
Growth teams can overdo metrics too. Clicks, impressions, and experiments are easy to accumulate. The useful question is whether the metric represents a better user outcome and a better business outcome.
The same goes for product dashboards. A feature shipped, a prompt run, or a document generated is not automatically progress. For a tool, I want to know whether someone completed the job with less friction. For a workflow, I want to know whether the team made a clearer or faster decision without losing the evidence behind it.
This is one reason I keep returning to decision systems. How PMs should keep a decision log so AI stops resurfacing rejected ideas is about making the reasoning retrievable, not generating more notes. Metrics need the same treatment: they should help a team decide what to do next.
A small product bet template
When a feature idea arrives, I try to reduce it to five lines before discussing scope:
Interactive
Product bet check
Use this before turning a feature request into a roadmap commitment.
Completion
This is the gap between understanding the article and actually using it.
- Use this block as the practical summary, not just the article ending.
- If one item feels vague, the article probably needs sharper guidance.
- A short checklist beats a long recap when the reader needs to act.
The checklist is deliberately plain. It is not a scoring framework. It is a guard against confusing internal enthusiasm with evidence.
What marketing did not teach me
The crossover has limits. Growth can tempt teams to optimise the visible step while ignoring the system behind it. Product managers still need to understand the technical constraints, long-term product quality, support burden, and strategic cost of a decision.
That is why the best product-growth work is not ‘growth versus product.’ It is a shared loop. Product makes a better promise possible. Growth exposes whether people understand and want it. The result informs the next product decision.
At small teams, that loop can be unusually fast. The people who write the product sentence may also inspect the funnel, talk to users, and watch the support issues. That proximity is an advantage if the team uses it to learn instead of merely shipping more.
My take
Marketing taught me to respect the moment before a build starts. The useful question is not ‘can we make this?’ It is ‘whose problem becomes easier, what behavior should change, and what would tell us we were wrong?’
That is not a marketing trick. It is product judgment. In an era where AI makes output abundant, it may be one of the clearest ways for a PM to stay valuable.
FAQ
Can someone move from marketing into product management?
Yes, especially when they can translate user research, experiments, positioning, and behavioral data into product decisions. They still need to develop technical judgment, delivery discipline, and ownership beyond the launch.
What marketing skills are most useful for product managers?
The strongest are user-language research, clear problem framing, experiment design, distribution awareness, and measuring outcomes instead of activity.
Do product managers need to own growth metrics?
They need to understand the metrics that reflect whether their product is helping people and the business. Ownership varies by team, but product decisions should not ignore acquisition, activation, retention, or support signals.
Does AI make growth experience less useful for PMs?
No. AI can make assets and prototypes cheaper, but it does not replace judgment about the user problem, the test, or the evidence needed to make the next decision.