Are you a Data Product Manager, or do you just have the title?
Rambling about the DPM role, and two bonus sections at the end
Hello and welcome to the first newsletter since I rebranded this Substack 🎉 I thought I’d go for a slightly more descriptive name: Value from Data & AI 😁
In today's newsletter:
How the rise of data product management has also come with a hefty wave of companies rebranding existing roles as "Data PM", how spot how much that describes your role, and how to get unstuck
I'm working on a Data PM course! Call for feedback and interest
Upcoming data product management event in London I’ll be speaking at
Main article: Faux DPM-ness
In the past two years, we've seen a remarkable surge in Data Product Manager (DPM) roles, with the number nearly doubling since 2022. This growth is exciting, signalling a shift towards more product-oriented approaches in data work. However, it also raises a critical question: Are all these new DPMs truly doing data product management, or are we seeing a wave of role rebranding without fundamental changes in responsibilities and approaches?
As someone who's been in the data product management space since 2017 (nevermind that we didn't call it that back then), this fills me with both optimism and cause for concern.
On the one hand, businesses are waking up to the importance of having that value-focused intermediary role between business and technical teams. Twelve years ago, the hype was on Data Science - "the sexiest job of the 21st century" (HBR). More recently, the same authors that used that phrase came back to argue that "your company needs data product managers".
On the other, this wakeup is often too superficial: Companies are rebranding existing roles without making the deeper changes to their operating models or upskilling their staff in order to meaningfully transition into developing data products and applying product thinking to data work.
Outline of this article:
Why I'm worried about the rebranding of traditional governance & management roles into data product managers
How to spot whether you're in that 'rebranded DPM' bucket or not
Pre-empting the "you shouldn't be gatekeeping" response
Some thoughts on how to get unstuck
The "Copy Your Homework" Trap
A common pitfall for companies playing innovation catch-up is the tendency to replicate the practices of successful organisations without fully understanding them. It can be helpful to see what good looks like for others, but that's not the same as understanding the why behind it.
Case in point: When stories about the 'Spotify Model' emerged, many companies moved to imitate it, thinking that's how Spotify continues to work today - but actually Spotify never really implemented that model after sharing it with the world. Despite the co-author of that model telling people not to imitate it, I've met lots who have tried to - and I myself was guilty of this a few years back.
So what's going on? Why are we playing house?
Product Management is a very expansive discipline. There's so. many. things. to learn about. Software engineering. User research. UX design. UI design. Opportunity Discovery. Data structures. Stakeholder management. Legals. Go to market. Sales. Marketing. Partnerships. Licensing. Pricing. Financial modelling. Unit economics. User personas. MVPs. A/B testing. Prototyping. APIs. Data analytics. Copywriting. Influencing without authority. Product strategy. Project management. Testing. Performance monitoring. Branding. Market research. Domain knowledge.
The list goes on...
You don't need to be a master at all of the above, but most PMs end up needing to build up knowledge in most of those areas over time. Depending on your product focus, you may be more focused on the back-end (platforms, APIs, engineering teams), or the front-end, or on go to market and distribution, and so on.
But if you've only ever dealt with, say, one or two of those things, it's going to take some time for you to build up a sufficiently well-rounded skillset to be able to do the job effectively. If you've only ever developed data pipelines or acted as a scrum master or built BI reports, but now you've been told you're the team's Data PM, at a minimum you may need to learn the basics of opportunity discovery, prioritisation, learn about parts of the technology, learn about the underlying data, understand the domain and processes of your users and stakeholders... And doing all those things will in turn require you to either have or develop various soft skills that your previous role may have not been as conducive to developing.
This isn't a call for despair. Yes, product management is hard. No, it's not something you can sit through a week-long course on and instantly emerge ready to be a star player. No, I don't care if you have a certificate that says otherwise. But that's okay! Product management is one of those jobs where on-the-job learning makes up the bulk of your learning and development. Books, podcasts, articles, and courses are great, but they'll only act as scaffolding to help you get the hang of it - they'll never be an A-Z blueprint for how to do the job.
One of the most critical competencies a Product Manager can have is an aptitude for learning. Even if you've been a PM for 10 years, every time you switch roles or companies is in many ways like starting from scratch: New product, new customers, new industry, new stakeholders, new internal politics. Of course, your toolkit will have many skills you can re-use, but a lot of the knowledge you'll need will be completely new. If the prospect of having to learn new skills and concepts continuously excites you, take that as reassurance that Product is very likely a good fit for you.
By the way, this rebranding phenomenon isn't unique to data product management, which is much newer than product management as a whole. Product Managers of all kinds find themselves in anti-patterns like feature factories where PMs are nothing more than backlog managers, and unempowered product teams all the time - especially when large corporates decide they want to be more like those Silicon Valleytech firms that seem to innovate so much faster than them.
To avoid this trap, we need to look beyond titles and truly understand what data product management entails.
Does your DPM title reflect your actual day-to-day?
The other day, I posted a 10-point list of warning signs that your DPM title might not quite match your responsibilities. You can go over that list and see how many points line up with your day to day. Alternatively, I've re-written it as four dimensions relating to DPM work below:
Think of these as a spectrum / sliding scale. Chances are, where you sit on each of the four dimensions will correlate - but you may e.g. be quite far on the right in the first 2, and fairly close to the left on #4.
Reflect on where you fall in each of these areas. If you find yourself consistently on the left-hand side of these dimensions, it might be time for some tough love: You may have the title, but you might not be doing the work of a Data Product Manager.
BUT don't take this as an extreme either: You might be doing a lot of great data product work and still be somewhere in the middle on some of these. I know I often am! For example some quarters are much more deadline-/project-driven than product-oriented, and if I just look at that quarter in isolation it can feel like a big regression. But on the macro level, it's (hopefully) still product- and impact-oriented work.
I can hear you object: "This is gatekeeping - there is no single 'true' way to do Product!"
Yes and no. It's gatekeeping in the sense that I am arguing that there are folks who are doing the work of a product manager (which is a VERY broad umbrella), and others who are not, despite having the title. Being clear about what different roles are about helps create clarity around expectations, and helps folks identify the right learning & career development paths.
To give a different example of this: I think it's quite shit that many companies decided to rebrand their analytics roles as 'data scientist', just because folks don't want to apply for 'data analyst' roles anymore (Facebook is the most prominent example of this, where all its product analysts are called data scientists - why?!). It's a weird mix of title inflation and incorrectly treating analytics as inferior to data science, rather than separate discipline that companies treat as a second-class citizen at their own peril.
If you're clear on the role you're doing or skilled at, you can find appropriate courses, subscribe to relevant podcasts, apply to jobs that are a good fit, and get an idea of what your next professional step might look like. Data is a relatively nascent profession - unlike accountants or engineers or lawyers, we've only been around for a few decades, and the work has changed in some pretty meaty ways since the early days of Business Intelligence and Big Data (though other fundamentals have stayed broadly the same).
If Data is a nascent profession, Data Product Management isn't even out of the maternity ward yet. We can't agree on the definition of a data product or if data-as-a-product and data product are the same thing. But that's not an excuse for not trying to converge towards common standards and approaches! It's just an illustration of why doing so is hard.
Let me be clear: This isn't about gatekeeping or making anyone feel bad about their current role. The point is to encourage critical thinking about whether your role truly embodies product management principles or if it's a rebranded version of previous work. I have no issue with a project manager, data steward, or analytics manager upskilling to transition to data product management. I also have a lot of sympathy for folks who are thrown into that new role without much training to start with - they'll figure it out (eventually).
BUT it's essential for us to know when we're in "fake it till you make it" territory, so that we can focus on 1️⃣ identifying skills to develop, and 2️⃣ steer the wider organisation towards towards the right ways of working.
Let me expand on that last part: Whether a Data PM "isn't really doing product work" is largely not about the individual in question, but about the org structure, ways of working, and goals & objectives they find themselves having to deal with.
BUT that is not an argument to resign your fate to the organisational design. By learning and applying core PM skills like opportunity discovery and prioritisation, spending time with users, and collaborating closely with your technical team, you can start shifting your team's operating model away from a 'rebranded' data team that's stuck in a service-oriented model into one that's actually working more and more like a product team. It won't and can't be an overnight change - but that's fine.
So how do we move forward?
I've been through this cycle multiple times in my career. I'd go so far as to say that I've never been hired to do a fully Product-y role, but turned each one around to become that.
Awareness is the first step: Sometimes, especially earlier in my career, I didn't realize I was approaching things the wrong way. It was only after learning more about product management and related fields that I understood there were better ways to do things. I'm sure there's things I do today thinking they're the right way to do things that I'll look back and cringe slightly in 2/5/10 years' time.
Err on the side of outcomes over outputs: Your manager and/or stakeholders will likely think of you as a project manager (maybe a "project manager+", because you can do some other stuff too). By default, they'll be giving you work that fits that worldview. But, just like a PM does with their users, it's up to you to probe deeper, ask why, and understand what are the business results they're looking for - and then work to achieve those results. This will sometimes be about asking for permission, but most of the time it'll be more about asking for forgiveness. For example, if you just suggest in one sentence an alternative, it'll probably get shot down. If you spend a few hours on a more elaborate plan, proposal, or design for a better way to do things, it's more likely to be accepted - even if it's pitched as just a trial/experiment. If you go away for a week and deliver the result itself, only the worst of bosses will be pissed off (which is a 🚩).
Show, don't just tell: I've had much more success by doing the work I thought was needed and presenting the results, rather than just arguing about approach. Evidence is more compelling when it's tangible outcomes, not just a narrative. (I keep having to remind myself this when my theory-based objections fall on deaf ears - it's normal!)
In short, it's a bit of a 'fake it till you make it' angle - but not in the way we usually think of the term.
By the way, this section could be a whole talk or article, but I've tried to keep it fairly high-level. If you'd like to discuss your situation in greater depth, book a call and let's problem-solve together!
Closing thoughts
The rise of Data Product Management is an exciting opportunity for organisations and individuals to transform how they approach data work. I genuinely think it's the last major missing piece in the value equation for data, and it's why I spend so much of my time outside of work learning and sharing about it.
But if we want to be serious about reaping the benefits, we have to go beyond surface-level theatre and embrace the fundamentals of good product management.
Whether you're a DPM, aspiring to be one, or working with DPMs, I encourage you to continually assess what you're doing, whether it's adding value, and how you might do things differently. We can't do this if we're on autopilot - and if you're reading this article, there's a good chance you're already going sufficiently out of your way to ensure that.
I'd love to hear what others thing about this - feel free to drop a comment, a DM, or chat f2f at the next data product management meetup 🤗
📚 Call for interest: Data PM course
It's a pretty poorly-kept secret at this stage, but I've been working on creating course(s) for data product managers. I think there is a real gap for both aspiring and current Data PMs, and I'm trying to find as much spare time as possible to work on materials to help both.
Here's the tl;dr of what I'm working on (subject to change!)
Format: Live cohort-based course (meaning it's live and with classmate interaction)
Location: Online (with the option to do it in person for companies/teams as internal training)
Topic: Value (How to identify and define high-value opportunities, but also how to then get the right credit/recognition for the value you're adding to your org)
Duration/commitment: Short. Max 10 hours, spread over 1-2 weeks. Ideally it would be over one weekend or a couple of after-work slots.
Why a live cohort-based course? Why not just record some videos and sell them forever, like on Udemy?
I'm a bit biased because on-demand courses haven't worked well for me, but I think the evidence is also on my side for this one.
At a high level, here's the reasons for it:
High completion rate: Online on-demand courses have a completion rate of 3-6%, while it's quite rare for a cohort-based course to not be completed (>80%) (source)
Community and peer learning: Interacting with fellow learners is both conducive to better learning and a great way to meet others on a similar journey. Given how niche and nascent data product management is, meeting others is super valuable - it's why despite not living in London anymore, I still make the effort to host the Data PM meetup on a regular basis.
Early stage feedback: Like any new product launch, I want to learn quickly to improve the product as well. If something is missing from a live lesson, folks ask questions that you can answer live (or in a future class), and you then incorporate it in the curriculum properly for the next cohort.
Time to launch: Partly because of #3, and partly because a live course tends to be more focused than the broader-curriculum of an on-demand course (think "DPM 101"), I can get something launched faster if the focus is more narrow. I'd love to create a more expansive DPM foundations course for folks looking to transition into the role from a role like data science or analytics, but that'll take more work to do well. I don't want to ship a half-baked product that won't actually help people.
Does the above resonate with you? Is there a different topic/focus you'd be more interested in? Would you rather get a course on demand? I'd love to hear your thoughts!!
Drop me a message with your feedback, and let me know if I should add you to the waiting list for it!
🎤 IRL Data PM event in London on 31 July
The wonderful Ben Moulton and his recruitment company Orbis are hosting a Data PM event together with Trainline later this month.
Location: Trainline London HQ
Date: 31/07/2024
Time: 18:00
Agenda:
Talk by Mike Hyde (Trainline CDO)
Talk by Allison Busacca (Trainline Director of Product)
DPM panel discussion with myself, Marcelo Vireia (Skyscanner), Luis Garcia-Baquero (Spotify), Deena Rashid Shahrabani (Trainline), and chaired by Matt Smith (Data Delivery Director at Trainline)
How to attend: Sign up here
PS: Ben specialises in recruiting data product managers - a great person to know if you're looking to hire or be hired in the UK & Europe!
What do you want to see next?
I’ve got a few drafts in the works - which are you most interested in seeing next?