Technical PM. Data PM. Growth PM. How Did We Get Here — And Who Are We Deceiving?

Something has been bothering me for a while, and I want to say it plainly.

The product management community has spent the last few years carving itself into increasingly specific job titles — Technical Product Manager, Data Product Manager, Growth Product Manager, AI Product Manager, Platform Product Manager — as if the role had somehow become too large for one person to hold. And on the surface, that argument sounds reasonable. Products are more complex. Technology is moving faster. The skills required are broader than they were a decade ago. Specialisation, the thinking goes, is the rational response to complexity.

I disagree. And I want to explain why — not by dismissing the people making this argument, many of whom are smart and well-intentioned — but by pointing to the gap between the theory of PM specialisation and the reality of how most companies, particularly startups, actually operate.

Because here is the question nobody in this debate seems to be asking: if we are specialising the PM role into technical, data, and growth tracks, who exactly is doing the parts we are leaving out?

---

Aakash Gupta, a growth expert formerly at Apollo, Affirm, and Google, has been one of the most vocal voices on this: general PMs are losing ground. Companies want specialists. An AI PM. An API PM. A Consumer PM. His argument is rooted in real data — LinkedIn's Emerging Jobs Report shows Technical PM postings up 38% year-over-year. The logic follows: as products become more technically sophisticated and data-intensive, you cannot expect one person to be deeply fluent in engineering architecture, behavioural analytics, and growth loops simultaneously. Go deep somewhere. Be the expert.

And at the largest tech companies in the world — the Metas, the Googles, the Stripes — this argument holds. When you have forty product managers, you can afford to have one who goes deep on infrastructure, one who owns the growth funnel, and one who sits closest to the data platform. The organisation has enough headcount to divide the work without anything falling through the cracks.

That is a real context. The problem is that it is a vanishingly rare one. And the advice being handed down from that context is landing in a completely different reality.

Let me describe a company you have probably worked at or interviewed with.

It is a startup or a mid-sized tech company. It has a product team of one, two, maybe three PMs. It has a handful of engineers, a designer who also does research when needed, and a marketing person who doubles as the growth function. It does not have a dedicated data analyst embedded in the product team — it has a shared one who is also supporting finance and operations. It does not have a program manager coordinating delivery. It does not have a separate Growth PM, a separate Data PM, and a separate Technical PM working in coordinated harmony.

This is not a theoretical ideal of the PM role. This is Tuesday. This is what product management actually looks like inside the companies that employ the vast majority of product managers on this continent and in most markets globally.

So when the thought leadership says "specialise into a Technical PM or a Growth PM," I want to ask: in which company? With which supporting cast? Because in the company I just described — which is most companies — the PM who says "I only do the technical parts" is leaving a gaping hole where adoption strategy should be. And the PM who says "I only own growth" is building growth loops on top of a product they do not understand well enough to improve.

PM execution is made up of two things. Not delivery or adoption. Both.

Delivery without adoption is just shipping. You launched a thing. You do not know whether it worked. Adoption without delivery is just analytics — dashboards full of insight and no mechanism to act on them.

Together, they constitute what it means to own a product. This is what makes the PM role fundamentally different from a project manager. And it is why splitting it into technical, data, and growth lanes feels, to me, like a solution to a problem that mostly exists at companies large enough to afford the luxury.

This distinction matters, and it keeps getting muddied. Let me be direct about it.

The project manager coordinates what was decided. The product manager decides what gets coordinated.

Now here is where the irony gets painful: in most startups and growing tech companies in Nigeria, Kenya, South Africa, and across the African tech ecosystem, the product manager is being hired to do both. They write the PRDs and they run the sprint ceremonies and they track the delivery milestones and they report on product metrics. The job description often does not say "project manager" anywhere — but the actual work includes all of it.

So we have a situation where one person is doing the work of a full product manager and a project manager, and the discourse is telling them they should also specialise — that they should not try to do the technical and the data and the growth, because those are separate tracks.

Who, exactly, are we deceiving?

I want to be fair to the other side of this, because I do not think the people advocating for PM specialisation are wrong about everything. They are right that as organisations scale, it makes sense for certain PMs to go deeper in certain areas. A PM managing a data infrastructure product genuinely needs more technical depth than a PM managing a consumer-facing feature. A PM at a growth-stage company whose entire mandate is top-of-funnel expansion is going to develop different muscles than a PM focused on core product delivery.

These distinctions are real. The titles reflect genuine differences in emphasis.

But there is a difference between emphasis and division. A Technical PM should still understand adoption. A Growth PM should still understand delivery. A Data PM should still own the product lifecycle end to end. The specialisation is about where you spend more of your time and where your deepest expertise sits. It is not a licence to be ignorant of the rest of the job.

And that distinction is getting lost in a discourse that is increasingly treating these titles as separate disciplines rather than emphases within a single role. The product management community — especially those training and mentoring the next generation of PMs — has a responsibility to be honest about this. Telling a PM in a 20-person startup that they should be a "Technical PM" who does not worry about growth is not sophisticated career advice. It is advice that will produce people who are impressive in a job interview and ineffective in the actual job.

If I had to describe what product management execution looks like in the companies where most PMs work, it is this:

Enough technical fluency to be a real partner to engineering — to understand the system your product lives in, to ask intelligent questions about implementation, to write acceptance criteria that engineers can actually work from, and to make informed trade-off decisions when constraints force you to choose between scope, time, and quality.

Enough data literacy to own the post-launch question — to understand your funnel, interpret your cohort data, identify where users are succeeding and where they are falling off, form hypotheses about why, design experiments to test them, and translate what you learn into product decisions.

Enough growth thinking to connect those product decisions to business outcomes — to understand that adoption is not just a marketing problem, that the product itself is a growth mechanism, and that acquisition means nothing if activation and retention are broken.

And you need enough of all three — simultaneously — because in most of the companies where you will work, nobody else is doing the parts you skip.

---