

Data Breakthroughs: Solving Real-World Data Challenges
Lior Barak - Cooking Data
- 16
- Episodes
- Monthly
- Cadence
- 2025
- First episode
About Data Breakthroughs: Solving Real-World Data Challenges
A podcast where data experts solve real-world operational challenges submitted by listeners. Each episode tackles a fresh problem, delivering actionable solutions, key insights, and implementation steps to help data professionals overcome barriers and create business value. impactoperations.substack.com (https://impactoperations.substack.com/s/data-breakthroughs?utm_medium=podcast)
- Publisher
- Lior Barak - Cooking Data
- Category
- business · technology
- Language
- en
- Explicit
- No
- First episode
- 25 Apr 2025
- Latest episode
- 16 Sept 2026
Latest episodes
16 episodes in the feed.

16 Sept 2026
Forty Charts, No Decision
Data Breakthroughs · Season 2, Episode 2 Runtime: [[57]] minutes · Category: Data Analysis & Reporting A note before you start: this is one of the last episodes in this format — and I’m asking for your view on it below. Why this one is worth an hour There’s a version of this problem that’s about dashboards, and it’s the boring version. Somebody built the wrong report; build a better one. The version Timo found in the first five minutes of his brainstorm is different, and I didn’t see it coming. Nothing here is technically broken. The tracking works. The data exists. Three competent people produce exactly what was asked for, every two weeks, on time. And the output is a decision made on instinct anyway. What’s actually broken, in his words, is that “mentally they’re in a bad place”— and that no fix laid on top of that frustration will survive it. That reframe changed the whole session. What follows is where we got to. The problem, as submitted Category: Data Analysis & Reporting. Submitted by: Anonymous. Context: B2C wellness app, Series A, ~250,000 monthly users. Three-person data team. Issue — Every two weeks, before sprint planning, the PM asks the data team what to prioritize. She receives a 40+ chart report from Mixpanel: session duration, feature adoption, retention cohorts, everything. She still can’t make a decision. “The data shows everything but recommends nothing.” She makes gut calls anyway, which feels wrong given how much data is on the table. The cost, per cycle: three people, one full day, to build it. Two to three days for her to read it. Then the deadline hits and the decision goes to whatever the CEO mentioned last week or whatever’s loudest in the support tickets. Trigger — Every sprint cycle. It came to a head last quarter: they redefined what the dashboard needed to show, the data team took seven weeks to rebuild the report, and she still couldn’t decide fast enough. Result: a wasted A/B run and a feature release that caused churn. (Additional context I happened to have, knowing the PM: the Mixpanel API connection was fine, but the aggregation kept collapsing under the event volume — a lot of manual correction every cycle, and eventually a need for different tooling.) Boundaries — Two-week sprint cycle, velocity must hold. Mixpanel stays. And the fix has to start working next sprint, not after a months-long transformation. Tension — Two sentences, both worth sitting with: “The data team is undervalued.” “We are not data informed, we are data paralyzed.” Clarity statement (where we landed live): Reverse-engineer from the decision backwards. Define what success of the product actually looks like, then design the smallest set of metrics that tells the PM where her biggest lever is before a sprint — rather than redesigning the report again. Our guest timo dechau 🕹🛠 (https://substack.com/profile/29441309-timo-dechau) — solo consultant, product and growth analytics. Based in Aalborg, Denmark (not Copenhagen, as he’d like on the record). Timo started in product and never really left it — most of what he does in data is still built on product principles. His path ran through classic tracking implementation, then an equally long stretch on the data warehouse side, and in the last two or three years into strategy, which he says he’d written off as “something for old people” until he found out what it’s actually for: setting expectations early enough to prevent the problems that show up later. He works with companies trying to get their warehouse stack into a shape that supports real product analytics, growth prediction, and marketing attribution, and he’s building a product that sits on top of the usual suspects — Amplitude and Mixpanel — to add a more strategic layer to product analytics. Connect with Timo: * Website: timodechau.com (https://timodechau.com) * LinkedIn (https://www.linkedin.com/in/timo-dechau/): He posts two or three times a week, and describes LinkedIn as his first sounding board for ideas before they become blog posts or videos Where the two approaches met Timo’s first move: clear the room before you fix anything He got stuck on this for the longest part of his twenty minutes, and it’s the most useful thing in the episode. “I think the biggest problem is — they’re in a bad place mentally. Not business-wise, not from a data perspective. They’re collecting data, stuff is there. But mentally they’re in a bad place.” Frustration like this doesn’t start two months ago. It accumulates, on both sides, and by the time somebody writes “we are data paralyzed” into a problem submission, it has an audience — the product team has told other teams, management has heard about it, and the question in the room has quietly become why hasn’t this been solved already, when everyone else has solved it? (Very few companies have. Plenty claim to. That gap makes the environment harder, not easier.) So his quick win is a stop, not a start: Produce no sprint reporting at all for three sprints. Use the reclaimed capacity — a full day per cycle, per person — to build the replacement. And this cannot be agreed between the product and data teams alone. It goes up to management, it gets stated openly, and something gets delivered at the end. Otherwise the same trap closes again. Then: borrow the product strategy to narrow the scope Product is measurable in a thousand directions, which is why forty charts happened in the first place. Timo’s scope-narrowing device is the strategy nobody in data usually reads. There’s a business strategy. Product derives its strategy from it. Spend time with management and product understanding what they actually want to move in the next twelve months — then translate that movement into metrics. The payoff is political as much as analytical: “When we can come up with some metrics that show strategic progress, everyone is happy — even when we haven’t solved the core problem yet.” It takes pressure out of the room, it tells management whether their strategy is working, and it buys the credit needed to fix the rest properly. Then: measure outcomes, not interactions “One of the big issues of almost all product analytics setups is that it’s focusing on interactions and it’s not focusing on outcomes. Interaction is easier to track — there’s a button, we can click it, we can track it. But the real value comes when you take a step back and say: what are the outcomes of our wellness app? What do we want people to achieve?” Practically, that means event storming sessions to map the journey and identify value moments — even if it’s been done before — and then a shift in how results get presented: * Away from retention curves and cohort reports. Beautiful assets, genuinely useful, and readable by professional analysts. Not by a PM at 9am before sprint planning. * Towards metrics: a one-month, three-month, six-month retention rate. Put them on a time series. Cohort them later if you want. A PM can look at three of those and answer “did the last sprint move anything?” in about ten seconds. * Or user-state measurement, growth-model style: new → activated → active → at risk → dormant, and measure the movement between states. Activation rate, at-risk rate, and so on. Two constraints he names honestly. First, Mixpanel is a poor fit for this: “Mixpanel is not a metric-based tool. It’s an event data exploration tool” — metrics arrive late and aren’t first-class. Second, when the conversation stalls on “our tracking is bad,” the way out is often to stop tracking and instead derive from the product database. That’s source data. “Tracking cannot be good, because it happens in a browser.” Lior’s move: three questions every KPI has to survive I came at it from the other end — the architecture, not the tooling. Start from one to three KPIs that measure business value. Then put each one through three questions before it goes anywhere near a dashboard: * What action will this require of us? If a number moves and nobody does anything differently, it isn’t a KPI. It’s decoration. * Why do I need it? The purpose, stated. Day-7 retention exists so I can tell whether a feature is sticky enough to bring people back. Once that’s written down, question one has an answer. * Who owns the data, and who owns the KPI? Two different jobs. One is accuracy and lineage. The other is the definition, the calculation when it changes, and the communication. Then, in order: design the visualization and the filters → map back to the data sources so lineage is documented → communicate to management and get their buy-in, so nobody is surprised when the number moves → and test the whole thing with a simple CSV before asking anyone to build it. That last step matters more here than usual. The data team is already frustrated. Validating the concept by hand, before commissioning work, is the difference between one build and four. On ownership — my honest answer to Timo’s question about whether anyone ever agrees to own a KPI is a bad, mostly. But the principle holds: the requester is the domain expert, and the domain expert owns it. Handing it to the data team makes no sense, because as Timo put it, “they cannot make the smell test.” They’ll present a number, someone in the domain will say “that can’t be right,” and they’ll have no way to know who’s correct. And the decision book — an idea I took from Philip back in episode three and have since used myself. Alongside the metrics, write down what you do when each one moves. High level, not exhaustive. Each time a new scenario shows up, add it. It’s what turns “the number went down” into a sprint conversation instead of an argument. Three insights 1. Minimal, strategy-linked metrics get you halfway on their own. Both of us arrived at a small number — Timo from the strategy end, me from the KPI end. The convergence matters less than the discipline: don’t have more metrics than you can actually watch and act on. As Timo put it, if they genuinely do this, “they have won the game to 50% already.” 2. The data team is under pressure, and that pressure is load-bearing. Three people producing a full day of work every two weeks, for a report that doesn’t produce a decision, while being told they’re undervalued. That’s not a side detail in this problem — it’s the thing that will quietly kill any solution that ignores it. The human component isn’t the soft part of this. It’s the constraint. 3. Being able to say “this is our strategy, and these metrics show it moving” changes every conversation. Timo picked this one selfishly, and he was right to. It’s not just alignment theatre — it’s what gets a data team the standing to fix the harder things afterward. “Now, for the first time, I could show a specific part that was important to everyone. And once they were happy with that, we could start to build up the other parts.” Three actions 1. Run an event storming session. Product and data in the same room, mapping the journey and identifying where users actually get value — even if it’s been mapped before. It’s the cheapest possible start, both teams want the outcome, and nobody has to be convinced of anything first. (Owner: product + data together. Sprint 1.) 2. Build a decision book. For each candidate metric, write down what you’d actually do if it moved. Run KPI candidates through it on Post-its during a workshop, and see which ones survive — a metric without an attached scenario isn’t ready. (Owner: PM, with the data team. Sprint 1–2.) 3. Hold all existing reporting. Three sprints, with management’s explicit and public cover, and the freed capacity goes into the replacement. This is the one that needs permission rather than effort. (Owner: needs a management decision. Start immediately.) The sequencing matters: event storming first because it’s easy and both sides want it, the decision book second because it’s what makes the metrics real, and the hold third — by then you have something to point at when you ask for it. What we didn’t solve — and where we disagreed Timo’s closing position: “We developed a really strong plan, but it still needs convincing that it will succeed. We didn’t solve an engineering problem, where someone just has to go in and implement it. This is a culture problem and a personal problem.” He’s been in situations with a good approach that still didn’t go through, for reasons that had nothing to do with the approach. He put himself in question about whether this counts as a breakthrough. I put myself at yes. My reasoning, for what it’s worth: the problem isn’t the tools, and it isn’t the process; it’s the people — and people can be moved if they can see what’s in it for them. Which is also why I’d start smaller than the plan suggests. Something a boss of mine at Zalando used to say: don’t make big waves. Start with the thing that helps both teams immediately — the event storming — and by the time anyone works out how much has changed, they’re too far in to want out. Then raise the heat. Timo’s caution is the more experienced position, and it should remain on the record alongside mine. If you’re the PM who submitted this, he’s the one to plan for, and I’m the one to hope for. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit impactoperations.substack.com (https://impactoperations.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

2 Sept 2026
Four Dashboards, Four Different Forecasts
Data Breakthroughs — S2E1: Four Dashboards, Four Different Forecasts Real-world data problem solving in action. Guest Koray and host Lior Barak open a community-submitted challenge for the first time on the recording — no prep, no script. Problem category: Business Intelligence & Dashboarding Runtime: [[34]] minutes The challenge: A Series B B2B SaaS company has four dashboards reporting the current-quarter sales pipeline, each with a different total — and after a public disagreement between the CFO and the sales manager, the VP has stopped trusting all of them. The solution: Separate the data problem from the forecasting-logic problem by re-running all four dashboards against a closed historical quarter, then rebuild forward from one agreed calculation with the business in the room at every step. Key takeaways: Trust is the real damage. It goes fast and comes back slowly. Test against a closed quarter before touching anything — it tells you whether the split is in the data or in the assumptions. Different teams can keep different operational definitions. They cannot keep unagreed ones. Disclaimer: This podcast is for inspiration and educational purposes. Solutions discussed are general approaches — adapt them to your context and constraints. Music: "Calisson" courtesy of Riverside This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit impactoperations.substack.com (https://impactoperations.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

17 Dec 2025
Episode 11: When “Just Connect It” Takes Four Months
Episode Summary I’m incredibly excited to have Ilya back for the Season 1 finale. He was my very first guest in the pilot episode (https://cookingdata.substack.com/p/data-breakthroughs-solving-pipeline), 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 & ETLRuntime: 40 minutes The Problem Submitted by: Anonymous Marketing ProfessionalIndustry 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 IlyaFractional 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/ (https://www.linkedin.com/in/bkmy43/) * YouTube: https://www.youtube.com/@lab4.berlin (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/ (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: * 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. * 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. * 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. * 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 * 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. * 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. * 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): * 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. * 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. * 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. * 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 BarakGuest: Ilya, Fractional Head of DataMusic: “Calisson” courtesy of RiversideSeason: 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! Get full access to Cooking Data guided by Lior at cookingdata.substack.com/subscribe (https://cookingdata.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

10 Dec 2025
Episode 10: When Data Meets Decades of Experience
Data Breakthroughs - Episode 10: When Data Meets Decades of Experience Real-world data problem solving in action! Tiankai Feng (Director of Data & AI Strategy at ThoughtWorks, author of "Humanizing Data Strategy" and "Humanizing AI Strategy") and host Lior Barak tackle a manufacturing company where plant managers with 20+ years of experience resist a modern data platform. Problem Category: Organizational Data Strategy / Change ManagementRuntime: 32 minutes The Challenge: A family-owned manufacturer invested heavily in data infrastructure, but plant managers still make decisions based on "what happened last time" and gut instincts, creating a divide between analytics teams and operations. The Solution: Transform data from replacement threat to support tool through co-creation, clear communication about expertise-data synergy, and defining decision-making rules with proper incentives. Key Takeaways: Expertise vs. data is always a tension field - communicate how they work hand-in-hand, not against each other People don't use things they didn't help create - co-creation is essential for adoption Success metrics must reflect both short-term and long-term value to align incentives properly Guest: Tiankai Feng, Director of Data & AI Strategy at ThoughtWorks Author of "Humanizing Data Strategy" and "Humanizing AI Strategy" Connect: https://www.linkedin.com/in/tiankaifeng/ (https://www.linkedin.com/in/tiankaifeng/) Get Involved: Submit your data problem or Become a guest: https://data-breakthroughs-podcast.cookingdata.blog/ (https://data-breakthroughs-podcast.cookingdata.blog/) Join the conversation: #DataBreakthrough Full show notes: https://data-breakthroughs-podcast.cookingdata.blog/ (https://data-breakthroughs-podcast.cookingdata.blog/) Disclaimer: This podcast is for inspiration and educational purposes. Solutions discussed are general approaches - adapt them to your specific context and constraints. Music: "Calisson" courtesy of Riverside Get full access to Cooking Data guided by Lior at cookingdata.substack.com/subscribe (https://cookingdata.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

26 Nov 2025
Episode 09: When Analytics Becomes a Dashboard Factory
Data Breakthroughs - Episode 09: When Analytics Becomes a Dashboard Factory Real-world data problem solving in action! Eva Schreyer (Head of Data & Analytics at Neugelb/Commerzbank) and host Lior Barak tackle a community-submitted challenge about analytics overload for the first time during recording. Problem Category: Business Intelligence & Dashboarding / Organizational Data StrategyRuntime: 37 minutes The Challenge: A product team drowns in 40+ charts per report while struggling to make data-driven decisions, creating a disconnect between analytics investment and business value. The Solution: Transform from dashboard factory to strategic partner through executive alignment, monetizing requests, and prioritizing deep-dive analyses over generic reporting. Key Takeaways: Too much data doesn't mean good decisions-relevance matters more than volume Making stakeholders understand the cost of requests (in time/effort) dramatically improves prioritization Ask "what will you do differently when this metric changes?" to identify truly actionable insights Guest: Eva Schreyer, Head of Data & Analytics at Neugelb (Commerzbank) Connect: https://www.linkedin.com/in/eva-schreyer/ (https://www.linkedin.com/in/eva-schreyer/) Get Involved: Submit your data problem: https://data-breakthroughs-podcast.cookingdata.blog/ (https://data-breakthroughs-podcast.cookingdata.blog/) Become a guest: https://data-breakthroughs-podcast.cookingdata.blog/ (https://data-breakthroughs-podcast.cookingdata.blog/) Join the conversation: #DataBreakthrough Full show notes & visual diagrams: https://data-breakthroughs-podcast.cookingdata.blog/ (https://data-breakthroughs-podcast.cookingdata.blog/) Disclaimer: This podcast is for inspiration and educational purposes. Solutions discussed are general approaches - adapt them to your specific context and constraints. Music: "Calisson" courtesy of Riverside Get full access to Cooking Data guided by Lior at cookingdata.substack.com/subscribe (https://cookingdata.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

12 Nov 2025
Episode 8: The Office Kitchen Paradox: When 91% Accuracy Still Fails
Data Breakthroughs - Episode 8: The Office Kitchen Paradox Real-world data problem solving in action! Irena Bojarovska and host Lior Barak tackle a community-submitted challenge for the first time during the recording. Problem Category: Machine Learning & AI Implementation Runtime: 50 minutes The Challenge: A hackathon team built a smart kitchen demand forecasting model with 91% accuracy, but the company is still throwing away 20-25% of fresh products weekly while running out of popular items. The Solution: The breakthrough isn't about fixing the model, it's about fixing the data. The model is missing critical inputs (office attendance, special events) and is operating blindly due to data quality problems. The real solution combines better data, human-AI collaboration, and proper A/B testing. Key Takeaways: • Model accuracy ≠ real-world performance (91% test accuracy doesn't guarantee waste reduction) • Data quality and contextual information are your foundation (garbage in, garbage out) • Humans should augment the model, not be replaced by it (hybrid approach wins) Guest: Irena Bojarovska, Data Scientist at Zalando SEConnect: https://www.linkedin.com/in/irenabojarovska/ (https://www.linkedin.com/in/irenabojarovska/) Get Involved: Submit your data problem: https://data-breakthroughs-podcast.cookingdata.blog/submit-problem (https://data-breakthroughs-podcast.cookingdata.blog/submit-problem) Become a guest: https://data-breakthroughs-podcast.cookingdata.blog/become-guest (https://data-breakthroughs-podcast.cookingdata.blog/become-guest) Join the conversation: #DataBreakthrough Full show notes & visual diagrams: https://wabi-sabi-data-newsletter.com (https://wabi-sabi-data-newsletter.com) [or your actual newsletter link] Figma Board: https://www.figma.com/board/jfC4ipNvd8zSPIyZreEten/Irena-Bojarovska?node-id=1-14&t=Q46O2Ae9yuRHZRwy-1 (https://www.figma.com/board/jfC4ipNvd8zSPIyZreEten/Irena-Bojarovska?node-id=1-14&t=Q46O2Ae9yuRHZRwy-1) Disclaimer: This podcast is for inspiration and educational purposes. Solutions discussed are general approaches; adapt them to your specific context and constraints. Music: "Calisson" courtesy of Riverside Get full access to Cooking Data guided by Lior at cookingdata.substack.com/subscribe (https://cookingdata.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

12 Nov 2025
Episode 7: When Giants Have Algorithms and You Have Excel
Data Breakthroughs - Episode 7: Small Company vs AI Giants Real-world data problem solving in action! Jon Cooke (Founder of Dataception) and host Lior Barak tackle a classic David vs. Goliath scenario for the first time during the recording. Problem Category: Data Strategy & Customer AnalyticsRuntime: 36 minutes The Challenge: Small German seed company (7 people) with 600+ product varieties, 4 years of customer data, and 30 years of gardening expertise. They're losing to giants who use algorithms for personalized recommendations. Conversion rate: 2.1%. Sent tomato seeds in December while competitors suggested microgreens and winter planning guides. They have incredible data and domain knowledge - but no idea how to compete with automated personalization. The Solution: You don't need massive tech teams. Start with customer segmentation workshops, map buying journeys, understand your data quality, build a simple recommendation engine (could be done in half a day), and test with friendly customers. The institutional knowledge trapped in people's heads is your competitive advantage - you just need to capture and automate it. Key Takeaways: Understand customers and segments first - technology second Data quality dictates approach: good data = ML models, poor data = heuristic rules Simple models beat no models - you don't need world-class data scientists This is a business process problem with AI tools, not an AI problem Small teams can compete by moving fast and testing with customers Guest: Jon Cooke, Founder of Dataception20 years in data & AI | Former Databricks Solutions Architecture Lead | Ex-PwCExpert in data products, GenAI, and knowledge graphs Connect with Jon: Website: https://dataception.com (https://dataception.com) LinkedIn (https://www.linkedin.com/in/jon-cooke-096bb0/) Company: Dataception Get Involved: Submit your data problem: https://data-breakthroughs-podcast.cookingdata.blog/submit-problem (https://dataception.com)Become (https://dataception.com) a guest: https://data-breakthroughs-podcast.cookingdata.blog/become-guest (https://dataception.com)Join (https://dataception.com) the conversation: #DataBreakthrough Full show notes & visual diagrams: [Link to newsletter version] Disclaimer: This podcast is for inspiration and educational purposes. Solutions discussed are general frameworks - adapt them to your specific context and constraints. Music: "Calisson" courtesy of Riverside Get full access to Cooking Data guided by Lior at cookingdata.substack.com/subscribe (https://cookingdata.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

29 Oct 2025
Episode 6: The AI Bias Crisis - When Your Loan Model Can’t Explain Why
Data Breakthroughs - Episode 6: AI Bias & Explainability Crisis Real-world data problem solving in action! Elizabeth Press (Founder of D3M Labs, Deputy Chief Digital Officer at CHESCO) and host Lior Barak tackle one of AI’s most critical challenges for the first time during the recording. Problem Category: Machine Learning & AI Implementation / AI EthicsRuntime: 36 minutes The Challenge: A deep learning loan approval model improved accuracy by 23% and reduced processing time from days to minutes. Business results? Phenomenal. The problem? It systematically denies qualified applicants in certain zip codes at 40% higher rates - and the model is a black box that can’t explain individual decisions. Regulatory examination in 12 weeks. Potential discrimination lawsuits are looming. The Solution: Not all use cases should use unexplainable AI. Return to statistical fundamentals (logistic regression), implement hybrid human-in-loop systems, create cross-functional teams involving legal from day one, build test boxes for domain validation, and establish decision logs. Sometimes boring statistics beat sexy deep learning. Key Takeaways: High-stakes decisions (loans, justice, healthcare) should never use unexplainable black box models Involve legal, PR, and domain experts from the start - not retroactively Bias is quantifiable through business metrics (churn, customer complaints, defaults) You must be able to explain your model - without it, you run into catastrophic risks Speed means nothing if accuracy and ethics are compromised Guest: Elizabeth Press, Founder of D3M Labs | Deputy Chief Digital Officer at CHESCO. Former data leader | Taught “Profitable AI” at Hasso Plattner InstituteBackground in financial risk management and credit rating models Connect with Elizabeth: D3M Labs: https://www.linkedin.com/company/d3m-associates/posts/?feedView=all (https://www.linkedin.com/company/d3m-associates/posts/?feedView=all) YouTube: D3M Labs channel (https://www.youtube.com/@D3MLabs) LinkedIn: Elizabeth’s profile (https://www.linkedin.com/in/elizabethpress/) Focus: Profitable and secure digital business Get Involved: Submit your data problem: https://data-breakthroughs-podcast.cookingdata.blog/submit-problem (https://data-breakthroughs-podcast.cookingdata.blog/submit-problem)Become a guest: https://data-breakthroughs-podcast.cookingdata.blog/become-guest (https://data-breakthroughs-podcast.cookingdata.blog/become-guest)Join the conversation: #DataBreakthrough Full show notes & visual diagrams: [Link to newsletter version] Disclaimer: This podcast is for educational and inspirational purposes. Neither host nor guest is/are lawyer. AI ethics and legal compliance require professional legal counsel. Solutions discussed are general frameworks - adapt them to your specific context, regulations, and legal requirements. Music: “Calisson” courtesy of Riverside Get full access to Cooking Data guided by Lior at cookingdata.substack.com/subscribe (https://cookingdata.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

29 Oct 2025
Episode 5: When Every Team Has a Different “Most Valuable Customer”
Episode Summary In Episode 5, we tackle an organizational alignment nightmare that every growing company faces. David Cohen and host Lior Barak encounter a problem for the first time during recording: Every department has a different definition of “most valuable customer,” leading to a VIP program disaster where the same customers get treated as both high-priority and basic-tier depending on which team they interact with. 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 StrategyRuntime: 32 minutes The Problem Submitted by: AnonymousIndustry 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 (https://www.linkedin.com/in/davcohen06/)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/ (https://www.superpositionstrat.com/) * LinkedIn: https://www.linkedin.com/in/davcohen06/ (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 * 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. * 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. * 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: * 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. * 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. * 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. * 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 (https://www.figma.com/board/Ir9SQFVI8n5m7CLGLgpHTk/David-Cohen?node-id=1-14&t=vbK7UYpIfw0yZhrB-1): 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 (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 (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 BarakGuest: David CohenMusic: “Calisson” courtesy of RiversideVisual Content: Figma collaboration board Accessibility Episode Transcript: Full transcript available aboveVisual 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://www.superpositionstrat.com/) https://superposition.co * 💼 LinkedIn: https://www.linkedin.com/in/davcohen06/ (https://www.linkedin.com/in/davcohen06/) * 🏢 Company: Superposition - Strategy workshops for data & AI consultancies Get full access to Cooking Data guided by Lior at cookingdata.substack.com/subscribe (https://cookingdata.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

15 Oct 2025
Episode 3: The Churn Prediction Challenge
Data Breakthroughs - Episode 3: From Notebooks to Action Real-world data problem solving in action! Nick Zervoudis (Data Product Management Consultant & Coach) and host Lior Barak tackle a community-submitted ML deployment challenge for the first time during the recording. Problem Category: Machine Learning & AI Implementation Runtime: 45 minutes The Challenge: A high-accuracy churn prediction model (87%!) sits trapped in Jupyter notebooks while the sales team desperately needs daily at-risk customer alerts in Salesforce to prevent customer loss. The Solution: A phased 90-day deployment approach with human validation, cost/revenue tracking, and strategic go/no-go decision points - prioritizing quick wins while building toward full integration. Key Takeaways: Always run a standard checklist for IT, legal, privacy, and data access requirements Define success metrics upfront - what does "breakthrough" really mean for your business? Don't wait for perfection - export data ASAP and let teams start learning from it Guest: Nick Zervoudis, Data Product Management Consultant & Coach at Value from Data & Former Head of Product at CKDelta (doubled annual revenue, 5x ARR), Co-host of "Data Product Management in Action" podcast Connect with Nick: Website: https://blog.valuefromdata.ai/ (https://blog.valuefromdata.ai/) Course: https://maven.com/nick-zervoudis/dpm-value-course (https://blog.valuefromdata.ai/) LinkedIn: https://www.linkedin.com/in/nzervoudis/ (https://blog.valuefromdata.ai/) Get Involved: Submit your data problem: https://forms.office.com/r/KUPaLPEZwMBecome (https://blog.valuefromdata.ai/) a guest: https://forms.office.com/r/Qy2riCHvT5Join (https://blog.valuefromdata.ai/) the conversation: #DataBreakthrough Full show notes & visual diagrams: [Link to newsletter version] Disclaimer: This podcast is intended for educational and inspirational purposes. Solutions discussed are general approaches - adapt them to your specific context and constraints. Music: "Calisson" courtesy of Riverside Get full access to Cooking Data guided by Lior at cookingdata.substack.com/subscribe (https://cookingdata.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

13 Oct 2025
Episode 4: The Dashboard Chaos - When Self-Service BI Spirals Out of Control
Episode Summary In Episode 4, we tackle the classic “self-service BI gone wrong” scenario. Christian Klug and host Lior Barak encounter a creative studio’s nightmare for the first time during recording: 300+ dashboards created in just 6 months, nobody knows which numbers to trust, and teams are paralyzed by choice. What started as democratizing data became a path back to Excel spreadsheets. Problem Category: Business Intelligence & DashboardingRuntime: 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 KlugDirector 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/ (https://www.linkedin.com/in/christian-klug-83529a103/) * Band Instagram: https://www.instagram.com/cruorhilla/ (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 * 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. * Define True Sources: Establish the single source of truth for each KPI. No more debate about which conversion formula is “correct.” * Identify Data Owners: Make people accountable for data that affects board-level KPIs. Create awareness that changes have high stakes. * 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 * Establish Deployment Process: Changes to official dashboards require discussion, agreement, and sign-off. Protect the Boss KPI layer from surprises. * 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 * 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. * 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. * 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): * 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. * 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. * 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. * 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” WisdomChristian’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 StrategyI 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 DataThis 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 (https://www.figma.com/board/9TkbQUCBmXnbK7zdbRtf6p/Christian-Klug?node-id=1-14&t=WH1HlvtOj9NJGyE5-1): 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 (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: * 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 BarakGuest: Christian KlugMusic: “Calisson” courtesy of RiversideVisual 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 aboveVisual 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/ (https://www.linkedin.com/in/christian-klug-83529a103/) * 🎸 Band Instagram: https://www.instagram.com/cruorhilla/ (https://www.instagram.com/cruorhilla/) * 🎵 Spotify: * 📍 Based in Berlin, Germany Get full access to Cooking Data guided by Lior at cookingdata.substack.com/subscribe (https://cookingdata.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

26 Sept 2025
Data Breakthroughs - Episode 0
Data Breakthroughs - Episode 0: Why This Podcast Exists Season opener explaining the unique collaborative problem-solving format. Host Lior Barak shares why he created a podcast focused on real-time thinking processes rather than post-success stories. Runtime: 8 minutes Key Points: • Real problems solved live by practitioners encountering them for first time • Focus on strategic thinking processes, not tool recommendations• Principle-based solutions that work across different contexts • Learning from how others approach unfamiliar challenges What's Coming: 10-11 episodes released bi-weekly, starting with dual launch today Get Involved: Submit problems (https://data-breakthroughs-podcast.cookingdata.blog/): Guest applications (https://data-breakthroughs-podcast.cookingdata.blog/): Discussion: Tag @Lior Barak on LinkedIn Sample: Features clip from upcoming episode with Artur Yatsenko (Urban Sports Club) showing collaborative breakthrough moment Host: Lior Barak - Data Strategy Leader, Author of "Data is Like a Plate of Hummus" Social Media Posts LinkedIn Announcement 🎙️ Data Breakthroughs Season 2 is LIVE! Episode 0 explains why I created a podcast that's different from every other data show. Instead of interviewing people about past successes, we solve real problems in real-time. 🎯 What makes this unique: → Host & guest see problems for the first time during recording → Focus on thinking processes, not tool recommendations→ Real collaborative problem-solving, not rehearsed presentations → Principle-based solutions that work across contexts 🚀 Launching with dual drop: Episodes 0, 1, and 2 available now 📅 Schedule: New episodes every second week Want to submit a problem or join as a guest? Links in comments. #DataBreakthroughs #DataStrategy #ProblemSolving #Collaboration Twitter/X Thread 🧵 1/5 Most data podcasts follow the same format: "Tell us about your successful Snowflake implementation" But what if we flipped that? What if we solved NEW problems in real-time? That's Data Breakthroughs. Thread on why this format matters 👇 2/5 Traditional format: Guest shares what they already know Our format: Guest tackles what they've never seen before The learning happens live. The vulnerability is real. The solutions emerge through collaboration. 3/5 We don't ask "Which tool should we use?" We ask "How should we think about this problem?" Principles over products. Capabilities over configurations. Strategic thinking over tactical tutorials. 4/5 I created this because I wanted to learn how other practitioners think through unfamiliar challenges. How do they approach problems at strategic altitude? Turns out, the audience loves listening to genuine thinking processes too. 5/5 Season 2 launches today with Episodes 0, 1 & 2. New episodes bi-weekly. Real problems. Real collaboration. Real breakthroughs. 🎧 Listen: [podcast links] 📝 Submit problems: [form link] Disclaimer This podcast focuses on collaborative problem-solving and strategic thinking processes. Solutions discussed are principle-based approaches meant to inspire your own thinking - always adapt recommendations to your specific context and constraints. Get full access to Cooking Data guided by Lior at cookingdata.substack.com/subscribe (https://cookingdata.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

26 Sept 2025
Data Breakthroughs - Episode 2: Philipp Loringhoven
Data Breakthroughs - Episode 2: When Teams Can't Agree on Customer Numbers Real-world data problem solving in action! Philipp Loringhoven and host Lior Barak tackle a community-submitted challenge about conflicting metrics between marketing and sales teams. Problem Category: Data Governance Runtime: 43 minutes The Challenge: Marketing and sales teams report significantly different customer acquisition numbers, causing meetings to focus on defending data rather than strategic planning. The Solution: Establish clear metric ownership, create KPI definition libraries, and implement certified data layers to prevent conflicting sources. Key Takeaways: 90% of data problems are communication problems, not technical issues Management must enforce central numbers and pick battles wisely Small companies should limit themselves to 5-8 core KPIs to avoid chaos Guest: Philipp Loringhoven, Marketing Analytics & Data Strategy Specialist Connect: https://linkedin.com/in/philipploringhoven (https://linkedin.com/in/philipploringhoven) Get Involved: Submit your data problem: https://forms.office.com/r/KUPaLPEZwM (https://linkedin.com/in/philipploringhoven) Become a guest: https://forms.office.com/r/Qy2riCHvT5 (https://linkedin.com/in/philipploringhoven) Join the conversation: #DataBreakthrough Full show notes & visual diagrams: https://cookingdata.substack.com/p/data-breakthroughs-episode-2-marketing-sales-alignment (https://cookingdata.substack.com/p/data-breakthroughs-episode-2-marketing-sales-alignment) https://www.figma.com/board/30ZlIDFsIwHnN7XJqJImj6/Philipp-Loringhoven?node-id=2024-444&t=FmOoiLmnMzpU9t3e-1 (https://www.figma.com/board/30ZlIDFsIwHnN7XJqJImj6/Philipp-Loringhoven?node-id=2024-444&t=FmOoiLmnMzpU9t3e-1) Disclaimer: This podcast is for inspiration and educational purposes. Solutions discussed are general approaches - adapt them to your specific context and constraints. Music: "Calisson" courtesy of Riverside Get full access to Cooking Data guided by Lior at cookingdata.substack.com/subscribe (https://cookingdata.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

26 Sept 2025
Data Breakthroughs - Episode 1: Artur Yatsenko
Data Breakthroughs - Episode 1: Breaking Technical Stalemates Real-world data problem solving in action! Artur Yatsenko and host Lior Barak tackle a community-submitted challenge for the first time during the recording. Problem Category: Data Engineering & InfrastructureRuntime: 43 minutes The Challenge: Product owner with full CEO backing can't deliver analytics capabilities because two lead engineers have been locked in architectural debates for 6 months, paralyzing the entire team. The Solution: Transform the "academic debate club" into a business partner through forced decision-making, cost visualization, solution hackathons, and MVP delivery that demonstrates value quickly. Key Takeaways: • Technical conflicts are often people problems in disguise - focus on decision-making authority and team dynamics • Customer-centric development applies to internal data tools - validate with business users early and often• Every day of architectural debate has a measurable financial cost that should be made visible to the team Guest: Artur Yatsenko, Director of Data Engineering at Urban Sports ClubConnect: https://www.linkedin.com/in/arthuryatsenko/ (https://www.linkedin.com/in/arthuryatsenko/) Get Involved:Submit your data problem: https://forms.office.com/r/KUPaLPEZwM (https://forms.office.com/r/KUPaLPEZwMBecome)Become (https://forms.office.com/r/KUPaLPEZwMBecome) a guest: https://forms.office.com/r/Qy2riCHvT5 (https://forms.office.com/r/Qy2riCHvT5Join)Join (https://forms.office.com/r/Qy2riCHvT5Join) the conversation: #DataBreakthrough Full show notes & visual diagrams: [Link to newsletter version] Disclaimer: This podcast is for inspiration and educational purposes. Solutions discussed are general approaches - adapt them to your specific context and constraints. Music: "Calisson" courtesy of Riverside Get full access to Cooking Data guided by Lior at cookingdata.substack.com/subscribe (https://cookingdata.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

2 May 2025
Data Breakthroughs: Solving Pipeline Reliability Issues That Destroy Trust | EP01
Data engineering leader Ilya Vladimirskiy discusses preventing data pipeline breaks that damage trust in data and negatively impact business decisions, emphasizing the importance of people and communication over technology in this interview.

25 Apr 2025
Data Breakthroughs: Solving Real-World Data Challenges
Industry experts tackle listener-submitted data challenges on the Data Breakthroughs podcast, providing actionable solutions and implementation steps for data professionals to overcome barriers and create business value in this episode.
Podcast Authority Score: 18 / 100
A composite of feed quality, social presence, YouTube performance and engagement. Read the methodology.
- Quality
- 37
- Social presence
- 0
- YouTube
- 0
- Engagement
- 0
Contact Data Breakthroughs: Solving Real-World Data Challenges
- Guest appearances
- Books guests
Based on episode analysis; this does not confirm that the show is currently accepting guests.
Host of Data Breakthroughs: Solving Real-World Data Challenges?
Claim your podcast to manage its listing and keep your show details accurate.
Pod Engine is an independent podcast discovery and analytics service and is not affiliated with or endorsed by this podcast. Artwork and show content belong to their owners. Full legal notice.
Explore this show
Podcast research with Pod Engine