That’s exactly why I asked to write this guest article. James is a former CDO and now Director at Anmut, so he’s been on both sides of the table - building the case and being the person who decides on it. His piece covers what executives are really weighing up when your proposal lands on their desk, and why a strong business case is often the beginning of the conversation, not the end.

The Business Case Isn’t the Decision: What Execs Are Really Weighing When You Leave the Room

by (author of )

You’ve just delivered the perfect pitch for your data project. The ROI is clear, risks are mitigated, the timeline realistic. Your exec sponsor nods thoughtfully.

“Let me think about it,” they say.

Three weeks later: tumbleweed.

Or worse - the project is approved, but with half the budget, a compressed timeline, and a jump-scare “co-ownership” arrangement with a team that wasn’t even in the room.

As data professionals, we’re trained to believe that good analysis leads to good decisions. Build a solid business case, quantify the value, demonstrate feasibility - and rational actors will make rational choices.

Right?

Well, any data leader bearing boardroom scars will tell you that’s not always how it works.

The business case is your opening gambit, rarely fait accompli. Once you leave the room, another conversation takes place- one where your carefully constructed ROI model is just one among many factors that may affect the outcome.

This article is about that hidden conversation: what execs are really weighing, why even strong business cases stall, and what you can do about it.

Three questions execs ask that you (may) never hear

Let’s be clear—we do need to demonstrate impact. A solid business case is the price of entry into any sensible boardroom discussion.

Yet while you’re presenting your case, execs are running parallel calculations about risk, politics, and organisational reality. Here are three examples.

1. “Does this help me or hurt me?”

This is a question few say out loud, but believe me, it’s one of the first filters every exec applies. People aren’t neutral evaluators. They have their own goals, performance targets, risk tolerance, and incentives.

They’re asking:

“Does this project advance what I personally care about? Or does it represent a risk I’m unwilling to carry?”

The calculus can be brutal:

• Will this make me look good?

• Does this move me toward my next promotion?

• If it fails, does it damage my reputation?

• Will it require spending political capital I need for something else?

I once delayed a significant data strategy project because the main stakeholder was an interim CTO. They didn’t want to commit to strategic changes as it contradicted their aim to keep the lights on and not rock the boat. It was a decision they wanted to leave to a new leader looking to make their mark.

As data professionals, we’re not just asking for budget. We’re often asking people to put their credibility on the line for something they may not fully understand or can’t verify is working until it’s too late.

Execs have wildly different risk tolerance for betting on data projects:

• The one secure in their role with a strong track record is more likely to take a bet

• The one who’s new and under scrutiny may need far more proof

• The one who’s interim or planning on leaving is optimising for quick wins, not multi-year transformation

• The one whose incentives are skewed so badly you can’t win - like the Sales Director whose bonus is so tied to their course of action, that little you can say will sway them (I’ve been there)

You need to understand what your sponsor is personally optimising for, because it probably isn’t exactly what the business case says. Are they trying to prove something to the CEO? Do they need a win before their annual review? Have they been burned by data projects before?

If your initiative doesn’t align with their personal incentives or creates unacceptable risk, your business case may wither on the vine.

2. “What am I not being told?”

Experienced execs develop pattern recognition about what gets left out of business cases. When everything looks perfectly aligned - no friction, no trade-offs, no difficult conversations - many get suspicious.

The savviest will be sniffing out what you’re not saying: Technical debt you’re creating elsewhere. Dependencies on overloaded resources. Assumptions about stakeholder cooperation that are, let’s be honest, optimistic.

One question I’ve heard time and again, often after the data leader has left the room:

“So, what’s the real reason this hasn’t been done before?”

I once proposed a reporting mechanism across a portfolio of shopping malls. Detailed proposal, locked-down ROI, comprehensive implementation plan. My mistake was not considering organisational memory of past attempts. As a new data leader, I didn’t have the full history.

The exec knew better. There was a history of major political resistance from regional directors that went unmentioned in the business case. The project got approved (after a humbling moment for yours truly) but with a mandatory three-month “stakeholder alignment” phase that basically doubled the timeline.

The key: proactively surface the uncomfortable truths. Execs trust people who tell them what could go wrong more than people who promise it won’t. They’ve seen enough sanitised business cases to know when someone’s hiding the messy bits.

3. “What trade-offs need to be made to fund this?”

Every yes is multiple nos.

Execs aren’t just weighing your project against other data initiatives. They’re thinking about organisational capacity - not just budget, but attention, political capital, the company’s finite ability to absorb change.

Your data initiative isn’t competing against other data projects. It’s competing against:

• The sales team’s territory expansion the CEO promised the board

• The product launch that’s already behind schedule

• The cost reduction program the CFO needs to hit margin targets

• The “quick win” that makes someone look good before year-end

I once saw a use case for predicting shopping behaviours (£4M value over three years, proven technology, passionate exec sponsor) get killed in committee. Why? Marketing made a more compelling case for a customer-facing app that needed the same time-limited technical team AND the CEO had already committed to it.

The predictive project had an objectively better business case. But it was competing in a portfolio-level game where promises had been made elsewhere.

You need to understand what else is on the table and how your initiative stacks up in the broader context. This goes way beyond the data portfolio.

Why your £2M ROI loses to their £500K project

The Execution Confidence Discount

Whether fair or not, many execs mentally apply a “delivery discount” based on your track record. It’s not just about expected value - it’s about the cost of failure and your own credibility/political capital.

I’ve seen significant data initiatives go unfunded in favour of projects with lower value but which the organisation believes are more likely to succeed.

Your credibility and track record are part of your business case, whether you include them or not. Data teams carry specific baggage here with a history of over-promising, obsession with tools over impact, underestimating change management, and “90% done” projects that never close the last 10%.

Data teams that present like service desks rather than business enablers tend to attract an unfortunate reputation.

Strategic Narrative Fit

Some projects just “feel right” because they align with the story leadership is telling.

CEO talking about “AI-first strategy” to the board? Your ML project gets a narrative boost. Company in cost-cutting mode? Even brilliant growth initiatives get deprioritised. New exec looking to make impact in their first 90 days? Small, fast projects trump optimal long-term plays.

As data leaders, we need to ask: how do our projects fit the story of the business today? Note: this story may well be at odds with stated business goals. It may even be at odds with what you’re expected to do.

There’s a Japanese concept called “reading the air” (kūki wo yomu) all about sensing unspoken cues, atmosphere, and group dynamics to understand what’s really expected. This is an advanced skill gained from repeated exposure to the business, but every data leader needs it.

Organisations move in a direction (which can change often), and initiatives that accelerate that movement have built-in momentum. The ones that don’t - even if objectively better- are swimming upstream.

Reversibility Bias

Execs favour decisions they can undo quietly if things go wrong.

A marketing campaign that flops? Stop spending. A data platform that fails? You’re stuck with vendor contracts, half-built infrastructure, and organisational scar tissue that makes the next data proposal even harder to sell.

This is why “pilot” and “proof of concept” get approved when “enterprise rollout” doesn’t. It’s not that execs don’t see the bigger value - they’re pricing in the option to cut losses.

Frame your initiative in phases with clear exit ramps. Show them how they can pull the plug without being locked into multi-year commitment. You’re making it easier to say yes, as well as safer, overall.

Playing the Game

Once you understand what execs are really weighing, you can address those concerns directly rather than hoping your ROI overwhelms them.

Make the risk conversation explicit. Don’t wait for execs to ask what could go wrong - tell them. Include a “what could go wrong” section in every business case. Not dry risk registers with traffic lights. Specific scenarios: “The biggest risk here isn’t technical- it’s getting regional sales teams to actually use this. Here’s what we’re doing to address that before we build anything.”

Understand personal stakes. You need to understand what people are personally optimising for. Ask them (diplomatically): What does success look like for you personally? What are you worried could go wrong? What else are you being measured on this quarter? I’ve said it a thousand times - data is a people business, whether we like it or not.

Position within the portfolio. Don’t sell your project in isolation. Show how it enables other priorities. Find a way into the boardroom (all the best CDOs have). Talk to people who attend board meetings. Ask: “What’s taking up most of the oxygen in leadership meetings right now?” Then position your initiative as an enabler of those priorities.

Build trust first. If you don’t have execution credibility, don’t ask for the big bet. Start with something small, low-risk, and high-visibility. Deliver it early. Communicate the win. Use that credibility to ask for something bigger. This is painful when you can see the big opportunity sitting right there. But trying to skip this step is why strong technical leaders stall at director level. Trust is the hidden variable in every business case.

Increasing your chances

Even when you do everything right, you might still get a no.

The timing is wrong. The political landscape shifted. Someone else’s project is more important. Or the exec team simply doesn’t believe your team can deliver, fair or not.

This isn’t a game you can win purely on merit.

Data professionals hate this. We’re trained to believe that good analysis leads to good decisions, that facts win arguments, that rationality prevails.

But organisations aren’t rational- they’re human. Decisions get made based on trust, politics, timing, risk tolerance, personal incentives, and factors you can’t fully control.

There is a maturity shift: Junior data leaders think their job is to build the perfect business case. Senior data leaders know their job is to understand the decision-making environment and navigate it strategically.

The difference is about being better at “reading the air,” building relationships, picking your battles, and knowing when to push and when to wait.

Once you stop expecting decisions to be purely rational, you can start playing the actual game. Build relationships that create trust. Demonstrate execution capability through small wins. Position your work within broader strategic priorities. Address the real concerns execs have, not just the ones they voice in meetings.

I get it. To the rationally minded, this may seem painfully political. But the most impactful data leaders have learnt how their organisations work and become effective within that reality.

The truth is that your business case is less about proving you’re right than helping execs make a decision they can live with.

The numbers matter. But they’re not the decision. They’re the starting point for a much more complex calculation about risk, trust, timing, and strategic fit.

PS: If you liked James’ guest article, you should definitely check out his Substack, !

In other news…

1: James also came as a guest in our DPM community webinar last week! The topic was related -but separate- to that of this article: Data as an Asset: From IT Artifact to Business Value.

If you’ve already joined our new DPM community platform on Circle, the link above will take you straight to the recording. If you haven’t joined yet, you can do so in less than 1 minute via this link.

2: I’ve become obsessed with Claude Code. I’ve accidentally built a personal operating system for myself (CRM, task management, knowledge management, workflow automation). And it all happened organically during one of my busiest months in years - this wasn’t some funemployment procrastination project 😆

I’ve genuinely never been more excited by AI, and I’ve been working in data science for the last ten years. It’s been thanks to the confluence of three things:

1. Claude Code working off local files unlocks so many more possibilities for reuse, automation, and self-improvement (the ‘self’ being Claude I mean - but me also)

2. Yes, the new models (Opus 4.5 & 4.6) have really been that much better than anything before (if you don’t believe me, here’s what Andrej Karpathy had to say last week)

3. Add Wispr Flow to all of the above and suddenly ‘10x productivity’ isn’t as sci-fi as I would’ve dismissed it a few months ago

I’ll be sending out some resources (tutorials, starter prompt, and sort of stuff) in the coming days. I’ll share these here too, but if you want to get an email specifically about it, leave your email here.

3: The Data & AI Product Management online community is growing. We haven’t officially launched yet, but over a hundred people have already joined. If you’re a data or AI leader looking for a space to talk strategy, value, and getting things funded -without the vendor noise- come and have a look. Join here.

Upcoming community webinars:

• March 9: What does a Data Platform PM actually do? (with )

• March 18: 50 Data Products in 4 Years: What DS Smith Got Right (and Wrong) (with Adrian Pinder)

• March 26: EU AI Act Explained (with Hamish Silverwood)

Plus, I’m gradually getting us more and more perks and freebies:

So, yeah. You should join! It only takes 30 seconds 👇

Join the DPM Community

After 2.5 years of running data & AI product management meetups in London and Barcelona (and inspiring folks to start their own in Montreal and Paris), I’ve been meaning to document the insights from our discussions. These conversations are too valuable to stay in the room!

So when (who started the Montreal DPM meetup!) took wonderfully detailed notes during our September session, I knew it was finally time to make this happen.

On Tuesday, September 23, 2025, the Data Product Management Meetup in London brought together data enthusiasts to explore data monetisation - specifically, how to launch a data service beyond your core business offering. Most participants were from organisations where data isn’t the primary product.

Below is a structured summary of the key takeaways. It’s not a comprehensive guide, but a collection of thought starters and reflections from the session.

A big thank you to for writing 90% of the below article, to Graham Libaert for reviewing it, and to the other 5 roundtable participants for an excellent discussion last month (we’re keeping the other names private, because we operate under the Chatham House Rule).

Lastly, special thanks to Harbr Data for sponsoring September’s meetup, and for being our most active supporter since the community’s inception 🙌

What Is Data Monetisation?

We started by clarifying our terms. “Data monetisation” typically refers to one of two definitions:

The narrow definition: Selling data externally

• Represents a new revenue stream by offering data as a product or service to external customers

• Requires a robust go-to-market strategy, including marketing, sales, and customer support

• Requires strong data governance to tackle data quality, access control, and compliance issues that, if neglected, can lead to financial or legal consequences

The broader definition: Making money from your data

• Focuses on optimising internal data usage and evaluating data value

• Typically managed by data teams operating as cost centres

• May involve chargeback models to allocate costs within the organisation

Our discussion focused primarily on external monetisation (i.e. the narrow definition).

Finding Your First Customers

The first step is understanding who your data could serve. Unlike your core business customers, data customers may come from adjacent industries or entirely new markets. For example, a retailer’s customer data might be valuable to logistics analysts or urban planners.

Research customer pain points and explore how data can solve their challenges. This customer-centric approach ensures relevance and highlights the importance of data discoverability - making it easy for potential customers to find and engage with your data.

Look to ‘hack’ the feedback loop: Get feedback as quickly as possible! This will help guide your decision-making and investment - after all, in the early days you don’t know if your data has value (or how much).

The Power of Data Combination

Because we often don’t fully understand our prospects’ business landscapes, the real value often lies in linking datasets to create richer, more actionable insights.

For example, footfall data becomes much more insightful when combined with sociodemographics: you go from knowing how many people visited a location to understanding who those visitors are - their age, gender, or home postcode.

Making Data Discoverable

Show the Metadata, Not the Data

Make metadata visible (descriptions, sample insights, and usage context) without exposing the full dataset. This creates a “FOMO” effect: potential customers see what’s available and want to explore further.

Think of it like a storefront window: you’re not selling the whole inventory, but you’re showing enough to make people want to come inside.

Simple Signals Matter

One participant shared adding a “Become a Data Partner” button to their website. It’s a low-effort, high-visibility tactic that signals openness to collaboration and invites dialogue.

This visibility moves you from passive availability to active engagement. However, exposing data externally also reveals governance weaknesses, such as poor data quality or inadequate access controls.

The Quality Bar Is Higher for External Customers

Multiple participants emphasised this: external customers have higher expectations than internal colleagues. Data quality issues that internal teams tolerate become dealbreakers for fee-paying customers. If there’s an outage, schema change, or other incident, you could breach contract terms or lose customer trust. Unlike internal colleagues, your customers have alternative vendors.

Key takeaways:

• Get your governance in order before selling data.

• Target use cases that match your current data quality levels. For example, if your pipelines sometimes fail overnight and cause a 1-day delay, don’t target clients who need real-time data 24/7.

Packaging: Services and Delivery Formats

To meet external quality standards, invest in supporting services:

Support models: Customers need someone to talk to for onboarding, troubleshooting, or clarifying data definitions.

• Quality management: Implement validation checks, version control, and continuous monitoring.

• Incident management: Have a clear process to detect, communicate, and resolve issues quickly.

• Access control: Define who gets access to what, and ensure compliance with regulations like GDPR.

Choose the Right Delivery Format

The format should align with your customer’s technical capabilities:

• Raw Data as a Service (DaaS): Ideal for tech-savvy clients like data scientists or engineers who prefer to ingest and model data themselves. Offers flexibility but requires technical infrastructure.

• Embedded BI within existing SaaS: Designed for non-technical users who need ready-to-use insights. Dashboards or curated reports embedded into workflows reduce friction and accelerate decision-making.

• API Access: For customers who want real-time or automated integration. Supports dynamic use cases like supply chain optimisation or predictive analytics.

• Data Apps or Interactive Tools: Packaging data as a lightweight application can drive better usability, allowing users to explore scenarios or personalise insights without touching raw data.

Tailoring the packaging ensures accessibility and value, but requires a clear understanding of costs to sustain the offering profitably.

Pricing: The Hard Part

When we got to “how do you work out the right price?” there were giggles - because pricing multi-industry, multi-use case products with complex cost bases is hard.

We grouped pricing options into three categories:

1. Cost-based pricing: Add a margin on top of production costs

2. Value-based pricing: Price based on the commercial value the data enables for the client. The same data could be priced completely differently depending on use case or industry (e.g., hedge funds might pay 10x more than government departments).

3. Market-based pricing: Look at how competitors price equivalent products, especially when you’re new to a market.

Options 1 and 3 are typically low-margin. Option 2 is ideal but hardest to achieve, either because (a) you don’t have a clear idea of your data’s commercial value to clients, or (b) competitors are willing to sell for much less.

Among the group, there was consensus that pricing should be as simple as possible - complex, multi-variable pricing models make it harder for customers to understand costs and commit to buying

The other key factor influencing pricing is unit economics (the revenue and costs per customer).

Understanding Your Unit Economics

You need to know how much each sale adds to your bottom line - and whether each sale generates more than it costs.

For example, if you produce a standardised weekly dataset at a fixed cost of $1,000 and sell it for $100 per client, you break even at 10 clients. Every subsequent sale becomes profit (though there’s usually some variable cost like storage or customer success staff).

If you’re producing something bespoke for each client (e.g. custom data engineering, connectors, enrichment) ensure that extra work is reflected in the price.

Critical Questions to Answer

Key questions you should know the answers to:

• How much are we spending to deliver each data product to each customer?

• If we doubled our customer base tomorrow, how much would costs increase?

• For complex products with many dimensions, do we understand (even roughly) how each adds to cost?

• How does total cost break down into storage, compute, licenses, and labour?

Understanding these costs is essential to price sustainably and decide whether to bundle services, offer tiered access, or charge per usage.

A sustainable monetisation strategy hinges on a clear cost model that covers development, maintenance, storage, computing, and support. By parametrizing these costs, organizations can automate pricing for consistency and scalability.

For those leveraging LLMs, offering model-switching options within packages can optimize costs based on use cases.

Start pricing simple -perhaps a fixed rate- then evolve into tiered models based on factors like geography, time range, or market segment.

The ‘Free Sample’ Trap

Several participants mentioned the trap of offering free samples, especially when producing them requires custom work. Free samples are often seen as worth $0: clients don’t prioritise their evaluation, and you spend months waiting for feedback.

When a customer pays (even a nominal amount you can credit toward the final price) they’re signalling commitment. It means the data is valuable enough to get budget approval, but also for them to actually spend time evaluating the data and make a decision.

In short: Avoid giving complete datasets away for free. (We’re talking about actual datasets here, not a 5–100-line sample meant to show what’s inside.)

Selling Data Products: Working with Sales Teams

Toward the end, we explored the cross-functional collaboration required to make data monetisation work, focusing on when to use your existing sales team, how to align incentives, and how to build effective partnerships.

Should Your Sales Team Sell Your Data Product?

If your business already sells data products, you have trained salespeople. But for everyone else (supermarkets, telcos, SaaS companies) your salespeople are probably the wrong fit, at least initially.

In the early days, you likely haven’t identified a solid product-market fit:

• You have use cases in mind but aren’t sure which will be your big winners. For example, you know your socio-demographic data can be used across many industries, but you’re not sure which ones will get the most value or pay a premium.

• Target customers may not yet be aware of your data’s value. For example, commercial real estate businesses are used to traditional tenant engagement, which doesn’t involve showing footfall data.

• Your current customer base might be totally different from data product buyers. For example, an EV chargepoint operator sells to property managers but wants to sell data to automotive manufacturers - your salespeople don’t have contacts in automotives and don’t want to spend time in an unfamiliar market.

• Your sales process is more consultative: you diagnose business problems in unfamiliar industries and propose solutions. This differs from commoditised sales, where your team has narrowly-defined target customers and specific pain points your product solves. Selling data can be more complex because you’re also selling a transformation in how clients work.

(By the way, this is why consultancies don’t typically employ dedicated salespeople -consultants do the selling because they also need to diagnose problems and create solutions.)

If your sales team already takes a consultative approach, you might add data products to their portfolio. But if they’re used to selling a specific product to customers who know they want it, you need to be more closely involved.

Aligning Incentives

Salespeople are “coin-operated” - motivated by clear financial incentives like commission. This matters in two ways:

• If selling your data product is much harder than selling the rest of the portfolio, salespeople won’t prioritise it.

• If you’re trying to get facetime with a client, the account owner might think you’re stealing their commission. Clarify they’ll get their commission regardless.

Introduce data product-specific incentives tied to data sales or bundled opportunities. This motivates sales teams and encourages them to spot new ways to embed data into existing deals.

Building Trust and Partnership

Salespeople are protective of their clients and don’t want to risk losing commission. You need to demonstrate you’re (1) safe to put in front of clients, and (2) someone who can help them sell more.

Frame your involvement as helping close deals. Focus on how your involvement in the consultative sales process means a bigger commission check and faster deal close - not that this will “help establish product-market fit.”

This is classic change management: not everyone will be onboard from day one. Focus on salespeople who see the potential and join forces with them first. Results speak louder than product visions on PowerPoint slides.

The Sales-Data Product Manager Partnership

One effective strategy is pairing Sales and Data Product Managers in a “good cop, bad cop” setup.

Sales professionals excel at building rapport, understanding pain points, and positioning solutions. They speak the customer’s language and identify where data products fit into strategic conversations. However, they often lack technical understanding of the data’s potential, making it hard to pitch its value.

Data Product Managers bring technical credibility, strategic clarity, and realistic boundaries. They translate data capabilities into business outcomes and ensure customers understand what’s possible, scalable, and compliant.

Together, they create a balanced client experience. Sales learns about the data offering; Data Product Managers gain insight into customer language and priorities. Over time, this builds a stronger go-to-market rhythm.

There’s more to it…

While the above is long, it’s just scratching the surface!

Some of the topics we didn’t get to (or barely touched on):

• Cannibalisation with core business and/or other data products

• What your contracts can and cannot help with

• IP rights & different licensing models

• Building privacy-first data products

• Ensuring regulatory compliance

• Working with Finance

• Skills & roles needed

• Data Marketplaces

• Go To Market

• Partnerships

• …and more

There’s a lot to it!

Call for feedback: If data monetisation is a topic of interest, we can do more deep-dive articles and/or video events 👀 Let us know! Leave a comment, send an email, or drop me () a DM.

PS: We’ll be joined by Anthony Cosgrove this week (15th Oct) for another community webinar, and it will be very relevant to the topic of data monetisation! So if you found the above interesting, definitely join us on the 15th.

About the Data & AI Product meetup

As mentioned at the top, this discussion was one of six roundtable discussions that happened in parallel during last month’s London Data & AI Product Management meetup.

In London and Paris (which I, , run directly), we meet monthly.

Our blurb about the community:

​Data and AI product management is still a young discipline, and there aren’t many spaces dedicated to learning from peers.

​So we started this meetup in 2023 to change that! Since then, it’s grown into a vibrant community with chapters in London, Barcelona, and Paris.

​Whether or not “product” is in your job title, if you’re involved in shaping data, analytics, and AI initiatives (e.g. product managers, strategists, BAs, data scientists, engineers, analysts) you’ll find like-minded people here.

​This is an informal, welcoming space to swap lessons, share challenges, and enjoy drinks and snacks along the way 😊

Upcoming events:

• October 14: Monthly meetup in Barcelona

• October 15: Online webinar with Harbr’s Anthony Cosgrove (which, by the way, will be super relevant to the topic of data monetisation!)

• October 28: Monthly meetup in London

& in case you missed it, we also recently held two other webinars for the DPM community that you can watch:

• Building Influence Without Authority: Lessons from 10 years at McKinsey with Clare Kitching

• Stop Building Data/AI Products Nobody Uses! How UX & Product Boost Adoption with Brian T. O’Neill

Thinking of starting your own local chapter? Let me know! And check out the below article / call to action to find out more:

And most data leaders hear it the same way: You should be in charge.

In product management, there’s an equally damaging one-liner that gets misunderstood the same way: “The product manager is the mini-CEO of their product.”

Both framings suggest the same thing: That your success depends on being the decision-maker. The person in charge. The boss.

That misunderstanding -thinking you should be the boss- creates one of two failure modes (which we’ll call anti-patterns)

In one, you’re frustrated that you don’t have the authority you think you deserve. In the other, you have authority but use it in ways that shut down the expertise you need most.

I’ve seen both anti-patterns play out across data product managers, heads of data, CDOs, and data leaders of all stripes. Both stem from the same fundamental misconception: That your job is to be in charge, rather than to facilitate great decisions.

Here’s what both look like, why they happen, and what to do instead.

Anti-pattern 1: You have zero authority (and you’re mad about it)

Your data engineers ignore your recommendations about the data platform. The business intelligence team builds dashboards without consulting you. Sales promises data products you’ve never discussed.

You get frustrated. “Why won’t anyone listen to me? I’m supposed to be driving the data strategy!”

This often happens when you’re new to the role - especially if you’re coming from a position where you did have authority. Maybe you were a senior data scientist whose technical recommendations got implemented. Maybe you were a data engineer who made architectural decisions. Maybe you were an analyst whose insights drove business changes.

Or you’re a Head of Data or CDO without clear authority. You’re “responsible” for data quality, data governance, the data platform - but engineering doesn’t report to you. The business teams don’t have to use what you build. You’re accountable without authority.

Or you see “manager” in your title and assume it means what it says. Manager. That means you manage people, right? You’re in charge of something?

So you try to establish that authority.

Week one, you’re more assertive in meetings. Week two, you start sending detailed emails outlining your decisions (that nobody reads). Week three, you escalate to your manager or skip-level: “Can you help me establish more authority with the teams?”

You introduce more “process” and “governance” to force people to include you. You create approval workflows. You require sign-offs on data architecture decisions. You insist on being in every meeting where data strategy might come up.

You’re doing all of this because you think the problem is that people don’t respect your authority. If only they understood you’re supposed to be in charge, they’d listen.

But the teams start working around you.

You find out about the new ML pipeline after it’s been deployed. The BI team and their stakeholders solved a reporting problem together and didn’t think to tell you. Your 1:1s become status updates rather than strategy discussions. You’re CC’d on decisions instead of being asked for input. Business teams hire their own data analysts/scientists. Leadership brings in an external consultancy instead of giving your team the work for the high-visibility project.

The more you try to assert authority you don’t have, the less influence you actually build.

In short: You become a bottleneck to route around, not a leader to collaborate with.

(And they’re right to try and work around you - or at least I can’t blame them)

Anti-pattern 2: You have all the authority (and you’re using it badly)

Your org structure gives you authority. Maybe you’re a CDO with a full data organisation reporting to you. Maybe you’re a Head of Data with engineers, analysts, and scientists on your team. Maybe you’re a data product manager whose technical team can’t ship without your approval.

You think: “Finally! This is how it should be. I’m in charge - I make the calls.”

People do exactly what you tell them to. Requirements get implemented to the letter. Nobody pushes back.

And somehow, the results still don’t follow.

Here’s what this looks like in practice:

• You make unilateral technical decisions without consulting your leads. You decide the data platform should use technology X because you read about it at a conference, missing that your senior data engineer knows it won’t integrate well with your existing systems. You mandate a particular approach to data modeling because it’s “best practice,” ignoring that your data architect understands the specific constraints of your domain.

• You dismiss feedback from the business because being “data-driven” means the data team knows best, right? The sales team stops telling you what customers are actually asking for. Finance stops explaining why certain metrics matter to the business. You build technically sound solutions that nobody uses.

• You treat domain experts like order-takers rather than collaborators. The data scientist who’s been working in this industry for 10 years has an idea about how to improve the model, but you’ve already decided the approach. They shrug and implement your way, knowing it won’t work as well.

You override your BI lead’s dashboard design because you “know what users want.” You tell the data engineer which indexes to create. You set priorities without understanding what technical dependencies exist or what’s actually blocking value delivery.

Then you wonder why nobody seems engaged. Why people don’t bring ideas to you anymore. Why they nod along in meetings but don’t seem excited about what you’re building.

That’s because your team has stopped thinking. They’ve become order-takers.

The data engineer who could’ve spotted a fatal flaw in your approach stayed quiet. The analyst who had a better way to present insights didn’t share it. The data scientist who knows the domain better than you just nodded along.

You’ve optimised for compliance, not for outcomes.

Both anti-patterns are wrong

Both stem from the same root: You think you should be the boss.

In Anti-pattern 1, you realise you’re not actually the boss, get frustrated, and try to force authority you don’t have. You focus on building scaffolding (process, hierarchy, approvals) instead of building relationships.

In Anti-pattern 2, you act like a stereotypical 1980s movie boss - the kind who barks orders and doesn’t care if anyone agrees. You think having authority means you should use it to direct everyone.

Here’s the thing: When a CEO makes the mistake of conflating their authority for influence, they can usually force compliance through formal authority (even if it’s bad leadership). When a data leader makes this mistake in Anti-pattern 1, you just get ignored. When you make it in Anti-pattern 2, you get compliance without commitment.

Neither gets you what you actually need: A team and organisation that’s genuinely aligned around solving the right problems in the right way.

They both treat influence as a power dynamic rather than a collaboration model. You’re either fighting for power you don’t have, or wielding power in a way that shuts down the very expertise you need to succeed.

What real influence actually looks like

Real influence isn’t about having authority or not having it. It’s about creating an environment where the best ideas win, regardless of where they come from.

The “mini-CEO” advice is actually quite good - if you understand that great CEOs are facilitators, synthesisers, and relationship-builders first.

They:

• Create alignment around shared goals. Instead of telling the team what to build, you help everyone understand why you’re building it and what success looks like. Your data engineer isn’t just “implementing a pipeline” - they understand they’re enabling sales teams to respond to leads 10x faster, and suddenly they’re spotting optimisation opportunities you never would have thought of.

• Ask “dumb” questions. “What am I missing?” “What would make this fail?” “Who else should we talk to?” You’re not trying to prove you’re the smartest person in the room. You’re trying to extract the collective intelligence of everyone around you.

• Help teams understand trade-offs. When engineering wants to rebuild the entire data platform and the business wants three new dashboards by next week, you don’t just pick a side. You don’t dictate the answer. You help both sides see the constraints the other is working under, and facilitate a conversation about what you can actually achieve.

You create space where your technical leads feel comfortable pushing back on a bad idea. Where you feel comfortable being wrong. Where everyone understands the “why” well enough that they can spot problems you didn’t see.

This is especially critical for data leaders

Your data scientists understand the math better than you. Your data engineers know the systems better. Your business stakeholders know their domain better.

If you’re not creating space for all of that expertise to surface, you’re building with one hand tied behind your back.

I’ve seen data products fail because the leader insisted on an ML solution without understanding that the data engineer knew the required data wasn’t actually available (and a non-ML approach would’ve worked fine). I’ve seen dashboards get built to spec that nobody uses because the leader didn’t involve the actual users in the design process - just their VP.

The data scientist who could’ve spotted a fatal flaw in your approach stayed quiet because you’ve made it clear you’re not interested in being challenged. The business stakeholder who knows their team will never adopt this tool doesn’t speak up because you’ve positioned yourself as the expert.

Your job isn’t to be the boss of your data strategy. It’s to be the person who helps everyone else make better decisions about it.

(btw, Brian T. O’Neill and I spent an hour on the problem of “building data products no one uses” and how to prevent that problem)

What this looks like when you get it right

You know you’re doing this well when:

• Your technical leads proactively flag concerns before they become problems, because they trust you won’t shoot the messenger

• Your analysts and BI developers bring you problems, not just solutions waiting for your approval - they see you as a thought partner, not a gatekeeper

• Business stakeholders include you in early conversations because they trust your judgment about what’s possible

• Decisions get made faster because everyone understands the “why” and can make calls independently

• People volunteer ideas in meetings instead of waiting to be asked

• When you’re wrong (and you will be), someone feels comfortable saying so

This is influence through collaboration, not influence through authority (or lack thereof).

Because at the end of the day, whether you’re a data product manager, head of data, CDO, or CEO - facilitating great decisions beats making all the decisions yourself.

Besides, who wants to be a mini-anything? 😆

Want to get better at this?

This is hard to unpack in a newsletter because it’s deeply contextual. The tactics that work when you’re new to an organisation are different from what works when you’ve already lost credibility. The approach when you have formal authority is different from when you don’t.

Which is exactly why next week, I’m doing a webinar with Clare Kitching (ex-McKinsey Associate Partner, now an independent consultant) on how to influence effectively as a data leader, regardless of your org structure.

Register to join on LinkedIn. We’ll also stream (and take questions from) YouTube and Substack, if you prefer those to LinkedIn. And we’ll record it if you can’t make it live (but if you can, do join live - you probably won’t watch the recording anyway 😆)

Shameless plug: Come learn how to build influence with my 3-week training+coaching programme

If you want to dive even deeper into building influence and demonstrating value (and work with me directly in group & 1:1 sessions), I’m running one last cohort of the ROI of Data & AI course this month.

We’ll cover how to quantify and communicate the value of your data products, get buy-in from stakeholders, and build the credibility that makes influence easier. Because influence is a lot easier when you can point to concrete outcomes you’ve driven.

Applications close on October 7, and I’m planning to stop offering this iteration of the programme going forward. There’ll be a version of it in 2026 for sure - but it’ll be slimmer and less comprehensive.

If you’re interested, apply here before the 7th. And if you’re not 100% sure about it, apply anyway - the next step is for us to have a 15-30’ call to go over any questions (and make sure you’re a good fit for it).

If you found this article useful, here’s a couple other articles that run along the same theme:

"Hey team, just discovered our client dashboard is showing last month's data. Anyone know who handles the refresh schedule?"

Sarah from Product typed first: "That's a data engineering thing."

Marcus from Engineering responded within seconds: "Actually, that dashboard is owned by Analytics."

Chen from Analytics chimed in: "We just visualise the data. The pipeline that feeds it is Engineering's responsibility."

Twenty minutes later, the thread had grown to 47 messages. Everyone had explained, in increasingly defensive detail, why fixing the dashboard wasn't their job. Meanwhile, the client (who had a board presentation the next morning) was still looking at stale data.

I've watched this scene play out countless times across different teams, different companies, different industries. The specifics change, but the pattern remains: a problem emerges in the space between job descriptions, and instead of someone stepping up to solve it, everyone steps back to protect their territory.

This isn't just about a broken dashboard or a frustrated client. It's about a mindset that's quietly poisoning data teams everywhere - the reflexive retreat to "that's not my job." It's a phrase that sounds reasonable in isolation but becomes toxic at scale. And if you've ever found yourself in one of these Slack threads, either as the person asking for help or as one of the defenders of your job description, you already know the damage it can do.

What you might not realise is how much this mentality is limiting not just your team's success, but your own career growth.

This is why hearing "that's not my job" is one of my biggest pet peeves to hear at work (with a few key caveats).

It's both a career-limiting move and the opposite of being a team player.

If you're fuming at the above and find yourself muttering "toxic workplace", I promise the article below is nuanced enough to bring your blood pressure down. If you're already nodding along, I hope this article will help you better advocate for the ways of working you're desperately trying to get in your team.

Why do people say 'it's not my job?'

I get where the comment is coming from. You were hired to do a job. You are being paid to do that job. Other responsibilities might fall outside your skill, comfort level, enjoyment, or seniority/payscale (either in that you don't think you're paid well enough to do them, or that you have risen above that work).

It's very reasonable for someone to say:

• I want to have autonomy and choice over what work I do based on what I enjoy doing

• I want to have appropriate training and experience before being trusted with certain tasks

• I want to be compensated commensurately to my responsibilities

BUT often these reasonable expectations become roadblocks for your team and project.

Why "that's not my job" hurts both your team and career

If a certain task is not your job, but also not part of anyone else's job, then what do we do? By the logic of a "not my job" person, we just sit and wait until we can find someone whose job it is to do the thing.

Besides being a shitty way to work with your teammates (who often also do things that "aren't' their job" so that the team can win together), it's also an attitude that won't serve your professional growth.

A lot of the skills, experiences, and promotions that folks get come as a result of doing things that aren't strictly in their JD.

There's a few structural causes for why data teams in particular are especially prone to requiring folks to do things that aren't "their job":

Poor definition of D&A roles and responsibilities: Most data teams are incorrectly regarded by their organisations as a purely technical discipline. It's why you see Head of Data job descriptions requiring up-to-date Python and AWS skills, and why most orgs don't have someone doing the work of a Data Product Manager or Analytics Translator.

New specialisations emerge all the time: Compared to established fields like medicine, accounting, or engineering, the data profession is rather nascent, and new roles emerge as technology and ways of working advance.

Some examples:

• Data Engineering wasn't a common role when the data scientist role was first introduced 10-15 years ago

• Analytics Engineering came about partly as a result of tools like dbt

• Machine Learning Engineering emerged to describe the data scientists focused on building and maintaining models in production

• Data Product Management is seeing its rise as more and more organisations realise they need to (1) invest in understanding where the data team should direct its efforts (aka Discovery) and (2) treat their most important outputs as products

Unstable teams: I'm not a fan of it, but a lot of the time, data folks are staffed temporarily and moved around a lot. This means that where previously your job may have been X+Y, you might then join a bigger project where all you need to do is Y. And then after that you might need to do X+Y+Z. Maybe you were only hired with X+Y in mind, and nobody in your team was hired with expertise in Z. If the project is already underway and you don't have the time and/or budget to hire a specialist in Z, someone needs to step up and do it, or the project won't succeed.

As much as some responsibilities might be "not your job", it is equally likely that they are not not your job.

Why should I care?

Refusing to do the work will hurt your project and team

When everyone retreats to their job descriptions, work stops flowing. That dashboard refresh? It sits broken for days while emails ping back and forth about whose responsibility it "technically" is. Meanwhile, your team misses sprint goals, client relationships suffer, and stakeholders lose confidence in your data team's reliability.

I've seen entire projects derail because a two-hour task got stuck in a three-week game of responsibility hot potato. The irony? By the time you've spent hours in meetings arguing about whose job it is, someone could have just fixed it and moved on.

Refusing to do the work will also hurt your relationships with your team

Now, you might not care if your project or teammates suffer. You get paid either way. Fine.

Nothing breeds resentment faster than watching a teammate throw up their hands while everyone else scrambles to keep things moving. Your colleagues remember who steps up during crises and who hides behind job descriptions.

Sarah from Product will remember that when she desperately needed help cleaning messy data for a demo, Marcus from Engineering said "that's not my job" instead of spending 30 minutes helping her out. When Marcus later needs Sarah's help prioritising his feature requests, guess how enthusiastic she'll be?

A few years ago, I was on a team working on a thoroughly unpleasant project. A few months in, one of my teammates quit - and then proceeded to completely check out during their notice period. They were pissed at our employer, and the project (we all were). But the people who suffered as a result of them not doing anything for a month weren’t the big bosses, it was the rest of the team. None of us have forgotten about it.

Trust is built in moments like these, and "not my job" is trust's kryptonite.

Undermining your team's work will backfire on you also

Here's the thing about data teams: your success is completely intertwined. When the dashboard stays broken, it's not just "Analytics' problem" - it reflects poorly on the entire data function. Leadership doesn't distinguish between the data engineer who built the pipeline and the analyst who owns the dashboard when they're questioning why they invested in a data team that can't keep basic reporting working.

Your individual reputation rises and falls with your team's collective output. Being the person who lets the team fail while citing your job description doesn't protect your career - it tanks it along with everyone else's.

Doing things that aren't your job are good for career progression

The most valuable people I know became valuable by learning adjacent skills. The data scientist who learned enough front-end development to build better dashboards. The analyst who picked up enough data engineering to debug pipeline issues. The engineer who developed enough business acumen to suggest better data models.

These cross-functional skills don't just make you more effective at your current job - they make you promotable. Management roles require understanding multiple disciplines. Senior IC roles require being able to work across the entire data stack. And if you ever want to switch specializations or companies, having hands-on experience beats theoretical knowledge every time.

Plus, the projects that stretch you beyond your comfort zone often become your best stories in performance reviews and job interviews. "I stepped outside my role to solve X critical problem" demonstrates initiative, adaptability, and impact in ways that "I did exactly what my job description required" simply can't.

Caveats / in defence of "not my job"

[Caveat 1] Long-term vs short-term: If you're being continuously asked to do things that are far outside the remit of your role because your employer refuses to hire the right people & skills, that's different to becoming a blocker on a specific project or team sprint.

Of course if you're a data scientist being asked to magically find the time (and expertise) to do data engineering or BI development work for 12+ months now, then being unhappy about it isn't you being a bad team player - it's a resourcing issue. You should make your displeasure loud and clear to your people manager, the project manager, and if there's no signs of improvement, start looking for a new role (actually, start looking now, better to parallel-path these things than only start looking when you're past your breaking point)

BUT if your team's only BI developer is on holiday or recently left or the need for a front-end emerged more recently, and your project is on a tight deadline, AND you have the skills and bandwidth to do the dev work, 9 times out of 10 I think you should do it.

From a professional development point of view, learning/knowing how to do things that aren't strictly your job can be a great advantage too:

• Experimentation & openness to learn: For example, there's lots of data scientists that realised data engineering was much more enjoyable and fulfilling to them.

• Easier to transition to another role: Obviously, if you have the practical experience to show for it, even if you're not a fully-fledged specialist, you'll have an advantage over someone who just has some online certificates (or maybe, if you're applying for an internal move, they're a technical specialist but they lack the much more important domain & org knowledge you've built up)

• Embracing change: Like it or not, the world is changing at an accelerating rate. Learning how to learn, and being able and willing to adapt professionally is going to be a must-have.

[Caveat 2] Wearing multiple hats doesn't mean working multiple jobs: I'm also not advocating for folks to overwork themselves and do two jobs at once. If your project is being managed poorly and needs 1.5x the FTEs it has, that's a management problem, and you might actually be better off refusing the extra work - otherwise management will think "see, they didn't need the extra FTEs after all" and keep causing you the same pain.

[Caveat 3] Org type & maturity matters a lot here: All of the above greatly depends on the size of the organisation. You'll need to be a lot more willing to wear multiple hats if you're in a startup (or a newly-formed team/department that's acting like a startup inside a larger org) than if you're part of a huge enterprise with entire teams of each specialist role. If you want to be doing just "your job" and hate other tasks, you'll be better off in larger, more mature teams than fast-growing, less-structured workplaces.

How can I balance being a team player while protecting my career (and sanity)?

Step 1: Run the time audit

Ask yourself: "Is this a quick task, or am I signing up for many months of doing work I don't like and/or aren't good at?"

If it's a few hours or days, just do it. If it's weeks or months, you need to have a conversation with your manager about resourcing, priorities, and what gets deprioritised from your actual role.

Step 2: Address the precedent upfront

Don't just silently accept extra work and hope it goes away. Say something like: "I'm happy to handle the dashboard refresh this time since it's urgent, but we should figure out a long-term solution so this doesn't become a bottleneck again."

This positions you as solution-oriented while setting boundaries for the future.

Step 3: Find your angle

Before saying yes, identify what's in it for you. Could this help you:

• Learn a skill you've been wanting to develop?

• Get visibility with stakeholders you normally don't work with?

• Build a case for the promotion you've been seeking?

• Better understand a part of the business that would make you more effective?

If there's no upside and it's not urgent, you have more grounds to push back.

Step 4: Drive the fix, not just the band-aid

When you step in, also advocate for the systemic solution. "I'll handle this pipeline issue today, but I think we need to discuss hiring a data engineer or restructuring our on-call rotation."

This shows leadership thinking, not just task completion.

Step 5: Know your organisational context

In a 50-person startup where you're the only data person? Wearing multiple hats is part of the deal. In a 500-person company with specialised teams? You should have more grounds to stick to your lane.

Match your approach to your environment's maturity and expectations.

The key is being strategic, not reflexive. Instead of automatically saying "not my job" or automatically saying yes, pause and evaluate: What's the cost, what's the benefit, and how can I handle this in a way that helps both the immediate situation and sets better precedents for the future?

In summary, being a good team player is a two-way dance

Data teams that embrace "not my job" thinking build silos. Data teams that embrace shared ownership build competitive advantages.

The companies winning with data aren't the ones with the most clearly defined job descriptions - they're the ones where people care more about outcomes than org charts.

The next time you see one of these situations unfold - whether it's in a Slack thread, a meeting, or a casual hallway conversation - you have a choice to make.

You can be the person who explains why it's not your problem. Sometimes that's the right call - when you're being exploited, when it's genuinely outside your capabilities, or when stepping in would set a destructive precedent. But those should be the exceptions, not your default response.

Most of the time, you can be the person who solves problems.

So pick your battles, and try to maximise your impact by being willing to do what it takes to get projects over the line. At the same time, you need to set yourself, your team, and your company up for long-term success by not burning out & stretching yourself too thin.

My advice? Assume “this is my job” as your default, not the other way around.

// In other news

🎙️ This week: We’ll be doing a LinkedIn live with Brian T. O’Neill

We’ll be talking about why so many technically brilliant data & AI projects fail to deliver real impact - and how product management and UX design can help bridge the gap. Brian is one of the leading voices in bringing UX thinking to data teams, so it’s a conversation you won’t want to miss.

This will be the first in a series of live conversations I’ll be running - I’m very excited.

We haven’t published the page on LinkedIn yet, but for now block the time on your diary (I left everything from my side a little too last minute…).

If you don’t want to miss it, drop a comment or DM me and I’ll make sure to send you a direct message with the registration link once it’s ready.

🍻 Next week: London Data PM meetup & BigDataLDN

I’ll be at BigDataLDN, one of Europe’s largest data conferences of the year. If you’re around, let me know! I mostly go to these things to catch up with people, so if you want to meet IRL, I’d love to connect.

AND we’ll have our monthly data product management meetup on 23 September - the evening before BigDataLDN. Special thanks to our friends at Harbr Data for sponsoring the evening.

🔗 Sign up for the meetup on Luma.

📚 Next month: I’m running another cohort of my course, ROI of Data & AI

After two fantastic public cohorts in January and July, I’ve decided to do a third cohort this year.

It’s a live course that’s designed for data product managers and data leaders who want to move beyond technical delivery and learn how to articulate, measure, and grow the business value of their work.

🔗 Apply to join us here.

🎁 Bonus: I’m giving all subscribers €100 off (use code ‘SUBSTACK’) when enrolling.

🌍 Thinking of starting an IRL meetup for data product managers?

Do you live somewhere with a non-zero number of fellow Data PMs, but without a DPM meetup? I want to help you change that!

I’ve already had folks reach out with an interest to start a local chapter in Dublin, Wroclaw, New York, and Melbourne. If you’re in one of those cities and want to help share the load, let me know! Hosting is much easier when you don’t need to attend 100% of meetups.

For more info, check out this article:

"I've been at [Fortune 50 company] for 20 years, and I have NEVER seen anyone follow up on whether we actually achieved the savings from our initial business case. Never."

Damn. She said the quiet part out loud.

Twenty years. Hundreds of millions in supposed "savings" from data and technology investments. Zero follow-up.

(This was in the context of her having been part of my data product management course, where we go over methods to estimate ROI upfront and after the fact)

She's not alone. I'd estimate 90% of data and transformation initiatives never measure their actual ROI against their business case. We promise millions in value, get the budget approved, build the thing... and move on to the next shiny project.

But this leader didn't just have this realisation and accept it as "how things work." She's started changing it. I'll come back to exactly how she's transforming her approach later. But first, let's look at why this problem has become so widespread - and why it matters more than ever.

The scale of the problem

Think about this for a moment. According to Statista, global spending on digital transformation reached $2.5 trillion in 2024, projected to reach $3.9 trillion by 2027. AI spending alone hit $244 billion in 2025 and is forecast to reach $827 billion by 2030.

But here's the thing - we don't even know which initiatives are failing, because nobody's measuring.

Trillions invested… And $??? returned back.

I've seen this sort of disaster play out across all sorts of industries - in my own work, in my clients', and across all the data leaders I meet in the data product management meetups I organise.

The two most common patterns: (1) dashboard factories and (2) analytics assembly lines. Let’s expand on both before proceeding:

Pattern 1: The Dashboard Factory

Teams build BI dashboards, stakeholders seem happy (or at least don't complain much), but there's almost zero understanding of whether those dashboards actually improve decision-making.

These teams operate like service desks - they receive requests and deliver against them, with performance measured by metrics like time to completion and governed by SLAs. They track login frequencies and maybe time spent on each page, but they have no idea if anyone is actually making different decisions because of what they see.

Companies spend millions on dashboard platforms where the BI team couldn't name a single business outcome that had demonstrably materialised because of their work.

Pattern 2: The Analytics Assembly Line

A data science team builds an exciting prototype that shows real promise. Then it gets thrown over the wall to an engineering team to industrialise. Then that team hands it off to a "global business services" (GBS) team (usually offshore) to run and maintain - because the focus shifts from maximising business value to minimising IT costs.

The GBS folks running the analytics product become totally disconnected from the business problem it was meant to solve, left with little more than technical documentation and no real domain knowledge. There's rarely a proper product roadmap, and when there is, it's usually based on the original scoping from months or years earlier - not feedback from actual users. To make things worse, end users are usually "shielded" from speaking to the GBS team.

(In the better scenarios, there’s a more proper handover phase from builder to maintainer - but the structural disconnect persists regardless)

Why this happens everywhere (and it's not just laziness)

First reason: It's genuinely uncomfortable.

What if the savings didn't materialise? What if your model was wrong? What if the technology worked perfectly, but the business process changes never happened?

I've spoken to data leaders who privately admitted their biggest data & AI projects "technically worked" but delivered less than 10% of promised business value, but nobody challenged them on it. So they claim victory and move to the next project. Better to be known for delivering projects than for delivering disappointing results.

Second: It's institutionally hard.

The person who built the business case has often moved to a new role by the time measurement should happen. The assumptions have changed. The baseline shifted. Market conditions evolved.

But here's the real killer: Measurement & Evaluation is never part of the original scope. By the time you should check whether you delivered on your promises, there's no budget, no time, and definitely no appetite for "going backwards."

I've seen this pattern so many times:

• Q1: "We need to build this AI system to save $5M annually"

• Q4: "The system is live and working perfectly"

• Q1 next year: "What $5M? We're focused on the new customer experience initiative now"

Third: Nobody asks for it.

Your CFO approved the budget based on promised returns, but they're not following up either. They've got 50 other initiatives to worry about. The board sees that you "deployed AI" or "became data-driven" - mission accomplished, right?

This creates a perverse incentive structure where success is measured by deployment, not by business outcomes.

Why this matters more than ever

The last 10-15 years were forgiving. Cheap money, growth-at-all-costs mentality, and "digital transformation" budgets that seemed unlimited. In that environment, you could get away with fuzzy ROI measurement.

But we're firmly back in "the CFO runs the show" territory:

• Rising costs of capital mean every dollar spent needs to generate measurable returns. The days of betting on "strategic positioning" or "future optionality" are largely over.

• AI efficiency plays are everywhere, but they're double-edged. Yes, AI can reduce costs - but only if you can measure and optimise those reductions. Otherwise, you're just adding AI complexity on top of existing inefficiencies.

• Shareholder pressure for profitable growth means no more buying growth with unprofitable initiatives. Every major tech company has done layoffs in the past 18 months, even while reporting record revenues.

The signs are everywhere: Layoffs even when companies are making record profits. Pressure to "do more with less" and "use AI to replace expensive processes." Greater scrutiny over every budget line item.

If you can't prove your data initiatives deliver measurable business value, your budget is at risk.

By the way, I wrote more about this last year:

What the smart money is doing differently

Back to that data leader I mentioned at the start. Here's what she did differently, and why it's working:

1. She picked ONE initiative - the simplest, most measurable one in her portfolio. Not the sexiest AI project, not the most technically challenging. The one with the clearest path to measurement.

2. She built a specific business case: 2-5% savings on a 9-figure-a-year spend (meaning $millions in projected savings). Not "significant savings" or "efficiency improvements" - specific percentages with clear baselines.

3. But here's the crucial part: Before starting the project, she got the transformation team to commit to tracking actual vs. promised savings, and added Measurement & Evaluation as one of the project's workstreams from day one.

Not just "we'll save money." But "we'll save 2-5% and here's exactly how we'll measure it in Q1 vs our baseline."

If you don’t do #3 upfront, chances are you won’t do it later. You’ll be told you need to focus on the next initiative, that the stakeholders are now too busy, and so on. Even if you do something to measure value, it’ll read too much like grading your own homework. Things look very different if you’re grading against a rubric that’s been established before the work began.

When data quality becomes negotiation power

Without getting into specifics, her initiative had to do with supply chain optimisation - and so their data also came from their suppliers, not just internal sources. By linking business value directly to suppliers' data quality, their negotiation team now has commercial leverage.

Here’s what makes this setup a brilliant win-win scenario:

• If suppliers improve their data quality: Better optimisation algorithms → indirect cost savings through efficiency gains → suppliers get rewarded with continued business (and better commercial terms)

• If suppliers don't improve: The commercial team levies data quality penalties → direct cost savings through reduced shipping costs → suppliers get motivated to fix their data

Suddenly, data quality becomes a commercial negotiation point, not just an IT complaint that everyone ignores.

The result? For the first time in her 20-year tenure at the company, she's running a data initiative where:

• ROI is reported on, not just estimated to write business cases

• Success is measured in dollars saved, not models deployed or deadlines met

• Business stakeholders are the most invested in data quality (!!!)

A framework you can steal

Here's the methodology that's working for her (and others I'm seeing succeed):

1. Start stupidly simple

Pick the most boring, measurable initiative in your portfolio. The one where:

• Success can be measured in dollars, not "engagement" or "adoption"

• The baseline is clear and historical data exists

• Business stakeholders already care about the outcome

• The data pipeline is relatively straightforward

• The number of stakeholders is manageable (ideally this will be one ‘customer’ - not fifteen country leads and seven user personas)

2. Build measurement into the business case

Don't just promise savings - work together with your stakeholders to specify:

• The metric(s) by which success will be defined

• Expected improvements on those metrics

• Timeline for measurement (quarterly, not annual)

• Who will be responsible for tracking

• What data sources will be used for verification

• How you'll separate correlation from causation*

*this one is tricky. Sometimes, especially earlier on, you can ditch this and just do simple pre-/post-analysis, especially if you know that there aren’t lots of confounding factors.

3. Make data quality a commercial issue, not a technical one

Poor data quality is a killer issue in data initiatives - literally. But, unlike what a lot of vendors out there will tell you, it’s not the root cause. Sure, your model sucks because the data sucks. Garbage in, garbage out, and all that.

But the data usually sucks because fixing it is not an organisational priority - not because of inherent technical challenges.

So, if DQ is a challenge (current or anticipated), you need to find ways to tie data quality/compliance to business relationships:

• Supplier contracts with data quality SLAs

• Customer experience metrics tied to data accuracy

• Internal team KPIs linked to data usage

• Budget allocations dependent on measurable outcomes

You probably won’t get a fully committed SLA from day 1, and that’s fine. For now, start tying technical debt and data debt to commercial metrics.

I’ll be writing an article on this point soon because it deserves a lot more space, but for now, just keep in mind that the best way to prioritise your tech & data debt is to communicate its importance in terms of the business impact it’s hindering / enabling.

4. Track continuously, report regularly

Match your tracking to the business rhythm. Continuous tracking for high-frequency operations, weekly tracking for weekly decisions. Report to stakeholders regularly - quarterly usually strikes the right balance between engagement and overwhelm. Annual reporting is useless, as it gives you no time to course-correct.

Note: Reporting shouldn’t just be about passing on metrics updates. Too often, there’s gold in sharing quotes from end users or customers, or examples of the impact being delivered.

5. Celebrate small wins publicly

When you hit a milestone - even 0.5% savings in month 3 - make sure people know. Success breeds success, and visible wins make future projects easier to approve.

Always remember that no matter how clearly you think your stakeholders are aware of the value you’re delivering for them, the real answer is “less than you thought”.

And on the internal-facing side of things, it’s a real motivator for your team to be aware of how their work is connecting to business outcomes - and help them become even greater champions of customer- and value-centricity in their work.

It all compounds 📈

Here's what happens when you nail the measurement on one project:

• Credibility compounds. Your next business case gets approved faster because stakeholders trust your numbers.

• Learning compounds. You and your team understand what actually drives business outcomes vs. what just looks impressive in demos.

• Relationships compound. Business stakeholders become your advocates instead of seeing data projects as "IT stuff they have to tolerate".

• Budgets compound. CFOs give bigger budgets to teams that can prove ROI.

I’ve seen this play out countless times - in my own work, in my clients’, and in the folks I’ve learned from over the years.

During my course, I use the below diagram to explain this idea further: As you start delivering value (and proving it), trust with your stakeholders grows. As your stakeholders trust you more, you’re looped into decisions earlier on - such as selecting which initiatives your team should work on.

Your next steps

The lesson isn't revolutionary, but it's urgent: Start small. Pick one project. Measure the actual ROI. Then do it again.

Don't wait for the "perfect" AI initiative or the most strategic transformation project. Pick the most boring, measurable win you can find.

Because in 2025, being able to prove business value isn't a nice-to-have capability for data leaders.

It's table stakes.

What's your experience with measuring data initiative ROI? Have you seen similar patterns in your organisation? Hit reply and let me know - I read every response.

P.S. If you're working on getting better at proving ROI from data initiatives, you might be interested in my course on exactly this topic. But honestly, just start measuring something. The course can wait.

In other news

📺 I’m starting a YouTube channel!

This one’s been a long time coming.

You might have noticed that while I post on LinkedIn many times a week, this newsletter is a lot quieter. I’ve got so many drafts, but can’t seem to get over my perfectionism for long-form writing in the way I can for shorter-form posts.

So I want to give YouTube a try and see if I find it easier to turn drafts into videos than I do articles. Plus, video lends itself to having guests over much more easily… 👀

You can subscribe here - nothing’s uploaded yet, but watch this space!

🇬🇧 Speed data-ing in London

We tried something new this month: Speed networking for data product managers. Kudos to Luca for proposing the format AND running the event on the day 🙌

🇬🇧🇪🇸🇫🇷 More Data PM meetups coming up

• 🇬🇧 London: 23 September - the night before BigDataLDN!

• 🇪🇸 Barcelona: Two events in September! Regular meetup on the 9th, and a special event about going freelance/independent on the 18th

• 🇫🇷 Paris: No date set yet, but you can sign up to get invited when the next event is announced here

Do you live somewhere with a non-zero number of fellow Data PMs, but without a DPM meetup? I want to help you change that! See the article below:

By the way, I’ve already had folks reach out with an interest to start a local chapter in Dublin, Wroclaw, New York, and Melbourne. If you’re in one of those cities and want to help share the load, let me know! Hosting is much easier when you don’t need to attend 100% of meetups.

“Every generation has its burdens. The particular plight of Gen X is to have grown up in one world only to hit middle age in a strange new land. It’s as if they were making candlesticks when electricity came in. The market value of their skills plummeted.”

Reading through this NYT article interviewing Gen Xers in creative professions and how they’ve been pushed out of the market, I couldn’t help but think that this will be the story of so many white collar / knowledge work professionals sooner than later.

In the past, industry shifts requiring folks to switch careers en masse usually happened infrequently enough that they just affected the next generation.

In the rare occasions where they happened more frequently, support was often inadequate, and the societal consequences disastrous (we are still suffering the social and political consequences of the outsourcing of manufacturing that happened decades ago, for example).

Globalisation, deregulation, and technology sped the cycle up over the past few decades.

AI (and the continuation of the previous trends) is super-charging it, even if e.g. globalisation is also retracting in some ways.

“The cruel irony is, the thing I perceived as the sellout move is in free-fall.” (Chris Wilcha, film director)

It’s tempting to point to what AI can do right now and say “it’ll never be good enough [to take my job specifically]”. But that ignores the fact that it’s not just that AI is improving over time, but that the rate of that improvement is also increasing.

It’s just like when Western countries shrugged off Covid in February 2019 saying ‘it’s just a handful of cases’, and ignoring the fact that they were rising exponentially.

Saying that AI will never take over legal, consulting, software, or executive work because it makes mistakes today misses the point - nobody [reasonable] thinks it’s today’s ChatGPT that will.

Not all fields will be impacted in the same way. Some, like software (my prediction anyway), will expand - see Jevon’s Paradox.

Others, I suspect, are bound to contract - or become hopelessly commoditised (and then probably contract, as folks who entered those fields for the payout will see the equation not worth it anymore)

Most, I wager, will change in shape: What used to be a pyramid-like structure (countless juniors, many seniors, a few execs/partners) will see themselves rebased to have a more even number across different levels.

As that happens, many of us will either decide to move laterally or do a full-on reinvention.

Maybe many Product Managers will become Product Engineers. Maybe others will become nurses, or shop owners, or something that doesn’t exist today (Holodeck Engineer, anyone?)

The so-what of all this depends on the point of view you’re looking at things from:

• As a (selfish) individual: Accept that change is a constant, don’t get complacent, pick up new skills, prepare for change

• As a (concerned) citizen: Lobby for fair regulation and taxation that balances incentivising innovation with protecting the losers/victims of it

• As a corporate leader: Currently, far too many are playing a short-termist game of layoffs and not hiring any juniors that will backfire in the longer run

I don’t think it’s all doom and gloom. But equally, there’s a lot of misplaced optimism coming from the folks parroting the CEOs of companies like Anthropic and OpenAI (who have a huge vested interest in being seen as the paragons of progress, and AI as the solution to all of our ills).

Two things can be true:

1. AI will revolutionise our economies and usher a new era of productivity for humanity writ large

2. AI’s rapid rollout will devastate communities and individuals that aren’t able, willing, or ready to ride the wave

“That TV spot you spent six months on now becomes a TikTok execution you spend six days on.”

— Greg Paull, marketing consultant

There are many in fields currently being swept away that are investing in re-skilling. Meanwhile, there’s others who are trying to embrace it, but (in my view) are still too attached to their craft. You can already see these tensions playing out in creative fields like design and illustration. Look at this post, for example - and it’s actually a fairly moderate example too:

The author says that the AI-generated image is “soulless” and unsubtle, and just carries recycled styles. My 3 main objections to this:

1. Not to be glib, but what does “soulless” really mean here? I personally don’t see it. I do agree with one of the comments about LLMs making all designs look the same - but if that bothers enough people sufficiently, will we let things stay so? Or is this just because we’re still in the early years of AI art?

2. More seriously, professionals made the same argument for soulless digital art vs. real art made with pencil or oil paint. Tron was denied an Oscar because using computers to create special effects was considered “cheating” in 1982. Photographers argued that digital photography isn’t art (2006). And so on.

3. For commercial designs, does ‘soul’ matter? Maybe sometimes, but certainly not always. It’s why so many companies outsource illustration - to agencies, to freelancers, to ChatGPT. It’s not a core competency or differentiator. Good enough is good enough.

Scrolling down the comments of the post above, some folks echo my thoughts, others rightly say they prefer the AI version (art and aesthetics are subjective, after all), and then there’s the folks that are totally unwilling to engage:

If your stance is “us graphic designers must condemn all uses of AI”, you won’t get very far. If you believe that LLMs are illegitimate because of the way Open AI and others got their hands on training data, or because of their high energy consumption, fair enough. But what will the condemnation serve? Will business owners be swayed to pay orders of magnitude more (and slow down)? Will your government ban ChatGPT (and also be able to enforce that ban)? Will all your colleagues side with you, or will some leap at the opportunity to beat you in the market?

Let’s also be mindful of the self-serving nature of such arguments. Would you be making the same arguments if the livelihoods being threatened were only those of software developers? Or factory workers? What if AI had developed the way we expected it to 10-20 years ago, and automated jobs like taxi and truck drivers long before knowledge workers were on the chopping board?

Of course, an argument can be self-serving and also correct. But it’s worth examining our opinions and the biases that have led to us holding them.

I’ll give you an example of my own: In the pre-LLM era, one of my superpowers and genuine differentiators against most of my peers and colleagues was the ability to translate complex technical concepts in a way that’s understandable to non-expert audiences. It was a really valuable and appreciated skill. Today, that’s fairly trivial to achieve with ChatGPT. It often manages to do it much better than me, and at a fraction of the time. I could be bitter about it (and a small part of me sure is), but that won’t serve me in any way - I now use it to accelerate my own thinking and focus on things that aren’t as commoditised to serve as my USPs.

We aren’t entitled to our craft remaining relevant in a world where it’s been commoditised by technology

To be clear, I think both the IP and energy-intensity criticisms of LLMs are very valid, and more needs to be done to address the inequalities inherent in the way LLMs have been built and are being rolled out. I worry in particular that we as a society will decide to disregard the intellectual property claims of all the artists, journalists, and authors whose works were -arguably illicitly- fed into foundation models. I doubt we’ll see a successful class action that totally redresses those groups. I’m a bit more optimistic on the energy consumption & production front, especially because that’s a technical problem more than a moral and legal one.

We aren’t entitled to our craft remaining relevant in a world where it’s been commoditised by technology - any more than a tanner, a typesetter, or a blacksmith was. Society moved on, and we accepted it. No one’s lobbying for the return of lamplighters or switchboard operators. Why would knowledge work be any more sacred?

Maybe we’ll get to a point where doing product management or UX design will be a vintage hobby, just like how there’s folks learning blacksmithing today 😆

Anyway, that was today’s ramble. I want to try and post on here more regularly again - appreciate it’s been half a year of quiet. Thanks for subscribing/reading, and if you disagree, argue with me in the comments!!

🌱 In other news

#1: Trading pints for hikes

We had some great data, AI, and product hikes in New York and Barcelona in the last month. It’s not everyone’s cup of tea, but if you want to mix things up with your events, give touching grass a go!!

#2: New Data & AI PM training cohort

I’ve just announced a new-and-improved cohort of my ROI of Data & AI programme for July. I’ve taken the feedback & my own insights from running 4 cohorts with 39 participants so far to make this one the best one yet.

You can read all about it on the course page so I won’t repeat all the info here. But I will leave a few quotes from past participants:

💬 Fortune 50 Director: “We had a GenAI proposal with no budget. By estimating the value and showing potential productivity gains, we unlocked buy-in and got it fast-tracked.”

💬 Data Engineering Consultant: “We used to go off and work in a silo for months before getting feedback […] we now catch misalignments early instead of finding out later that what we built isn’t accepted.”

💬 Head of Product: “The interactive elements of the course were great, it was beneficial to have discussions with others in similar roles across multiple sectors! Highly recommend to anyone who's working on data transformation projects/products.”

💬 AI Product Manager: “As a new AI Product Manager, this course gave me the essential tools to communicate ROI to C-level stakeholders and conduct effective discovery. It’s a must for anyone looking to level up with the right frameworks for AI product work.”

💬 Fortune 50 Sr. Manager: “[One month] after the training, I started challenging assumptions more proactively. In one case, that led to de-scoping features a market wasn’t even using - avoiding $200,000 in unnecessary delivery”

💬 Data Science Consultant: “We managed to renew the project for another year while growing the team we had because we will work in more areas. The client appreciated that I took the initiative to gain more knowledge of the project, which helped her make decisions and define solutions.”

💬 Data Product Owner: “Asking myself why we’re doing things has allowed me to recognise when work is unnecessary. It’s helped me focus on real opportunities and avoid wasted effort on things that won’t be used.”

Do any of these sound familiar?

• You don’t know what the data pipelines, models, dashboards, and other outputs you work so hard to create are being used for. Who uses your dashboards? What does the data science team do with the data you send them? How do the business stakeholders use the reports they get every week?

• Even if you know what your outputs are being used for, you don’t know how they impact the business commercially. Have they helped increase revenue? Reduce costs? Avoid fines?

• Your team functions like a service desk: Requests come in, and you do some triage/prioritisation, but generally it’s about picking up tickets and delivering them

• You get no visibility or notice, let alone a say, on whether data upstream from you changes - instead, you find out about e.g. a schema change after it's happened, because suddenly something has broken.

• It is not uncommon for a stakeholder to have forgotten they requested a dataset or report from you by the time you send it to them.

• Everything you do is treated like a project: Once it’s done, it’s done. You don’t generally stay in touch with the users, gather feedback, plan improvements, release new features - if that happens, it’ll be because a new request came through for it.

If any of this sounds relatable, you’re far from alone. The service-oriented model and way of working is the default for data teams in most organisations. It results in piles of technical debt, wasted or low-value work, inefficiency, stress, and attrittion.

It’s also the reason I feel so passionately about helping data leaders and data teams adopt a product-centric model.

To that end, I recently built my first course, Value from Data & AI: How to demonstrate & maximise your impact. I delivered it for the first time a couple of weeks ago to the 20 most senior folks at a data engineering consultancy here in Barcelona, and I was delighted with the results - so I’m ready to release it more widely.

It took many intense weeks of work preparing everything, and by the end I had:

• 180 slides

• 45 printed workbook pages

• Bonus resources

• ~8 hours of content including 12 exercises and case studies

• 7 days of doing absolutely nothing in order to recover afterwards 😆 (with apologies again to my friends for bailing on our climbing trip in Sardinia…)

About the course

The course consists of two modules:

1️⃣ Opportunity Discovery is about confidently identifying and evaluating potential opportunities for data, analytics, and AI in a business.
2️⃣ Opportunity Valuation is about quantifying the ROI and commercial value of data work - historic or upcoming.

Who is the course aimed at?

I wrote the course with three sorts of folks in mind:

1. Data & AI Product Managers eager to maximise their impact and credibly demonstrate their products' value contribution

2. Data Science, Analytics, and BI Managers tired of always reacting to business requests, and instead want to focus on proactive, impactful work

3. Consultants and freelancers looking to sell more projects while increasing the impact they have for their clients

“I'm looking to transition to data product management. Is this course for me?”

This course isn't aimed at folks looking to transition to DPM. Our focus will be much more narrow than all the different skills & competencies a DPM requires.

That said, if you are currently in a technical management role (eg data science manager, analytics manager), this course will give you a solid foundation towards transitioning to a DPM role.

If you’re interested in a “DPM 101” course, do let me know! I’m slowly working on creating one to launch it sometime in 2025, and I’d love to hear from folks interested in such a course. I’ve created a quick form about it here.

What’s the format of the course?

The course is a live, cohort-based course lasting approx. 8 hours of 2x half day live sessions. It’s very interactive - not just listening to things I have to say about data product work!

How much time is required? I know my target audience is very busy, so I’ve trimmed out all the fluff and packed everything into two intense half days spread over two weeks.

After the main section of the course is over, there will also be a monthly 2-hour call for the next 3 months, giving everyone a chance to regroup, share their progress, and problem-solve together. This part will be much more like group coaching added on top of the course, and I really encourage everyone who’s signed up for the course to also join these sessions (at no extra cost).

Where is it? Last month’s edition was offline (we all met in Barcelona), but the next cohort will be online.

When is it? Jan 13-24, with most of the teaching happening on Monday Jan 13 and Monday Jan 20, at 1pm GMT (that’s 2pm CET, 8am ET, 6:30pm IST). Besides the main teaching segments, I’ll also be offering office hours during the course, and then after the course is over, I’m also planning to have accountability & progress update sessions one, two, and three months later.

Who else is joining? I’ll be screening all applicants to make sure the course is a good fit for them, and vice-versa. Given the interactive nature of the course, I really want to be selective about who takes part.

Is the course any good?

I’d like to think so! I spent the past few months condensing lessons learned from the past 8 years working at the intersection of data science, analytics, consulting, and product management, and even hired an L&D expert to help me create the course.

I’m still working on recording testimonials from cohort 1, but here’s a few stats from the feedback folks submitted upon completion of the course:

• Overall score: 8.9/10

• 100% of participants felt confident applying what they learned in their day-to-day work

• 90% of participants would definitely recommend the course to a colleague (10% said they would probably recommend it)

• I also asked which module was everyone’s favourite: Valuation got 55% of the votes, while Discovery got 45%

I’m interested! How do I sign up?

There’s two ways to take the course:

1. As an individual, you can apply to join a public cohort (meaning you’ll be learning alongside folks from other companies).

2. If you’re interested in training exclusively for your team/company, send me a message.

The next public cohort will be in January 2024, and I’m offering a 30% discount for those who sign up before 30 November 😁 (use code NOVEMBER30)

// in other news

Data Product Management in Action podcast: I recently recorded some episodes I’m super excited about, and can’t wait for them to get released. If you’d like to come along as a guest, fill this form!

In-person data product management meetups:

• London: Next meetup is on 9th Dec, and you can sign up for future meetups here

• Montreal: Sign up for future meetups here

• Barcelona: We had a great meetup last week! Sign up for future meetups here

• Paris: Next meetup is on 3rd Dec, and you can sign up for future meetups here

• Cambridge/Boston: It’s not explicitly branded as a DPM meetup, but seeing the invite list of the Boston low-key data happy hour, it’s not not a DPM meetup 😉

• Dublin: Meetup isn’t launched yet, but my colleague Sagar is collecting interest via this form.

• [Your city here?]: Hit me up if you’re thinking of starting a DPM meetup - I’d love to help! Arielle and I will be putting together some resources from our experience hosting 15+ DPM meetups over the past couple years to help others do the same 😊

I’m not talking about ML POCs that were built more to show off the technology than solve a business problem, or which would cost more to operate and maintain than the benefit they’d bring. I mean when you’ve ticked pesky boxes like:

• “Is the problem we’re looking to solve valuable enough?”

• “Do we have the right data?”

• “Is our model good/accurate enough?”

• “Do we have the right business/domain expertise guiding us?”

• “Have we engaged the business stakeholder whose team will use our tool?”

And yet, after some digging, you find out that folks aren’t using your tool - a tool which you were sure would meaningful improve key KPIs1 and had built up a business case that leaders from tech, data, and business all validated.

A lot of data & product folks think of product validation as being about feasibility (can we build the thing), viability (does it make commercial sense to build it), and value (are we solving a valuable enough problem).

Here’s what that looks like in Venn form:

What’s missing from that view is usability (I know I call it out as part of the blue circle, so technically it’s not missing - but you probably didn’t notice it). Usability is one of the four big risks, as Marty Cagan calls them in his excellent book Inspired.

In short, you need to make sure that your product is usable to make sure it gets used. It sounds really basic, but is often totally overlooked.

Examples of data products with usability challenges:

• Accessing the data requires (very basic) SQL knowledge, but the end user doesn’t know any SQL and finds the idea of learning it intimidating and/or something they don’t have time for

• The dashboard is hard to use without browsing a pre-recorded training video and/or separate documentation, and the users either don’t remember the training they went through, or never bothered to go through it

• Accessing the insights requires logging into a separate tool that’s not part of the user’s regular workflow, so it’s easy for them to forget to do it

• The dashboard was built with desktop screens in mind, but the users are out in the field, so they only have smartphones and small tablets at their disposal. The dashboard doesn’t load everything in that view, and examining charts is impossible

• The model and dashboard refreshes every Sunday at 11pm, which means that it’s out of date halfway through the week. Users spotted the out of date figures and no longer trust the dashboard or the model that sits behind it, because they were used to seeing live numbers in their previous (much less smart/powerful) tool.

• The dashboard doesn’t let users drill down by {date/product/customer/whatever matters to them}. When the dashboard was being designed, it was the manager of the manager of those users who was part of the project as the business stakeholder / person giving feedback, and they were only looking at figures at a much less granular level, so they were happy with what you made.

• The interactive webapp and ML model are perfectly aligned to users’ workflow, device type, technical understanding, and everything else, but none of the users were involved during the development and testing process. Instead, one day there were told “this is the new tool, stop using Excel now” and it left a very sour feeling. Who made this tool? What makes them think they know better? Who do they think they are, coming here telling us how to do our job? What do you mean they’ve automated some of my tasks? For many months since go-live users find excuses for why they aren’t using the tool, and many aren’t even responding to you with feedback - they think you’re out to automate their jobs and get them fired.

I can keep going with examples, but I think you get it. In our effort to do things quickly and without disrupting the business (or because we’ve been given 100 promises by business leaders that we are building the right thing for their org), we end up building something that isn’t right, or that for other reasons ends up not being used. It’s why change management and user experience (UX) design are so important in data transformations.

I’ll write about change management another time - this post is to recommend one of my favourite resources for applying UX design thinking to data work.

The Experiencing Data podcast

Experiencing Data is Brian O'Neill's podcast where he interviews data product leaders on how teams are integrating product-oriented methodologies and UX design to ensure their data-driven applications will get used in the last mile. It's been a fantastic learning resource for me, both for learning about new approaches and ideas and (perhaps more importantly) for affirming when I've been on the right track in my own thinking.

I’ve been listening to the podcast for 2+ years now, and recommend it to pretty much every data professional interested in the non-technical aspects of data work that I meet.

Listening to Experiencing Data was also what drove me to dust off the old Design Thinking skills I'd picked up when I first started working in consulting and product management, and spend 10 weeks on a UX Design course at Brainstation (I wrote about my learning highlights here). We talked a bit about the course, how it's been valuable on the job, and how I wish I'd learned some of these things sooner in my career.

One thing I always appreciate when someone recommends a podcast is being pointed to a few standout episodes to go check out - it gets too daunting otherwise. So here's mine for Experiencing Data (with the caveat that I still have loads of episodes left to go through, some recent and some old):

• Manav Misra on how he established a data product approach at Regions Bank, creating new roles (including his CDAO role)

• Emilie Schario (who wrote one of the older data product thought pieces I've come across) on running data teams as product teams

• Eugenio Zuccarelli on helping paediatric cardiac surgeons make better decisions using machine learning. Super cool use case and really highlights the need for taking SMEs and users on the journey with you, not just handing them a 'finished' product

• Sebastian Klapdor on how he implemented a data product team at Vista, which now employs 35 data product managers (nearly 1% of the company's workforce!)

• Jon Cooke for a variety of golden nuggets on how to generate business value quickly and with a small team through data products

• Peter Everill on carrying out product discovery to drive user adoption and business value at Sainsbury's

• Nadiem von Heydebrand on treating data products a bit like how fund managers think of investment portfolios

• Osian Jones on running a data platform team as a product team, especially re:coming up with the right ways to collect feedback, understand adoption, and quantify your impact when you're in a central/platform team (i.e. usually multiple steps removed from the end user impact you're enabling)

A year ago, I was also a guest on the podcast (episode #130). I can’t believe it’s only been a year - I listen back to what I’m saying and who I was at the time and it feels like so much longer ago. Lots has changed both personally and professionally, though I still stand by everything I said on the episode 😄

Besides the podcast, Brian has a number of other resources on his website, including articles, a newsletter, a course, and the Data Product Leadership community (which I am part of).

// in other news

Busy period for in-person DPM meetups:

• London: Next meetup is on 9th Dec, and you can sign up for future meetups here

• Montreal: Sign up for future meetups here

• Barcelona: Next meetup is today (20 Nov), and you can sign up for future meetups here

• Paris: Next meetup is on 3rd Dec, and you can sign up for future meetups here

• Cambridge/Boston: It’s not explicitly branded as a DPM meetup, but seeing the invite list of the Boston low-key data happy hour, it’s not not a DPM meetup 😉

• Dublin: Meetup isn’t launched yet, but my colleague Sagar is collecting interest via this form.

• [Your city here?]: Hit me up if you’re thinking of starting a DPM meetup - I’d love to help! Arielle and I will be putting together some resources from our experience hosting 15+ DPM meetups over the past couple years to help others do the same 😊

DPM podcast: I recently recorded some episodes I’m super excited about, and can’t wait for them to get released. If you’d like to come along as a guest, fill this form!

Books I’m reading:

• DPM-related: I’ve been loving re-reading Team Topologies. So much of the reason why technical teams do or don’t deliver value comes down to org structure, ways of working, and preserving (or not) domain knowledge. Team Topologies does an excellent job articulating the antipatterns involved in most tech orgs, and lays out a set of principles for overcoming them.

• Nonfiction, but not DPM related: Good Work by

  Paul Millerd is about working out what ‘good work’ means to you. Along with Paul’s first book, The Pathless Path, it’s a book I can’t shut up about, and if we’ve met recently I have almost certainly gone on a 20-minute ramble and/or gifted you a copy of the book.

• Fiction: I love science fiction, and on a serious note I think it helps product managers think more creatively and be more visionary about the future. It’s also just really good fun. Over the past couple of months, I’ve listened to approx. 238 hours (!) of J.S. Morin’s series Galaxy Outlaws, Astral Prime, and Mercy for Hire. It’s so good, and there’s so much of it (I just started the 4th series, so another ~60 hours of quality listening). And I would especially recommend it in audiobook format. Super fun.

I really love these events. Working as a PM can be very lonely. We rarely work closely with other PMs, and almost never the way that e.g. data scientists might work together. There's little to no equivalent to pair programming, peer reviews, joint problem-solving etc. Plus, being in a leadership role, you often need to be careful with what you say to others.

And you just can't beat the in-person experience. On the one hand, you have the Zoom fatigue that comes with spending so many hours a day in meetings, user interviews, customer calls, and technical working sessions. On the other, LLMs are having the unfortunate side-effect of making me question half the stuff I come across on social media. Lastly, especially with asynchronous communities on places like Circle and Slack, you look away for one second (or one week, or one month...) and suddenly there's more unread messages than you'll ever have hope to keep up with.

There’s some brilliant online communities out there for folks working in data, product, and even the intersection of the two (shout out to the DPLC), and they clearly work great for lots of people. Maybe I’m more Zoom- and Slack-fatigued than the average PM, but I have struggled to be consistent in participating and getting value out of these over the past ~7-8 years. I have, however, gotten tons of value out of tech-enabled IRL communities (shout out to London Rock Climbers)

Side note: My prediction about how LLMs will impact society outside of job automation is that we'll see a return and re-emphasis on local, IRL communities. That's partly because LLMs are resulting in a lot more disinformation (or just garbage) content, but also partly because of the direction social media has been on for a few years now. We crave authenticity, but also to escape the pernicious trap of push notifications, red dots, and doomscrolling.

Anyway, back to data product management meetups. Since the London DPM meetup started in May of '23, two more have launched, and another is in the works:

• Montréal, Canada: Last year, Arielle Rolland and I got chatting about her starting a DPM meetup in Montréal after hearing about the London one on my Experiencing Data podcast episode. After a quick call together, Arielle set up the Montréal DPM meetup with great success, and they recently held their 3rd meetup. Next one happening on Oct 16!

• Barcelona, Spain: When I've moved from London to Barcelona earlier this year, I knew I had to do the same thing here - and I'm pleased to report that we had 30+ folks attend Barcelona's first Data & AI PM meetup!

• Dublin, Ireland: Most recently, my colleague Sagar Nikam has started preparing for the launch of Dublin's DPM meetup! Fill in this form if you’re in Dublin and interested 😊

Open offer to all

Open offer: If you're thinking of starting a meetup for Data & AI PMs, I'd love to help out.

Besides the DPM meetups I've organised over the past couple years, I've been organising events for over a decade ranging from debate tournaments with hundreds of participants to bouldering social meetups

Here's how I can help:

• Help garner interest: Share my google form template that I've used for Barcelona (currently being used to gauge interest in Dublin 👀)

• Help with setting up the first event: I've made image templates on Canva for the 4 different formats I use (Luma banner, Luma logo, Luma social preview, LinkedIn post)

• Connect you to folks in my network who'd be good to attend your event, either as audience or as speakers (if you want to organise talks/panels, not just networking/roundtables)

• Advice around meetup formats based on size and audience profile

• Let’s create a free, virtual community to supplement the IRL meetups: What I love about the meetups is that they're face to face. Personally I'm very online-community-fatigued (doesn't help that I'm part of so many...), and the only ones I'm currently active on right now are the ones that are there to supplement the two IRL communities I'm part of. I want to try the same for the London, Barcelona, Montreal, and Dublin meetups, where we can have a combination of location-specific channels for folks to connect in between meetups, as well as topic-specific channels like "#data-mesh" or "#mlops" or "#job-ads"

"Alright, what's in it for you?" I hear you wonder. It's a good question. To an extent you can ask the same question for the two meetups I run, or the DPM podcast I've started co-hosting, or this newsletter 😆

In truth, I really enjoy this stuff. I think product thinking is sorely needed in data teams, and I'm excited to spend my free time reading, writing, and chatting about how we can do it best. I remember how much it sucked to be a Data PM ~6-7 years ago and feeling like an impostor when comparing myself to all the B2C app and B2B SaaS PMs I was meeting or learning from in courses, meetups, and books.

On the more selfish side, it's a way for me to reach more people. For example, I'd ask meetup hosts to help 'scout' for great guests to invite to the DPMiA podcast, or to refer anyone who'd benefit from my writing or teaching. I'm considering doing more freelance work in the future (not yet), which would also benefit from being connected to more folks around the globe 😊 But I very much see all that as a win-win, rather than something extractive.

DPM meetup FAQs

1. I worry that it's a lot of effort
   Thankfully it can be quite lightweight, especially if you can partner with companies willing to host. In London, we've rotated across a few different offices from companies willing to offer up their space and pay for a few drinks and snacks. If your company is willing and able to host the first meetup, that may make things simpler. Other times, there might be someone else who's even more willing and able.

2. Will enough people show up?
   Quality > quantity. Some of our best meetups were <15 people in attendance. Even when we get more folks to join, I usually split us into small groups to get the benefits of a small gathering: Everyone gets to contribute, and folks feel more like they're part of a conversation rather than presenting to an audience.

3. What's the right format?
   There's no one-size-fits all here. It will depend a lot on three dimensions:

   1. How many people are in attendance

   2. What roles those people have (e.g. are they all Data PMs or similar? or lots of technical folks too?)

   3. How experienced everyone is. An event with lots of early career or student attendees may be better as a presentation or panel event, while an event with more senior folks would be better as a roundtable, for example

   
   In London and Barcelona, we’ve so far focused on creating small roundtables (/group therapy) discussions, instead of the more traditional format of presentations or panels. At first it was one group of 10-15 people, then we split into two groups, and most recently we had 5 or 6 groups of 4-8 people each. But we may mix things up and add some presentations at some point as well!

   
   We’ve also played around with time of day: Usually the meetup in after work, but we’ve also had a breakfast meetup (and to be honest, I’d love to have more of those - lots of folks can’t make the evening due to childcare duties, but can commute 1h earlier than usual more easily).

4. Who's the right target audience?
   Here's the mix of profiles that's made for brilliant discussions in my London and Barcelona meetups:

   • Data & ML product managers (duh)

   • Folks in other roles implicitly doing the work of a DPM (e.g. business analyst, data science manager, analytics manager, head of data)

   • Non-data product or engineering folks who often work with data teams (e.g. engineering manager, software PM)

5. I want to start a meetup, but my company can't / won't sponsor it
   You can look to other members of your local community who could host (i.e. provide a venue and some drinks or snacks), or meet at a coffee shop, bar, or restaurant. Especially if you start off as a small group, you don't necessarily need a private venue, though personally I prefer them as they're more quiet - but so are some cafes, for example.

6. How can I get more advice?
   Together with Arielle, we’ll start putting together more resources to help others host their own DPM meetups. I’m also happy to jump on a call with you and chat about it 😃

Hit me up if you're thinking of setting one up and wondering about the effort, logistics, or anything else. I'd love to see more local DPM meetups pop up, and hopefully I can come visit too 😊

Off topic: I’ll be launching my course in the coming days!

The tl;dr syllabus is:

1. Value Mapping: Strategies and tactics for quantifying the commercial, operational, reputational, and environmental benefits of data and AI initiatives

2. Opportunity Discovery: How to quickly identify & pitch the highest value opportunities for data and AI initiatives that can move the needle

If you’re interested and would like to know more, I’d love to get your input on this quick 1-minute survey.

An (extremely brief) history lesson

In the early days of 'data science', you had unicorns that were seemingly able to do it all: Find the right opportunities, get the data, wrangle the data, build models, recommend decisions, productionise solutions. Or so the story went anyway.

As more companies started buying into the hype of the "sexiest job of the 21st century", we saw much-needed specialisation emerge: Data engineers started preceding data scientists, helping reduce the amount of time spent wrangling data (and doing it in a more scalable and sustainable way). Then came machine learning researchers, machine learning engineers, model analysts, data science product managers, analytics engineers, and so on.

Why do we specialise data roles?

The logic is the same, or at least similar, as in any scaling organisation: What starts as a 1-person role (e.g. 'marketing manager') becomes a small team (e.g. a content marketer, SEO expert, and their manager), and gradually turns into a department comprised of many teams and specialisations (e.g. Brand / Growth / Acquisition). It's partly because the workload increases, but also because specialists have a deeper focus and expertise. If you're in the early days of forming a data team, you may not need someone who is an expert at fine-tuning ML models, or who can optimise data platform costs, or who has deep domain expertise in marketing mix modelling. You're just trying to get quick wins and often incur a lot of tech-debt to do so (which is good, given the alternative would be to over-engineer stuff you don't even know is needed).

I often see organisations see the Data PM as someone that can act as a shield for the rest of the data team: The person that can go to meetings, talk to people, think about what the team should work on while everyone else is focused on delivery. When your data scientists are complaining that they have so many meetings there's no time to do actual work, that seems like a good thing.

But it's a double-edged sword, because it's good for your data scientists (or analysts, or engineers) to be spending some time with end users, both to understand the problem space better, relate to the users and their pain points, but also to then provide suggestions as to what the solution should look like.

This is an issue on a few levels:

• We might miss out on the right solution: When your technical team is there as you learn about the as-is process, the current way of doing things, the pain points, and who the users are, they might be able to put 1+1 together where the Data PM would've missed something. Maybe the DPM was going to propose something more complex than what's needed, maybe they'd have failed to identify a potential pain point as resolvable, maybe they'd not think a certain bit of information was worth passing on back to the team when they debrief.

• It becomes harder for the data scientist/analyst/engineer to understand the impact of their work: It's one thing to be given context in a sprint planning session or via a Jira ticket, and another to actually shadow the person you're gonna help make better decisions, or whose tedious workflow you'll help simplify. If you're just executing tasks because they're on tickets with your name on, work gets less interesting and satisfying.

• It stunts the data team member's professional development: Communicating with business stakeholders, identifying ways data can drive efficiency/growth/decisions, and understanding your org are all things that data scientists should be doing, and getting better at over time. That's how they'll progress to Senior then Manager, or move laterally to Data Product, or eventually become Head of Data.

How can I avoid stunting my teammates' development?

First off, talk to your technical teammates. Some will express the desire to spend more time with business stakeholders, or to take turns presenting, or maybe they'll want to give project management a go. Others will want to avoid as many meetings as possible, because they want to remain technically-focused ICs. Not everyone wants to make manager, or become T-shaped, and usually orgs need both profiles to succeed. Also, make sure to have this conversation more than once - people change their minds and priorities! I try to do it 1-2x a year usually. It also helps do things like allocate tasks or move folks across teams when you know what they actually want to do vs. what they do somewhat begrudgingly.

For the folks who want to get more business exposure: By all means, spare them from calls where you don't think they'll learn or contribute. For example that'll often be calls about project status or resourcing (though not always). Also feel free to agree on trials/experiments together. The grass is always greener on the other side, and some data scientists who at first say they want to be in more meetings or present or interview may change their mind after doing it - at which point they'll be grateful you're covering for them, rather than build up resentful thoughts.

Ensure your technical lead is your peer, not de facto subordinate. This might be the DS Manager, or they might just be the most senior data scientist or engineer on the project. This is a general good practice for many reasons, but in this context, they're the person that should be leading on Opportunity Discovery alongside you. As a rule of thumb, I aim to have my technical lead attend >80% of sessions that are about understanding either the problem space (and > 90% of sessions that are about fleshing out the solution).

A common working pattern from the software world is to have a Product Trio (Product Manager + Engineering lead + Designer) handle Discovery, and for the Eng/tech lead to then be responsible for briefing the technical team, breaking down the work, and managing delivery. A lot of data teams take a much more hierarchical approach, where the data lead / data product manager / data product owner isn't just covering the product side of things, but is also expected to act as the technical lead - even though they're often not technical enough to do so. Even if your Data PM is technically savvy, having two brains work on the same problem is usually better - as long as you're still clear about who owns which part of the work, rather than get to the classic "if there's more than one owner, then no one's owning anything" situation.

The last idea to throw out there is to give data scientists or data engineers some limited PM duties. At the end of the day, not every component or piece of work will end up being big enough to warrant having a DPM own it. Having a member of the technical team that built it also act as its owner will give you the dual benefit of (a) ensuring someone is doing things like maintaining the component, getting feedback, acting as the first point of contact, and over time improving it, while (b) giving that person a trial run for what it's like having to do that sort of thing. I will admit, this is something that we've often said we wanted to do, but it's not always stuck - and that's happened at every single company I've worked at since becoming a product manager 😅. You've gotta walk the walk, not just talk the talk! If someone's the lead/owner for a component, they need to be given the time to carry out that role - not expected to magically find 0.5-1 FTE days a week out of their free time.

Lastly, take note at how I'm talking about 'teammates' here, not reports. Even if organisationally you're a PM with the DS/DE folks on your team/product reporting to you, it's important to treat them as peers when it comes to their expertise.

How do we move ahead?

I no longer worry that having Data PMs in well-organised data product teams leads to the stunting of technically-focused team members. More junior (and/or antisocial) team members start off by focusing on delivery, and over time get the option to spend more time on business-facing tasks like discovery, planning, getting feedback. Technical leads get to be the DPM's peer, and bear equal or at least equivalent responsibility in validating opportunities and making sure their team is working on the right things, not just that they're working in the right ways.

But my worry remains for the teams that aren't really working as cross-functional product teams, but that have rather renamed their data project managers into "DPM" or "DPO" (usually it's the latter, and combined with a horrible, anti-Agile implementation of 'aGiLe' like SAFe). In such teams, you have a disconnect between the DPO/DPM and the technical team, and in turn between the business problem and the folks working on the solution for it. If you're a Data PM or PO in such a team, try involving your tech lead / some of your technical team in key meetings with your stakeholders.

If you're a data scientist feeling wrongly left out of meetings with stakeholders, try and suggest changing that, even if it's framed as a limited time trial. Point to examples where your non-involvement led to errors, delays, or other issues - but try not to frame it confrontationally. “What if we tried…” tends to work much better than “see, this is why I was pushing to…”, as it avoids putting the other person on the defensive.

Good luck!

Unrelated news from this month: DPM events

This month was busy on the IRL meetup side, with Data PM meetups taking place in Barcelona, London, and Montréal all days apart from each other. Plus, right after the London meetup came two days of BigDataLDN, one of the largest data conferences of the year. Data products were everywhere at BDL, though a lot of the time people were actually talking about the data-as-a-product mesh term (about which I’ll share a rant another day). Suffice to say, I'll be spending the next few days drinking smoothies, eating salads, and avoiding (too much) social contact to recharge my social and physical batteries 😆

Coming up:

• September 24: Montréal Data PM meetup #3 (in person)

• October 1: Mindfuel Value Measurement DPM panel with , Andreas Mazat, William Alvarez, and myself (online)

I hear there might be a few more DPM meetups being organised in a couple of European cities… Watch this space 👀 Next week’s newsletter will touch on this some more, but if you’re thinking of organising a DPM meetup in your city, hit me up! I’d love to help out.

I really want to buy into the claims that this is a preview of things to come: No more crappy enterprise software nobody likes to use, which requires $millions paid to consultants to configure the software for you 🦄 And with the AI-fication of development, you can have non-FAANG tech talent work together with business users to build the tools.

BUT I am sceptical about this, on a few levels. Let's 'delve'1 in…

First source of scepticism: This might be more PR stunt than real story

Remember, Klarna is gunning for an IPO. This isn't the first story about how they're using AI to achieve impressive results in recent months - in Q1, they announced that they're using AI to automate 700 customer service jobs. The techno-optimist in me says they're just making good use of generative AI, but the sceptic in me is thinking that they're maybe just trying to create an impression that they’re a solid buy ("an AI-first company!"), regardless of what their financial statements might suggest come IPO time.

Klarna is far from alone here. Companies of all shapes and sizes are rushing to push out examples of using Generative AI, even when the business case is weak (spending more on Open AI API credits, cloud compute, or data scientist wages than what they're saving), or when the technical implementation is poor and results in hilarious and/or costly repercussions.

Objection #2: Can companies really DIY the tools they need?

The argument here is the same as with no-code tools pushing development from specialised, expensive software teams to the hands of business users.

The no- (or low-)code argument goes: Business users understand their problems best, they're experts in their domain. When you need to bring in a software team, you need to spend a lot of time translating requirements, risk misunderstandings, and incur huge costs to build stuff. With a no-code tool like Notion or Airtable, you get the drag-and-drop beauty of Excel, and couple it with the power of databases and other software components that lets you build simple-yet-powerful business applications like CRMs, project management trackers, content calendars, budget planners, and product roadmaps.

A lot of teams are very happy users of Notion, Airtable, Coda. They tend to be in smaller organisations, have simpler requirements, and start from a relatively greenfield setup.

Enterprise SaaS can be very complicated. Granted, a lot of that complexity is borne out of a need to serve many different customers, but a lot of it is also because, well, it's complicated stuff. Lots of workflows, governance, features, compliance reqs, localisation... There's a reason why most SaaS companies add headcount besides needing more folks to grow even further.

Looking at the Klarna story, they called out that their replacement of Salesforce and Workday wasn't just about using AI - it was also about standardisation and simplification. So it makes sense that maybe a bloated tool wasn't needed after they simplified their workflows and SOPs. The question is, will that simplification last? Kudos to Klarna if so. But usually complexity in orgs follows the second law of thermodynamics, and increases over time.

If Klarna's requirements for complexity in their CRM or HCM grow over time, will the company reach the tipping point where it makes economic sense to go back to Salesforce or Workday? And even if that happens, will economic rationalism prevail, or will they instead bow to the sunk cost fallacy and double down by investing more on enhancing their software than it would've cost to re-buy instead?

Objection #3: Just because you can doesn't mean you should

Suppose the economic case of Klarna, or any Klarna, ditching their costly, bloated, and unfit-for-purpose SaaS tool is overwhelming. They can save money and

Well, no. Investment decisions are not made on the basis of "do the benefits outweight the costs?", they are made by evaluating opportunity cost. Take this simple case as an example - suppose I have $100, and want to decide where to invest it.

Option 1: I invest $100 and get back $150
Option 2: I invest $100 and get back $500
Option 3: I invest $100 and get back $50
Option 4: I do not invest my $100 and keep $100

Looking at the above, you'd be silly not to take option 2, right? Assuming I've not hidden the details about probability of success and risk and all that.

But why? Option 1 is also net positive! Benefits > costs! But obviously the net gan is much less, $50 vs $400.

Okay, back to the less simplified point: Businesses generally succeed by honing in on their competitive advantages and investing their time and effort and extracting value out of them. It's why most businesses nowadays use AWS, GCP, or Azure instead of hosting their software in proprietary datacentres and server farms: Even if it costs a bit more to run your workloads in AWS than your own servers, you don't need to run a whole IT department that has to take care of that stuff for you, buying hardware, maintaining it, and then being in trouble if you've under- or over-invested. It's why I'm using Substack to host this blog and send out copies via email, rather than build my own website to do so - I want to use my time to write articles, not debug the stupid coding errors I'm inevitably bound to make.

So what does this mean in the context of Klarna? Well, think about it: Who's building this in-house software? It'll be a mix of Klarna's technical folks and the business users who'll be using it. Is that the best use of their time? Shouldn't they be shipping features, running campaigns, keeping customers happy? Why are they spending time on this instead? Will they also need to keep spending time away from their day job to maintain the software?

Maybe it's some other tech team (not Klarna's A-Team) building this. Maybe it's outsourced. But it still has to be managed. Which executive now has to dilute their focus because in-house software product management has become part of their remit?

All that said, there comes a point where the best use of a company's resources is to in-house a capability. When I was at PepsiCo, I was scaling an internal product that was replacing what was previously being done by an agency. The agency was changing tons for the work, so we only used them for large countries, and they only did the work once every 1-3 years, so the insights weren't fresh.

Another example of in-housing that defies conventional wisdom is 37Signals' migration away from the cloud, who are looking to save ~$7m over the next five years (for context, their cloud spend was $3.2m per year, so this is a big saving). Does that mean everyone should start buying server racks again? Almost certainly not. But it made sense for 37Signals, who have a relatively stable userbase, strong technical expertise, minimal need for higher-level cloud services, and a clear economic case for the transition.

Going back to the question "will AI eat software?", when it comes to this objection I think what we're looking at is a shift in the threshold / tipping point where a previously unwise decision to DIY becomes wise. AI lowers the barriers to software development, for example by making a small team of developers more productive, or making it easier to disentangle complex business logic. It's a bit like how it's easier to build software today using Python and its abundance of packages compared to 40 years ago when COBOL was the backbone of enterprise applications.

Objection #4: This is AI-washing

It's a lot more palatable to say "we are cutting jobs and/or budgets because AI is making us more productive" than, say, because you realised you over-hired, or because of inflation remaining high, or because you think there is a recession looming.

Another (of many) example: UPS had its largest layoff in 116 years last February, with the CEO alluding to their AI work in the same announcement (but later a UPS spokesperson clarified that AI isn't replacing jobs), rather than letting the attention go towards the drop in parcel volumes or their rise in labour costs following their agreement with their unionised workforce 6 months earlier (NY Times).

So, is AI going to eat software?

Look, there will be some 'eating' for sure. For use cases where the business case almost made sense before LLMs, the answer is most likely now DIY > buy. But I don't think most 'buy' decisions were just one step away from being 'build' decisions.

What I do see as much more likely is for software companies that successfully pivot (or start as greenfield developments) with AI at their core to make steady advances against incumbents. In some cases, that'll be companies competing with other software businesses, like Intercom's embedded AI chatbots. In other cases, it'll be more about AI automating work that was previously seen as strictly a human service offering, like paralegal work being done by the specialised LLM foundation models of Harvey AI.

Could a law firm build their own paralegal agents using Open AI's API + software engineering teams + specialists collating legal knowledge? Yeah, probably. Would it be cheaper, faster, and more reliable than to use Harvey? Not in the short term, that's for sure. And probably not longer-term unless if you're one of the largest players in the market.

Could an ecommerce business built its own Intercom-style chatbot? Maybe if they're quite large, but even then - what strategic priorities will you need to drop or dilute in order to save a 6 figure sum? And then you'll have built something that's not going to evolve over time or get fixed when it breaks, unless if you decide to make another sacrifice and once again deprioritise your competitive advantage.

Self-sufficiency sounds like a nice idea, but it's not generally what's most profitable. Apple, the world's largest company by capitalisation, outsources its manufacturing. Nvidia doesn't build its chips either - they do the design, and TSMC manufactures them. Shopify provides the online storefront, but doesn't handle logistics or fulfilment. Netflix uses AWS instead of running their own infrastructure. The list goes on.

AI is transforming the way we build software, which will of course impact the SaaS landscape. But it won’t happen overnight, and not all attempts to ditch SaaS will be well-thought out (much like all decisions in large organisations where the principal-agent problem runs amok)

In other news

Book recommendation: I've been reading David Pereira's excellent book, Untrapping Product Teams. Really enjoying it - will be sharing my notes and highlights in the coming weeks.

Barcelona meetup: Last week, we held the first Barcelona Data & AI product management meetup! If you're in Barcelona, then (a) sign up to join the next meetup here, and (b) let's meet for coffee!

London meetup: Next week, I'll be in London for the BigDataLDN conference, as well as our next London Data & AI product management meetup

Data PM in Action podcast: We recorded some excellent episodes earlier this summer that I can’t wait to see published in the coming weeks. If you’re a Data PM and want to share your story and lessons learned, drop me a message.

DPM course: I'm putting the finishing touches on my first course! If that sounds interesting to you, I'd love to get your feedback on what you'd like to see included or not included before I launch later this month!

I’m not a fan of Feature Factories, but I’ve learned to stop taking an absolutist stance against the approach ("they're idiots! have they never read Marty Cagan or Melissa Perri?!")

I’ve accepted two truths on this:

1. This might be what's best for your business at the moment; and

2. I won't change the entire company's operating and business model from one day to the next.

But that doesn’t mean we’re doomed! In today’s newsletter, I’ll explain how to get unstuck and start nudging your org to see things your way (hint: the advice is in the title).

Let’s get to it.

It might be for the best

"Sales-driven" and "project-driven" often get used as derogatory terms in the Product world. We have our reasons for it, but let's be clear: We aren't always right. Sometimes, a sales-led model really is what's best. The two main cases I've seen for it are (1) when you need to sell to stay afloat (not everyone has tons of seed/VC cash to burn), and (2) that it's a good way to establish product-market fit.

Let's go over the four main reasons why orgs remain sales-driven.

Reason 1: Cash is king

Businesses need cash to stay afloat. Sometimes, that means having to be short-termist. To quote legendary economist John Maynard Keynes: "In the long run, we're all dead": The long run is nothing but a collection of compounding short term decisions (which is also the argument to not be purely short-termist). It's all well and good to think about your long-term vision, but if the company can't survive the journey to your product utopia, it'll all be just a nice story to reminisce about.

Reason 2: Enterprise products are not $20/user/month SaaS

The need for cash isn't the only reason why a sales-driven model might make sense. If you're working on B2LargeB / B2Enterprise products, you're likely looking at a very slow number of deals that are each worth six, seven, or more figures each, and which will all likely require a good amount of effort from sales, product, and engineering to get over the line.

Reason 3: "Product-Market Fit" isn't an intellectual exercise

It's funny how often companies claim to have reached product-market fit for products that have hardly ever been sold. Just because prospects are receptive to your demos ("that looks great!", "this is really smart", "I can see us using this") doesn't mean

Note to the above: My experience is mostly in 0-1 B2LargeB (or internal) data and AI products. I think the case for being product-led becomes a lot stronger later down the maturity curve, and also for smaller ticket sales.

Reason 4: Okay fine, sometimes companies are just silly

The last reason why sales-led growth is here to stay in your org is the one you were probably thinking of from the start: That this is what the business is used to, and that there isn't necessarily a higher strategy behind it. In that case, change might be what's needed - but it'll take time and effort the right kind of effort

Change takes time convincing

Let's say you think your org is too sales-driven (if you're an internal PM like most Data PMs are, you can replace this with something like "important stakeholder needs this asap"-driven). And let's say it's not for, um, sound strategic reasons - but do remember that you're not the CEO, and that you may not see or understand the full picture. PMs are not 'mini CEOs' and should they live under any such delusions.

You have a vision for how your product and company can succeed, if only it were more product-led! Focus on building a great product that sells itself - though you know that doesn't mean the same thing as "build it and they will come". It's about finding the right problems that need solving, and then solving them in a scalable way. Wasn't that why they needed to hire a Product Manager, anyway?

You've tried to explain this to your manager, whose new job title is Product Director, but they've never actually worked as a PM - and it shows. You grow more and more frustrated as you're asked to build useless feature after useless feature, just because a salesperson promised it or because your CMO thinks it's embarrassing to not be able to show that you have all the same features as our competitors. You despair. Where is the upfront discovery? Where is the retrospective evaluation of what's worked well vs. what hasn't? Will we never sunset features that are just adding clutter? How will we know when to double down on something promising?

Or, as an internal data PM, you're churning out tables, reports, dashboards, and models, just because some other project or director is asking for them. Same as your frustrated external-facing colleague, you don't know which ones are adding value versus which ones are just shipped for the sake of it. You don't even know if any of it is being used, let alone what it's being used for. Questions about how much monetary value each output is adding are in the same plane as Iain M. Banks' utopian science fiction novels: Intellectually very interesting, but bear little impact on your day-to-day reality1.

Both of you, the external and internal PMs, are being asked to focus on outputs, not outcomes. And it's not just about keeping your manager happy in your weekly 1:1s - you know this stuff is going to affect your end-of-year performance rating, your chances of getting promoted, and the things you can brag about on your CV.

So you play the game. You pretend burndown charts are an indicator of performance. You push your team to churn things out faster. You proudly display your team's throughput metrics like you're a literal factory trying to meet quota. Every day that passes, you feel less like a Product Manager, and more like a project delivery person. Oh, what would Marty think?

You've gotta play the game - but the rules are changing

Look, if your performance rating and general keeping of the peace depends on delivering the outputs your org expects you to, I'm not gonna tell you to not do that.

But you can't only do that.

Guess what? If you ship all the features that are required -nay, demanded- and they don't translate into any more sales or genuine cost savings or whatever else actually matters to a business' continued survival, nobody is going to celebrate your hard work. At least nowhere nearly as much as when a big customer finally signs or ARR targets are met.

Meanwhile, some other team (or company) might get lucky. They'll happen to sign a customer not because of the brilliant plan to get them, but just because the customer was ready to sign. Or because they were in a rush to spend their annual budget before losing it next year. Or because one of their VPs went to school with one of your VPs. Whatever. And that team may well be hailed as geniuses. Their PM gets fast-tracked for promotion, their performance bonuses are 2x that of everyone else, and their CVs tell a pretty damn compelling story.

That's the trouble with aiming for outcomes, by the way. You won't be able to control them nearly as well as outputs. A macroeconomic shift might make everything 10x harder, or 10x easier. A competitor pivoting to something stupid might open up opportunities for growth. Another's raise might raise your cost of acquisition significantly. But that's business - it's not fair. And at the end of the day, outcomes are what we're after. It's just that so many of us work for sufficiently large and complicated orgs that we can hide away behind excuses and convoluted performance management systems that we can spend our entire career destroying more value than we create.

Okay, that was a bit grim. Sorry. But you know it's true. You see those people all the time. All they seem to do is fail upwards. And a lot of corporate cultures will continue to reward them. Maybe they've just been better at playing the game than you.

But things are changing. Much like the rest of the tech sector, data teams have benefited from over a decade of cheap money, high FOMO, and the benefit of the doubt about when companies can expect to see a positive ROI.

Here's a couple slides I shared at my talk at the Athens Analytics & BI meetup a few months ago:

My argument was twofold:

1. These are things more companies will increasingly demand, if they aren't already

2. Data teams should look to provide and demonstrate their value contribution before they are asked - because it might be too late by the time that happens

Try, as much as you can get away with, to do what's most likely to trigger the desired outcome. Even if it's not your job. Even if nobody is asking for it.

Remember: Show, don’t tell!

Play the game, but cheat too

“A rising tide lifts all boats.”

That's what my example about the team stumbling onto success earlier was about: If your product is doing well, if it's growing, if it's returning a healthy profit - that's the rising tide. Same for your overall company performance. Otherwise you get fun situations like layoffs, hiring freezes, micromanaging leadership, and all those other things that often turn into self-fulfilling prophecies.

So how do we raise the tide when that's not our job?

Here's the advice: Try, as much as you can get away with, to do what's most likely to trigger the desired outcome. Even if it's not your job. Even if nobody is asking for it.

Show, don't tell. And do that while seeking forgiveness, not permission.

If you go to your manager saying "I think I should spend 2 weeks interviewing users and doing prototype testing before we start building this next feature", there's a good chance you'll be told no. If your leadership isn't used to working that way and doesn't see the value of that work, then mentioning some books or courses you took won't do much.

Contrast that with showing up saying "Hey, I've been showing some of our friendly customers mockups of the dashboard, and everyone has been positive about X, but also negative about Y. I took the initiative to mock up an alternative to Y and that seems to be more popular. Should we go ahead with Y(a), or would you like us to go ahead and develop Y(b) instead? I can send you the interview recordings and summaries if you want to dive deeper"

Over time, people will see the value of this work, and expect it. But not until they see the results.

That's what I've done for the bulk of my career. To some extent, it's about being proactive and not expecting to be told what to do every step of the way - problem solving! But other times, I was very much doing what I thought needed to be done, even when I was sort-of-and-sometimes-literally told to not waste time doing those things.

Epilogue

One line that never really comes up in the job descriptions of jobs I've applied for is that a PM needs to educate their teams and colleagues. Sure, sometimes there's stuff about evangelising their product, or helping develop data literacy, but it's never about "educate your team on what the hell a product manager does all day".

And yet that's a line I've consistently had to add to my own JD.

I'm sure data scientists 10 or 15 years ago were having to do the same. If you've been hired by people who don't know what you know, and have never done what you're doing, of course you can't expect them to have the playbook laid out for you from the start. And they aren't always aware of this, or they are, in theory, but when push comes to shove, their own instincts kick in about what's important, relevant, or required.

I've seen folks who have been hired into these kinds of complex, high-ambiguity, high-agency-requiring roles and just followed orders. It doesn't go very well. The reaction from their team or their stakeholders or their manager goes along the lines of "yeah, they're a bit useless aren't they?" behind their back, because they don't really understand how that person is meant to be useful. It just feels like they're not doing things right.

A PM needs to have high agency in order to succeed. You can't just do as you're told. I mean, you can, but then you're probably fooling yourself a little bit about the exact line of work you're in 😅

Epilogue after the epilogue

An offer to help out, bundled together with me asking for your help.

I’m working on a course for Data PMs, and I’d love to hear from folks interested in it. If you’d like to share your thoughts book a free coaching call here. Or maybe you’re not interested in the course, but want the coaching anyway - that’s a totally valid reason to book a call too 😊

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:

1. Why I'm worried about the rebranding of traditional governance & management roles into data product managers

2. How to spot whether you're in that 'rebranded DPM' bucket or not

3. Pre-empting the "you shouldn't be gatekeeping" response

4. 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:

1. 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)

2. 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.

3. 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.

4. 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?

We also don’t overcomplicate the art of prioritisation into a full-blown science. We want prioritisation to be quick and easy, especially when doing a first-pass scan that’s about zeroing in on the top x% of the work, and parking the rest either in a backlog or trashcan. So, if we’re taking “effort” as one input, that won’t be a full-blown work breakdown structure for each new feature, estimated in # of FTE hours and other resource requirements. It’s more likely to be a t-shirt size (small, medium, large, extra large) or maybe a score ranging from 1 to 5. Same for impact, confidence, reach, or any other proxy for those things you might be using.

This makes sense if your product team is empowered - meaning you don’t need to be micromanaged/get approvals from above every time you want to work on a new feature. It also helps if you have a reasonable ability to get other resources you might need - a data engineer’s time, some third-party data, and keep stakeholders who want to work with you to build things to help them.

In many ways, working in such a team and org is a very big green flag. It means your leadership gets that the 1900s hierarchical model of management is not conducive to modern knowledge work, where seniority doesn’t equal expertise, and self-organising product teams can deliver enormous value without (much) top-down direction.

In our quest for simplified prioritisation, we sometimes forget the language of business

Not having to worry too much about “buy in” and “business cases” can also be a trap for data teams. Consider that many data teams have operated for years with a relative carte blanche - a blank cheque to work on what they think will help the business. After all, data scientist is the sexiest job of the 21st century, and data is the new oil, right? And yet, this has helped engender a “build it and they will come” mindset that’s left with data products not being adopted or delivering value, or with data teams simply beholden to HiPPO request after HiPPO request, or with endless projects to build “data foundations” and platforms and then move to the next shiny platform tech before the old one even started being used in anger. It’s no surprise that we see study after study about how data teams fail to provide ROI-positive value to their organisations (e.g. last year Gartner reported that less than half of data and analytics teams provide value - as reported by their own leaders)

“Just because I don’t do long business cases for every new feature or product doesn’t mean I just think I should build it and they will come”, you might (very rightly) be thinking. I agree. Sometimes a simple ICE T-shirt exercise is enough to identify clear winning bets, and the time it would take to validate those assumptions is better spent actually building the damn thing. That’s because sometimes it’s obvious enough how a new project/product/feature/whatever is going to result in a big uplift in sales, or cut costs, or whatever else matters to your business most, and all without costing a fortune in time and money.

For example, maybe a single sale of a new external-facing data product will bring in $1M, and you know this because you’ve got a client ready to sign. You also know it’ll cost you at most $100k (unrealistically conservative estimate) to build and maintain, so you’re happy to put this as the #1 priority for this quarter - nothing else has a 10-20x ROI projection at the moment. So you’re not concerned about the specifics of cost to build, or whether you’ll be able to scale the product to more customers.

We can project this example into a broader 2x2 matrix looking at expected impact vs cost:

The above assumes a reasonably high confidence about costs and impact/value. If you're not sure yet, you have two options: (1) Accept the risk, or (2) spend more time validating your assumptions.

Here's what this year's potential work might look like on this 2x2:

Do you know your data team's ROI?

I'm willing to bet you've got gaps. A lot of data initiatives, especially the ones that are internal to an organisation, often have a very ambiguous returns - or at least they're not reported by and known by the data team itself. Finance or Commercial might have some numbers somewhere that overlap with your work, but it won't quite be 'ROI per data product'.

Similarly, you might be missing the cost side of things - even if you have an idea of value generated, at least from some initiatives.

Here’s a few examples of where your assumptions might be lacking on the value (or impact, or benefit) side of things:

• Your benefit is very simple to describe: This is a request coming from the CEO/CIO/SVP of Marketing/other HiPPO, so the impact of the request is you’ll keep this person happy (or at least not mad at you) 🙃

• You know how many FTE hours you’re going to save/unlock, but don’t know how much those are worth to the business. You can’t go around asking people for their payslips, can you?

• You have an idea for how much your ML model could improve a metric by, but there’s so many dependencies… You don’t want to commit to a target before version 1 has been built.

• Even if you know with certainty that you’ll e.g. predict churn probability with an accuracy of x% or higher, you don’t own the actual outcome, which is the sales team using these scores to prioritise which customers they call and offer “please stay with us” discounts.

• Maybe you’re confident that you and your stakeholder/sponsor in XYZ department will co-own the outcome, because you’re building an end-to-end product, not just a black box model, but neither of you is sure how to quantify the impact in monetary terms. But the operational metric is widely-known around the business, so you’re happy to articulate your product’s benefit in terms of that KPI.

And on the cost side:

• You treat the labour cost of your team as free, because it’s a given. We’re gonna pay them regardless of what they do, right?

• You don’t know exactly how much compute, storage, and other cloud costs your product is costing at the development or production phases. All you know is maybe how much your whole department's cloud spend is (and you don’t like thinking about such big red numbers)

• You ignore any cost that your stakeholders’ departments will incur, like the FTE hours they need to spend to help you build something for them (except maybe when it comes to calculating how many FTE hours you’re saving them!)

If you're missing the above, you can't know where on the 2x2 a new request or existing product sits! And even if you have some idea about it, it'll be harder to communicate that 2x2 position to others, like the HiPPO requesting dashboards that are a waste of everyone's time.

OK, I get it. Knowing the dollar value will help me prioritise what work to do first, next, or never.

It does! But that's not all.

• Internal buy-in: Putting hard numbers against requests for resources makes the conversation much more likely to go in your favour (at least if your request makes financial sense). Maybe you need another data engineer, or a software license that'll drive your team's productivity up, or more love from marketing, or budget to buy third-party data... It all costs money at the end of the day, and that's all it is when you look at it from Finance's point of view.

• Client buy-in: If you're selling to external clients, you're gonna benefit greatly from this sort of quantified benefits analysis. If you know the client does £50M in annual revenue, and your product can demonstrably help raise that by 1% 6 months after they buy, that's £250k in year 1, and £2.25M by year 5. Not too bad for a £100k/year subscription fee, right?

• Your own progression and recognition at your company: Your end of year review is going to look a lot more positive if you can demonstrate in no uncertain terms the business value you and your team have added.

• A better CV/resume for when it's time to move on: Being able to highlight your impact is (a) a very important thing one's CV should always be doing, but (b) especially important if you're a PM, where the ability to do so is a key skill for the job itself. A bit like a web developer with a videogame-like CV that showcases their skills (just not as exciting).

OK, OK, fine. I know quantifying impact is valuable. But for my product, it's uniquely hard, you see...

You're probably thinking this, aren't you? I know I have too. Lots of times. It's hard, but not as hard as you think. And, like many hard things, it's very much worth it. If it was easy, it probably would've been done already...

I want to write another piece going in depth on how to do all of this, but until then, here's some tips that'll get you 80% of the way there:

1. Keep it simple. Don't expect a scientific, high-precision measurement. Especially for version 1. Like with other parts of the job, we start simple, and add complexity over time - if need be. If you only had 15 minutes and a piece of paper to do a back of the envelope calculation of the benefit, what would that look like? Start there. Document your assumptions.

2. Involve others. Just like you're not expected to write the code for your product, or run sales, or fulfil deliveries, this too is a team effort. Maybe you need to get input from your technical users to understand how much more accurate their models are thanks to your data. Or maybe it's about speaking to operational users to understand roughly how much quicker they're taking a decision now that they have a dashboard instead of a pile of Excel sheets flying around. Or you need to speak to Finance to get a rough idea of how much each FTE hour or litre of fuel saved is worth to the business.

3. Get signoff. It's one thing for the data team to report that they helped generate $50M in sales, save £200k in fuel costs, or prevent a €1M fine, and another for those numbers to be fully credible (and credited!) by the business. Involve Finance or whoever it is that can back these estimates. They'll probably also help you with using the right assumptions and simplifying them enough, but not too much.

4. Do all of this before the work, not after. It's going to be much easier to get signoff without being accused of moving goalposts or trying to get credit retrospectively for an outcome you didn't influence. Most importantly, it's going to be so much easier to estimate the value of a product if there is a clear proposition for how it's going to add value. If you don't do this before development starts, there is a much higher chance you'll end up working on the wrong thing, and THAT'S why it'll then be much harder to quantify the value. Built a dashboard an exec asked for once and then never looked at? Yeah, I have bad news for you...

Conclusion

The best time to start estimating the potential cost and value of a data product, project, or team is before the work starts. The next-best time to do this is right now. Start simple, start crude, start with the larger projects and forget about the long tail of dashboards and small projects for now. Maybe that's enough to get you the resources you need to stop being so under-staffed, under-tooled, or under-appreciated. Or maybe it's the first step.

Further reading

• The approach I've described in this article is aimed at DPMs within existing orgs and operating models. If you're a data leader in a position to establish a broader governance process, ‘s latest article offers a fantastic blueprint. It's one of those "I can't believe he's giving this out for free" articles you should bookmark and reference.

• Again by Benny is a great heuristic for determining what % of the value should be credited back to the data team. He's covered it in a few places, but my bookmark is to minute 11 on this podcast.

• On 'starting simple', a great technique is Fermi estimation. The idea is you're looking to get the order of magnitude right using back-of-the-envelope calculations, not arrive at a super precise figure. Ultimately, knowing how many zeroes you can expect on the cost or benefit side is usually going to be enough to make a decision.

Other news and events I wanted to share

• We had our fifth and largest-ever London data product management meetup last month 🥳 If you want to get notified of future meetups, sign up here.

• I've opened up free coaching calls! If you or someone you know would benefit from a chat about breaking into data product management, or for those already in the trenches looking to get an outside perspective, you can book a call here.

• Orbis have launched a new podcast, Product Leaders, whose inaugural season had not one, but two data product episodes! Check out my London DPM meetup co-host Caroline's episode here, and mine here.

• On a final (slightly too self-centred note for my liking) note, I met with Harbr's Anthony Cosgrove and IAG Loyalty's Chanade Hemming to talk about data product management. You can find the webcast on YouTube.

• There’s a LinkedIn live happening tomorrow (13/03) I’m very excited about: Jon Cooke, Stuart Winter-Tear, and William Alvarez-Garzon are getting together in Mindfuel’s latest DPM live webinar. Here’s the link to watch it.

• Jon is also starting a podcast, Data Product Workshop. I’m looking forward to episode #1 on business storytelling that’s coming out next week (link).

• I hear there’s another data product management podcast coming out soon… Watch this space 👀

You can listen to the episode here, or wherever you get your podcasts1. Or click ▶️ below:

Off the back of the episode, I thought I'd elaborate on two separate things:

1. A bit about the Experiencing Data podcast, why I love listening to it, and a few stellar episodes I recommend starting with

2. Zooming in on one of the topics we discussed on the podcast: Overcoming & embracing impostor syndrome as a Data PM

1: The Experiencing Data podcast

If you haven't come across it before, you've gotta check it out (I mean, you've subscribed to a data product management newsletter, so yes, I insist).

Experiencing Data is Brian O'Neill's podcast where he interviews data product leaders on how teams are integrating product-oriented methodologies and UX design to ensure their data-driven applications will get used in the last mile. It's been a fantastic learning resource for me, both for learning about new approaches and ideas and (perhaps more importantly) for affirming when I've been on the right track in my own thinking.

Listening to Experiencing Data was also what drove me to dust off the old Design Thinking skills I'd picked up when I first started working in consulting and product management, and spend 10 weeks on a UX Design course at Brainstation (I wrote about my learning highlights here). We talked a bit about the course, how it's been valuable on the job, and how I wish I'd learned some of these things sooner in my career.

One thing I always appreciate when someone recommends a podcast is being pointed to a few standout episodes to go check out - it gets too daunting otherwise. So here's mine for Experiencing Data (with the caveat that I still have loads of episodes left to go through, some recent and some old):

• Manav Misra on how he established a data product approach at Regions Bank, creating new roles (including his CDAO role)

• Emilie Schario (who wrote one of the older data product thought pieces I've come across) on running data teams as product teams

• Eugenio Zuccarelli on helping paediatric cardiac surgeons make better decisions using machine learning. Super cool use case and really highlights the need for taking SMEs and users on the journey with you, not just handing them a 'finished' product

• Sebastian Klapdor on how he implemented a data product team at Vista, which now employs 35 data product managers (nearly 1% of the company's workforce!)

• Jon Cooke for a variety of golden nuggets on how to generate business value quickly and with a small team through data products

• Peter Everill on carrying out product discovery to drive user adoption and business value at Sainsbury's

• Nadiem von Heydebrand on treating data products a bit like how fund managers think of investment portfolios

• Osian Jones on running a data platform team as a product team, especially re:coming up with the right ways to collect feedback, understand adoption, and quantify your impact when you're in a central/platform team (i.e. usually multiple steps removed from the end user impact you're enabling)

Go check it out, and look at all the other resources that Brian's put out there as well. There's a course, a newsletter, a community...

Anyway, let me go over one of the topics we covered on the episode I was on 😆

2: Overcoming & embracing impostor syndrome

In recent years, I'd gotten quite good at not feeling like an impostor at work. I'd found my niche (data product management), built up my skills, and seen myself deliver ongoing value while developing further. And yet, when Brian invited me on the podcast, those long-overcome feelings resurged: Why am I being invited to a podcast full of guests with titles like 'CDO' and 'Head of Data'? What would I have to say that hasn't been said already, or that's not miles beneath what others had contributed?

Some of that reasoning was just unhelpful negative thinking that comes from feeling like an impostor because others have deeper or broader expertise. But it did prompt me to think about the questions substantively too: “What perspectives could I bring to the episode that I haven’t come across in previous episodes?”

As I was thinking about what on earth I could bring to the podcast, I actually realised that feeling like an impostor relates to one of the most important learning moments in my career journey: I've come to see impostor syndrome as synonymous with the sort of interdisciplinary knowledge work we do as data practitioners, especially for data product managers.

Let me explain.

Interdisciplinary teams necessarily involve 2 things:

1. Different team members have different specialisations and strengths

2. It is important that these local specialists understand each other's domains somewhat well as they do not operate in siloes

Some examples of this:

• A data scientist working on a proof-of-concept model needs to have some idea of what the productionised model might look like (e.g. can't rely on data from the future to make predictions). They might also need to do some of the operationalisation themselves. They're not a data engineer, but they've had to learn about the client's data systems as well as MLOps.

• The BI/front-end developer designing the dashboard providing the model's predictions and recommended actions needs to understand the context and language the end user will be familiar with. They're not an expert in the end user's domain (say, hardware procurement), but they'll need some domain expertise to do their part.

• The salesperson responsible for selling this dashboard to new clients is neither a procurement domain expert nor a data scientist, but they need to understand the conceptual solution well enough to qualify leads, run discovery calls, and know when a prospect is asking for something totally different than what the product is about.

The examples above are data-related, but you can apply this to most forms of knowledge work. It may apply less to more traditional professions, where progression tends to be more linear. I don't think this line of thinking will be of much help to a med student comparing themselves to seasoned doctors (but then again medicine is changing too as new research, cases, and technology comes about)

Here's the diagram I came across a few years ago that really solidified this worldview that I tried to verbally describe on the podcast:

Two ideas emerge clearly upon viewing this diagram:

1. The fact that the sum total knowledge/experience others have is greater than yours is misleading - we’re all separate bubbles (but yes, some folks will know more! that’s fine)

2. Looking at the yellow bubbles, they don’t overlap very much with one another - except through the blue bubble

It's funny just how impactful an image can be. I'd come across the same ideas before, and even a related diagram (your classic product management 3-way Venn of UX, Tech, and Business). And yet my mind would always find excuses why those aren't applicable or sufficient to explain my impostor-ness. But David Whittaker's diagram lit a lightbulb that everything else had felt to light up.

I see this play out almost daily, with folks from different teams talking past one another, or missing things that are clear as day to me. To be clear, I’m not trying to be all “I’m so smart and they’re not!” - I miss lots too. I’ll stare blankly when a data scientist explains exactly why they picked one model over the other, and gaze with admiration the salesperson that charms their way through a sales call. But I’ll also push to be in the sales meeting to explain our tech setup, and I’ll be the mediator in a tense exchange between Engineering and Commercial who are getting worked up despite agreeing with each other (but lack the shared vocabulary to realise).

Here's the DPM version of David Whittaker’s diagram (with many other yellow circles omitted!):

As I mentioned on the podcast:

You’re never going to be as good at the thing your colleague does because their job almost certainly is to be a specialist: they’re an architect, they’re a designer, they’re a developer, they’re a salesperson

I mean, you might be. Maybe you used to be a data scientist that’s switched to product. I’d like to think I’m still pretty good at some of the ‘yellow bubble’ skills that aren’t my sole focus anymore. But the point is that your unique value-add as a (D)PM comes not from just having e.g. UX design skills in isolation, or knowing lots about how a retailer works, or from knowing how to sell complex AI projects to a retailer - it’s from the fact that you bring a perspective that spans all three of these. It means you can spar with your engineering team, write effective sales and marketing materials, and help land that new client. It’s all about helping your teams become that “greater than the sum of their parts” thing.

We need more folks to embrace their T-, Π-, and M-shaped skillsets. Feeling like an impostor blinds the generalists among us from seeing our skills for what they are, and it also blocks us from seeking new skills and experiences if they don’t conform to that sweet, linear progression track that helps tame those negative thoughts.

3: Quick plug: Are your data products actually three data projects hiding under a trenchcoat?

Another topic we discussed with Brian on the podcast was what I wrote about just over a year ago, which is the antipattern I’ve observed several times now around what constitutes a product.

The TL;DR: A little bit like Mat Velloso’s painfully apt tweet from a few years ago, sometimes we talk about things being ‘data products’ when in fact once you peek under the hood it’s just a series of different projects.

Anyway, do excuse the plug, but here’s my article:

4: Another quick plug for those based in London

We’ve got our next data product management meetup coming up on Dec 11 (register here)! You can also sign up to be notified about future meetups.

5: Let me know what you think!

Alright, that's it for today. Let me know what you think of the podcast episode. I'd love to know if some bits resonated, or caught your attention, and if there's anything you'd like to hear more from me on.

At the end of the day I'm writing these articles and posting on LinkedIn primarily because I'm looking to help others learn about our nascent niche, so please don't feel shy about asking me or commenting directly! I also love all feedback, no matter how harsh it may be.

The past few months have been a bit nuts, so I've barely had the chance to write or post. I'm gonna try and shape up some of my other drafts over the holidays. I may or may not have another podcast appearance coming soon too... 😅

Until next time!

More and more organisations were realising that they needed a Product Manager / analytics translator / consultant-esque person to help drive value out of their costly investments in data, analytics, and AI2. A smaller number of data orgs were similarly realising that they were de facto employing such people, who had often taken up tasks like user discovery, value mapping, and feature prioritisation organically (which is one of the most common Product Manager origin stories, yours truly included).

So I thought I'd start collecting data on this, and see how my prediction fares in the coming years. Since the summer of 2022, I've been taking snapshots from LinkedIn and Glassdoor of the # of people with a DPM-related job title, as well as DPM-related job postings. While this is far from the best methodological approach (see the 'Limitations' section later on), it's been easy to take 5 minutes every few weeks and write down a few numbers.

The trends I saw roughly matched what I was anticipating a couple of years ago:

• The number of DPMs and the DPM job title has increased significantly (+51% since June 2022)

• DPM has overtaken the data/analytics translator role (from 2020-onwards)

• DPM is more commonplace than DPO

Show me the data!

Alright, here you go. My amateur-level ‘research’ on the popularity of the DPM job title among the denizens of LinkedIn:

I looked at the number of DPM+DPOs on LinkedIn, first without a geographical filter (black points), and then for the US and the UK. Why not any other countries, you rightly ask? Laziness. Or, well, the knowledge that if I had to manually extract 20 different data points every time I remembered to do this, I’d likely give up and end up with zero data. When you collect your KPIs manually, it’s essential to consider the likelihood your human data collectors will give up or give you wrong data, after all.

I also wanted to look at Analytics/Data Translators, a job title that I first came across in 2018 when McKinsey championed it. I kept the y-axis equal to the one for DPMs to make it easy to compare the two.

I also took to Google Trends, which I trust more than my ad hoc LinkedIn queries, but is also less precise in what it measures. The pattern holds:

Of course, these results are all relative to one another, nothing close to overall search volume. For reference, here's how Data PM compares to DS and PM searches:

But hey, August 2023 was the first time DPM was at 1%, rather than <1% compared to the other two. To the moon!

Another comparison I looked at was with the "data products" and "data as a product" keywords. I was expecting data as a product to have spiked a lot more aggressively in the last couple of years - another reminder that my LinkedIn feed is a bubble.

What about job postings?

The LinkedIn data in the previous section can be a bit misleading - what about folks who used to be Data PMs, but aren’t anymore? LinkedIn would count those too (unless they’ve deleted that info from their profile, which would explain for example the decrease from Aug 2023 to Sep 2023). So, let’s look at job postings too.

The data here has been a lot less reliable - I think the way LinkedIn returned results to my queries changed, first between Feb and Jul 2023, and then again more recently.

Besides data quality, there’s the broader issue with using LinkedIn to understand recruitment - a lot of these jobs aren’t advertised in public channels, but instead get filled internally or via word of mouth. But still, it was interesting to see the drop in open roles from H2 2022 to 2023 (and lines up with the wave of layoffs + hiring freezes in tech).

Bringing in Google Trends again:

Google Trends data here isn’t illustrating the demand for DPMs - probably more of a proxy for DPM job-seekers looking for such roles.

Limitations of this research

• No data cleaning: I couldn't extract postings, and instead just had to note down the snapshot count. Sometimes, when you search for a keyword or phrase on LinkedIn Jobs, even if it's wrapped in quotation marks, you don't quite get what you'd expect. From the spot-checks I did over the months, this seems to mostly be an issue for the job posting results, and less so for # of people results.

• Non-exhaustive search phrases: I did not include "AI Product Manager", "AI Product Owner", "Data Science Product Manager" and so on. I suspect "AI" ones will get more popular over time.

• Manual, ad hoc data extraction: I repeated the searches used to populate these charts on an ad hoc basis, so some trends might be exaggerated due to randomness (and others might be understated). For example, I didn't take any snapshots between Feb 2023 and Jul 2023 when life got in the way - was the growth linear? Was there a larger peak followed by a dip? Not sure.

• Lack of self-identification as DPM: Many people doing the work of a data product manager don't necessarily know that that's what they're doing, or for other reasons don't self-identify as DPMs (e.g. because their job title is something industry- or company-specific, or because they'd rather brand themselves as PMs more generally)3

• Confusion/disagreement over the DPM job title: This used to be a lot more prominent, with folks using the term to mean "Product Manager who uses data analytics to better understand their user base". Thankfully, with the rise of data products and data product management, this has become less common (though Udacity's not-a-DPM-course course is still the top result when I google data product management... sigh4). So, again, this data is all about what people put down on LinkedIn, not about the job they're actually doing. Just like how there are lots of folks with "product manager" as their job title, but the orgs they're in force them into being little more than project managers - it is what it is.

Like with lots of other data, my advice is to focus less on the exact absolute numbers and look more at the proportions and directional changes: For example, that there has been a sharp increase in the number of people with DPM-related job titles, or that Analytics Translators are a lot more rare than DPMs.

Conclusion

If you're reading this, you're probably not surprised by the data I've shown, just like I wasn't. Some of the growth in the DPM role has been due to more organisations waking up to the need for bringing product management / analytics translation / value realisation into the fold.

Cynically, I also think a lot of it has come from the slightly more mindless and superficial "copy what seems to work without fully understanding it" trend we see continuously with traditional organisations trying to catch up on all sorts of digital, data, and technology topics. As I wrote in my last article, this stems from seeing what 'good practice' looks like, rather than understanding deeply what good practice is.

Still, adopting the nomenclature of data products and data product management is a good starting point. Knowing what to Google is sometimes half the battle, and so as more of us share what we've learned the hard way about building data products, I hope that'll mean the easier it'll be for newcomers to catch up and overtake us. At the same time, I'm certain that I have lots of hard lessons ahead of me too - we're only just getting started!

For me, these two articles were a bit of a wake-up call. Not in that they pointed to issues I was previously unaware of (see e.g. my previous article on here, or this LinkedIn post). Rather, it was a wake-up call on the urgency and scale of the problem, and a reminder to be vigilant and take active steps to not become part of a horror story in some data scientist’s blog post two years from now.

I would recommend reading both articles. For the less patient, I’ve written a summary of the main points below, followed by my thoughts on the matter. You can skip ahead if you don’t want to go through my summary.

My selective summary of the two articles

In the first article, @ryxcommar shares several grievances. A few that stood out for me:

• Lack of DS expertise amongst leadership: “Nobody knew or even cared what the difference was between good and bad data science work. Meaning you could absolutely suck at your job or be incredible at it and you’d get nearly the same regards in either case”

• Lack of domain expertise: “Insane” ideas rooted in a lack of understanding of customers, the business, macro environment, or accounting.

• Datawashing: Management green-lighting DS projects as a way to make their “insane ideas” appear grounded in objective truth (side note: “decision-driven data rather than data-driven decisions” is a turn of phrase I will be using for many years to come)

• VC-inspired calculus: Try 100 things knowing most will fail, because a handful succeeding will be good enough. Business soundness aside, ryx observes that it’s pretty awful to be one of the employees working on the stuff that’s very likely to flop1.

• Skill gaps among data scientists: Several root causes, including lack of mentorship for more junior data science hires, lack of senior/experienced DS leadership (“where is the adult in charge?”), a general talent shortage in folks who are good at both data science and software engineering, and many data scientists taking the wrong approach to self-directed learning, going for superficial or irrelevant topics instead of mastering the fundamentals first.

All of the above ultimately led the author to feel like their work didn’t matter, add value, or fulfil them. Not a good mix! At least they seem to be happy and fulfilled now that they’re in data engineering. But what about everyone else who’s still in DS, and the businesses that employ them?

In his article, takes a more systematic/impersonal view of data science, but there is a lot in common between the two articles. In fact, Vin starts off with the same premise as ryx:

The motto of most data science teams should be, 'You can't be doing it wrong if nobody knows what you're doing.' Pull back the covers on most models, and you'll find deeply flawed methods. But no one in the business knows enough to call it out.

Similar to ryx’s article, Vin’s criticisms are distributed across both business/leadership and technical/data science teams:

Criticisms on the business side:

• Dangerously inadequate training: The sort of data literacy training business people tend to get (e.g. a 6-8 week bootcamp) is not just inadequate for training them to be leading data teams, but also gives them a false sense of competence. Models are not evaluated, requirements are not articulated well, and statistical rigour is an afterthought, if that.

• Decision-driven data: Leaders asking data scientists to fudge the numbers when their beliefs are challenged, rather than vice-versa.

• Poorly-built data teams: Lack of specialist roles like ML engineer, MLOps engineer, data engineer, and data analyst (and either data scientists forced to be all-in-one, or data scientists hired with the promise of DS work but then forced to be the data engineer of the team).

Criticisms on the data side:

• Who will guard the guards? When data science teams are the ones that instruct the business on how to measure the success of their initiatives, they become their own QA and QC, and shift blame to MLOps rather than their own models’ reliability.

• No UX considerations: DS teams, like technical teams on transformation programmes more generally, will blame users for not adopting their solutions (“they don’t get it”, “they’re not technical enough”, “they’re set in their ways”)

There is a big interplay between the above (which Vin calls out as well): If your leaders don’t know what they need from the data teams, or what good looks like, they will hire the wrong people, for the wrong roles, structure their teams poorly, and make those hires work on the wrong things. And when you tick some or all of those boxes, you get all the bad DS outcomes from the bullets above.

My rapid-fire thoughts on how to address these challenges

Each of the points made below could (and in the future, probably will) be an article in its own right. Before I get to that, though, I wanted to share the tl;dr for each one. Do shout if you’re especially interested in me expanding on specific bits from the below!

Data science, data products,should be a solution to a problem, not a solution in search of a problem.

• Senior leadership needs to shift from a buzzword-driven, FOMO-induced “we need to become data-driven” approach to a deliberate exercise of identifying opportunities for data and technology to add value. A decision being backed by data of some variety is not automatically better, nor is building ML models left, right, and centre going to automatically lead to value for your business.

• One of the books I’ve been reading over the past few weeks around this has been Teresa Torres’ Continuous Discovery Habits, which I’d really recommend to any data product manager, data scientist, or data leader working on data products.

To be data-driven, you need rigour.

• Evaluating the success of a project using “A/B testing” is meaningless if that A/B experiment has been set up poorly, because it literally means that you might be seeing a positive uplift when in fact there was none, or even worse when your “data-driven” intervention actually makes sales worse.

  • For example, suppose you’re launching a new customer loyalty scheme, and you invite your already-engaged customers to join. In that case, comparing their engagement against that of your least-engaged customers who haven’t joined the new scheme is obviously going to show that the new scheme is a massive success, even if it’s anything but.

  • And remember: Being rigorous means being ready to accept ‘no’ for an answer.

• I’m not gonna suggest a stats textbook, nor do I think everyone needs to become a statistician to work on data projects and products, but you should certainly have a meta-understanding of what’s at play, otherwise it’ll be in “unknown unknowns” territory: Ben Goldacre’s Bad Science is an excellent read in its own right, but also specifically relevant to the topic of data science’s un-scientific tendencies.

• If you’re a leader and don’t know how to evaluate for statistical rigour, you need to be mindful of that and make sure someone in your team will cover that base for you. 

• If you’re a data scientist worried about the rigour of your experiment or modelling approach, find a way to raise that point to the business by appealing to the things that matter to them: “Statistical rigour” will likely be meaningless to a business team, but the business outcome your experiment is helping build towards is very much something they care about. 

  • If you’re in a situation like this right now and want to bounce ideas on getting your business stakeholders onboard, give me a shout - I’d love to jump on a call and help you out.

UX and user adoption are really important considerations, not an after-thought for version 2.0.

• In orgs that aren’t already on the top end of the digital and data maturity curve, data science initiatives usually involve getting some not-so-data-savvy part of the business to embrace data. These initiatives are (sometimes rightly, sometimes wrongly) met with distrust by the business, often because they don’t see the value data can bring, because they feel threatened, or because what’s been built is simply not fit for purpose.

• The key idea here is to build with your users, not just for them - both because that’ll be the key to securing their buy-in and adoption, but also because your data team probably doesn’t have all the context and domain expertise needed without close collaboration! This, incidentally, is one of the key reasons why I favour delivering data products over ad hoc ‘insights’ or one-off projects.

• My #1 content recommendation here would be Brian T. O’Neill’s Experiencing Data podcast. Brian and his guests talk through lots of examples and best practices for how to build data products that are simple, usable, and ultimately valuable.

Do you know what is good, or just what good looks like (in someone else’s context?)?

• You can’t make ‘data-driven’ decisions (or even the more modest milestone of ‘data-informed’ ones) by simply trying to copy+paste what you see out in the wild. It’s nice learning about what Big Tech does through their tech blogs and conference presentations, and sometimes it can inspire great ideas to bring back to our own orgs, but these are absolutely not blueprints for your own org. Besides the fact that the challenges, resources, and skills they might have are probably vastly different to your own, these things are often snapshots taken at one particular point in time and may have also been sanitised heavily before making their way to external audiences.

It’s important to remember that data science and its related fields and sub-fields are all still very nascent. Even IT is a toddler of a profession when you compare it to fields like accountancy, medicine, or law, so it’s hardly a surprise that we’re all still figuring things out (and often re-inventing or unnecessarily changing stuff). For me, this sort of wake-up call and healthy debate about what’s working and what’s going poorly is all great - after all, how else could we make things better?

PS: Like with my last post, I used Stable Diffusion to generate the image. This time, I even used ChatGPT to help me think of a few prompts (though this was definitely one of those uses of GPT-3 where you need to take 5% of what it’s given you as inspiration, instead of do the last 5% on top of what it’s done automatically…)

Over the past few years, I’ve read lots of pieces around my domain (data, analytics, and ML) that talk about operationalisation and productionisation. I’m sure you’ve seen the headlines: How the vast majority of ML models never make it past POC, and how value from data & analytics projects can only really be derived when they’re operationalised and scaled across a business. And it’s certainly good advice! We shouldn’t rely on one-off recommendations, and of course if a business is to be data-driven (or at least data-informed) it should democratise data and insights to more than a handful of people. 

While this advice made sense, I’ve often found it largely irrelevant to the immediate challenge of scaling the data products I was responsible for. Our actual problem was a little more embarrassing: We didn't quite have a 'product' in our hands yet.

I wanted to share my thoughts on the challenge of going from data projects to data products. To that end, I’ve split this post into three broad parts:

1. Warning signs your product isn't a product (yet)

2. The likely root causes that got you here

3. My advice for getting unstuck

If this sounds like it might be true in your data teams or clients, have a read, and let me know what you think! I'd love to hear how common (or uncommon) this experience has been for folks.

Product? More like three ad hoc projects under a trenchcoat

Across the data teams I’ve worked in, we’ve often had to work in a very project-centric fashion. Sometimes this was a deliberate decision. Other times, there was a vision from the top to develop scalable products and reap the exponential returns they unlock. Despite that, we found ourselves delivering projects anyway - at least at first.

Had it been a deliberate decision, that would have been fine. But it wasn’t, at least not fully.

Warning signs your product isn't a product (yet)

I'm sure this isn't an exhaustive list - but it's a list of things I've seen come up several times.

• When you need to generate new outputs (a data file, a dashboard, a report), someone needs to modify code - for example, to change a hard-coded value like the date range you want to use, or generate an output for a different customer's domain.

• Developers don't work off a single, unified codebase.

• There are many versions of similar scripts or notebooks - probably because they're hardcoded to match different project requirements, or because they were made by different developers in the team.

• Developing new features, or adjusting existing ones, is a very cumbersome process that takes inexplicably long amounts of time to do.

• A broader sniff test: Every time you have a new customer/user, you need to invest time and effort to make your product work for them. I'm not talking about new features or use-cases here, or configuration, or about ingesting their data, but about what happens with that input data until it's been turned into the output your product is about.

How did we end here?

Why does this happen? Besides any incidental or individual drivers, I see three structural factors at play: The skills and know-how of the technical team, the business/product team, and the priorities of the business at large.

1. Lack of software engineering experience among the data/dev team

First off, many data teams consist of data scientists and analysts that haven’t come from a software background, and so aren’t experienced in the sorts of engineering practices common in software teams. This includes knowledge of git, parameterisation of inputs, automation of workflows, test-driven development, CI/CD, code optimisation, and so on. This means that the way things are built from the start may not be generalisable, refreshable, automatable, or otherwise scalable. The crucial note to make here is that I’m not talking about building production-grade systems instead of MVPs: It often takes the same amount of time (or at least not orders of magnitude more) to build something that’s relatively generalisable versus something completely bespoke.

The example I’ve seen over and over again (and been guilty of myself at times!) has been with hardcoded inputs: You specify the start and end date within your code, rather than treat it like a parameter that can be tweaked without having to edit various lines in the code to e.g. get data for July instead of June. Had the person or team doing the development had this in mind from the start, they might've had to slow down by 20% or even 50% for the first delivery but end up with something that can be reused at will.

2. Lack of software (or product) experience among leadership (and/or the product team)

Separate from the technical delivery team’s skills and background, there’s the profile of the data team's leadership. Who 'leadership' is depends on the org structure - it could be the PM, it could be a Head of Data/BI, or it could be the commercial director that's building a data or data science team under them.

When your entire professional career has been about delivering projects, you think in terms of, well, projects. So even if you’ve been given the mandate to develop an internal product for a certain recurring use case (e.g. pricing, sales, marketing), you might end up treating it as a series of projects: It might be the “X use case project” versus the “Y use case project”, or the “Country A project” versus the “Country B project”, or even the “Q1 recommendations” versus the “Q2 recommendations”. I've been guilty of this as the Product Manager, and I've seen my peers in data teams do the same.

This could happen in subtle but recurring ways, like the way you (de)prioritise tech debt, or in terms of bigger design decisions taken. It might be in the form of listening to those on your team that speak your language better (BAs, PMs, data scientists from a business analytics background) rather than those who ‘don't seem to get it’: Data engineers, more junior data scientists (who might be more technical), or otherwise anyone that's banging on about technical stuff that doesn't seem as important as your next big milestone or commercial priority.

My advice: Listen to those voices too, and try to understand them (and help them explain). It might not be easy - but if it was, wouldn't their concerns and suggestions have been heard already?

3. The higher-level priorities of the team, department, or company

Even if you have identified all the right bits of technical debt and understand the importance of productising your not-quite-a-product product, your hands might be tied, at least in the short term. It might be that the project-after-project approach was a commercial necessity, or a deliberate approach for the purpose of seeking out product-market fit. Perhaps the pursuit of bespoke solutions for different internal teams was a political decision, to appease other leaders who also only spoke the language of projects. Or, well, maybe your senior team had a broad vision of data products scaling across the business, but lacked either the specific know-how or the time to get stuck in the right level of detail to ensure that vision became a reality.

This might overlap heavily with the previous root cause: It depends how large and layered your organisation is. In a smaller company, leadership and product/business might be the same folks. In a larger enterprise, there will likely be many layers of decision-makers influencing your priorities. If you're in an empowered product team, I'm willing to bet the sort of challenge I discuss in this post isn't one you're dealing with, but I'd be happy (and curious!) to be corrected.

To recap, your product might not quite be a product yet for a variety of reasons, ranging from a lack of technical expertise, product leadership, or simply the fact that senior leadership’s priorities lie elsewhere. Whatever the reason or reasons, you've ended up stuck in a less-than-ideal situation - but also one that's solvable.

To get unstuck, make sure everyone knows you're stuck

So much of Product Management ultimately comes down to effective, high-impact communication: In order to get buy-in for your new productisation initiative, you'll have to get appropriate buy-in.

Here's my generic but effective template for what this looks like:

1. Articulate the problem and the pains it causes;

2. Paint a picture of a world with the problem solved;

3. Show what it takes to get there

How you go about gathering the ammunition for these three sections will depend on the situation you're in: Look back at the potential root causes of the state of your product to understand which levers are available to you.

• Tech skills gap: If the challenge is a skills gap among your development team, look at adjacent teams first - for example, is your team comprised of data scientists, who in turn work with a data engineering team further upstream? They might be able to help share best practices or even become the team who'd be responsible for taking over ownership of the data asset and helping turn it into a data product.

• Management skills gap: If the problem is that the technical team's calls for tech debt being prioritised have been ignored, then that team will help you get your technical roadmap/next steps nailed, as well as point to all the specific issues you're dealing with. Just make sure you're presenting the information the tech team gives you in a way your audience will understand. As an aside, they'll probably really appreciate you for it, and your working relationship will grow stronger, which will pay many dividends in the future.

• Leadership buy-in: If you've found yourself in a situation where those above you (or those above them, or those above them) are the blocker, it's time for some upwards management: Educate your superiors on the situation (without going into unnecessary levels of detail that will make them lose interest or the ability to follow), emphasising the outcomes you want to achieve. Make sure you've done your homework on what you're actually asking for: Is it to push back on some delivery dates to make room for productionisation? Is it to change what your sales team is offering to clients into something more standardised?

Some final notes for anyone embarking on a productisation initiative

• Sell the benefits: By standardising and automating your capability to produce data deliverables into a product, you are making the lives of everyone involved better: Your tech team can focus on developing new features (or improving existing ones, like data quality) instead of doing tedious, repetitive work, your customers can get their outputs faster and cheaper, and the business can benefit from getting exponential returns on their investment. Honestly, it's pretty neat.

• You can't do this alone: You'll need both the input and support from your team, peers, manager, users, and stakeholders: The plan for productisation will probably come mostly from the tech team, or other technical experts. Your manager or other leaders will likely have great advice on how to get wider buy-in from the organisation. Your users will help you understand what your product will need to evolve into. Other teams may have gone through a similar journey previously, or may also need to go through this now.

• Don’t fall for the Spotlight Effect: Your product may be your whole world (or at least your main professional focus!), but it's probably just one of many (or many, many) concerns of your managers, their managers, and anyone else you need to influence across your organisation. Be clear on why this matters to the things each of them cares about, tailor your comms approach for each one, and remember you may need to repeat your message a few times before it sinks in.

PS: If you’re wondering about the cover photo, I used Stable Diffusion’s AI art tool, DreamStudio - really fun to play around with, but definitely takes patience and specificity to get anywhere near something you want!

When I started working on data products (and discovered that ‘product management’ was a thing a few months later), I found my impostor syndrome tamed: My role was by design not that of a technical expert, but rather that of a generalist who speaks the language of their customers and champions their needs. Neat!

Impostor, or just an outsider?

But then, as I started reading up on product management, and even take a couple of courses, I found that impostor syndrome peak up again: Why am I not able to relate to so many parts of what these PMs are talking about? What A/B testing can I do on a 20-user product? And ship something with half-broken data to an enterprise client or internal team? No way. Why can’t I find anything about the challenges I am actually facing? It was both demoralising and frustrating at the same time. I was used to googling my problems!

Fast forward a couple years ago, and I realised that while I’d worked as a product manager, I was not alone in finding the learnings of PMs from big tech and B2C apps only somewhat relevant. I read Building Products for the Enterprise, a great book which helped me appreciate some key differences between the products I’d worked on and those most PMs wrote about. Still, more questions were left unanswered, and I figured them out through a mixture of luck, learning from my technical teammates, and casting a wider net to learn about data modelling, architecture, and data and software engineering.

So why write about data product management?

Fast forward once more, to today (or, well, a few months ago): I realised that the lack of content that could help me get to the answers I was after quicker (or at least validate my thinking) means there is an opportunity for me to share the lessons I’ve learned. These are lessons that since then sometimes feel trivial, or obvious, either because I’ve internalised them so much in the last couple of years, or because they’ve come from my past lives as a data analyst, management consultant, and (non-data) product manager.

To get started, here’s my first post on the subject of productisation. Yep, that’s not a typo, I don’t mean productionisation (or ‘productionalization’, if you must). There’s thousands of pieces on the latter, but almost nothing on the former - especially stuff that I could make use of as I found the ‘data products’ I entered orgs to help manage to not actually be, well, products.

If you’d like to get an email every time I post a new article here, put your email in the form below.