I’m incredibly excited to have Ilya back for the Season 1 finale. He was my very first guest in the pilot episode, and honestly, he helped me figure out this format - what works, what doesn’t, how to make the collaborative problem-solving feel authentic. So it felt only right to close this season by bringing him back full circle.

In this finale, we tackle a frustratingly common scenario: a marketing stakeholder needs data from a new platform for critical quarterly forecasting, but the data team estimates four months to build the connector. Meanwhile, two hours disappear every morning into manual CSV downloads, cleanups, and copy-paste operations, a process that’s already caused a 50% error in pipeline analysis.

What seems like a technical integration problem quickly reveals itself as something much deeper: an organizational breakdown in ownership, communication, and mutual understanding between business stakeholders and data teams. And true to form, Ilya immediately zeroes in on the people side of things.

Problem Category: Data Integration & ETL
Runtime: 40 minutes

The Problem

Submitted by: Anonymous Marketing Professional
Industry Context: Company with established data infrastructure and quarterly business planning cycles

Problem Framework

Issue: Need data from the new marketing automation platform for quarterly forecasting, but building a connector will take four months, according to the data team. Currently manually downloading CSV files daily.

Trigger: Quarterly planning cycle starts in 8 weeks. Currently spending 120 minutes every morning downloading, cleaning, and manually importing marketing data files. Last week, a copy-paste error threw off pipeline analysis by 50% - only caught because the numbers seemed unrealistic.

Tension: The data team focuses on building robust, enterprise-grade connectors that take months to develop properly. While understanding their approach, there’s an immediate business need that can’t wait for the perfect solution. The manual process is unsustainable and risky, but the data is critical for business planning.

Boundaries:

• Cannot change the quarterly planning timeline (set by business cycle)

• The marketing platform was selected by leadership and cannot be changed

• The data team has limited capacity and other priorities

• A budget exists for reasonable interim solutions

• Must maintain data quality standards for forecasting accuracy

Tech Stack: New marketing automation platform with CSV export capability, central data warehouse for forecasting (specific tools not disclosed)

Clarity Statement: Need an interim solution to get marketing platform data into the data warehouse reliably within the next 8 weeks, without waiting for the full enterprise connector that will take 4 months.

Our Guest

Ilya
Fractional Head of Data & Data Leadership Consultant

Ilya brings over 15 years of data experience, having led data functions at companies like Ada Health (symptom checker app), and various startups and scale-ups across Berlin and Munich. Originally from Moscow with a background in computational mathematics, he moved to Germany in 2002 and transitioned from database research to hands-on data engineering and leadership roles. After the biotech winter impacted Ada Health, Ilya pivoted to fractional and interim data leadership, helping companies build data platforms and teams across different domains and stages.

Special Note: Ilya was our very first guest in the pilot episode and returns to close out Season 1, bringing his people-first philosophy full circle.

Connect with Ilya:

• LinkedIn: https://www.linkedin.com/in/bkmy43/

• YouTube: https://www.youtube.com/@lab4.berlin (Data leadership discussions while smoking pipes - yes, really, and it’s worth checking out)

• Website: https://www.lab4.berlin/

The Breakthrough Discussion

Initial Reactions

Ilya and I immediately recognized this as a people problem disguised as a technical problem. As Ilya put it: “From most failing projects and situations like this, I rarely saw the root cause was technology or tools.”

The four-month estimate raised red flags for both of us. As Ilya observed, connecting to an API of an existing marketing tool shouldn’t take four months - what’s likely happening is that “building a connector” actually means the entire pipeline: getting the data, integrating it into the company data model, and delivering it through BI tools with proper business logic.

The Real Problem

Through the reflection break and collaborative discussion, we identified the core issues:

1. Communication Breakdown: The data team likely down-prioritized this request because other initiatives have a higher business impact, but they haven’t articulated this clearly. The stakeholder hears “four months” without understanding what’s blocking it.

2. Ownership Confusion: It’s unclear who owns the decision about prioritization and tradeoffs. Without clear ownership, every request becomes a negotiation rather than a strategic decision.

3. Missing Context: The data team probably doesn’t understand the business impact of the delay (corrupted forecasts, wasted ad spend, strategic planning delays). The stakeholder doesn’t understand what the data team is actually building and why it takes time.

4. Us vs Them Dynamic: The situation has devolved into adversarial positioning - “the data team won’t help me” versus “stakeholders want everything immediately” - rather than collaborative problem-solving.

The Solution Approach

Rather than a single technical fix, our discussion produced a multi-layered solution:

Immediate Relief (Week 1-2): Ask one of the engineers to build a simple Python script or similar automation. This doesn’t need to be production-grade infrastructure - just something that reliably pulls the CSV, does basic transformation, and loads it into the warehouse. This can be a 2-3 day task rather than a 4-month project.

Transparency & Context (Week 2-3): Create a visible initiative backlog overview showing everything the data team is working on. When someone says “it will take four months,” they should be able to show exactly what’s blocking it and why those other priorities matter more. This isn’t about justifying delays - it’s about enabling informed decisions.

Rational Decision Framework (Week 3-4): Develop a structured way to articulate both the cost of building solutions and the business impact of delays. Put numbers on the table: What does two hours of manual work daily cost? What’s the risk value of potential forecast errors? What’s the opportunity cost of the data team working on this versus their current priorities?

Strategic Alignment (Ongoing): Establish clear ownership and a prioritization process that considers both technical complexity and business impact. This isn’t about the data team gatekeeping or stakeholders demanding - it’s about having a framework where tradeoffs are visible and decisions are rational.

Key Takeaways

3 Critical Insights

1. This is an Organizational Problem, Not a Technical One: The four-month timeline isn’t about technical complexity - it’s about priorities, communication, and organizational dynamics. The actual technical work of connecting to an API could be done much faster if approached as a quick automation rather than an enterprise-grade infrastructure.

2. The “Us vs Them” Dynamic Is Killing Efficiency: When stakeholders and data teams position themselves as adversaries rather than collaborators, every interaction becomes a negotiation. The marketing person sees the data team as obstructionist; the data team sees stakeholders as demanding and unrealistic. Neither side wins in this dynamic, and the business suffers.

3. Ownership Clarity Is Essential: Without clear ownership of prioritization decisions, every data request becomes contested territory. Someone needs to own the decision about whether a four-month wait is acceptable given the business impact, and that person needs visibility into both the technical constraints and business consequences.

4 Action Items

For the Problem Submitter (and anyone in similar situations):

1. Request a Quick Automation Script (This Week) - Ask a data engineer to build a simple Python script or similar automation that pulls the CSV, does basic transformation, and loads it into your warehouse. Make it clear this doesn’t need to be production-grade infrastructure - just something reliable enough to bridge the gap. Timeline: 2-3 days of engineering time.

2. Create Initiative Backlog Visibility (Week 2) - Work with the data team to create a visible overview of all current initiatives. When told something will take four months, you should understand what’s blocking it and why those priorities were chosen. This isn’t about challenging their decisions - it’s about having context for informed discussion.

3. Articulate Cost and Impact With Numbers (Week 3) - Document the actual business impact: two hours daily of manual work (cost it out by salary), risk of forecast errors (quantify the potential impact), strategic planning delays (what decisions are being made without this data?). Similarly, ask the data team to articulate what they’d need to deprioritize to tackle this sooner.

4. Establish Ongoing Prioritization Framework (Week 4+) - Work with leadership to create a clear process for prioritizing data work that considers both technical complexity and business impact. Identify who owns these decisions and ensure they have visibility into both technical constraints and business consequences. This prevents future “four months” surprises.

Episode Highlights

• 02:00 - Problem reveal: Four months for a marketing platform connector

• 06:30 - Ilya’s immediate diagnosis: “This is a people problem, not a technical one”

• 14:45 - Post-reflection discussion: Unpacking the communication breakdown

• 24:30 - The ownership question: Who actually decides priorities?

• 31:00 - Quick wins vs long-term solutions: The Python script approach

• 36:05 - Did we break through? An honest assessment

The Honest Assessment

At the end of the episode, Ilya and I agreed: This wasn’t a breakthrough moment.

As Ilya candidly put it: “If I had a silver bullet, a process, or an idea how to solve it in a company, I would probably not be here. I’d be a millionaire.”

This pattern - stakeholder requests taking months, manual workarounds creating risk, “us versus them” dynamics - happens constantly across companies of all sizes. It’s not easily solved because it’s deeply rooted in organizational structure, culture, and human nature.

What our episode provided wasn’t a magic solution but a structured framework for thinking about these conflicts:

• Separating immediate tactical relief from long-term strategic solutions

• Making tradeoffs visible rather than hidden

• Moving from adversarial positioning to collaborative problem-solving

• Establishing clear ownership and rational decision processes

The problem that was submitted - the manual CSV downloads - can likely be solved with a quick automation. But the deeper problem - the organizational dynamics that created a four-month timeline - requires more fundamental changes that depend heavily on company culture, team size, and leadership support.

Resources & Concepts Mentioned

• Python Automation Scripts: Simple scripts using libraries like pandas for CSV processing and database connectors (psycopg2, mysql-connector, etc.) for warehouse loading

• Backlog Transparency Tools: Project management platforms (Jira, Linear, etc.) configured for stakeholder visibility

• Prioritization Frameworks: Cost of delay, weighted shortest job first, RICE scoring (Reach, Impact, Confidence, Effort)

• Interim vs Enterprise Solutions: The concept of “good enough for now” automation versus production-grade infrastructure

Continue the Conversation

Submit Your Data Problem or Become a Guest

Visit our show website:

https://data-breakthroughs-podcast.cookingdata.blog/

Here you can:

• Submit your data challenge for a future episode

• Apply to be a guest

• See the latest episodes

• Explore past problems and solutions

Share Your Alternative Solution

Have you dealt with similar stakeholder-data team conflicts? How did you resolve them?

• Use #DataBreakthrough on social media

• Reply to this newsletter with your approach

Implementation Follow-up

If you try any of these approaches and they work (or don’t work), I’d love to hear about it. Real implementation stories help the entire community learn.

Season 1 Reflection

This episode marks the end of Data Breakthroughs Season 1. I started with Ilya in the pilot episode, and it felt only right to close the season with him returning. Throughout the season, I’ve seen a consistent theme: most data problems are actually people problems. Whether it’s pipeline reliability, customer definition alignment, ML deployment challenges, or dashboard governance, the technical aspects are rarely the core issue.

Thank you for being part of this first season. Your problem submissions, guest applications, and community engagement have made this possible.

About Data Breakthroughs

Data Breakthroughs brings together data practitioners to solve real operational challenges through collaborative problem-solving. Each episode features authentic, unscripted brainstorming sessions where neither the guest nor I sees the problem beforehand, creating genuine, real-time problem-solving moments.

Host: Lior Barak

Credits

Host & Producer: Lior Barak
Guest: Ilya, Fractional Head of Data
Music: “Calisson” courtesy of Riverside
Season: 1, Episode 11 (Season Finale)

Season 2 Preview: Coming late February 2026 with enhanced problem submission requirements, extended reflection breaks, and continued commitment to authentic, unscripted data problem-solving. Season 3 recording begins in April 2026 for a June 2026 release.

Disclaimer

This podcast is for inspiration and educational purposes. The solutions and approaches discussed are general frameworks meant to spark ideas and collaboration. Always adapt recommendations to your specific organizational context, constraints, and requirements. Not every problem has a breakthrough solution, and sometimes the most valuable outcome is understanding the complexity better.

Thanks for being part of Season 1. See you in late February 2026 for Season 2!

Your company invested in a modern data platform. But your plant managers with 20+ years of operational expertise are refusing to use it. This is the classic data transformation paradox: you can build the best system in the world, but if experienced practitioners don’t believe in it, adoption fails. In this episode, Tiankai Feng (Director of Data & AI Strategy at ThoughtWorks) and host Lior Barak encounter this challenge head-on, discovering how to bridge the gap between data thinking and operational experience, and building the change management strategies that actually drive adoption in legacy organizations.Problem Category: Organizational Data Strategy / Change Management
Runtime: 32 minutes
Recording Date: 2024

The Problem

Submitted by: Anonymous
Industry Context: Family-owned manufacturer of watering systems, grown from 50 to 340 employees over 8 years

Problem Framework

• Issue: The company invested heavily in data infrastructure and hired a talented analytics team, but in crucial production meetings, plant managers still make decisions based on “what happened last time” and gut instincts rather than the comprehensive operational data now available. Last week, there was a heated debate about capacity planning where the data clearly showed one recommendation, but leadership went with the plant manager’s experience instead.

• Situation: A family-owned manufacturer has built a modern data platform with real-time production metrics, quality tracking, and predictive maintenance capabilities. The “old guard” plant managers have 15-20 years of experience and have successfully navigated crises through relationships and intuition.

• Trigger: During a quarterly planning meeting, real-time data showed that Plant B was operating at 87% efficiency while Plant A was at 94%, suggesting they should shift a major contract to Plant A. However, the Plant B manager argued that his team “knows how to handle rush orders better” and convinced leadership to keep the contract there. The project ended up three weeks late and 12% over budget - exactly what the data predicted.

• Tension: There’s a growing divide between data people and operations people. The analytics team feels their insights are being ignored, while plant managers feel like their decades of experience are being devalued by “kids with spreadsheets.” The company is caught in the middle, having championed both the data investment and needing to respect the expertise that built the company.

• Boundaries: Cannot replace experienced plant managers - their operational knowledge is irreplaceable. Family ownership values loyalty and long-term relationships. Union environment requires careful change management. Manufacturing deadlines don’t allow for lengthy decision processes. Safety-critical environment where wrong decisions have serious consequences.

• Tech Stack: Modern data platform with real-time production metrics, quality tracking, and predictive maintenance capabilities (specific tools not disclosed)

• Clarity Statement: Enable decision makers to combine data insights with their operational expertise to make the best decisions possible, while acknowledging both the value of experience and the value of evidence.

Our Guest

Tiankai Feng
Director of Data & AI Strategy at ThoughtWorks

Tiankai is passionate about the human side of data and AI, which is why he’s written two books: “Humanizing Data Strategy” (2023) and “Humanizing AI Strategy” (2024). At ThoughtWorks, a consultancy focusing on data and tech solutions, he helps organizations navigate the complex intersection of technology and people. He also uses his musical talents to make data and AI more approachable through songs like “Governors of Data” (about data governance) and “U&I and AI” (about the future of dating if AI is involved too much). His work emphasizes that successful data and AI strategies require understanding culture, communication, and change management - not just technology.

Connect with Tiankai:

• LinkedIn: https://www.linkedin.com/in/tiankaifeng/

• Books:

  • Humanizing Data Strategy: https://amzn.eu/d/hG8CSPt

  • Humanizing AI Strategy: https://amzn.eu/d/bZtMMI1

The Solution

Strategic Approach Overview

Rather than forcing adoption of the data platform or dismissing decades of operational expertise, the solution focuses on repositioning data as a support tool that enhances - rather than replaces - human judgment. The key is co-creation: involving plant managers in building the dashboards and decision frameworks they’ll actually use, while clearly communicating that expertise and data work hand-in-hand, not against each other.

Core Solution Components

1. Reframe Data as Support, Not Replacement (Foundation) The first critical shift is messaging: data is not here to replace the plant managers’ expertise or prove them wrong. It’s a support tool to help them make even better decisions. This addresses the fundamental fear driving resistance - that experienced managers will be devalued or replaced by technology. Lior shared the story of a friend whose family owned a coffee roasting business: when they introduced data-driven processes, one employee said, “Finally, I have time to smoke cigarettes” (don’t smoke!). The point: data created space for people to do other valuable work, not to eliminate their jobs.

2. Co-Create Dashboards and Data Sets (Quick Win - 30 Days) Never build dashboards in isolation and throw them over the fence. Bring plant managers into the design process from day one:

• Identify decision points in business processes together

• Define what data is needed for those decisions - with their input

• Build dashboards that reflect their language and priorities

• Translate technical KPIs into operational language they understand. This isn’t just good practice - people simply don’t use things they didn’t choose or help create. When stakeholders are part of the solution, they’re invested in its success.

3. Define Decision-Making Rules and Incentives (Long-Term - 60-90 Days). Create clear frameworks for when and how data should inform decisions:

• Establish business rules (e.g., “if plant capacity drops below 50%, a data-driven decision is required”)

• Define thresholds and triggers for different types of decisions

• Clarify what decisions are data-driven vs. expertise-driven, vs. hybrid

• Align incentive structures: if managers are only rewarded for short-term results, they’ll choose gut-feel solutions that work immediately rather than data-informed approaches that optimize long-term performance

4. Improve the Operating Model Between Teams (Cultural Shift) Address the “kids with spreadsheets” vs. “old guard” dynamic:

• Create shared goals between analytics and operations teams (not competing objectives)

• Assign analysts to work directly with plant managers (embedded collaboration, not remote reporting)

• Establish data champions within plant management - find early adopters who can authentically advocate to their peers

• Develop structured upskilling programs that respect existing expertise while building data literacy

5. Measure and Prove Value (Evidence Building) Build proof of data’s impact on both short-term and long-term decisions:

• Track success metrics that matter to plant managers (on-time delivery, quality, safety)

• Create “data success stories” showing how data + expertise led to better outcomes

• Document cases where data prevented costly mistakes (like the Plant B example)

• Use dashboards with monitoring and alerting to make data insights actionable, not just informative

Implementation Roadmap

30 Days (Quick Wins):

• Reframe all communication: data as a support tool, not a replacement

• Launch co-creation sessions with 2-3 plant managers to build the first dashboard together

• Translate existing KPIs into operational language with manager input

• Identify data champions among plant managers

60 Days (Structural Changes):

• Complete first co-created dashboards with clear action triggers

• Define decision-making framework: when to use data vs. expertise vs. both

• Review incentive structures - do they reward short-term gut-feel or long-term optimization?

• Establish regular collaboration sessions between analytics and operations

90 Days (Cultural Integration):

• Implement the data champion program across all plants

• Document first “success stories” of data + expertise wins

• Roll out an upskilling program that honors experience while building literacy

• Engage the union/works council proactively about the data’s supportive (not replacement) role

Key Takeaways

3 Critical Insights

1. Expertise vs. Data Is Always a Tension Field: Especially among experienced professionals who’ve succeeded without comprehensive data for decades. They’ve navigated crises through intuition, relationships, and pattern recognition - and it worked. Now they’re being told to trust numbers on a screen over their hard-won knowledge. The solution isn’t to declare one side “right” - it’s to communicate clearly that expertise and data should work hand-in-hand, not against each other. Value both sides. Make it about doing things better together, not devaluing someone’s unique experience.

2. People Don’t Use Things They Didn’t Choose: This is the fundamental flaw in most data platform implementations. The analytics team builds something in isolation, optimizes it for what they think matters, then presents it to stakeholders who had no input. Of course, they resist. Co-creation isn’t a nice-to-have - it’s essential for adoption. When you build dashboards, define metrics, and establish processes with the people who’ll actually use them, they become invested in the solution. They were part of the journey, not just handed a destination.

3. Success Metrics Must Reflect True Value: If plant managers are incentivized purely on short-term results, they’ll choose gut-feel solutions that show immediate wins - even if data suggests a different long-term approach. The question “how is success measured?” determines whether data gets used. When bonuses, promotions, and recognition are tied to quarterly performance, managers will optimize for that timeframe. For data to matter, incentive structures must reward both immediate operational excellence and strategic, data-informed optimization that pays off over time.

5 Action Items

For the Problem Submitter (and others facing similar challenges):

1. Reframe Communication Immediately (Week 1) - Stop positioning data as the “right” way to make decisions versus the “wrong” way of gut instinct. Start messaging: “Data is here to support your expertise, not replace it.” Have leadership explicitly communicate that plant managers’ operational knowledge is irreplaceable and that the goal is augmentation, not replacement. Address fears head-on, especially in union environments where job security concerns are legitimate.

2. Launch Co-Creation Sessions (Week 1-4) - Identify 2-3 plant managers who are at least neutral (if not enthusiastic) about data. Bring them into dashboard design sessions: “We want to build something that actually helps you. What decisions keep you up at night? What information would make those easier?” Build the first dashboard together, in their language, with their priorities. Use this as a proof-of-concept that others can see working.

3. Define Decision Framework and Rules (Week 4-8) - Work with plant managers to map decision points: Which decisions require immediate action based on floor expertise? Which benefits from data analysis? Which needs both? Create clear business rules and thresholds (e.g., “capacity below X requires data review before proceeding”). This removes ambiguity about when data should be consulted and prevents it from feeling like constant second-guessing.

4. Assign Embedded Analysts (Week 8-12) - Don’t have analytics teams work remotely and deliver reports. Embed analysts directly with plant managers - someone who sits with them, understands their daily challenges, and can translate between data insights and operational reality. This builds trust and ensures data solutions are grounded in real-world constraints (manufacturing deadlines, safety protocols, union requirements).

5. Review Incentive Structures (Ongoing) - Examine how plant managers are measured, rewarded, and promoted. If the system only values short-term performance, no amount of data evangelism will change behavior. Work with leadership to ensure success metrics acknowledge both immediate operational excellence and strategic, data-informed optimization. Create “data success stories” that leadership recognizes and celebrates - make data adoption visible and valued.

Episode Highlights

• 02:34 - Tiankai introduces himself and his musical approach to making data governance fun

• 04:46 - Problem reveal: “kids with spreadsheets” vs. decades of plant floor experience

• 08:07 - Tiankai’s critical question: “Why even build a modern data platform if no one is using it?”

• 09:15 - The clarity statement: enabling decision makers to combine data with expertise

• 11:49 - Tiankai’s brainstorming: “Have decision makers given feedback before, or was it built in isolation?”

• 13:40 - The incentive question: how are plant managers measured - short-term or long-term?

• 16:23 - Tiankai’s process architecture: identifying decision points and co-creating data sets

• 17:07 - Lior’s coffee roasting story: when data creates space instead of replacing people

• 19:42 - The translation challenge: making KPIs speak “people language”

• 24:35 - Refinement discussion: expertise and data must go hand-in-hand

• 30:50 - Tiankai’s follow-up point: change management is always the underestimated problem

Resources Mentioned

• Humanizing Data Strategy by Tiankai Feng: Leading Data with the Head and the Heart - https://amzn.eu/d/hG8CSPt

• Humanizing AI Strategy by Tiankai Feng: Leading AI with Sense and Soul - https://amzn.eu/d/bZtMMI1

• ThoughtWorks: Consultancy focusing on data and tech solutions

• Tiankai’s YouTube Channel: Songs about data governance (”Governors of Data”) and AI

• Change Management frameworks: Referenced as critical for data platform adoption

Continue the Conversation

Submit Your Data Problem

Have a challenge you’d like us to tackle? Use our structured framework:

https://data-breakthroughs-podcast.cookingdata.blog/

Become a Guest

Data practitioner interested in collaborative problem-solving? Apply here:

https://data-breakthroughs-podcast.cookingdata.blog/

Share Your Alternative Solution

Did this episode spark a different approach? Share it with the community:

• Use #DataBreakthrough on social media

• Reply to the Wabi-Sabi Data newsletter

Implementation Follow-up

If you implement this solution, we’d love to hear about your results! Reach out for a potential follow-up mini-episode.

About Data Breakthroughs

Data Breakthroughs brings together data practitioners to solve real operational challenges through collaborative problem-solving. Each episode features authentic, unscripted brainstorming sessions focused on creating practical, implementable solutions.

Host: Lior Barak

• Podcast Website:

https://data-breakthroughs-podcast.cookingdata.blog/

Credits

Host & Producer: Lior Barak
Guest: Tiankai Feng, Director of Data & AI Strategy at ThoughtWorks
Music: “Calisson” courtesy of Riverside

Accessibility

Episode Transcript: Auto-generated transcript available on all podcast platforms

Disclaimer

This podcast is for inspiration and educational purposes. The solutions and approaches discussed are general frameworks meant to spark ideas and collaboration. Always adapt recommendations to your specific organizational context, constraints, and requirements. The goal is to have fun while exploring data challenges together!

Your analytics team has built comprehensive dashboards with 40+ charts per report. You have all the data anyone could want. But executives are paralyzed by choice—too much information, no clarity on what matters. The dashboard factory is destroying decision-making instead of enabling it. In this episode, Eva Schreyer (Head of Data & Analytics at Neugelb) and host Lior Barak tackle the analytics paradox: why more data and dashboards can actually cripple organizations. They explore how to escape dashboard chaos by focusing on strategic clarity and building analytics systems that matter.Problem Category: Business Intelligence & Dashboarding / Organizational Data Strategy
Runtime: 37 minutes
Recording Date: 2024

The Problem

Submitted by: Anonymous
Industry Context: Mobile application (B2C), subscription + ad-supported model, growth stage company with 200+ employees and 2-5 million active app users

Problem Framework

• Issue: The product team receives large volumes of analytics output (40+ charts and tables per report) but lacks clarity on actionable insights. Data is descriptive rather than prescriptive, leaving product managers unsure which features to prioritize.

• Trigger: Leadership began requiring data-backed justification for all major product decisions (sprint planning, roadmaps, alignment). This increased demand for analytics exposed the gap between raw reporting and actionable guidance.

• Tension: Leadership questions why investment in analytics isn’t accelerating decision-making. Without actionable recommendations, product decisions slow down, features risk being prioritized based on opinion rather than evidence, and the business loses time and money on low-impact initiatives. Ultimately, the disconnect reduces trust in the analytics function and its value to the product organization.

• Boundaries: Not about tooling limitations-reports are generated quickly and comprehensively. The analytics team produces reports upon request, but doesn’t own or influence prioritization frameworks. Product managers rely on intuition or incomplete data storytelling to decide roadmap items.

• Tech Stack: Mixpanel, SQL-based internal database queries, Looker for visualization

• Clarity Statement: Transform the analytics function from a reactive dashboard factory into a strategic partner that helps product managers make confident, data-driven prioritization decisions while demonstrating clear value to leadership.

Our Guest

Eva Schreyer
Head of Data & Analytics at Neugelb (Commerzbank)

Eva leads data and analytics for Neugelb, the tech hub of Commerzbank that builds mobile banking apps. Her team handles everything from data ingestion and infrastructure to analytics and insights, with the ultimate goal of influencing stakeholders to take action based on data. With experience navigating both startup-like environments and corporate structures, Eva brings a valuable perspective on balancing analytics depth with stakeholder engagement. She is also a co-organiser of dbt Berlin meetup and TLE - Tech Leadership Exchange.

Connect with Eva:

• LinkedIn: https://www.linkedin.com/in/eva-schreyer/

The Solution

Strategic Approach Overview

Rather than building more dashboards or improving existing reports, the solution focuses on fundamentally changing how the analytics team operates-from order-takers to strategic partners. The approach combines quick wins (executive alignment on core metrics) with structural changes (establishing request evaluation processes and embedded collaboration models).

Core Solution Components

1. Create Executive Alignment First (Quick Win) Start by creating a single executive dashboard with a maximum of 5 KPIs that everyone agrees on. This forces alignment on what actually matters and provides a north star for all other analytics work. While it sounds simple, defining these metrics (like “active user”) often surfaces important strategic discussions that have been avoided.

2. Monetize Every Request Make the cost of analytics work visible-whether in actual hours (”this will take 20 hours of analyst time”) or even playful “monopoly money.” Stakeholders dramatically change their prioritization when they understand the investment required. Eva shared an example where a senior stakeholder immediately withdrew a request when learning it would take two days of work.

3. Shift from Dashboards to Deep Dives Instead of creating more generic dashboards that must work for every scenario, focus on targeted, ad-hoc analyses that deeply explore one strategic feature or question. These “talk analyses” allow for much richer storytelling and more actionable insights than generic visualizations that try to serve all purposes.

4. Establish Request Evaluation Process. Implement a systematic approach to evaluating new data requests:

• Map all existing dashboards to understand the current state

• Apply the “5 W’s” framework: Why do you need it? What will it make you do? When do you need it? Who needs it? Who will it impact?

• For each request, ask: “What will you do differently when this metric changes?”

• Remove dashboards where stakeholders can’t articulate a clear action based on the data

5. Move Closer to Product (Strategically) Rather than fully embedding analysts in product teams (which risks recreating the dashboard factory problem at a smaller scale), establish regular sync meetings between product and analytics teams. This creates space for collaborative thinking about what data actually matters while maintaining the analyst’s ability to push back on low-value requests.

Implementation Roadmap

30 Days (Quick Wins):

• Map all existing dashboards and their stakeholders

• Create an executive dashboard with max 5 KPIs

• Pilot “monetized requests” with one product team

• Move one major analysis to Excel/sheets to force fresh thinking outside the cluttered current environment

60 Days (Structural Changes):

• Remove dashboards with low value (using the 5 W’s framework)

• Establish a formal process for approving new data initiatives

• Create an async board for users to request and justify data needs

• Define a process for each dashboard to have a clear “value statement”

• Implement weekly sync between product and data teams

90 Days (Cultural Shift):

• Establish data requests as a product backlog with prioritization

• Complete first round of deep-dive analyses on strategic features

• Implement regular dashboard cleanup sessions

• Begin tracking which insights lead to actual product decisions

Key Takeaways

3 Critical Insights

1. Too Much Data Doesn’t Mean Good Decisions: Having comprehensive data coverage creates analysis paralysis. When stakeholders are overwhelmed with information, they retreat to gut-feel decision-making and stop trusting analytics. Relevance and actionability matter infinitely more than volume. As Lior shared from his experience at a major telecom: 600+ dashboards didn’t create better decisions-it created chaos.

2. Make Stakeholders Understand the Cost: When analysts try to be “extra helpful” by saying yes to every request, they often end up being unhelpful. Making the time investment visible (whether in hours, opportunity cost, or even playful “monopoly money”) dramatically changes stakeholder behavior. It transforms conversations from emotional (”I need this data!”) to rational (”Is this worth 20 hours of analyst time?”).

3. Actions, Not Justifications: Data should drive actions, not justify past decisions. The critical question for every dashboard or metric is: “What will you do differently when this number changes?” If stakeholders can’t articulate a clear action, the dashboard is vanity metrics at best. This shift from data as CYA to data as a decision driver fundamentally changes the analytics-product relationship.

5 Action Items

For the Problem Submitter (and others facing similar challenges):

1. Create Executive Dashboard (Week 1-2) - Facilitate an alignment meeting with leadership to define a maximum of 5 core KPIs for the product. Push through the discomfort of narrowing down-this forces clarity on what actually matters. Yes, it will expand over time, but establishing this baseline creates a shared language and prevents drowning in vanity metrics.

2. Audit and Monetize (Week 2-4) - Map every existing dashboard with its stakeholder and estimated maintenance cost. Begin requiring stakeholders to justify new requests by explaining what actions the data will drive. Pilot with one product team by sharing time estimates for requests transparently, about what analytics work actually costs.

3. Transform One Analysis (Week 4-6) - Select one strategic feature and conduct a deep-dive “talk analysis” instead of creating a dashboard. Present findings in a meeting with clear recommendations. Demonstrate the value of targeted analytical thinking over generic reporting. This creates a proof point for a different way of working.

4. Establish Request Process (Week 6-12) - Implement systematic evaluation for new data initiatives: require problem statement, expected action, and stakeholder commitment before work begins. Create a weekly product analytics sync to review priorities collaboratively. Begin regular dashboard cleanup sessions to remove unused reports.

5. Move Strategically Closer to Product (Ongoing) - Rather than fully embedding analysts (which risks recreating the problem), establish regular collaboration rhythms. Consider A/B testing as a way to demonstrate analytical value-even something simple like button copy changes. This shifts the relationship from “give me a dashboard” to “help me make better decisions.”

Episode Highlights

• 03:18 - The “silly filter” icebreaker reveals Eva’s insight about time-of-day context

• 05:39 - Problem reveal: “40+ charts per report” and Eva’s immediate reaction: “I love that problem, it’s so real”

• 07:48 - Discussion of Mixpanel as a tool for product managers, not just analysts-but why aren’t they using it?

• 14:20 - Reflection break: Eva discusses the challenge of staying objective when the problem mirrors her current situation

• 15:58 - Eva’s concern about “analysis paralysis” from too much unstructured data

• 21:17 - Lior’s T-Mobile story: the shock of seeing 600+ dashboards and learning “having all data” isn’t the answer

• 27:38 - Eva introduces the “monetize every request” concept from a recent meetup

• 28:59 - Lior’s Zalando story: how “it’ll take a week” instantly killed an “urgent” request

• 34:38 - Discussion of why an “executive dashboard” isn’t as simple as it sounds-defining “active user” can be surprisingly contentious

Resources Mentioned

• Mixpanel: A Product analytics platform that enables self-service analysis for product teams (mentioned as underutilized in the problem)

• Looker: Business intelligence and visualization platform (part of current tech stack)

• DBT (data build tool): Mentioned by Eva as a tool that changes team dynamics by enabling analysts to build their own data models

• Google Firebase: A/B testing platform Eva’s team uses for product experiments

• The “5 W’s” Framework: Why, What, When, Who (needs it), Who (impacts)-systematic approach to evaluating data requests

Continue the Conversation

Submit Your Data Problem

Have a challenge you’d like us to tackle? Use our structured framework:

https://data-breakthroughs-podcast.cookingdata.blog/

Become a Guest

Data practitioner interested in collaborative problem-solving? Apply here:

https://data-breakthroughs-podcast.cookingdata.blog/

Share Your Alternative Solution

Did this episode spark a different approach? Share it with the community:

• Use #DataBreakthrough on social media

• Reply to the newsletter

Implementation Follow-up

If you implement this solution, we’d love to hear about your results! Reach out for a potential follow-up mini-episode.

About Data Breakthroughs

Data Breakthroughs brings together data practitioners to solve real operational challenges through collaborative problem-solving. Each episode features authentic, unscripted brainstorming sessions focused on creating practical, implementable solutions.

Host: Lior Barak

Credits

Host & Producer: Lior Barak
Guest: Eva Schreyer, Head of Data & Analytics at Neugelb (Commerzbank)
Music: “Calisson” courtesy of Riverside

Accessibility

Episode Transcript: Auto-generated transcript available on all podcast platforms

Disclaimer

This podcast is for inspiration and educational purposes. The solutions and approaches discussed are general frameworks meant to spark ideas and collaboration. Always adapt recommendations to your specific organizational context, constraints, and requirements. The goal is to have fun while exploring data challenges together!

Your demand forecasting model is performing beautifully in testing—91% accuracy, textbook metrics, everything looks perfect on paper. Then you deploy it to production and reality hits: the model is completely useless. It’s the classic “office kitchen paradox”—your perfect model fails where it matters most. In this episode, Irena Bojarovska (Applied Scientist at Zalando) and host Lior Barak encounter this mystery for the first time during recording, tackling one of machine learning’s most dangerous illusions: the gap between test accuracy and real-world impact. They explore why metrics lie, how models fail in production, and what actually matters when accuracy doesn’t.Problem Category: Machine Learning & AI Implementation
Runtime: 50 minutes

The Problem

Submitted by: Anonymous / Internal Team
Company Context: Mid-sized tech company with office kitchen operations

Problem Framework

Issue: A hackathon team built a smart kitchen demand forecasting model to predict fresh food ordering needs, achieving 91% accuracy during a two-week prototype. However, the company is still discarding 20-25% of its fresh products weekly, while simultaneously running out of popular items.

Trigger: Six months after the initial hackathon success, the model is deployed in production but delivering disappointing real-world results. Despite the impressive validation metrics, the core problem persists: food waste remains high and stockouts continue.

Tension: The gap between testing accuracy (91%) and operational results (20-25% waste) reveals a fundamental mismatch. Resources were invested in building the model, but the practical benefits have not materialized. The problem has become a symbol of “good metrics, bad outcomes.”

Boundaries: This isn’t about changing purchasing practices or organizational discipline. It’s specifically about why the model’s strong accuracy doesn’t translate to reduced waste and improved availability.

Tech Stack:

• Demand forecasting model (built during hackathon)

• Fresh food ordering system

• Historical ordering data

• Current validation metrics: 91% accuracy

Clarity Statement: Close the gap between model accuracy and operational waste reduction by understanding and fixing the data quality, input factors, and human decision-making elements affecting real-world performance.

Our Guest

Irena Bojarovska
Applied Scientist at Zalando SE

Irena originally studied applied mathematics and computer science in Russia before moving to Berlin in 2012 to complete her PhD in applied harmonic analysis at TU Berlin. She started her career as an analyst at Air Berlin, where she focused on understanding and presenting data. Since 2017 at Zalando, she’s shifted to the challenge of predicting data through her work in time series forecasting and demand prediction across 22+ markets. Her expertise spans deep learning models, foundational models, and optimization solutions. Outside of work, Irena is a dedicated mother of three and a passionate math educator who believes strongly in avoiding “garbage in, garbage out” problems in data science.

Connect with Irena:

• LinkedIn: https://www.linkedin.com/in/irenabojarovska/

  AI Guild Berlin Meetups: Community member and regular participant

  Math circle teacher at Lyzeum 2 Berlin: https://lyzeum2.de/irena-bojarovska

The Solution

Core Breakthrough: It’s Not the Model, It’s the Data and Context

The fundamental insight that emerged during this episode shifted the entire problem frame. The 91% accuracy achieved in a controlled two-week prototype environment doesn’t account for the real-world complexity that a production forecasting system encounters daily. The issue isn’t that the model is broken; it’s that the model is missing critical inputs and is blind to data quality problems.

Data Flow Solution

Phase 1: Diagnose Data Quality Issues

• Validate historical ordering data for completeness and accuracy

• Check whether the data used to build the model represents actual kitchen demand or just historical orders (which may already include waste decisions)

• Identify missing contextual information: Are people’s office attendance patterns captured? Are there special events, holidays, or company activities affecting food consumption?

Phase 2: Expand the Model’s Input Features

• People coming to office: Integrate office attendance data (via badge scans, calendar data, or voluntary surveys)

• Special events and anomalies: Capture company events, holidays, and team events that affect kitchen traffic

• Time-based patterns: Model day-of-week effects, seasonal variations, and growth trends

• Product interaction data: Understanding which items are actually consumed versus which are left untouched

Phase 3: Implement Human-AI Collaboration

• Use the AI forecast as an initial recommendation, not a final decision

• Enable kitchen managers or procurement teams to adjust forecasts based on knowledge the model doesn’t have (last-minute event changes, known patterns, market knowledge)

• Track these human adjustments and feedback loops to continuously improve the model

Phase 4: Measure Real Performance

• Establish baseline: What waste percentage did humans achieve before the model? (A/B test if possible)

• Define true success metrics: waste reduction percentage and stockout rates, not just model accuracy

• Monitor model performance over time and catch degradation early

Visual Concept

A diagram showing three layers:

1. Input Layer (what data the model receives): Attendance patterns, special events, product characteristics

2. Processing Layer (what the model learns): Demand patterns, correlations, anomalies

3. Output Layer (how humans use the forecast): Initial recommendation → Human adjustment → Final order → Actual consumption → Feedback loop

Key Takeaways

4 Critical Insights

Insight 1: Model Accuracy ≠ Real-World Performance The 91% accuracy achieved during the two-week prototype is misleading because it measures the model’s ability to predict historical orders, not actual food demand. In production, the model faces a fundamentally different problem: predicting what should be ordered to minimize waste while ensuring availability. This requires not just better predictions but better inputs and a fundamentally different success metric.

Insight 2: Data Quality and Contextual Information Are Your Foundation. The model is operating in an information vacuum. It doesn’t know how many people are coming to the office, whether there’s a company event that day, what time of year it is in terms of seasonal patterns, or which products actually get consumed. The biggest leverage point isn’t improving the algorithm, it’s improving the input data and adding human context. This is classic “garbage in, garbage out”: even sophisticated models can’t overcome poor or incomplete data.

Insight 3: Humans Should Augment the Model, Not Be Replaced By It. The optimal solution isn’t fully automated forecasting. It’s a hybrid approach where the AI provides an initial forecast based on patterns, and humans apply their knowledge of factors the model can’t capture (like knowing a popular employee is returning from leave, or that a team recently changed their office days). This human-in-the-loop approach creates a feedback system where the model learns and improves over time.

Insight 4: Define Success Beyond Model Accuracy. Before optimizing the forecast, clarify what success actually means for the business: Is the goal happy employees (always having their favorite items available)? Minimizing food waste for sustainability? Cost reduction? These objectives often conflict; perfect availability requires buffer stock (increasing waste), while minimizing waste risks stockouts (reducing satisfaction). The forecasting model is just one tool; the real solution requires understanding the priority order and exploring interventions beyond prediction, such as changing ordering frequency, adjusting portion sizes, or influencing consumption patterns through placement and presentation.

4 Action Items

For the Problem Submitter (and anyone tackling similar ML deployment challenges):

1. Audit Data Quality First (Timeline: 1-2 weeks)

   • Don’t assume the historical data is clean or representative

   • Check for missing values, inconsistencies, or biases in the ordering records

   • Verify that the data used for validation wasn’t influenced by the original waste problem

   • Ask: Was the 91% accuracy based on predicting actual orders, or on a cleaned/adjusted dataset?

   • This is your foundation; If it’s not solid, everything built on it is at risk

2. Expand Input Features with Behavioral Context (Timeline: 2-4 weeks)

   • Integrate office attendance data (badge scans, Outlook calendar acceptance data if available, or simple surveys)

   • Add special events, holidays, and known anomalies to the model

   • Capture product-level information (item popularity, shelf life, historical consumption patterns)

   • Even simple additions like “how many people are in the office today” can dramatically improve accuracy

   • Coordinate with HR or facilities teams, who likely already track this data

3. Implement A/B Testing: Humans vs. Machine (Timeline: 4-8 weeks)

   • Run the model in parallel with your current ordering process

   • Compare outcomes: What waste percentage does your human process achieve? What does the model achieve?

   • Even if the model achieves 25% waste while humans achieve 20%, understanding the gap helps you identify missing factors

   • This gives you a concrete, business-relevant baseline instead of abstract accuracy metrics

   • If the model is actually better, you have data-driven permission to trust it more

4. Build a Feedback Loop and Human-AI Collaboration Process (Timeline: Ongoing)

   • Don’t deploy the model in fully autonomous mode

   • Create a simple process where procurement/kitchen managers receive the forecast, but can adjust it based on knowledge the model doesn’t have

   • Log these adjustments and actual outcomes to identify patterns that the model is missing

   • Retrain the model monthly or quarterly with new data and human feedback

   • This transforms the system from “set and forget” to “continuously learning”

Episode Highlights & Timestamps

• 02:05-06:45 - Irena’s introduction and icebreaker questions (reveals her passion for data quality)

• 06:54 - The problem revealed: office kitchen demand forecasting

• 10:00-15:00 - Initial problem exploration and constraints discussion

• 15:00-30:00 - Reflection break (both participants brainstorm independently)

• 30:00-42:50 - Collaborative problem-solving: uncovering the data quality issue

• 42:50-49:00 - Refining insights and action items

Show Notes & Visual Assets

Diagrams & Visual Resources

Figma Brainstorming Board: https://www.figma.com/board/jfC4ipNvd8zSPIyZreEten/Irena-Bojarovska?node-id=1-14&t=Q46O2Ae9yuRHZRwy-1

This board contains the visual collaboration created during the brainstorming session, including:

• Three-layer data flow architecture (Input → Processing → Output)

• Feature expansion map (attendance patterns, special events, product characteristics)

• Human-AI collaboration workflow

• Feedback loop visualization

Episode Links & Resources

Guest Information:

• LinkedIn: https://www.linkedin.com/in/irenabojarovska/

• Role: Data Scientist at Zalando SE

• Specialization: Time series forecasting, demand forecasting, causal inference, A/B testing automation

Get Involved:

• Submit your problem: https://data-breakthroughs-podcast.cookingdata.blog/submit-problem

• Become a guest: https://data-breakthroughs-podcast.cookingdata.blog/become-guest

• Use #DataBreakthrough on social media to share your solutions

Episode Transcript:

• Full transcript available on Spotify, Apple Podcasts, and podcast platforms

• PDF transcript available through the Wabi-Sabi Data newsletter

Resources & Concepts Mentioned

• Time Series Forecasting: The mathematical foundation for demand prediction across multiple dimensions

• Reconciliation Problem: When forecasting at different aggregation levels (total vegetables vs. individual items), predictions can be inconsistent, a real issue in hierarchical forecasting

• Human-in-the-Loop Systems: The hybrid approach of using AI as a recommendation engine rather than a replacement for human judgment

• A/B Testing for ML: Comparing model performance against baseline or alternative approaches using real-world metrics

• Data Quality & Validation: The foundational practice of auditing and understanding input data before relying on model outputs

Continue the Conversation

Submit Your Data Problem

Do you have a data challenge you’d like us to tackle? Use our structured framework to submit: https://data-breakthroughs-podcast.cookingdata.blog/submit-problem

Become a Guest

Are you a data practitioner interested in collaborative real-time problem-solving? Apply to join us: https://data-breakthroughs-podcast.cookingdata.blog/become-guest

Share Your Alternative Solution

Did this episode spark a different approach? Share it with the community:

• Use #DataBreakthrough on LinkedIn, Twitter, or social media

• Reply to this newsletter with your ideas

Implementation Follow-Up

If you implement any of these solutions, we’d love to hear about your results! Reach out for a potential follow-up mini-episode or feature in our “Implementation Results” series.

About Data Breakthroughs

Data Breakthroughs brings together data practitioners to solve real operational challenges through collaborative, real-time problem-solving. Each episode features authentic, unscripted brainstorming sessions where the host and guest encounter a new problem for the first time and work through it collaboratively, without predetermined answers or scripts. The goal isn’t to deliver consulting advice, it’s to demonstrate how experienced practitioners think through complex data problems.

Host: Lior Barak

Credits

Host & Producer: Lior Barak
Guest: Irena Bojarovska, Applied Scientist at Zalando SE
Music: “Calisson” courtesy of Riverside

Accessibility

Episode Transcript: Available on all major podcast platforms
Visual Diagram: Will be shared on LinkedIn and in the Wabi-Sabi Data newsletter
Audio Descriptions: Included during the episode for all visual concepts

Disclaimer

This podcast is for inspiration and educational purposes. The solutions and approaches discussed are general frameworks intended to spark ideas and collaborative thinking. Always adapt recommendations to your specific organizational context, constraints, technical environment, and requirements. The goal is to explore how experienced practitioners approach data challenges together, not to provide definitive consulting advice. Your mileage may vary based on your specific situation.

Have feedback on this episode or suggestions for future topics? Reply to this newsletter or reach out on social media.

Follow-up Topics for Future Episodes:

• Sustainability solutions for food waste beyond forecasting

• Hierarchical forecasting and reconciliation challenges

• Building production-ready ML systems with limited resources

• Human-AI collaboration frameworks in operations

Episode 8 of Data Breakthroughs | Runtime 50 minutes

You have great products, deep industry expertise, and rich customer data. But your competitors are tech giants with unlimited engineering budgets, advanced AI systems, and scale. How do you compete when you can’t match their algorithms? In this episode, Jon Cooke and host Lior Barak tackle the classic small business nightmare: competing against AI-powered giants when you have limited resources. They discover how smart data strategy and focused customer intelligence can level the playing field, proving that sometimes you don’t need to out-engineer the competition—you need to out-think them.This episode is different. It’s a well-defined problem with clear constraints. No hand-waving about “becoming data-driven.” Just: We sell seeds, we have data, competitors are eating our lunch with recommendations, and help.

Problem Category: Data Strategy & Customer Analytics
Runtime: 36 minutes

The Problem

Submitted by: Anonymous (German Seed Company)
Industry Context: E-commerce, B2C, competing against Kiepenkerl and international players like Thompson & Morgan

Problem Framework

• Issue: Small online seed company competing against giants. Their advantage has always been personal expertise and horticultural knowledge, but losing customers to competitors who seem to know exactly what customers want before they do. Have 4 years of detailed customer data, but no idea how to turn it into a competitive advantage.

• Situation:

  • Sell 600+ varieties of seeds (vegetables, herbs, flowers) to German gardeners

  • Customers range from balcony hobby gardeners to serious organic farmers

  • Track everything: purchase history, seasonal patterns, regional preferences, and even weather data from customer locations

  • The founder has 30 years of gardening expertise

  • Still recommending products manually

  • Team of just 7 people

• Trigger: Last month, a customer complained that they recommended tomato seeds in December (seasonal nonsense) while the competitor’s website automatically suggested indoor microgreens and winter planning guides. Realized big players use algorithms to personalize experience, while they’re stuck sending generic newsletters to everyone.

• Tension:

  • Conversion rate: 2.1% (very low)

  • Passionate about helping people grow better gardens

  • Incredible domain knowledge and detailed customer data

  • Small team with no data science or engineering expertise

  • Can’t compete with automated personalization

  • Customers expect Amazon-level smart recommendations

  • Falling behind despite having better products and expertise

• Boundaries:

  • Small team: Just 7 people keeping the website running

  • No big data or engineering team

  • Limited technical expertise

  • Limited budget (can’t build massive AI infrastructure)

• Tech Stack: Not specified (implied: basic e-commerce platform, email marketing, website)

• Clarity Statement: “Automate recommendations through targeted personalization to increase conversion using existing data as a base.”

Our Guest

Jon Cooke
CEO, Nebulyx AI | CTO & Founder, Dataception Ltd

Jon is the CEO of Nebulyx AI (launched August 2025), an AI Digital Twin platform that lets enterprises preview their AI-native future before investing. He’s also CTO and Founder of Dataception Ltd, where he created the A.D.O.P.T. framework (AI, Data Object Graphs, and Product Thinking) and the Data Product Pyramid process.

What makes Jon unique: He spent 20 years watching 95% of AI projects fail, so he built a platform where companies can see what they’re building before they build it. His approach: Preview your AI-native business in hours using AI Digital Twins, Agent APE (AI Process Engineer), and Agent DOG (Data Object Graph builder) - test every scenario, prove ROI, all risk-free.

Connect with Jon:

• Dataception: https://dataception.com

• LinkedIn: https://www.linkedin.com/in/jon-cooke-096bb0/

The Core Insight: This Is a Well-Trodden Path (Which Is Good News)

Jon’s immediate reaction: “This for me is a well-trodden path. It’s something that a lot of people do. It’s a nice problem space and a fairly well understood problem space.”

Translation: You don’t need to invent anything. Customer segmentation → journey mapping → simple recommendation engine is solved territory. The challenge isn’t innovation - it’s execution within your constraints.

The Customer-First Approach (Jon’s Method)

Phase 1: Understand Customer Segmentation

Start with personas, not data:

• Who are your customers? (Window box gardeners vs. large garden owners vs. organic farmers)

• What are their buying patterns?

• What types of seeds work for their conditions?

• What are their knowledge levels? (Novice vs. experienced)

This is workshop territory. Get the team together. Get the founder’s 30-year expertise out of their head and onto paper.

Phase 2: Map Customer Journeys

Simple journey examples:

• Existing gardener wants to add new plants

• A new gardener wants ideas for starting

• Seasonal gardener planning next season

• Problem solver (pests, soil issues, etc.)

Map what seeds/products each journey needs. This is where institutional knowledge gets captured.

Phase 3: Create Knowledge Base

Doesn’t have to be sophisticated:

• Could start as an Excel spreadsheet

• Map customer segments → product recommendations

• Include pricing dimensions (recommend profitable products)

• Incorporate seasonal appropriateness

• Add weather/regional considerations

Phase 4: Build Simple Recommendation Engine (Quick Win)

Jon: “You could probably build the first incarnation of the model in like half a day.”

Not talking about sophisticated deep learning:

• Simple machine learning (random forest or similar)

• Based on purchase history + segment + season

• Test with friendly customers per persona

• Continuous learning as more data comes in

• Retrain weekly or daily (well-understood process)

Phase 5: Longer-Term Enhancements

• Personalized website experience (not just Amazon shopfront)

• Journey-based buying flow

• Community features (upload pictures, share successes)

• Gamification (plant competitions)

• Social sharing

The Data-First Approach (Lior’s Method)

Quick Learning Hack:

Ask ChatGPT or Gemini: “This is my problem, these are my data points. What model would work best?”

Not bulletproof, but it gets you learning fast. Tests well for understanding approaches without investing in data scientists first.

Key Caveat (Jon’s warning): “I wouldn’t recommend doing that. You need someone in the business who understands the models.”

But as a quick education tool? Valuable. Just don’t deploy without expertise.

The Phased Approach:

1. Get data into one place - Establish a single source of truth

2. Set a workshop for segmentation - Map out customer types with the team

3. Operate the model and start learning - Fail fast, figure out what works

4. Don’t kill manual work completely - Some customers might still get manual newsletters

Critical Addition: Hire a consultant to support

Even part-time. Someone who can:

• Set up the technical infrastructure

• Configure CRM properly

• Understand when to push emails

• Help test and validate models

• Bring domain knowledge about recommendations

The Convergence: Both Approaches Agree

Three Shared Principles:

1. Understand customers first, technology second

   • Segmentation before models

   • Journeys before algorithms

   • Business process before tooling

2. Data quality dictates approach

   • Good data → machine learning models

   • Poor data → heuristic rules and SME knowledge

   • Either way, you can still solve it

3. Simple models beat no models

   • Conversion rate is 2.1% - ANY improvement helps

   • Don’t need world-class data scientists

   • Need someone who understands the basics

   • Half-day to build the first version

Visual Diagram

Key Takeaways

3 Critical Insights

1. Understand Your Customers and Their Segments - This Is Fundamental: Regardless of what you do with AI or recommendations, truly understanding your customer segments is intrinsic to the business. You have SME knowledge (30 years of gardening expertise), but it’s trapped in people’s heads. Get it out. Map the personas, buying patterns, and journeys. This creates value even before you touch ML models.

2. Data Quality Dictates Your Approach (But Doesn’t Stop You): If data quality is excellent → machine learning path. If data quality is poor → heuristic/rules-based path using SME knowledge. Either way, you’re not stuck. Bad data changes your approach, doesn’t kill the initiative. You can still personalize, still recommend, still compete.

3. This Is a Long Learning Process: If the team isn’t comfortable with recommendation engines or the idea of AI-driven personalization, it will fail. This is change management as much as technology. Models drift over time. You’ll need continuous refinement. But this is core to the business now - understanding customers through data isn’t optional anymore.

3 Action Items

For the German seed company (and similar small businesses):

1. Week 1: Workshop - Map Customer Segments and Journeys - Get founder + team in the room. Map out customer types (balcony gardener, serious farmer, etc.). Document buying patterns. Create simple journeys. Capture the 30-year expertise in a structured format. This is non-technical but foundational. Test assumptions with a few friendly customers.

2. Week 2-3: Assess Data Quality and Consolidate - Get all data into one place (purchase history, seasonal patterns, regional data, weather if useful). Understand what you have vs. what you need. Determine: Machine learning path or heuristic path? Either works, just need clarity. Consider hiring a part-time CRM/technical consultant to help structure this properly.

3. Week 4-8: Build and Test Simple Recommendation Engine - Start with the simplest model that works (could be built in half a day per Jon). Test with friendly customers from each persona. Measure conversion improvement. Don’t kill manual newsletters yet - run parallel. Learn what works, iterate weekly. You don’t need perfection - you need 2.2% conversion instead of 2.1%.

Episode Highlights

• 02:23 - “AI secretly judges our data sets” - Jon on statistical judgment

• 03:08 - Jon’s creative data fixing: Visualize the entire business process

• 04:19 - Are dashboards judges or tools?

• 05:27 - Problem reveal: “Kiepenkerl” pronunciation challenge

• 06:01 - “Fantastic problem statement”

• 08:14 - Jon: “This is a well-trodden path, which is good.”

• 11:04 - Clarity statement: Automate recommendations through targeted personalization

• 13:07 - Jon’s brainstorming: Customer journey framework

• 17:13 - Lior: “We’re more or less the same way of thinking”

• 19:18 - The ChatGPT model selection hack (and why Jon disagrees)

• 20:13 - “You could build the model in half a day.”

• 22:16 - Conversion rate so low, any improvement helps

• 24:47 - Three insights and actions emerge

• 30:19 - Jon: “Data quality dictates the whole approach”

• 32:48 - “Did we get a breakthrough?” - Yes.

• 34:28 - Jon’s final wisdom: Business process problem, not AI problem

What I Learned from Jon

As the host, here are three insights from working with Jon that shifted my thinking:

1. The “Well-Trodden Path” Reframe

When Jon saw the problem, his first reaction was relief: “This is a well-trodden path. It’s a fairly well-understood problem space.”

I’ve trained myself to look for novelty, unique angles, and creative solutions. Jon’s instinct? Recognize the pattern and apply known solutions.

This isn’t a lack of creativity - it’s wisdom. Small businesses don’t need bleeding-edge innovation. They need tested approaches executed well within their constraints.

The recommendation engine problem is solved. Customer segmentation → journey mapping → simple ML model is documented, debugged, and battle-tested. Why reinvent? Just implement.

2. The Visualization-First Thinking Style

Jon said something that made me stop: “I think in pictures. I’m not one of these people who can stare at a data set and start seeing the matrix. I need to visualize stuff.”

Then he described his tool: “We use AI to visualize the entire business process around the data. Build almost like a digital twin of the business process.”

This flips the typical approach. Most people start with data, try to understand it, and then maybe visualize. Jon starts by visualizing the business process, then maps data to it.

It’s like he builds the container (the business process) first, then pours the data into it - not the other way around.

3. The Half-Day Model Reality Check

“You could probably build the first incarnation of the model in like half a day.”

This contradicted everything I’d internalized about ML being complex, requiring specialists, and taking months.

Jon’s point: The MODEL is easy. Random forest for recommendations? Half a day of coding.

The WORK is the data. Understanding it, cleaning it, mapping it to segments, and validating it with journeys. That’s weeks or months.

We fetishize the algorithm and ignore the data work. Jon does the opposite.

Bonus Observation: Jon’s consistency about “business process problem with AI tooling” (not “AI problem with business process considerations”) wasn’t just rhetorical. He genuinely thinks process-first. When I started sketching tech solutions, he pulled back to journeys and personas. That discipline - staying at the business layer until it’s crystal clear - is rare and valuable.

Resources Mentioned

• Dataception: Jon’s consultancy and product for visualizing business processes with AI

• Digital Twins: Concept of creating a virtual representation of business processes

• Random Forest Models: A Simple machine learning approach for recommendations

• Customer Journey Mapping: Workshop-based approach to understanding buying patterns

• Figma: Collaborative whiteboarding tool used during brainstorming

Continue the Conversation

Submit Your Data Problem

Have a challenge you’d like us to tackle? Use our structured framework:
https://data-breakthroughs-podcast.cookingdata.blog/submit-problem

We love specific, detailed problems like this one! Include your constraints, team size, and what you’ve tried.

Become a Guest

Data practitioner interested in collaborative problem-solving? Apply here:
https://data-breakthroughs-podcast.cookingdata.blog/become-guest

Share Your Alternative Solution

Did this episode spark a different approach? Share it with the community:

• Use #DataBreakthrough on social media

• Reply to this newsletter

What Would YOU Do?

We’d love to hear from listeners who have:

• Built recommendation engines for small businesses

• Implemented customer segmentation in resource-constrained environments

• Competed against larger players with AI/ML capabilities

• Captured institutional knowledge and automated it

How did you balance sophistication with simplicity?

About Data Breakthroughs

Data Breakthroughs brings together data practitioners to solve real operational challenges through collaborative problem-solving. Each episode features authentic, unscripted brainstorming sessions where the host and guest encounter problems for the first time during recording, creating practical, implementable solutions.

Credits

Host & Producer: Lior Barak
Guest: Jon Cooke
Music: “Calisson” courtesy of Riverside
Visual Content: Figma collaboration board

Accessibility

Episode Transcript: Full transcript available above
Visual Diagrams: Figma board link provided; all visual content described verbally during episode

Disclaimer

This podcast is for inspiration and educational purposes. The solutions and approaches discussed are general frameworks meant to spark ideas and collaboration. Always adapt recommendations to your specific organizational context, constraints, and requirements. The goal is to have fun while exploring data challenges together!

Connect with Jon Cooke:

• 🌐 Website:

https://dataception.com

• 💼 LinkedIn

• 🏢 Company: Dataception - Data & AI Consultancy

• 📍 Based in Totnes, UK

• 🎯 Expertise: Data products, GenAI, knowledge graphs, business process optimization

Your deep learning loan approval model is performing beautifully—23% accuracy improvement, predictions in minutes instead of days. Business leadership is thrilled. But then your team discovers a problem: the model systematically discriminates against certain zip codes, and it can’t explain why. Legal sees a potential lawsuit. Regulators are breathing down your neck. In this episode, Elizabeth Press and host Lior Barak tackle one of AI’s most critical and controversial challenges: building high-performance models that are explainable, ethical, and legally defensible. This is where data science meets compliance, bias meets business risk, and perfect metrics collide with impossible choices.This episode is different. We’re navigating the intersection of AI performance, ethical responsibility, legal compliance, and business pressure. And we’re doing it without being lawyers or ethicists - just data practitioners trying to solve an impossible problem.

Problem Category: Machine Learning & AI Implementation / AI Ethics
Runtime: 36 minutes

⚠️ CRITICAL DISCLAIMER: Neither Lior nor Elizabeth is are lawyer. This episode discusses AI bias, discrimination, and compliance from a technical and operational perspective only. Any organization facing similar challenges MUST consult with legal counsel specializing in AI regulation, discrimination law, and their specific jurisdiction’s requirements (EU AI Act, US regulations, etc.). These are high-stakes issues with severe legal consequences.

The Problem

Submitted by: Anonymous (Financial Services)
Industry Context: Lending/Credit approval, likely consumer finance

Problem Framework

• Issue: The AI loan approval model appears to systematically deny qualified applicants in certain zip codes at higher rates. Cannot explain individual decisions. Facing severe discrimination liability and regulatory risk.

• Trigger: Six months ago, implemented an advanced deep learning model for loan approval. Results were phenomenal:

  • Improved accuracy by 23%

  • Reduced processing time from days to minutes

  • Better risk assessments

  • Improved customer experience (for those approved)

  During a routine audit, the legal team discovered qualified applicants from certain zip codes being denied at rates 40% higher than similar applicants from other areas. When asked to explain specific decisions, the data science team said the deep learning model is essentially a black box that can’t explain individual predictions.

• Tension:

  • Facing impossible choice: Maintain a highly accurate AI system and accept legal/regulatory risks, OR revert to slower, less accurate traditional methods that can be explained

  • Regulatory pressure increasing

  • May face discrimination lawsuits

  • Business loves AI results but doesn’t understand compliance implications

  • Competitive advantage at stake

• Boundaries:

  • Cannot eliminate AI (competitive advantage)

  • Must maintain current processing speed and customer experience

  • Regulatory examination scheduled in 12 weeks

  • Budget exists for a compliance solution, but not a complete system rebuilding

  • Need to balance AI innovation with legal requirements

• Tech Stack: Deep learning model (type unspecified), loan approval system

• Clarity Statement: “Solve the ability of the data science team to explain decisions while acknowledging that ethics and legal compliance are intertwined but beyond our expertise as non-lawyers.”

Our Guest

Elizabeth Press
Founder, D3M Labs | Deputy Chief Digital Officer, CHESCO

Elizabeth is the founder of D3M Labs, a media platform dedicated to profitable and secure digital business. Before that, she was a data leader, and currently serves as Deputy Chief Digital Officer at CHESCO (Center for Hybrid Electric Systems at Brandenburg Technical University) - a research facility focused on hybrid electric drives for aerospace.

What makes Elizabeth unique: She bridges worlds that rarely connect - academic research, industrial applications, startup pragmatism, and government funding programs. Her background in financial risk management gives her rare credibility on this specific topic: she’s actually built credit rating models before.

Background:

• Current: Deputy Chief Digital Officer at CHESCO

  • Focus on secure digital twins and digital threads

  • Research on AR/VR and the mobility sector transformation

  • Emphasis on cybersecurity in digital factories

• Founder: D3M Labs media platform

  • Profitable and secure digital business focus

  • YouTube channel and LinkedIn presence

• Educator: Taught “Profitable AI” at Hasso Plattner Institute

  • 5,000+ students learned how to make money from AI

  • “Most AI initiatives lose money” perspective

• Former: Data leader and financial risk management experience

  • Built credit rating models

  • Understands the ethical implications firsthand

• Based in: Berlin, Germany

Philosophy: “AI is not sentient. AI is just a magnifier of the society we live in. You need to be cognizant when you have a use case that is critical to somebody’s life that AI is imperfect.”

Connect with Elizabeth:

• D3M Labs LinkedIn

• YouTube: D3M Labs channel

• Personal LinkedIn

• Focus areas: Digital twins, cybersecurity, profitable AI, secure digital business

The Solution

The Core Insight: Not All Use Cases Should Use Unexplainable AI

Both Elizabeth and Lior converged on a fundamental principle that challenges current AI hype: For high-stakes decisions affecting people’s lives (loans, justice, healthcare), you should never use a model you cannot explain.

This isn’t about capability. It’s about responsibility.

The “Back to Basics” Statistical Approach

Why Deep Learning Was Wrong for This Use Case

Elizabeth, drawing from her financial risk management background:

“I think that there’s an issue that this is a very complicated use case that should not be using an AI that you can’t explain. If you’re using an AI, you can’t explain to determine if somebody gets money or not that they might need for whatever, you’re not doing yourself, society, or that person any favor in any way.”

The Statistical Alternative: Logistic Regression & Explainable Models

Traditional statistical techniques that risk management has developed over the decades:

• Logistic regression for credit rating

• Clear, explainable variables

• Understanding multicollinearity

• Identifying confounding variables

• Statistical rigor over AI sexiness

The math might be “boring,” but it’s explainable. And in high-stakes scenarios, explainability isn’t optional - it’s the entire point.

The Hybrid Human-in-Loop System

Quick Win: Immediate Implementation (Weeks 1-4)

1. Hybrid Model Architecture:

   • AI makes an initial assessment

   • Rejected applications automatically escalate to human review

   • Human makes final decisions with AI recommendations as input

   • Decision gets logged with explanation

2. Model Confidence Scoring:

   • Don’t just output “approve/reject”

   • Output confidence level: “85% confident in rejection”

   • Low confidence (< 70%) → automatic human escalation

   • Creates structure beyond gut feeling

3. Decision Logging:

   • Document WHY each decision was made

   • Reference specific criteria used

   • Create an audit trail for regulatory review

   • Enable pattern analysis over time

The Cross-Functional Involvement Strategy

Critical Success Factor: Legal from Day One

Elizabeth’s strongest point:

“Get your legal team, your PR team, your marketing team in there. Get as many experts as possible and get their feedback on the modeling process. They might not know all the math, but get them challenging your assumptions, telling you what your constraints are, so it’s programmed in. Do this throughout the entire process. Do NOT do this retroactively because retrofitting a model for legal is just really painful.”

Who Needs to Be in the Room:

• Data scientists (obviously)

• Legal counsel (compliance experts)

• PR/Marketing (reputational risk)

• Domain experts (understand lending)

• Customer support (hears complaints)

• Executive sponsor (has authority to enforce)

When They Need to Be Involved:

• Before model design begins

• During feature selection

• During the testing phase

• Before production deployment

• During regular audits

The Quality & Bias Control Process

1. Control for Biases in Data Collection

Question every assumption:

• Why are we collecting THIS data?

• What assumptions are embedded in our data sources?

• Are there unconscious biases in how we’ve framed the problem?

• Have we tested for confounding variables?

2. Regular Bias Audits (Non-Judgmental)

Make bias checks part of normal quality practice:

• Not political witch hunts

• Part of regular operational reviews

• Like checking for model drift

• Document findings and corrections

3. Back-Testing Against Known Biases

• Run historical decisions through new logic

• Test with and without zip code data

• Identify which features actually drive discrimination

• May discover the “usual suspect” isn’t the real culprit

The Testing & Validation Framework

Create Test Boxes for Domain Experts

Don’t wait for data scientists to enable testing:

• Business users need scenario testing capability

• “What if we remove the zip code?”

• “What if we adjust the income threshold?”

• See results immediately

• Give feedback without a technical barrier

Validate Statistical Models Regularly

From Lior’s Zalando experience:

• Confidence scores next to every recommendation

• The team could override when confidence was low

• Transparency about uncertainty

• Regular validation against outcomes

The 12-Week Regulatory Response Plan

Week 1-2: Immediate Risk Mitigation

• Implement a hybrid human review for all rejections

• Begin decision logging for audit trail

• Assemble a cross-functional crisis team

Week 3-6: Root Cause Analysis

• Test with/without zip code data

• Identify actual discriminatory features

• Document statistical biases

• Prepare an explanation for regulators

Week 7-10: Remediation Implementation

• Rebuild model with explainable techniques (logistic regression)

• Implement confidence scoring

• Create escalation procedures

• Test thoroughly with diverse scenarios

Week 11-12: Regulatory Preparation

• Document the entire process

• Prepare explanations for past decisions

• Show corrective actions taken

• Demonstrate an ongoing monitoring plan

Visual Diagram

Key Takeaways

3 Critical Insights

1. Ethics Are Complicated, But With Sensitive Models They Must Be Considered: You can’t hide behind “I’m not an ethicist.” When your model affects people’s access to capital, housing, healthcare, or justice, ethical considerations are non-negotiable. The EU AI Act classifies these as high-risk use cases for a reason. Even if you’re not equipped to solve all ethical dimensions, you must acknowledge they exist and consult experts who are.

2. You Must Be Able to Explain Your Model - Without It, You Run Into Catastrophic Risks: This isn’t about satisfying curious stakeholders. It’s about legal liability, regulatory compliance, and basic fairness. If you can’t explain why Person A got approved and Person B (with similar qualifications) got rejected, you’re building discrimination into your systems, whether you intend to or not. Explainability isn’t a nice-to-have - it’s a legal and ethical requirement.

3. It’s Not the Speed of the Process, It’s How Accurate It Is: The business celebrated going from days to minutes. But what good is speed if the decisions are discriminatory? If your “improved accuracy” is actually improved discrimination? True accuracy includes fairness, explainability, and long-term defensibility. Sometimes the right answer is to slow down and do it correctly.

4 Action Items

For organizations facing AI bias/explainability challenges:

1. Weeks 1-2: Implement Hybrid Human-Review System Immediately - Stop allowing the black box model to make final decisions alone. Rejected applications escalate to human review. Humans make a final decision with AI as a recommendation input. This buys you time and creates a defensible process for regulatory examination. Log every decision with an explanation.

2. Weeks 1-4: Create Cross-Functional Crisis Team (Legal, PR, Data Science, Domain Experts) - Don’t let data scientists solve this alone in their cave. Get legal counsel involved immediately. Include PR (reputational risk), domain experts (understand lending), and an executive sponsor (authority to enforce changes). Make this team meet weekly until the crisis is resolved.

3. Weeks 3-6: Build Test Boxes for Domain Validation - Create an environment where business users can test scenarios without data scientist involvement. “What happens if we remove the zip code?” “What if we adjust the income threshold?” Enable domain experts to validate and challenge assumptions. Their expertise matters more than your math when it comes to discrimination.

4. Weeks 4-12: Rebuild with Explainable Statistical Models (Logistic Regression, Not Deep Learning) - Go back to basics. Use traditional statistical techniques that credit risk management has perfected over decades. Yes, it’s less sexy than deep learning. But you can explain it, audit it, and defend it. For high-stakes decisions, boring and explainable beats cutting-edge and mysterious.

Episode Highlights

• 04:25 - Elizabeth’s initial reaction: “This is a Pandora’s box”

• 07:55 - “The banality of evil” in credit rating models

• 09:20 - “AI is just a magnifier of the society we live in”

• 11:07 - “To what point do you actually need an actual human to make the final decision?”

• 13:47 - Elizabeth: “This is a very complicated use case that should not be using an AI you can’t explain.”

• 15:56 - “Let’s get back to the basics and look at math.”

• 18:53 - “Don’t use a black box model for such a thing”

• 24:32 - “We both believe in good statistics”

• 26:40 - “Tie your AI to strategy - know WHY you’re using it”

• 28:40 - “Bias is quantifiable through business metrics”

• 32:22 - “Legal nightmares happen because people don’t talk to lawyers BEFORE they do something”

• 34:29 - Final wisdom: “The tools need to fit the problem. AI doesn’t fix everything.”

What I Learned from Elizabeth

As the host, here are three powerful insights from working with Elizabeth on this impossible problem:

1. The “Banality of Evil” in Algorithms

Elizabeth referenced Hannah Arendt when discussing her past work on credit rating models: “We talked about the banality of evil.”

This stopped me cold. We’re not talking about villains deliberately building discriminatory systems. We’re talking about well-intentioned data scientists optimizing for accuracy metrics without considering the human cost of their “improvements.”

The evil isn’t in malice - it’s in thoughtlessness. In treating bias as a technical problem instead of an ethical one. In celebrating 23% accuracy improvement without asking “accurate at what? For whom? At what cost?”

Elizabeth’s background in financial risk management gave her the moral clarity to say what many of us think but hesitate to voice: Some use cases shouldn’t use unexplainable AI. Period.

2. Cross-Functional Isn’t Optional - It’s Life or Death

“Get your legal team, PR team, and marketing team involved. Not retroactively. Throughout the entire process.”

Watching Elizabeth frame it in the context of loan discrimination made it visceral.

Retrofitting a model for legal compliance isn’t just “painful” - it’s potentially catastrophic. By the time legal sees the black box model, you’ve already:

• Made thousands of discriminatory decisions

• Created an audit trail of bias

• Exposed your company to lawsuits

• Damaged your reputation

• Possibly ruined people’s lives

Legal involvement from Day One isn’t bureaucracy. It’s moral responsibility disguised as risk management.

3. Statistics Isn’t Boring - It’s Accountable

Elizabeth kept returning to “boring” statistical fundamentals: logistic regression, controlling for multicollinearity, and understanding confounding variables.

As someone who loves cutting-edge AI, I initially bristled. But she’s absolutely right.

Deep learning optimizes for patterns. Statistics forces you to understand causation. With logistic regression, you can point to specific factors and say, “This is why.” With deep learning, you shrug and say, “The neural network thinks so.”

In high-stakes scenarios, “the neural network thinks so” is legally indefensible and morally bankrupt.

Sometimes, the most advanced solution is knowing when NOT to use advanced technology.

Bonus Observation: Elizabeth’s work spanning startup pragmatism, academic research, and government programs gives her a rare perspective. She’s seen how AI hype plays out in reality. Her skepticism isn’t cynicism - it’s earned wisdom. When she says “most AI initiatives lose money,” she’s not being pessimistic. She’s being accurate.

Resources Mentioned

• EU AI Act: Regulatory framework classifying AI use cases by risk level

• Credit Rating Statistical Techniques: Logistic regression, multicollinearity analysis, and confounding variable identification

• D3M Labs: Elizabeth’s media platform on profitable and secure digital business

• Hasso Plattner Institute: Where Elizabeth taught “Profitable AI” course (5,000+ students)

• Digital Twins & Digital Threads: Elizabeth’s current research focus at CHESCO

• Figma: Collaborative whiteboarding tool used during brainstorming

Continue the Conversation

Submit Your Data Problem

Have a challenge you’d like us to tackle? Use our structured framework:
https://data-breakthroughs-podcast.cookingdata.blog/submit-problem

⚠️ For AI bias/ethics problems: Please include comprehensive context about potential harms, affected populations, and existing safeguards. These problems require extra care and expertise.

Become a Guest

Data practitioner interested in collaborative problem-solving? Apply here:
https://data-breakthroughs-podcast.cookingdata.blog/become-guest

Share Your Alternative Solution

Did this episode spark a different approach? Share it with the community:

• Use #DataBreakthrough on social media

• Reply to this newsletter

What Would YOU Do?

We’d love to hear from listeners who have:

• Navigated AI bias in production systems

• Implemented explainable AI for high-stakes decisions

• Worked with legal teams on AI compliance

• Rebuilt black box models with explainable alternatives

• Faced regulatory examination for AI systems

Critical: If sharing experiences, please anonymize sensitive details and consult your legal team before discussing specifics.

About Data Breakthroughs

Data Breakthroughs brings together data practitioners to solve real operational challenges through collaborative problem-solving. Each episode features authentic, unscripted brainstorming sessions where the host and guest encounter problems for the first time during recording, creating practical, implementable solutions.

Host: Lior Barak - VP/Head of Data | Data Strategy & Transformation Leader

Credits

Host & Producer: Lior Barak
Guest: Elizabeth Press
Music: “Calisson” courtesy of Riverside
Visual Content: Figma collaboration board

Accessibility

Episode Transcript: Full transcript available above
Visual Diagrams: Figma board link provided; all visual content described verbally during episode

Extended Legal & Ethical Disclaimer

This podcast is for educational and inspirational purposes ONLY. Neither the host nor the guest are lawyers, ethicist, or a regulatory compliance expert. The discussion represents personal opinions and general technical approaches - NOT legal advice.

AI bias, discrimination, and regulatory compliance are complex legal matters with severe consequences. Organizations facing similar challenges MUST:

• Consult qualified legal counsel specializing in AI regulation

• Understand jurisdiction-specific requirements (EU AI Act, US regulations, etc.)

• Conduct proper impact assessments before deployment

• Implement appropriate safeguards and monitoring

• Take full responsibility for their AI systems’ impacts

The goal is to have important conversations about AI ethics and responsibility. Always seek professional guidance for implementation.

Connect with Elizabeth Press:

• 📺 LinkedIn/YouTube: D3M Labs channel | D3M Labs channel

• 💼 LinkedIn: Elizabeth’s profile

• 🏢 Current: Deputy Chief Digital Officer at CHESCO

• 🎓 Educator: Hasso Plattner Institute - Profitable AI course

• 📍 Based in Berlin, Germany

Every department in your company defines “most valuable customer” differently. Sales prioritizes deal size, Support focuses on customer success scores, and Product values feature adoption rates. The result? The same customer gets treated as both VIP and basic-tier depending on which team they interact with—creating confusion, frustration, and missed revenue opportunities. In this episode, David Cohen and host Lior Barak tackle this organizational alignment nightmare head-on, discovering the root causes and building a practical framework for creating unified customer definitions across your entire company.This episode is different. We’re not debugging code or fixing data pipelines. We’re solving the messy human problem underneath the metrics.

Problem Category: Organizational Data Strategy
Runtime: 32 minutes

The Problem

Submitted by: Anonymous
Industry Context: Company with multiple departments (Sales, Support, Product, Marketing)

Problem Framework

• Issue: Every department in the company defines “most valuable customer” differently, making it impossible to create a coherent strategy or provide a consistent customer experience.

• Trigger: Launched a new VIP customer experience program last quarter. It turned into chaos. The same customers could be treated as high-value by sales (big contract) while getting basic support (low engagement score) and irrelevant marketing (different segment). Customers started complaining about inconsistent treatment.

• Tension:

  • Each department insists its customer view is correct for their function

  • Need one authoritative definition to guide the company's strategy

  • Every stakeholder meeting devolves into arguments about whose metrics matter most

  • Providing a confusing, fragmented experience to customers who don’t understand why treatment varies by team

• Current State:

  • Sales ranks by revenue

  • Support ranks by engagement frequency

  • Product ranks by feature usage

  • Marketing has its own segmentation based on campaign responses

• Boundaries: No master data management or unified customer scoring exists

• Tech Stack: Salesforce, Zendesk, product analytics platform, email marketing tools

• Clarity Statement: “Overcome the human problem of indecision in defining what value looks like and who in our customer base gets the most of it.”

Our Guest

David Cohen
Founder | Superposition

David runs a consulting firm that builds strategy workshops to help other consultancies in the data and AI spaces be more effective. He specializes in discovery processes for complicated and ambiguous client-facing projects, as well as internal growth needs for consultancies.

What makes David unique: He treats organizational alignment problems the way a workshop designer thinks - creating settings where ego can surface safely, conflicts can be resolved productively, and consensus can emerge from structured activities.

Background:

• Founder of Superposition consulting firm

• Specializes in strategy workshops for data/AI consultancies

• Expert in discovery processes for ambiguous projects

• Deep experience with stakeholder alignment challenges

• Long-time consultant and self-described “data nerd”

Philosophy: “This is actually a people problem and an ego problem rather than a technology or data one. The primary challenge is that we have an organization that does not agree on what value means.”

Connect with David:

• Website: https://www.superpositionstrat.com/

• LinkedIn: https://www.linkedin.com/in/davcohen06/

The Solution

The Core Insight: You Need Therapy, Not Dashboards

Both David and Lior independently arrived at the same conclusion during their 15-minute brainstorm: This is an ego problem disguised as a metrics problem.

The departments aren’t confused about data. They’re protecting territory, defending their worldview, and fighting for organizational influence. No amount of data warehousing will fix that.

The Workshop-Based Alignment Process

Phase 1: Bring Everyone Together (Physically)

• Create a dedicated event or series of sessions

• In-person preferred (virtual as backup)

• Representatives from each pillar: Sales, Support, Product, Marketing, and any others

• Designate a leadership advocate with decision-making power

• Consider retaining external facilitator to provide unbiased perspective

Phase 2: Structure for Open Sharing

• Create a setting where people can openly share concerns

• Allow teams to express why their definition is “right”

• Let people complain freely in a controlled space

• Focus on logic, not debate club tactics

• Use “yes, and” building rather than defensive arguing

Phase 3: Define Value (Not Metrics)

• Don’t jump to building anything yet

• Start at the highest level: What does it mean to provide value to a customer?

• Create a shared glossary of terms

• Define what a VIP customer persona looks like (like defining an ICP)

• Acknowledge that value to the customer ≠ is profitable to the company (potential wrinkle)

Phase 4: Discard Before You Add

• Define which metrics DON’T matter (easier than agreeing on which do)

• Narrow the working area by elimination

• Run the same 3 customers through each department’s current definition

• Make the problem visible: Show how different the results are

Phase 5: Force the Conflict Productively

• Use the process to short-circuit the disconnect

• Each team selects a representative to defend their position

• Stack-rank existing customers to surface disagreements

• Designated leader has a tiebreaker vote (counts as double/triple)

• A leader can supersede loud voices and give time to quieter teams

Phase 6: Build the Unified Definition

• Create one persona of what a VIP customer is

• Allow teams to bring their data sources to the table

• Build a composite formula that incorporates multiple perspectives

• Review definitions with executives for sign-off

• Document what “valuable customer” means company-wide

Phase 7: Implementation

• Build dashboards and reports based on agreed metrics

• Create an implementation plan to roll out the new customer experience

• Establish consistent treatment across all touchpoints

• Measure the success of the unified approach

Critical Success Factors

1. Leadership Buy-In is Non-Negotiable. Without a leader who can make final decisions, this process never ends. You need someone with:

• Tiebreaker vote authority

• Power to supersede loud voices

• Ability to give time to teams that don’t naturally speak up

• Executive backing to enforce the decision

2. Consider External Facilitation. Why consultants exist for this type of work:

• Unbiased third party with no territorial stake

• Can “be the bad guy,” so internal leaders don’t have to

• Expertise in facilitating difficult conversations

• No emotional attachment to any department’s metrics

• Acts as an organizational therapist

3. Assume Resistance (Because It’s Real) One assumption David made: At least one department won’t want to participate. This is realistic. The process must account for:

• Political dynamics

• Ego protection

• Fear of losing influence

• Concern about “wrong” metrics winning

Visual Diagram

Key Takeaways

3 Critical Insights

1. This is an Ego Problem, Not a Data Problem: The departments aren’t confused about metrics - they’re protecting territory and defending worldviews. Sales doesn’t actually think engagement frequency is wrong; they just don’t want Support’s definition to override theirs. You’re not solving for understanding the valuable customer. You’re solving for misalignment within your team. Treat it accordingly.

2. Leadership Buy-In Determines Success or Failure: Without leadership mandate and a designated decision-maker, any efforts to solve this problem will inevitably fail. You need someone who can break ties, settle disputes, and enforce the final decision. Otherwise, you’ll cycle through endless stakeholder meetings that go nowhere.

3. Internal Definitions Can Differ - Customer-Facing Ones Cannot: It’s actually fine if Sales, Support, Product, and Marketing measure success differently internally for their own optimization. The problem is when those different definitions create inconsistent customer experiences. You need a united front when it touches customers, even if internal reporting varies.

4 Action Items

For the next 90 days:

1. Week 1-2: Set Up the Alignment Event(s) - Bring everybody together, preferably in person. Schedule dedicated time (potentially a full week) for working sessions. Identify which teams need representation beyond Sales/Support/Product/Marketing (HR? Customer Success? Finance?). Designate a leadership advocate who will serve as decision-maker and facilitator.

2. Week 1-2: Decide on External Support - Evaluate whether to retain an outside consultant or facilitator to manage the process. Consider: Do you have someone internal who can be unbiased? Can your leader afford to “be the bad guy”? Is there enough trust for self-facilitation? External help speeds the process and protects internal relationships.

3. Week 3-4: Run the Same 3 Customers Through Different Definitions - Make the problem visceral and visible. Show numerically how differently each department would treat the same customers. This activity surfaces the chaos in a way that’s hard to argue with. Use it early in sessions to build urgency for alignment.

4. Week 4-12: Conduct the Alignment Sessions - Use structured workshop activities (see GameStorming book reference) to:

   • Define shared language and glossary

   • Build a unified customer value definition

   • Create VIP customer persona

   • Stack-rank existing customers using the new definition

   • Document metrics and data sources

   • Build an implementation roadmap

Episode Highlights

• 01:41 - “DO NOT TOUCH FINAL FINAL” - The universal file naming disaster

• 03:04 - Bad data tastes like unflavored cornflakes

• 07:02 - Clarity emerges: Defining what value means

• 08:25 - Critical assumption: Leadership buy-in exists (or doesn’t)

• 14:54 - The leader needs a tiebreaker vote power

• 20:18 - “This is literally what I do on a daily”

• 21:36 - Why leaders don’t want to be “the bad person”

• 22:39 - Consultants as organizational therapists

• 24:30 - The breakthrough: It’s okay to have different definitions internally

• 29:31 - Who else needs to be in the room?

What I Learned from David

As the host, here are three insights from working with David that shifted how I think about organizational data problems:

1. The Consultant-as-Therapist Reframe

David said something that made me pause: “You need somebody outside of that framework to be able to decide. You need to get a therapist.”

I’ve always thought of consultants as bringing expertise or capacity. David reframed it completely: Sometimes you need someone whose only job is to say the hard thing without worrying about next week’s team dynamics.

Leadership often doesn’t want to make these decisions because they don’t want to be “the bad person.” They’d rather hire an external who can take the heat, make the call, and leave. That’s not weakness - it’s smart relationship management.

2. Workshop Design is Strategic Thinking

Watching David think through this problem was like watching a game designer create levels. He wasn’t just planning what to discuss - he was architecting the settings where certain conversations could happen.

“Create a setting where people can openly share their concerns.” That’s intentional space design.

“Structure it so people can complain freely.” That’s psychological safety architecture.

“The leader needs power to supersede loud voices and give time to quiet teams.” That’s power dynamics engineering.

This isn’t facilitation tips - it’s understanding that the container shapes the outcome.

3. Discard Before You Add

“Define which metrics DON’T matter - that’s more important than defining which do.”

This flipped my approach. I always start with “What should we measure?” David starts with “What can we agree to stop measuring?”

It’s easier to build consensus around what to eliminate than what to prioritize. Once you’ve narrowed the field, choosing from what remains is manageable. But if you start by trying to pick winners, everyone defends their favorite metrics forever.

Bonus Observation: David immediately recognized this as his daily work (”This is literally what I do”). But instead of going into autopilot consultant mode, he stayed genuinely curious about the nuances. The mark of real expertise: Seeing a familiar problem and still finding it interesting.

Resources Mentioned

• GameStorming by Dave Gray, Sunni Brown, and James Macanufo: David’s recommendation for workshop activities and design thinking approaches. Manual for different scenarios and outcomes you can achieve through structured activities.

• Workshop Design Principles: Creating settings for open sharing, productive conflict, and forced consensus

• Superposition: David’s consulting firm focused on strategy workshops for data/AI consultancies

• Figma: Collaborative whiteboarding tool used during the brainstorming session

Continue the Conversation

Submit Your Data Problem

Have a challenge you’d like us to tackle? Use our structured framework:
https://data-breakthroughs-podcast.cookingdata.blog/submit-problem

Become a Guest

Data practitioner interested in collaborative problem-solving? Apply here:
https://data-breakthroughs-podcast.cookingdata.blog/become-guest

Share Your Alternative Solution

Did this episode spark a different approach? Share it with the community:

• Use #DataBreakthrough on social media

• Reply to this newsletter

What Would YOU Do?

We’d love to hear from listeners who have:

• Successfully aligned departments on shared metrics

• Run customer value definition workshops

• Navigated organizational politics around data definitions

• Brought in external facilitators for alignment work

How did you handle the ego dynamics? Share your experiences!

About Data Breakthroughs

Data Breakthroughs brings together data practitioners to solve real operational challenges through collaborative problem-solving. Each episode features authentic, unscripted brainstorming sessions where the host and guest encounter problems for the first time during recording, creating practical, implementable solutions.

Host: Lior Barak - VP/Head of Data | Data Strategy & Transformation Leader

Credits

Host & Producer: Lior Barak
Guest: David Cohen
Music: “Calisson” courtesy of Riverside
Visual Content: Figma collaboration board

Accessibility

Episode Transcript: Full transcript available above
Visual Diagrams: Figma board link provided; all visual content described verbally during episode

Disclaimer

This podcast is for inspiration and educational purposes. The solutions and approaches discussed are general frameworks meant to spark ideas and collaboration. Always adapt recommendations to your specific organizational context, constraints, and requirements. The goal is to have fun while exploring data challenges together!

Connect with David Cohen:

• 🌐 Website: https://www.superpositionstrat.com/

https://superposition.co

• 💼 LinkedIn: https://www.linkedin.com/in/davcohen06/

• 🏢 Company: Superposition - Strategy workshops for data & AI consultancies

Your high-performing machine learning model is stuck in Jupyter notebooks. Sales leadership desperately needs its churn predictions to save customer relationships, but your team can’t figure out how to get it into production. This is the “last mile” problem—every data team faces it, yet few know how to solve it efficiently. In this episode, Nick Zervoudis and host Lior Barak tackle this real challenge head-on, working through a practical churn prediction case and building a concrete 90-day roadmap for taking ML models from development to production.Problem Category: Machine Learning & AI Implementation
Runtime: 45 minutes
Recording Date: [Date]

The Problem

Submitted by: Maya (No family name or company 😞)
Industry Context: SaaS/Enterprise software with renewal-based revenue model

Problem Framework

• Issue: High-accuracy churn prediction ML model (87% accuracy, 60-day warning) exists but remains trapped in Jupyter notebooks, making it impossible for the sales team to act on predictions and prevent customer churn

• Trigger: Lost a major client that the model had flagged as high-risk six weeks earlier, but the sales team never received the alert due to a lack of systematic delivery from notebooks to Salesforce

• Tension:

  • Renewal rate targets aren’t improving despite significant AI investment

  • Sales reps feel they’re “flying blind” without the promised insights

  • CEO pressure on the data science team about ROI and business impact

  • Team credibility is at stake

• Boundaries:

  • The model itself works well (87% accuracy validated)

  • Data science team is capable - this isn’t about talent or training

  • Salesforce instance cannot be replaced

  • The sales team must stay in their primary Salesforce workflow

  • A budget exists for reasonable deployment solutions

• Tech Stack: Python ML model in Jupyter Notebooks, Salesforce CRM, AWS infrastructure

• Clarity Statement: “How can we enable our sales team to identify which customers are at risk of churning within their existing workflow?”

Our Guest

Nick Zervoudis
Data Product Management Consultant & Coach | Value from Data & AI

Nick helps data teams escape the reactive “service desk” trap and transition to value-creating data product organizations. After spending years bridging tech and business in data roles - from startups to consulting to corporate - he recently quit his Head of Product role at CKDelta (where he doubled annual revenue and achieved 5x ARR) to start Value from Data & AI.

Now he focuses on data product management training, consulting, and coaching, helping teams prove and maximize their ROI. Nick also co-hosts the “Data Product Management in Action” podcast, organizes Data & AI PM meetups in London and Barcelona, and was recently featured in Driven by Data Magazine with his article “From Order-Takers to Value Creators.”

Background:

• Former Head of Product (Data & AI) at CKDelta - achieved 2x annual revenue and 5x ARR

• Ex-PepsiCo Data Product Manager - built Store DNA platform that unlocked tens of millions in opportunities

• Strategic Advisor at Mindfuel

• MSc Management (Digital Business) from Imperial Business School

• Based in Barcelona, Spain

Connect with Nick:

• Blog:

Value from Data & AI

A newsletter about data & AI product management

By Nick Zervoudis

• Course - ROI of Data & AI: https://maven.com/nick-zervoudis/dpm-value-course

• LinkedIn: https://www.linkedin.com/in/nzervoudis/

• Youtube channel:

• Co-host: Data Product Management in Action podcast

The Solution

Phased 90-Day Deployment Strategy

Phase 1: Days 1-30 - Validate & Test

• Generate model predictions daily (CSV export from notebooks)

• Implement human validation by domain experts (sales managers)

• Begin acting on results to validate both the model AND the playbook

• Critical Go/No-Go decision at Day 30: Is this actually helping?

Phase 2: Days 31-60 - Refine & Scale

• Incorporate feedback and learnings into the model

• Continue acting on evolved predictions

• Implement AWS automation for daily runs

• Embed dashboards with results

• Set up Slack/email alerts as an intermediate delivery mechanism

• Cost and revenue validation checkpoint

Phase 3: Days 61-90 - Production Integration

• Build Salesforce API integration

• Create custom views for the sales team workflow

• Implement feedback loops

• Final ROI assessment (clear, measurable success criteria)

Visual Diagram

Key Takeaways

3 Critical Insights

1. The Checklist Blind Spot: Even experienced practitioners forget crucial stakeholders. Both Nick and Lior initially missed legal/GDPR compliance, IT security approvals, and Salesforce integration gatekeepers. Always run a standard checklist: IT access, privacy/legal compliance, data permissions, integration processes, security reviews.

2. Success Metrics Must Be Defined Upfront: An 87% accurate model means nothing without clarity on business impact. What does success look like? Preventing one major client loss? Hitting specific renewal targets? Reducing churn by X%? The metrics conversation needs to happen before deployment, not after.

3. Perfect is the Enemy of Good (and Fast): Waiting to build the perfect Salesforce integration while customers churn is malpractice. Export the CSV today. Send it manually. Let the sales team start learning. Quick wins build momentum and validate assumptions before investing in full automation.

4 Action Items

For Maya (and others facing similar ML deployment challenges):

1. Week 1: Run 30-Minute Mini-Workshop with Maya - Clarify success metrics, understand sales team workflow, validate assumptions about playbook effectiveness, and ensure alignment on what “breakthrough” means for this project

2. Week 1: Export Data ASAP - Don’t wait for perfect infrastructure. Generate CSV predictions and get them to sales team leaders immediately. Start the learning process today, not in 60 days.

3. Week 2: Understand Salesforce Integration Process - Meet with IT, Salesforce admins, and security teams to map the approval process, timeline, and requirements. This could be a 2-week or 6-month journey - find out early.

4. Week 2-4: Meet with End Users - Shadow sales reps, understand their actual workflow (not what Maya thinks it is), run mockups by them, and identify 2-3 champion users for initial pilot testing

Episode Highlights

• 03:00 - The “food truck vs. grandma’s dish” philosophy of data products

• 07:35 - Problem reveal and the shocking client loss trigger

• 14:13 - Crafting the clarity statement and debating scope

• 18:13 - The 15-minute solo brainstorm begins

• 20:48 - Nick’s “oh s%#%” moment: forgetting success metrics despite emphasizing their importance

• 25:29 - Lior’s phased architecture with built-in kill switches

• 30:27 - The GDPR revelation: “We completely forgot about legal!”

• 40:01 - Final verdict: Breakthrough achieved (with caveats)

What I Learned from Nick

As the host, I want to share three key insights from working through this problem with Nick that completely shifted my perspective:

1. The Art of Intentional Problem Understanding
Nick demonstrated something powerful: the discipline to pause before solving. He articulated how our brains naturally race toward solutions, but the real skill is channeling that energy into a deeper exploration of the problem first. This conscious approach transforms how you engage with challenges - instead of fighting your instinct to solve, you redirect it toward understanding.

2. Quick Wins Are Strategic Intelligence, Not Shortcuts
Nick brilliantly reframed what I initially thought was a temporary workaround. Sending that CSV isn’t settling for less - it’s strategic intelligence gathering. You’re validating assumptions, proving value, and learning how users actually work before investing heavily in infrastructure. This isn’t just pragmatic; it’s smart product thinking. The “quick win” becomes your reconnaissance mission.

3. The Strategic Checklist Mindset
Here’s what I loved about Nick’s approach to checklists: use them as guardrails for the essentials (legal, IT, security), but treat them as a foundation, not a ceiling. The checklist catches what you might miss in the complexity of the moment - it’s your safety net that frees you up to think more creatively about the unique aspects of each problem. It’s liberating, not limiting.

Bonus Insight: One of the most valuable moments was watching Nick, a data product management expert, catch himself forgetting about success metrics mid-brainstorm. Rather than being a weakness, it showed the power of systems and frameworks. Even masters need structure to maintain focus on what matters. It’s a reminder that expertise isn’t about being perfect; it’s about having the right tools to catch and correct yourself.

Resources Mentioned

• Figma: Collaborative whiteboarding tool used during the brainstorming session

• Value from Data and AI: Nick’s blog on data product management -

Value from Data & AI

A newsletter about data & AI product management

By Nick Zervoudis

• Maven Course: “ROI of Data & AI: How to demonstrate & maximise your impact” - https://maven.com/nick-zervoudis/dpm-value-course

• Data Product Management in Action: Podcast co-hosted by Nick:

Continue the Conversation

Submit Your Data Problem

Have a challenge you’d like us to tackle? Use our structured framework to submit it

Become a Guest

Data practitioner interested in collaborative problem-solving? Apply here

Share Your Alternative Solution

Did this episode spark a different approach? Share it with the community:

• Use #DataBreakthrough on social media

• Reply to this newsletter

What Would YOU Do?

We’d love to hear from listeners who have:

• Successfully deployed ML models to production

• Navigated Salesforce integrations

• Built churn prediction systems

• Solved the “last mile” problem

Share your experiences and alternative approaches!

About Data Breakthroughs

Data Breakthroughs brings together data practitioners to solve real operational challenges through collaborative problem-solving. Each episode features authentic, unscripted brainstorming sessions where the host and guest encounter problems for the first time during recording, creating practical, implementable solutions.

Host: Lior Barak

Credits

Host & Producer: Lior Barak
Guest: Nick Zervoudis
Music: “Calisson” courtesy of Riverside
Visual Content: Figma collaboration board

Accessibility

Episode Transcript: Full transcript available above
Visual Diagrams: Figma board link provided; all visual content described verbally during episode

Disclaimer

This podcast is for inspiration and educational purposes. The solutions and approaches discussed are general frameworks meant to spark ideas and collaboration. Always adapt recommendations to your specific organizational context, constraints, and requirements. The goal is to have fun while exploring data challenges together!

Have feedback on this format or suggestions for future episodes? Reply to this newsletter or reach out on social media using #DataBreakthrough

Quick Listener Survey

Help us improve! Three quick questions:

1. What was your biggest takeaway from this episode?

2. Would you have approached Maya’s problem differently?

3. What data challenges would you like us to tackle next?

Reply with your answers or share on LinkedIn with #DataBreakthrough

Connect with Nick Zervoudis:

• 📝 Blog:

Value from Data & AI

A newsletter about data & AI product management

By Nick Zervoudis

• 🎓 Course: https://maven.com/nick-zervoudis/dpm-value-course

• 💼 LinkedIn: https://www.linkedin.com/in/nzervoudis/

Your organization empowered teams with self-service BI tools to democratize data access. But now you’re facing dashboard chaos: 300+ dashboards created in 6 months, nobody knows which numbers to trust, and teams are paralyzed choosing between conflicting metrics. What started as democratizing data became a governance nightmare. In this episode, Christian Klug and host Lior Barak tackle this real challenge head-on, discovering why self-service BI governance matters and building practical strategies for bringing order to dashboard proliferation.Problem Category: Business Intelligence & Dashboarding
Runtime: 38 minutes

The Problem

Submitted by: Christian (creative/gaming studio)
Industry Context: 75-person creative studio, rapid growth phase

Problem Framework

• Issue: The self-service BI tool has over 300 dashboards and reports. Nobody can tell which ones are official, current, or trustworthy. Teams are paralyzed by choice, wasting hours hunting for reliable information - sometimes ending by creating another dashboard.

• Trigger: Last week, preparing for a board meeting, Christian needed the standard monthly sales performance report. He found 37 different dashboards with similar names created by different people over the past six months. After spending three hours trying to figure out which was correct, a colleague questioned the chosen numbers because they were using a “different version.”

• Tension:

  • The team is afraid to use any dashboard because they might be wrong

  • Creating new dashboards just adds to the chaos

  • Spending more time debating which report to trust than actually analyzing data

  • Decision-making has slowed to a crawl

  • Team is losing confidence in the entire BI investment

  • Reverting to manual spreadsheets (the thing they tried to escape!)

• Situation: Two years ago, they had a controlled BI environment with ~15 dashboards that the data team created and managed. Everyone knew which reports to use for different decisions. Then the company grew, needs changed, and they rolled out self-service capabilities - empowering anyone to create and publish their own dashboards and analysis.

• Boundaries: No explicit boundaries mentioned (part of the problem!)

• Tech Stack: Tableau with self-service publishing enabled, PostgreSQL, Excel

• Clarity Statement: “Create a governance process to decide which dashboards should be official, focusing on core ‘Boss KPIs’ that everyone can trust.”

Our Guest

Christian Klug
Director Data Analytics | BestSecret Group

Christian is a data leader with over 7 years of experience empowering people and organizations through continuous learning and data-driven decision-making. He started as a data analyst and evolved into leadership roles, always focusing on uncovering insights by analyzing data and challenging assumptions. His philosophy: consistency is the cornerstone of excellence.

Background:

• Current: Director of Data Analytics at BestSecret Group (Dec 2022 - Present)

  • Leads a 7-person Data Analysts team

  • Owns BI platform (Looker)

  • Developed the company’s Data Strategy

  • Implemented Team Topologies principles for organizational restructuring

  • Established SLAs that significantly enhanced decision-making speed

• Former: Team Lead, Inventory Intelligence at idealo internet GmbH (5+ years)

  • Led cross-functional data team (Analysts + Engineers)

  • Transformed from an analytical team to a data product creator

  • Member of B2B Senior Leadership Team

• Educator: Dozent at SRH Berlin School of Design and Communication

  • Teaches Business Intelligence and Data Science courses

  • Integrates theory with hands-on exercises

• Education: MSc Physics from Freie Universität Berlin (Grade: 1.5)

• Based in: Berlin, Germany

• Fun fact: Drummer in Berlin punk band Cruor Hilla (new album dropping fall 2025!)

Philosophy: “As a data leader, I thrive on empowering people through a culture of continuous learning. I achieve success by focusing holistically on systems, embracing full ownership, and leveraging incremental yet impactful adjustments.”

Connect with Christian:

• LinkedIn: https://www.linkedin.com/in/christian-klug-83529a103/

• Band Instagram: https://www.instagram.com/cruorhilla/

• Spotify (Band):

The Solution

The Three-Layer Data Architecture

Layer 1: Raw Data Layer (Restricted Access)

• Only data engineers have access

• All source data “as is”

• Technical processing only

• No direct business user access to prevent misinterpretation

Layer 2: Staging Layer (Restricted Access)

• Data engineers and select data analysts only

• Pre-processing and transformations

• Data quality checks

• Not for general consumption

Layer 3: Analytics Layer (Controlled Access)

• Data analysts and data stewards

• Business-ready datasets

• Proper context and documentation

• Foundation for official dashboards

Layer 4: “Boss KPI” Layer (Read Access for All, Write Restricted)

• Decision-maker facing layer

• Only approved, signed-off metrics

• The deployment process required for changes

• Slower to change, but protected and trustworthy

• “Cool name for gaming studio” - makes it clear this is serious business

The Cultural Reset Process

1. Listen First, Challenge Later: Identify with stakeholders what data they actually need for daily decisions. Accept their KPIs as-is initially to rebuild trust. You can refine later.

2. Define True Sources: Establish the single source of truth for each KPI. No more debate about which conversion formula is “correct.”

3. Identify Data Owners: Make people accountable for data that affects board-level KPIs. Create awareness that changes have high stakes.

4. Create Official Folder Structure:

   • Dedicated “Official” folder in Tableau (read-only for most)

   • Team-level folders for exploration

   • Move existing dashboards into team folders

   • Sandbox/testing area for changes before production

5. Establish Deployment Process: Changes to official dashboards require discussion, agreement, and sign-off. Protect the Boss KPI layer from surprises.

6. Enforce the Narrative: Use official dashboards in every team meeting, studio meeting, and all-hands. Make the numbers omnipresent and undeniable.

Visual Diagram

Key Takeaways

3 Critical Insights

1. Trust is Everything: Without trust in data, your entire BI investment delivers zero value. People revert to Excel, waste hours debating numbers, and decision-making grinds to a halt. Rebuilding trust isn’t just technical - it’s about relationships with stakeholders, consistent processes, and making people feel protected by governance, not restricted.

2. Freedom Without Boundaries = Chaos: Self-service BI sounds empowering, but without structure, it creates paralysis. When everyone can create everything, nobody knows what to trust. The promise of “democratizing data” becomes the reality of “data anarchy.” Boundaries aren’t limitations - they’re the framework that makes freedom productive.

3. Avoid Clutter at All Costs: More isn’t better. More dashboards = more confusion = more questions = less action. This applies to visualizations too - the more you show, the further you get from the decision. Curate ruthlessly. Protect your users from noise.

4 Action Items

For the creative studio (and others facing BI chaos):

1. Week 1: Define Core “Boss KPIs” - Run a workshop with key stakeholders. Listen to what data they actually need for daily decisions. Accept their definitions initially (you can refine later). Get everyone in the room talking. Document the true sources for each KPI. This is non-negotiable - you can’t win without this step.

2. Week 1-2: Pick Dashboards You Trust, Mark as Official - Quick win alert! Out of the 300 dashboards, identify the 15-20 that are actually correct and useful. Move them to an “Official” folder with restricted write access. Make it visually clear that these are different. Move all other dashboards into team-specific folders. Don’t delete anything yet - just organize.

3. Week 2-4: Use Official Dashboards Religiously - Enforce the narrative. Use ONLY official dashboards in every management meeting, team sync, all-hands presentation. When someone brings different numbers, point them to the official source. Make the official dashboards so omnipresent that using anything else feels wrong.

4. Month 2-3: Govern Access and Deployment - Implement the layered architecture. Restrict who can access raw data. Create a deployment process for changes to official dashboards (discussion → agreement → sign-off). Establish dashboard lifecycle management (how do we add/change/remove?). Build this into culture, not just process docs.

Episode Highlights

• 02:06 - “Super burnt meat” - Christian’s perfect metaphor for bad data

• 06:11 - The sad truth: It worked when it was curated and governed

• 09:35 - “Data is the new oil” promise vs. reality

• 16:37 - The “Boss KPI” layer concept emerges

• 22:15 - Phoenix Project reference: Handwritten deployment notes that fixed everything

• 23:03 - The notebook punishment story: Making people calculate KPIs by hand

• 29:44 - When people lose access to data, Excel returns

• 34:25 - “Nobody likes internal politics, but it’s there” - The emotion and data connection

What I Learned from Christian

As the host, here are three powerful insights from working with Christian on this problem:

1. The “Listen First, Challenge Later” Wisdom
Christian’s approach to rebuilding trust was brilliant: accept stakeholders’ KPIs as-is initially, even if you know they could be improved. Why? Because challenging from the start makes people defensive and stalls momentum. Get the quick win first (trusted dashboards), then use that trust capital to refine definitions later. It’s product management 101 applied to data governance.

2. Gaming Theory Meets Data Strategy
I loved Christian’s Age of Empires reference: “First, you need to go through the dark age. That’s just part of it.” You can’t fix everything at once. There’s an early game (stop the bleeding with official dashboards) and a late game (proper governance architecture). Many data leaders fail because they try to implement the late-game solution during the crisis. Christian gets the phasing right.

3. Emotions Are Data
This might be the most profound point of the episode: “Emotions are not just emotions, they’re information. Information is essentially data.” When someone is emotionally attached to their dashboard, that’s not irrational; it’s a signal. They’ve invested time, built something useful (to them), and now feel threatened. Ignoring this “data” guarantees your governance initiative fails. Christian’s awareness of the human side of data work is what separates good technical leaders from great data leaders.

Bonus Observation: Christian’s background in physics shows in how he thinks about systems. He doesn’t just solve the immediate problem (which dashboards to trust?), he designs the system that prevents the problem from recurring (layered architecture with controlled access). That’s rare thinking in data leadership.

Resources Mentioned

• Rick Rubin - The Creative Act: A book Christian recommends for creative professionals and data leaders alike. 100 short chapters that make you think differently about clarity and craft.

• Cole Nussbaumer Knaflic - Storytelling with Data: Christian’s top recommendation for anyone communicating with data. Teaches how to hit the spot and build meaningful relationships through data storytelling.

• The Phoenix Project: Reference to the scene where handwritten deployment notes slow down chaos and force intentionality - directly applicable to dashboard governance.

• Figma: Collaborative whiteboarding tool used during the brainstorming session

• Age of Empires: Not a data tool, but a surprisingly good metaphor for phased strategy implementation!

Continue the Conversation

Submit Your Data Problem

Have a challenge you’d like us to tackle? Use our structured framework to submit it

Become a Guest

Data practitioner interested in collaborative problem-solving? Apply here

Share Your Alternative Solution

Did this episode spark a different approach? Share it with the community:

• Use #DataBreakthrough on social media

• Reply to this newsletter

What Would YOU Do?

We’d love to hear from listeners who have:

• Tamed self-service BI chaos

• Implemented successful dashboard governance

• Rebuilt trust in data after a crisis

• Created effective “official” KPI frameworks

How did you handle the emotional side when restricting access? Share your experiences!

About Data Breakthroughs

Data Breakthroughs brings together data practitioners to solve real operational challenges through collaborative problem-solving. Each episode features authentic, unscripted brainstorming sessions where the host and guest encounter problems for the first time during recording, creating practical, implementable solutions.

Host: Lior Barak

Credits

Host & Producer: Lior Barak
Guest: Christian Klug
Music: “Calisson” courtesy of Riverside
Visual Content: Figma collaboration board

Next Episode Preview

Episode 5 coming soon! We’re looking for challenges in Data Quality & Governance and Organizational Data Strategy. Submit your problem or nominate yourself as a guest.

Accessibility

Episode Transcript: Full transcript available above
Visual Diagrams: Figma board link provided; all visual content described verbally during episode

Disclaimer

This podcast is for inspiration and educational purposes. The solutions and approaches discussed are general frameworks meant to spark ideas and collaboration. Always adapt recommendations to your specific organizational context, constraints, and requirements. The goal is to have fun while exploring data challenges together!

Connect with Christian Klug:

• 💼 LinkedIn: https://www.linkedin.com/in/christian-klug-83529a103/

• 🎸 Band Instagram: https://www.instagram.com/cruorhilla/

• 🎵 Spotify:

• 📍 Based in Berlin, Germany

You’re drowning in data theory. Whitepapers, frameworks, and best practices—but nothing that solves the actual problems your team faces with data platforms. Most data podcasts celebrate success stories or dissect past wins. This one is different. Data Breakthroughs brings real practitioners together to solve problems in real-time. No scripts, no perfect answers—just genuine collaboration where teams work through challenges they’ve never encountered before and figure out solutions together. This season opener, hosted by Lior Barak, shows you exactly what makes this podcast a resource for solving your most pressing data platform challenges.

Episode Type: Season Introduction
Runtime: 5 minutes
Recording Date: September 2025

Why This Format Exists

The Personal Journey

Lior shares his experience as a frequent podcast guest and conference speaker, and the frustration of always discussing solutions after the fact. The realization that his "too pragmatic" approach - both a strength and limitation - meant missing the strategic thinking process that leads to breakthrough solutions.

The Missing Piece

Most data content focuses on tools and implementations: "Here's how we deployed Snowflake" or "Why we chose Python over R." But what's missing is the thinking process - how do experienced practitioners approach problems they've never encountered before?

The Collaborative Discovery

Instead of prepared presentations, Data Breakthroughs features genuine problem-solving sessions where host and guest work together to understand the challenge and develop solutions based on principles and capabilities, not specific tools.

What You'll Hear This Season

Real Breakthrough Moments

The episode features a clip from Artur Yatsenko (Director of Data Engineering at Urban Sports Club) demonstrating the collaborative discovery process - moving from technical debates to understanding business realities and the need to "deliver value quickly because business is impatient."

Focus on Principles

Rather than tool recommendations, episodes explore:

• How to understand problem spaces before jumping to solutions

• Strategic thinking processes of experienced practitioners

• Capability-based approaches that work across different tech stacks

• The synergy that emerges when different perspectives collide

Season Structure

Episode Release: New episodes every second week
Season Length: 10-11 episodes
Launch: Two episodes dropping simultaneously to kick off the season

Get Involved

Submit Your Problem

Have a data challenge that keeps you up at night? Something that can't be solved with a Google search or standard best practices? Submit your problem and it might be featured in a future episode.

Become a Guest

Data professionals interested in collaborative problem-solving on challenges they've never seen before - reach out to join a session.

Stay Connected

• Newsletter: Wabi-Sabi Data / Cooking Data Blog

• LinkedIn: Tag @Lior Barak for discussions

• Direct Messages: Open for conversations about problems, solutions, and future collaboration

About the Host

Lior Barak is a Senior Data Strategy Leader and author of "Data is Like a Plate of Hummus." Known for his pragmatic approach to data challenges, he created this podcast to learn from other practitioners' strategic thinking processes while solving real problems in real-time.

What's Next

Episodes 1 and 2 are available now, featuring collaborative problem-solving sessions that demonstrate the format in action. New episodes drop every second week.

Connect with the show: Your comments, problem submissions, and alternative solutions help shape future episodes.

Your marketing and sales teams report completely different customer numbers. This isn’t just a reporting issue—it’s a business problem that undermines decision-making and erodes trust between departments. When teams can’t agree on fundamental metrics, projects stall and opportunities slip away. In this episode, Philipp Loringhoven and host Lior Barak tackle real data discrepancy issues, discover the root causes of team misalignment, and build practical frameworks for resolving data conflicts that plague cross-functional organizations.Problem Category: Data Analysis & Reporting / Data Governance & Quality
Runtime: 43 minutes
Recording Date: December 2024

The Problem

Submitted by: Anonymous CPO
Industry Context: Small to mid-size B2B organization

Problem Framework

• Issue: Marketing and sales teams report completely different numbers for new customer acquisition metrics, leading to unproductive meetings focused on defending numbers rather than strategic planning

• Trigger: Joint leadership offsite where both teams presented conflicting KPIs publicly, making discrepancies impossible to ignore

• Tension: "I can't trust the data my own team gives me" - growing friction between teams, wasted time defending numbers instead of doing actual work, and inability to make strategic decisions

• Boundaries: Not about report design or slow systems - it's about having multiple conflicting truths for fundamental business metrics

• Tech Stack: Assumed three data sources - Product (backend), Marketing (tracking), Sales (CRM)

• Clarity Statement: "We need to establish a single source of truth for customer metrics so teams can focus on their jobs instead of arguing about whose numbers are correct"

Our Guest

Philipp Loringhoven
Freelance Marketing Analytics & Data Strategy Specialist

Philipp started his career in marketing before switching to data nearly a decade ago. Today, he helps companies make smarter marketing decisions by combining analytics, business intelligence, and customer insights. He's a frequent speaker at conferences, teaches at universities, and hosts the podcast DataEngage to make data more accessible for marketers and decision-makers.

Connect with Philipp:

• LinkedIn: Philipp Baron Freytag von Loringhoven

• Podcast: DataEngage (dataengage.io)

• Company: Team Advertico

The Solution

Data Flow Overview

The solution focuses on establishing clear definitions and ownership rather than technical fixes. Key components include creating a KPI definition library, implementing asynchronous alignment processes, and establishing a certified data layer that prevents non-verified metrics from reaching reporting systems.

Visual Diagram

Key Takeaways

3 Critical Insights

1. People First, Technology Second: 90% of data problems are communication problems. Most data quality issues occur because stakeholders haven't clearly communicated why specific data accuracy matters to their work.

2. Management Must Make Decisions: Small companies can't afford lengthy debates about metrics. Leadership needs to enforce central numbers and pick their battles wisely, sometimes simply declaring "this is our source of truth" to move forward.

3. Constrain to Scale: Small organizations should limit themselves to 5-8 core KPIs rather than trying to track everything. More metrics create more opportunities for discrepancies and confusion.

4 Action Items

For the Problem Submitter (and others facing similar challenges):

1. Enforce Central Numbers Tomorrow - Management should immediately declare one authoritative source for each core metric (e.g., "paying customers = backend system count") and communicate this across all teams.

2. Document 5-8 Core KPIs - Create a simple, accessible definition library for your most critical business metrics, including who owns each metric and how it's calculated.

3. Implement Asynchronous Feedback Collection - Before holding alignment meetings, have teams independently document their current metric definitions to identify discrepancies in advance and make meetings more productive.

4. Establish Certified Data Layer - Implement technical controls that prevent non-certified metrics from reaching reporting systems, reducing the ability for teams to create conflicting numbers.

Episode Highlights

• 05:22 - Defining the three assumed data sources and their conflicts

• 11:42 - Deep dive into customer journey mapping and definition challenges

• 19:13 - The revelation that "most data issues are communication issues"

• 28:29 - Collaborative development of key insights and actionable solutions

• 38:34 - Breakthrough assessment: Did we solve it or need more information?

Resources Mentioned

• Customer Journey Mapping: Framework for aligning team definitions of customer stages

• KPI Definition Libraries: Centralized documentation for metric definitions

• AI for Data Alignment: Using generative AI to help structure consistent metric definitions

• Certified Data Layers: Technical architecture to prevent conflicting data sources

Continue the Conversation

Submit Your Data Problem

Have a challenge you'd like us to tackle? Use our structured framework: https://forms.office.com/r/KUPaLPEZwM

Become a Guest

Data practitioner interested in collaborative problem-solving? Apply here: https://forms.office.com/r/Qy2riCHvT5

Share Your Alternative Solution

Did this episode spark a different approach? Share it with the community:

• Use #DataBreakthrough on social media

• Email us at podcast@wabisabidata.com

• Reply to this newsletter

Implementation Follow-up

If you implement this solution, we'd love to hear about your results! Reach out for a potential follow-up mini-episode.

About Data Breakthroughs

Data Breakthroughs brings together data practitioners to solve real operational challenges through collaborative problem-solving. Each episode features authentic, unscripted brainstorming sessions focused on creating practical, implementable solutions.

Host: Lior Barak - Founder of Cooking Data

Listen on:

• Spotify:

• Apple Podcasts:

Connect with the Show:

• Cooking Data Newsletter:

  Cooking Data guided by Lior

  “Cooking Data” is where I share lessons from helping organizations turn data from an afterthought into a product. Expect real frameworks, examples, and reflections as I shape my next book, with your input.

  By Lior Barak

• LinkedIn: https://www.linkedin.com/in/liorbarak/

• Website: https://datapearls.app

Credits

Host & Producer: Lior Barak
Guest: Philipp Loringhoven
Music: "Calisson" courtesy of Riverside

Accessibility

Episode Transcript: Available on all podcast platforms
Visual Diagrams: Audio descriptions provided during the episode for all visual content

Disclaimer

This podcast is for inspiration and educational purposes. The solutions and approaches discussed are general frameworks meant to spark ideas and collaboration. Always adapt recommendations to your specific organizational context, constraints, and requirements. The goal is to have fun while exploring data challenges together!

Data architecture conflicts are paralyzing your engineering team. Your CEO is backing data transformation. Budget is approved. But you’re stuck in a 6-month architectural debate: vendor-managed solution or build in-house infrastructure? Neither engineer is wrong. But both can’t be right. In this episode, Artur Yatsenko (Director of Data Engineering at Urban Sports Club) and Lior Barak explore decision-making frameworks that actually resolve these technical stalemates and get teams moving forward.Problem Category: Data Engineering & Infrastructure
Runtime: 43 minutes
Recording Date: September 2025

The Problem

Submitted by: Anonymous Product Owner
Industry Context: Technology company with CEO backing for data transformation

Problem Framework

• Situation: Product owner hired to build a data-driven culture with full CEO support and a clear budget for a modern data platform, expected to present results fast

• Issue: The Engineering team is locked in a 6-month architectural debate, preventing any delivery of analytics capabilities

• Trigger: Two lead engineers with conflicting visions - one wants full CI/CD automation with pristine long-term foundation, the other prefers rapid delivery with off-the-shelf tools

• Tension: Product owner caught between feuding technical leads and impatient CEO; zero shipped products, business operating without reliable data, team credibility at risk, department appears ineffective

• Boundaries: Not a resourcing problem or lack of business need - this is purely an internal technical strategy conflict blocking all delivery

• Tech Stack: Legacy system requiring migration, but specific tools are undefined due to ongoing debate

• Clarity Statement: Transform the data team from an "academic debate club" into a business partner that demonstrates value through delivery

Our Guest

Artur Yatsenko
Director of Data Engineering at Urban Sports Club

Artur is a data professional based in Berlin who's been on the city's data scene for more than a decade. Having previous work experience at Delivery Hero, Zalando, and now Urban Sports Club, Artur leads engineering, product analytics, and data science functions. He's passionate about customer insights, experimentation, and democratizing data access while maintaining governance.

Connect with Artur:

• LinkedIn: https://www.linkedin.com/in/arthuryatsenko/

• Visual collaboration board: https://www.figma.com/board/HwwB0V9O05WYZnpINLHCbA/Artur-Yatsenko

The Solution

Data Flow Overview

A graduated approach that starts with vendor-managed ingestion tools and data warehouse storage, followed by transformation layers and BI visualization. The architecture evolves incrementally based on user feedback and team learning, avoiding the paralysis of trying to build the perfect system from day one.

Visual Diagram

Key Takeaways

3 Critical Insights

1. People Problems Disguised as Technical Problems: What appears to be an architectural debate is actually about decision-making authority, team dynamics, and failure to prioritize business value over engineering preferences.

2. Customer-Centric Development Applies to Internal Tools: Data teams must validate solutions with business users early and often, rather than building elaborate systems based on assumptions about what stakeholders need.

3. The Hidden Cost of Perfectionism: Every day spent debating architecture has a measurable financial cost in delayed business decisions, missed opportunities, and eroding stakeholder confidence.

4 Action Items

For the Problem Submitter (and others facing similar challenges):

1. Force a Decision (Week 1) - Establish clear decision-making authority and set a firm deadline for architectural choices. Use external validation or committee review if needed to break the stalemate.

2. Implement Cost Visibility (Week 2) - Create a visible dashboard showing the daily cost of the delayed platform in terms of team time, blocked business initiatives, and lost productivity.

3. Execute a Solution Hackathon (Week 3-4) - Give each architectural approach 2 days to build a working prototype that solves a specific business problem. Compare practical results rather than theoretical benefits.

4. Launch Excel-to-Visualization MVP (Week 4-6) - Deliver immediate value with the simplest possible solution while the platform debate resolves. Export key business data to CSV/Excel and create basic visualizations to demonstrate team value.

Episode Highlights

• 05:30 - Problem reveal and initial reactions to the "academic debate club" characterization

• 15:20 - Artur shares Urban Sports Club's successful graduated platform approach

• 22:30 - Key breakthrough moment: recognizing this as a people problem, not a technology problem

• 30:45 - Solution framework discussion balancing short-term delivery with long-term architecture

• 38:50 - Action items and implementation roadmap

Resources Mentioned

• MVP Development Principles: Start simple, get user feedback, iterate based on real usage patterns

• Graduated Architecture Approach: Begin with vendor solutions, build internal expertise, then optimize custom components

• Decision-Making Frameworks: Time-boxed discussions with clear authority for final choices

• Cost Visualization Tools: Simple dashboards showing the daily cost of delayed decisions

Continue the Conversation

Submit Your Data Problem

Have a challenge you'd like us to tackle? Use our structured framework: https://forms.office.com/r/KUPaLPEZwM

Become a Guest

Data practitioner interested in collaborative problem-solving? Apply here: https://forms.office.com/r/Qy2riCHvT5

Share Your Alternative Solution

Did this episode spark a different approach? Share it with the community:

• Use #DataBreakthrough on social media

• Reply to this newsletter

Implementation Follow-up

If you implement this solution, we'd love to hear about your results! Reach out for a potential follow-up mini-episode.

About Data Breakthroughs

Data Breakthroughs brings together data practitioners to solve real operational challenges through collaborative problem-solving. Each episode features authentic, unscripted brainstorming sessions focused on creating practical, implementable solutions.

Host: Lior Barak - Data consultant and former analytics leader with experience scaling data teams at high-growth companies

Credits

Host & Producer: Lior Barak
Guest: Artur Yatsenko
Music: "Calisson" courtesy of Riverside
Visual Content: Collaborative Figma board created during the session

Accessibility

Episode Transcript: Auto-generated transcript available on all podcast platforms
Visual Diagrams: Audio descriptions provided during the episode for all visual content

Disclaimer

This podcast is for inspiration and educational purposes. The solutions and approaches discussed are general frameworks meant to spark ideas and collaboration. Always adapt recommendations to your specific organizational context, constraints, and requirements. The goal is to have fun while exploring data challenges together!

Have feedback on this format or suggestions for future episodes? Reply to this newsletter or reach out on social media.

Data pipeline failures are one of the most damaging problems in data operations. When your pipelines break, you lose data quality, miss critical business deadlines, and worst of all—you lose trust from the business teams relying on your data.

In this pilot episode, I talk with Ilya Vladimirskiy, a Fractional Data Leader with 15+ years of experience building data platforms at companies like Zalando, Ada Health, and Carfax Europe. We dive deep into the real-world challenge of preventing pipeline failures and explore the organizational, communication, and technical solutions that actually work.

The pilot episode of Data Breakthroughs features Ilya Vladimirskiy, a Fractional Data Leader with a proven track record of tackling complex data challenges. With over 15 years of experience, Ilya has led initiatives in Data Mesh implementation and built data platforms that drive effective decision-making at companies like Zalando, Ada Health, and Carfax Europe. His hands-on experience in scaling data teams and navigating diverse tech stacks (GCP, AWS, etc.) makes him an ideal guest to discuss practical solutions for preventing data pipeline breaks. If you're looking for real-world strategies from a data leader who's been in the trenches, you won't want to miss this episode!

We dove deep into the problem, sharing experiences and starting to brainstorm potential solutions. It was an insightful discussion, and it also helped me refine the podcast format to bring you even more value in future episodes.

What to expect in Data Breakthroughs going forward:

• Problem-First Focus: We'll tackle challenges directly from data consumers, ensuring our discussions address real-world business needs.

• Categorized Challenges: Episodes will be organized by domain (analytics, infrastructure, strategy) to align with guest expertise.

• Actionable Solutions: While exploring the problem is key, our main goal is to deliver practical takeaways you can implement.

• Balanced Discussions: As your host, I'll ensure a perfect blend of technical depth and business relevance within our 45-minute format.

• Diverse Perspectives: We'll embrace the many ways to solve data challenges – there's no one-size-fits-all!

This pilot episode is crucial in shaping Data Breakthroughs into a valuable resource for our community. And that's where you come in!

Core Data Concepts

• Data Pipeline: A set of processes that move data from one or more sources to a destination, often involving extraction, transformation, and loading (ETL).

• Schema: The structure of data, defining the types of data (e.g., text, numbers, dates) and their relationships within a dataset.

• Data Warehouse: A central repository for storing and analyzing large amounts of data, often used for business intelligence and reporting.

• Data Lake: A storage repository that holds a vast amount of raw data in its native format until it is needed.

• ETL (Extract, Transform, Load): A process used to move data from various sources into a data warehouse or other destination.

  • Extract: Reading data from various sources.

  • Transform: Converting data into a usable format.

  • Load: Writing the transformed data into the destination.

• Data Governance: The overall management of the availability, usability, integrity, and security of data in an enterprise.

• Data Contract: An agreement between data producers and consumers that defines the format, structure, and quality of data being exchanged.

• Data Mesh: A decentralized approach to data management that emphasizes domain ownership and self-service data infrastructure.

• API (Application Programming Interface): A set of rules and specifications that software programs can follow to communicate with each other.

• SLA (Service Level Agreement): A commitment between a service provider and a client that defines the level of service expected.

Roles and Teams

• Data Producer: An individual or team responsible for creating or generating data (e.g., software engineers, application developers).

• Data Consumer: An individual or team that uses data for analysis, reporting, or decision-making (e.g., data analysts, business users).

• Data Engineer: A professional who designs, builds, and maintains data pipelines and data infrastructure.

• Data Analyst: A professional who analyzes data to identify trends, patterns, and insights to support business decisions.

Systems and Technologies

• ERP (Enterprise Resource Planning): Business management software that integrates various functions like finance, HR, and supply chain management.

• BI (Business Intelligence): Technologies and strategies used to analyze business data and provide actionable insights.

• AWS (Amazon Web Services): A cloud computing platform offering various services, including data storage and processing.

• GCP (Google Cloud Platform): A suite of cloud computing services offered by Google.

• SQL (Structured Query Language): A programming language used to manage and manipulate relational databases.

Key Concepts from the Discussion

• Data-driven decision-making: Using data to inform business strategies and actions.

• Data-informed decision-making: Using data as one factor among others (e.g., experience, intuition) in making decisions.

• Observability: The ability to monitor and understand the internal state of a system based on its outputs.

• Schema validation: The process of ensuring that data conforms to a predefined schema or structure.

• Cross-functional teams: Teams comprising members from different functional areas (e.g., engineering, data, business).

I need your help to make Data Breakthroughs even better:

For Data Consumers: Are you struggling with a data challenge in your organization? Submit your problem to be featured on an upcoming episode of Data Breakthroughs! We're looking for real-world data challenges across:

• Data Analysis & Reporting

• Data Engineering & Infrastructure

• Data Governance & Quality

• Machine Learning & AI Implementation

• Organizational Data Strategy

• Business Intelligence & Dashboarding

• Real-time Data Processing

• Data Integration & ETL

🔗 Submit Your Data Challenge Here

For Data Professionals: Are you a data practitioner who enjoys solving complex problems? Join us as a guest on Data Breakthroughs to collaborate on solving real business challenges with data. We're looking for professionals with experience in:

• Data Leadership

• Data Engineering

• Data Science

• Analytics Engineering

• Data Architecture

• Data Product Management

🔗 Apply to Be a Guest

Why is this podcast so important today? In our increasingly data-driven world, the gap between those who produce data and those who consume it can lead to misunderstandings, inefficiencies, and ultimately, a lack of trust in the data itself. Data Breakthroughs aims to bridge this gap by fostering open conversations on practical solutions and real-world impact.

Thank you again to Ilya for being an amazing first guest!

Stay tuned for more updates, and mark your calendars: the first official episode of Data Breakthroughs drops on May 2nd!

Best,

Lior

🎯 Why Listen:
If you work in data engineering, analytics, or product, this episode gives you field-tested solutions for common data infrastructure problems.

🔗 Links Mentioned:

Ilya's LinkedIn: https://www.linkedin.com/in/bkmy43/

5X: https://www.5x.co/

Bruin: https://getbruin.com/

Data Mesh Manager: https://www.datamesh-manager.com/

Open standards for data contracts

--------

Whiteboard diagram from our episode

Connect & Contribute

Submit your data challenge

Apply to be a guest

Welcome to Data Breakthroughs

The Podcast That Solves Real Data Problems in Real Time

Are you struggling with data challenges that slow down your organization?

Data Breakthroughs brings together data practitioners to solve real-world operational challenges through better data practices. Each episode features experts tackling freshly submitted problems, providing practical solutions with clear action items that create immediate business value.

What Makes This Podcast Different

✅ Real Problems, Real Solutions - No theoretical discussions. We solve actual challenges submitted by professionals like you.

✅ Authentic Problem-Solving - Our experts encounter the problem for the first time during recording, giving you unfiltered access to their thought process.

✅ Actionable Takeaways - Every episode delivers a conceptual solution, key insights, and concrete steps you can implement immediately.

✅ Cross-Domain Expertise - From data infrastructure and governance to analysis and ML implementation, we cover the full spectrum of data challenges.

How It Works

1. Problem Reveal - Each episode starts with a fresh challenge submitted by a data consumer

2. Independent Brainstorming - Host and guest take 15 minutes to develop initial approaches

3. Collaborative Solution - Experts reconvene to create a comprehensive data solution

4. Implementation Roadmap - Every episode concludes with 4 concrete action items

Listen On

• Cooking Data Substack

• Spotify

• Apple Podcasts

• And everywhere you get your podcasts

New Episodes Every Two Weeks

For Data Consumers: Are you struggling with a data challenge in your organization? Submit your problem to be featured on an upcoming episode of Data Breakthroughs! We're looking for real-world data challenges across:

• Data Analysis & Reporting

• Data Engineering & Infrastructure

• Data Governance & Quality

• Machine Learning & AI Implementation

• Organizational Data Strategy

• Business Intelligence & Dashboarding

• Real-time Data Processing

• Data Integration & ETL

🔗 Submit Your Data Challenge Here

For Data Professionals: Are you a data practitioner who enjoys solving complex problems? Join us as a guest on Data Breakthroughs to collaborate on solving real business challenges with data. We're looking for professionals with experience in:

• Data Leadership

• Data Engineering

• Data Science

• Analytics Engineering

• Data Architecture

• Data Product Management

🔗 Apply to Be a Guest