#82. Three Years in Product Management at QuantumBlack: Part 1 - Building Products and Teams
Lessons from Kedro
Three years ago, I walked into QuantumBlack, McKinsey's AI consulting arm, knowing virtually nothing about machine learning.
Today, as I transition to my next chapter, I'm reflecting on the lessons that shaped not just my approach to product management, but my understanding of what it means to build products that truly serve users.
This is the story of building Kedro, and Kedro-Viz—an open-source data science visualization tool—and the uncensored reality of three years of product management wins, failures, and everything in between.
Table of Contents
Setting the Stage
Year One: The Art of Listening (2022
Year Two: The Power of Collaboration (2023
Year Three: Thinking Strategically (2024)
The Three Products Every PM Manages
33 Lessons in 3 Years
📻 AI Audio Version Available (Disclaimer: Slight transcript variation) 25mins
Setting the Stage
Think of Kedro as turning data science chaos into organized workflows.
It's like having a project manager for your data pipeline—ensuring files are properly organized, steps happen in the right sequence (analysis after cleaning, modelling after pre-processing), and maintaining a clear audit trail of every data source and transformation. No more "Where did this dataset come from?" or "Which script do I run first?"
For those unfamiliar with the specific ecosystem, I stepped into:
Kedro: An open-source machine learning framework that helps data teams organize and share their code using pipelines
Kedro-Viz: The visual companion that transforms complex data pipelines into clear, shareable flowcharts
My role: Product Manager responsible for Kedro-Viz's strategy, development, and user experience
The beauty of working on an open-source product means I could share details usually limited by confidentiality. So, here's the real story—complete with the messy middle parts most product retrospectives skip.
Year One: The Art of Listening (2022)
Day One: Becoming Your Own User
After standard onboarding, I did what any PM should do: I became a user. I worked through Kedro's spaceship tutorial, consumed every blog post, listened to podcast mentions, and studied the documentation.
But reading about users isn't the same as talking to them.
The Research That Changed Everything
Our user adoption had been declining, and nobody knew why. Instead of building based on assumptions, I designed my first user research exercise from scratch:
Defined clear objectives and hypotheses
Recruited participants through Slack and polls
Conducted 10 in-depth interviews
Systematically analysed recordings using proper tagging
Synthesized findings into actionable insights
The results were eye-opening. We discovered integration challenges, configuration pain points, documentation gaps, and fundamental misunderstandings about how Kedro-Viz fit into users' workflows.
Key lessons from this first research sprint:
You can add value from day 1 - User research immediately contributed meaningful insights
Tools evolve your process - I graduated from manual analysis to systematic tagging with Dovetail
Show, don't tell - Ask users to demonstrate workflows rather than just describe pain points
Embrace the silence - Don't rush to fill conversational gaps; let users think and elaborate
Talk to non-users too - Understanding why people don't use your product is equally valuable
The Experiment Tracking Saga: A Master Class in Stakeholder Alignment
In data science and machine learning projects, experiment tracking is the process of recording and organizing all the details of your experimental work so you can monitor progress, compare results, and understand what works. It is important in data science where small changes in the input could lead to significant outcomes.
Months before I arrived, the team had released an experiment tracking feature. Adoption remained stubbornly low, and as the new PM, investigating this became my first major project.
The Research Deep Dive
Armed with lessons from my initial research, I went deeper:
Polled users across Slack and Discord
Interviewed both users and non-users of experiment tracking tools
Analysed support tickets and documentation
Benchmarked against competing solutions
The verdict was clear: users preferred other tools that better solved their core needs. I identified 11 specific reasons, clustering around three critical themes:
Saving and comparing plots across experiments
Comparing metrics for different input parameters
Hosting and sharing experiments with team members
The Resistance
When I presented a roadmap to address these themes, I hit my first major stakeholder challenge. Senior engineers who had built the original feature pushed back hard: "If users aren't adopting the basic feature, why build advanced capabilities?"
The conversation got heated. We reached an impasse.
The Escalation and Resolution
My product lead stepped in with a masterful reframing exercise:
"Which problem are we solving to increase adoption? Are users not adopting because:
(1) they think we don't support visualizing metrics over time, or
(2) because we don't make it easy to compare multiple experiments?"
This simple reframe shifted the conversation from "should we build this?" to "which specific user problem are we solving?"
We conducted user testing with design prototypes of two approaches (time-series plots vs. parallel coordinates plots). Sessions revealed users were split 50/50 on preferences, leading us to build a simplified version supporting both.
The lessons that stuck:
Problem framing is everything - Get stakeholders aligned on the specific problem before discussing solutions
Engage before the meeting - Socialize ideas individually before group discussions
Naivety can be valuable - Fresh perspective helped surface unquestioned assumptions
Know when to escalate - When alignment breaks down, get help from leadership
Be a translator - Convert user feedback into engineering-friendly problem statements
Trust takes time - Building credibility is foundational to everything else
Beyond Features: The Product Marketing Awakening
A concerning pattern emerged: users kept requesting features we'd already built. They either didn't know the features existed or didn't understand how to use them.
Worse, because we hadn't defined our positioning, others were doing it for us—incorrectly categorizing us as "data orchestrators" and comparing us to tools we weren't competing with.
The Strategy Session
One memorable brainstorming session with my Product Lead and Technical Writer started with a brutal question: "Why isn't Kedro the dominant framework in this space?"
Our answers became our action plan:
Learning curve → Create tutorials, video courses, improve documentation architecture
Messaging → Define clear positioning, update presentations, highlight advantages
Awareness → Systematic content strategy and developer advocacy
This session taught me that the real work begins after you ship the feature. You need to announce it clearly, demo it to users, gather feedback, and iterate continuously.
Year Two: The Power of Collaboration (2023)
The Shareable URLs Project: A Case Study in Team Collaboration
Our research revealed a new user type: "technical translators"—people who used Kedro-Viz to understand and communicate about data science projects but weren't technical enough to set up the tool themselves.
These users were sharing screenshots or screen-sharing during Zoom calls. Functional, but limiting.
The Collaborative Approach
Instead of diving straight into development, we took a truly collaborative approach:
Deep partnership with engineering and design - We explored technical feasibility together before making commitments
User testing throughout - My designer ran excellent sessions that caught issues like time zone confusion early
MVP thinking - We focused on the simplest solution that solved the core problem
Iterative improvement - One engineer later devised an even better approach using GitHub Pages
The feature launched successfully with strong adoption—our first truly collaborative win.
The key insight: As a PM, your job isn't to have all the answers. It is to be a great thought partner who can frame problems clearly and facilitate solutions that leverage your team's expertise.
The Meta-Lessons: Working ON the Team
Some of my most rewarding work wasn't on the product—it was on how we worked together:
Team norms sessions where everyone shared their working styles and needs
Monthly in-person days to build rapport (we were fully remote otherwise)
Psychological safety initiatives - creating space for "stupid" questions and encouraged dissent
Celebration rituals - team dinners or karaoke after major releases
Clear role definitions - PM owns value/viability, Designer owns usability/experience, Tech Lead owns feasibility/delivery
The Alignment Day That Sparked Innovation
Our "Kedro-Viz Alignment Day" was a half-day brainstorming session with sticky notes and whiteboards. It generated wild ideas that became real features—like visual tips highlighting new features, and the entire "low-tech users" segment that led to shareable URLs.
We discovered that these users were: Business Analysts, Product Managers, Project Managers etc, who use Kedro-Viz to follow 'what's going on' and inspect the data science code of their team.
The lesson: The best ideas come from unexpected places. Foster environments where every team member feels safe to contribute.
Year Three: Thinking Strategically (2024)
Balancing Tactical and Strategic
My product mentor introduced me to a crucial concept: the need to zoom in and zoom out continuously.
Zooming in meant understanding:
What the team was working on this sprint (2 weeks)
Engineering decisions and technical architecture
Milestones, timelines, and dependencies
Individual contributor workloads and blockers
Zooming out meant preparing:
Well-researched arguments for what to work on next (4-6 weeks)
Proper documentation with user stories and acceptance criteria
Risk assessments and dependency mapping
Answers to "What can we ship quickly? What's the lowest effort, highest value thing we can build?"
For a new feature request or user problem, my first step was always the same: create a comprehensive ticket that would serve as the single source of truth. Think of it as a PRD (Product Requirement Document) but in a more digestible, actionable format.
Each ticket became a complete narrative that included the user story explaining the "why," detailed analysis of existing solutions complete with screenshots for visual context, and clear success metrics with specific acceptance criteria.
The goal was simple: any engineer should be able to pick up this ticket and immediately understand not just what needed to be built, but why it mattered and how we'd know when we got it right.
But here's where it gets interesting.
Most meaningful problems are too complex to tackle in one sprint. They need to be decomposed into smaller, manageable pieces—each requiring its own focused ticket. This is where this "mother ticket" becomes crucial.
The mother ticket acts as the strategic overview, connecting all the smaller implementation tickets like chapters in a book. Engineers can dive deep into individual tasks while always having access to the broader context and rationale.
It prevents the common pitfall of teams losing sight of the forest for the trees, ensuring that each small piece of work ladders up to the larger product vision.
The Initiative → Epic → Story Framework
I learned to think in terms of:
Initiatives: Big things taking multiple quarters (e.g., "Make Kedro-Viz collaborative")
Epics: Large bodies of work taking weeks to months (e.g., "Shareable URLs")
Stories: Simple tasks from the user's perspective (e.g., "As a data scientist, I want to share my pipeline view so my PM can review it")
Breaking down problems this way made everything more manageable and helped the team understand how individual tasks connected to larger outcomes.
When Things Don't Work: The Honest Post-Mortem
Not everything succeeded. One feature I worked on launched to flat adoption numbers and never recovered. When I later proposed removing it, the team resisted—it's always harder to kill features than to build them.
What I learned from failure:
Build a 10X better product experience - If you're building for users who already have a working solution, incremental improvements aren't enough to drive switching behaviour. You need something dramatically better. Gmail didn't just offer slightly more storage than Hotmail's 2MB or Yahoo's 4MB—it launched with 1GB, a 250-500X improvement that made the old solutions feel instantly obsolete.
Do more rigorous user validation - Listen to what users aren't saying, not just what they are
Review decision logs - Examine assumptions that led to building the feature in the first place
Conduct pre-mortems - Assume the project has failed and brainstorm reasons why before you start building. As Shreyas Doshi says: "If you do a pre-mortem right, you won't need a tough post-mortem."
The Three Products Every PM Manages
A mentor asked me a question that stuck: "What kind of PM do you want to be?"
I could be:
A PM who excels at discovery and user research
A PM who gives the development team maximum velocity
A PM who's a direct and effective decision-maker
The question forced me to think about my value proposition:
What outputs does my team need from me?
What happens because I'm here (and what wouldn't happen if I weren't)?
The insight: Every product manager manages three interconnected products—the actual product, their team's effectiveness, and their own career development. Neglect any one of them at your peril.
The Product, Team, Their Career.
33 Lessons in 3 Years
Here are the key lessons that will guide my next chapter:
On User Research
1. You can add value from day 1
2. Always improve your tools and processes
3. Show, don't tell—watch users work
4. Embrace silence in interviews
5. Talk to non-users too
6. Right-size your research team
On Stakeholder Management
7. Problem framing is everything
8. Engage stakeholders before group meetings
9. Naivety can be valuable
10. Know when to escalate
11. Be a translator between users and engineers
12. Trust takes time to build
On Product Development
13. Learn continuously from colleagues
14. The real work begins after launch
15. Use visuals when announcing features
16. Continuous learning requires humility
17. Have a structured learning approach
18. Apply what you learn immediately
On Team Dynamics
19. Improve how you work together
20. The best ideas come from unexpected places
21. Be a great thought partner
22. Build and test demos quickly
On Strategy
23. Be both quantitative and qualitative with data
24. Zoom in and zoom out continuously
25. Always be prepared with research
26. Break problems into actionable chunks
On Failure and Growth
27. Build a 10X better product experience
28. Do rigorous user validation
29. Review decision logs regularly
30. Conduct pre-mortems
31. Manage your three products: product, team, career
32. You're a keeper of team culture
33. Don't forget to breathe and have fun
These 33 lessons shaped not just how I approach product management, but how I think about building teams, serving users, and growing as a professional. They're the tactical foundation that every PM needs to master.
But there's more to the story. Managing the product that is your career—that third interconnected product—requires a different kind of reflection. It's about understanding culture, making difficult transitions, and having the courage to start over.
In Part 2, I'll share what I've learned about career management as product management, the culture lessons that shaped my leadership approach, and why I have decided to become a beginner again.
Until next time.
Nero
The Best is Yet to Come
If you enjoyed this article, you would also enjoy #42. Product Manager, QuantumBlack Year One before I release part 2 next . You might also find Nero’ Weekly, What Does It Take to Build a Successful Startup? and Sam Walton Made in America. My Story interesting reads.
You can subscribe now to receive all 80 of my articles including deep dives and career articles, technology and product articles, business breakdowns, and book reviews.
