Impostor syndrome and other bits from my Experiencing Data podcast appearance

Sharing a few highlights about my episode and the podcast in general

I recently had the pleasure of being a guest on the Experiencing Data podcast. I've been listening to Experiencing Data for nearly two years now and learned loads about data product management, design thinking, and successes & learning moments from all sorts of data/product/business leaders.

You can listen to the episode here, or wherever you get your podcasts¹. 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:

Awesome diagram by David Whittaker (@rundavidrun)

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!):

Diagram by yours truly

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.

I quote this joke a couple of times each month

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:

Before putting your data products in production, make sure they're actually *products*

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!

1. I've been using a podcast player called Snipd recently, and quite enjoying its automatic transcripts, AI summaries, and ability to create 'bookmarks' (i.e. save/highlight key sections from an episode) that I can then sync with my personal notes vault. It's pretty nifty. Here's a link that gives out 1 month for free (as far as I can tell, I don't get anything in return)