130 - Nick Zervoudis on Data Product Management, UX Design Training and Overcoming Imposter Syndrome
Experiencing Data w/ Brian T. O’Neill (UX for AI Data Products, SAAS Analytics, Data Product Management) - En podcast af Brian T. O’Neill from Designing for Analytics - Tirsdage
Today I’m joined by Nick Zervoudis, Data Product Manager at CKDelta. As we dive into his career and background, Nick shares insights into his approach when it comes to developing both internal and external data products. Nick explains why he feels that a software engineering approach is the best way to develop a product that could have multiple applications, as well as the unique way his team is structured to best handle the needs of both internal and external customers. He also talks about the UX design course he took, how that affected his data product work and research with users, and his thoughts on dashboard design. We discuss common themes he’s observed when data product teams get it wrong, and how he manages feelings of imposter syndrome in his career as a DPM. Highlights/ Skip to: I introduce Nick, who is a Data Product Manager at CKDelta (00:35) Nick’s mindset around data products and how his early career in consulting shaped his approach (01:30) How Nick defines a data product and why he focuses more on the process rather than the end product (03:59) The types of data products that Nick has helped design and his work on both internal and external projects at CKDelta (07:57) The similarities and differences of working with internal versus external stakeholders (12:37) Nick dives into the details of the data products he has built and how they feed into complex use cases (14:21) The role that Nick plays in the Delta Power SaaS application and how the CKDelta team is structured around that product (17:14) Where Nick sees data products going wrong and how he’s found value in filling those gaps (23:30) Nick’s view on how a digital-first mindset affects the scalability of data products (26:15) Why Nick is often heavily involved in the design element of data product development and the course he took that helped shape his design work (28:55) The imposter syndrome that Nick has experienced when implementing this new strategy to data product design (36:51) Why Nick feels that figuring things out yourself is an inherent part of the DPM role (44:53) Nick shares the origins and information on the London Data Product Management meetup (46:08) Quotes from Today’s Episode “What I’m always trying to do is see, how can we best balance the customer’s need to get exactly the data point or insight that they’re after to the business need. ... There’s that constant tug of war between customization and standardization that I have the joy of adjudicating. I think it’s quite fun.” — Nick Zervoudis (16:40) “I’ve had times where I was hired, told, 'You’re going to be the product manager for this data product that we have,' as if it’s already, to some extent built and maybe the challenge is scaling it or bringing it to more customers or improving it, and then within a couple of weeks of starting to peek under the hood, realizing that this thing that is being branded a product is actually a bunch of projects hiding under a trench coat.” — Nick Zervoudis (24:04) “If I just speak to five users because they’re the users, they’ll give me the insight I need. […] Even when you have a massive product with a huge user base, people face the same issues.” — Nick Zervoudis (33:49) “For me, it’s more about making sure that you’re bringing that more software engineering way of building things, but also, before you do that, knowing that your users' needs are going to [be varied]. So, it’s a combination of both, are we building the right thing—in other words, a product that’s flexible enough to meet the different needs of different users—but also, are we building it in the right way?” – Nick Zervoudis (27:51) “It’s not to say I’m the only person thinking about [UX design], but very often, I’m the one driving it.” – Nick Zervoudis (30:55) “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, whe