Last week, I participated in a DAMA Norway book club session to present my book, Data as a Product Driver 🚚. The last question they asked me got me thinking afterwards.

The question was something like, “What were your sources of inspiration when writing the book?” And then I mentioned that I had read many books on data, as well as on product management, and I cited some authors: Teresa Torres, Marty Cagan, Itamar Gilad…

Afterwards, I thought that as a data professional with years of experience, I don’t think people in this field typically read many product-focused books, which is why I’ve decided to expand on the answer in this blog post.

The Wrong Books for the Real Problems

I started reading Product Management-type books because the problems killing the data teams I was managing weren’t actually architectural or data-related. They were organizational. And data books don’t teach you how to fix organizational problems.

Let’s dig a little deeper.

Data books teach you how to build things. How to model data. How to architect platforms. How to choose technologies. These skills matter—you need technical depth to be credible.

But here’s what they don’t teach you: how to decide what’s worth building. How to organize teams for impact. How to measure value instead of output. How to make product teams actually want to work with you.

That second part is what determines whether your data team succeeds or becomes an expensive ticket queue.

I’m not saying data books are useless. But once you understand data modeling and platform architecture, your biggest problems aren’t technical anymore. They’re about team structure, goal setting, and decision-making.

And the best books about those topics? They’re not in the data section.

Seven Books That Changed How I Lead Data Teams

Building on the last question I got in the book club session, here are seven product (and platform) management books that have fundamentally changed how I lead teams:

1. Escaping the Build Trap (2018) by Melissa Perri’s

2. Transformed (2024) by Marty Cagan

3. Evidence-Guided (2023) by Itamar Gilad

4. Continuous Discovery Habits (2021) by Teresa Torres

5. The Manager’s Path (2017) by Camille Fournier

6. Empowered (2020) by Marty Cagan

7. Team Topologies (2019) by Matthew Skelton and Manuel Pais

Here’s what each taught me that no data book did.

Outcomes Over Outputs: Escaping the Build Trap and Transformed

Two books taught me that the fundamental problem with most data teams is that we measure the wrong things and organize around the wrong boundaries.

Melissa Perri’s “Escaping the Build Trap” defines the problem clearly: “Outputs are easily quantified things that we produce. Outcomes are the things that result when we finally deliver those features, and the customer problems are solved.”

Data teams set goals on pipeline uptime, number of dashboards, and query performance, but they don’t tell you if you’re creating value.

An output is a dashboard. An outcome is faster decision-making because the right people can see the right metrics at the right time. An output is a machine learning model. An outcome is reduced fraud that saves money. I’ve written about this in depth in a previous article:

Perri also challenges how we organize: “Most data teams organize by technical layer: data engineering, analytics, data science. But value flows through customer journeys: acquisition, activation, retention, monetization. What if you organized data teams around these value streams instead?”

On the other side of the same coin, Marty Cagan’s “Transformed” goes deeper into what actually needs to change. The book frames transformation along three dimensions:

1. Changing how you build: Moving from projects to products. Stop creating “orphaned features” that never get iterated on because you’ve moved to the next project.

2. Changing how you solve problems: Give teams problems to solve, not features to build (same as Perri): “Instead of stakeholders prioritizing their perceived solutions and providing these in the form of a roadmap to a feature team, now the product team is assigned problems to solve, and the product team is empowered to discover a solution.”

3. Changing how you decide which problems to solve: Use an insight-driven strategy, not opinion-driven roadmaps.

Cagan also emphasizes direct access to data: Give product teams direct access to data. Build self-service tools. Your job as a data team shifts from running every query to helping teams ask better questions.

In the companies I worked with, teams reorganized from functional units (all analysts together, all engineers together) to domain-aligned teams. The growth team got its own analyst and data engineer focused only on acquisition and activation. Data people started learning the business in depth, rather than supporting 4 different areas superficially.

Discovery and Evidence: Evidence-Guided and Continuous Discovery Habits

Once you’re organized around outcomes in cross-functional product teams, how do you decide what to build? Two books taught me that.

Itamar Gilad’s “Evidence-Guided” introduced me to the GIST model (Goals, Ideas, Steps, Tasks) and changed the way I structure my work. Most data teams jump straight to tasks: “Build this dashboard.” But what’s the goal? What idea are we testing? What steps validate whether this is worth doing?

The book’s key principle is to think about Ideas to fulfill outcome-based Goals and then validate those ideas using Steps and Tasks.

The Steps part is key because before I used to jump from Idea to Tasks, but Steps help product teams gather evidence and assess its quality.

An executive’s opinion is weak evidence. Competitor behavior is slightly stronger. User interviews are stronger still. A/B test results with statistical significance are the strongest evidence.

Each of these items is a validation Step, like a data analysis or a fake door test. Success is measured differently: it’s not about producing code; it’s about learning something that informs the next decision.

And by the way, Itamar wrote the Foreword for my book, Data as a Product Driver 🚚.

Teresa Torres’ “Continuous Discovery Habits” reinforces this with structured discovery techniques for product teams. The key being product discovery isn’t a phase you do once; it’s a habit you practice continuously.

When data people are embedded in product teams using these frameworks, they run small experiments to test assumptions. They help structure discovery interviews to combine qualitative insights with quantitative data, and they do it weekly, not once per quarter.

After reading these books, I adopted ICE scoring for data product ideas. Embedded analysts and data scientists started owning discovery work alongside product managers.

Managing Empowered Teams: The Manager’s Path, Empowered, and Team Topologies

The last group of books helped me manage product teams, both teams that build customer-facing features and teams that maintain internal platforms.

Camille Fournier’s “The Manager’s Path” gave me a foundational understanding of engineering management: what it means to manage humans, how to shield teams, provide context, and foster a high-performing, psychologically safe environment.

Marty Cagan’s “Empowered” focuses specifically on managing product teams and the work of the product leaders in the team (Product, Engineering, Design, and, as I posted in previous articles, Data).

Cagan emphasizes that coaching is job #1: “If you are a manager, you should be spending most of your time and energy on coaching your team.”

Finally, “Team Topologies” by Matthew Skelton and Manuel Pais gave me a framework for structuring teams for flow.

If you want decentralized analytics, don’t centralize all your analysts. If you want product teams to own their data quality, don’t create a separate data quality team that “owns” it for them. Your org structure determines what you can build.

The book identifies four team types. Data teams map to these:

• Stream-aligned teams: Embedded data people working with a specific product team or business domain. This should be your primary pattern. The analyst or data scientist on the growth team, and the data engineer supporting the payments domain. Their job is to enable the fast flow of value in their domain.

• Platform teams: Your data platform team providing self-service tools and infrastructure. They reduce cognitive load by handling the complex technical foundation: data pipelines, data warehouse, experimentation platform, and analytics tools.

• Enabling teams: Specialists who help other teams learn new capabilities. Maybe an experimentation specialist coaching product teams on how to run better A/B tests in big organizations. Or a machine learning engineer helping product teams understand when ML is the right solution and when it’s overkill. They work with teams temporarily to build capability, then move on.

• Complicated-subsystem teams: Deep specialists in complex domains. Your ML infrastructure team if you’re doing sophisticated machine learning at scale. Your real-time streaming team if you’re processing millions of events per second with complex transformations.

If this resonates, start where your biggest pain is: (1) setting outcome-driven goals and organizing teams by value streams, (2) focusing on product discovery, or (3) team management, and start reading those books today!

Any other book you would add to the list?

Enjoyed this post? You might like my book, Data as a Product Driver 🚚.

Several months ago, I published an article introducing a framework for setting data platform goals. The framework organized platform goals into four distinct layers, from outputs (features shipped) to direct business outcomes (revenue impact). The article resonated with many people who struggle with the same challenge: how do you prove your platform’s value when you’re several steps removed from the business metrics that matter?

After publishing, I received several messages asking for concrete examples. How are real companies actually using this framework? Which layers are they operating in? What metrics work in practice versus theory?

I reached out to platform managers and leaders and listened to podcast episodes to understand how several companies approach platform goals, and I am happy to share the conclusions in this article.

The Four Layers Revisited

Before diving into the examples, let me briefly recap the four-layer framework for platform goals that I shared in the previous article:

Layer 1: Platform Outputs.

They measure what you ship: features delivered, tickets closed, tools implemented. Easy to track, but tells you nothing about impact.

Layer 2: Adoption, Engagement, and Reliability.

Goals in this layer measure whether people use what you build and whether it works: adoption rates, active users, and system uptime are examples.

Layer 3: Efficiency Metrics.

They measure productivity gains: time saved, manual work eliminated, faster decision cycles.

Layer 4: Direct Business Outcomes.

Business outcomes directly connect to money, risk reduction, or strategic business metrics, such as revenue attribution, cost savings, and customer retention improvements.

The framework needs to be seen as a hierarchy of preference. You should aim as high as you can while being honest about what you can credibly measure and impact.

Now, let’s move towards the three examples.

reMarkable: Building for Immediate Business Value

Eirik Folkestad leads the data platform team at reMarkable, the Norwegian e-paper tablet company. His team primarily operates between layers two and three, focusing on adoption metrics and efficiency gains.

“We don’t track a single metric,” Eirik explained. “Instead, we assess business impact qualitatively across three areas: enabling insights that wouldn’t otherwise be possible, automation and self-service that save hours on manual processes, and time to insight.”

The team has deliberately moved away from layer-one goals as its platform has matured. In the early days, they needed to build foundational capabilities, including fetching, storing, and transforming data, as well as creating basic reports and dashboards. At that stage, tracking platform outputs made sense. But once those foundations were in place, the team shifted focus.

“With our data platform foundation and core data products now in place, we’re rigged for delivering more layer four goals that help optimize business processes,” Eirik said.

reMarkable’s approach is pragmatic about measurement. They track health indicators, such as active users, in self-service analytics tools and data quality metrics. As you move to measure efficiency metrics (layer three) and, if possible, direct business goals (layer four), it is useful to keep adoption and engagement metrics (layer two) as guardrails. But they acknowledge the challenge of direct attribution: “All value is indirect—it flows through our domains and functions.”

The team’s philosophy is straightforward: stay close to the business, understand their needs, and build what they’ll actually use. “If the need is visibility into sales numbers, then deliver that, and don’t create a data catalog that will never be used,” Eirik emphasized. This value-driven approach means developing only features with immediate adoption potential and dropping anything that doesn’t get used.

Salesforce: Anchoring to Efficiency Despite the Challenges

Rounak Mehta leads product for an internal data platform at Salesforce, building a system to turn application telemetry into adoption metrics at scale. His team anchors to layer three (efficiency metrics) as the closest they can get to real business outcomes.

Rounak mentions: “For instance, one of my OKRs last year was time to metric—how long does it take us to turn product telemetry into adoption metrics.”

The team has operated at the efficiency layer since its founding two years ago, but they’re always looking for opportunities to measure layer four business outcomes. “It’s as you wrote in your article—impact at that layer is usually correlated, not causal,” Rounak explained.

What would Rounak love to measure but can’t? At layer four, he’d track the opportunity cost of applications that couldn’t be built or took too long because of platform gaps. At layer three, he wants more rigorous tracking of time spent finding and using the data his platform produces.

The breakthrough for Rounak’s team came when executives finally felt the pain directly. “One of the big drivers of bringing that pain to light was the time to deploy and scale agents and their performance,” he said. When strategic initiatives stalled because the data platform didn’t exist, suddenly the value became obvious.

His advice to other platform leaders: “Build close relationships with executives who have important and urgent needs that trace back to problems you can solve. As the number and volume of these executives grow, they can build the case for investment better than you would.”

OpenAI: Platform Goals in a Research-Driven Organization

Jake Brill heads the integrity product at OpenAI, managing a platform team that builds shared technology for trust, safety, and core capabilities. His perspective reveals how platform goals work differently in organizations where research and product development are tightly coupled.

The integrity platform team Jake’s leads focuses on reliability and enablement metrics: latency, uptime, and system maturity. These are layer two metrics, but with a critical distinction—they directly enable other teams to achieve their layer four goals.

“The success metrics for integrity have a different shape from other teams,” Jake explained during a podcast interview that I happened to listen to while working on this article. “For our integrity platform team, we view our success metrics as: are we building systems that enable the success of other products?”

“For example, our team is responsible for our identity system,” Jake noted. “We think a lot about how many nines of reliability we have, because if people can’t log into their accounts or sign up, OpenAI isn’t going to accomplish its overall goals.”

This approach reflects a deeper truth about platform work: sometimes your layer-two metrics serve as the foundation for other teams’ layer-four metrics. The platform team doesn’t set direct goals for user growth or revenue, but they build systems that enable those metrics.

What makes OpenAI’s approach distinctive is that they plan quarterly but “write plans in pencil, not in pen,” expecting to accomplish only 60-70% of any given plan. This flexibility acknowledges that platform priorities shift as new capabilities emerge from research.

Jake’s team also handles a challenge most platform teams face: handling a massive volume of inbound requests. “Being a platform team, we get multiple times more requests than the average team, both because we’re building shared technology and because we have close partners in operations, policy, and investigations.” In my opinion, you need to try to minimize this while acknowledging that it won’t reach zero and that some capacity needs to be reserved.

Lessons Learned Across Companies

After going through these three examples, I think three clear patterns emerge from these conversations:

The measurement gap is real. All three leaders struggle with the distance between their work and business outcomes. They’ve made peace with operating at layers two and three, using proxy metrics and qualitative assessment where direct measurement isn’t feasible.

Executive pain drives investment. Both Rounak at Salesforce and Jake at OpenAI emphasized the importance of leadership feeling the direct impact of platform gaps. Abstract ROI calculations matter less than concrete examples of strategic initiatives blocked by missing capabilities.

Value-driven beats feature-driven. Eirik’s emphasis on immediate adoption and Rounak’s focus on urgent executive needs both point to the same lesson: build what people will actually use, not what you think they should want. This requires constant contact with your stakeholders and a willingness to kill features that don’t get traction.

Practical Recommendations

If you’re leading a platform team and struggling to move beyond “features shipped” metrics, here’s what these examples suggest:

Start with an honest assessment. Map your current goals to the four layers. If everything sits at layer one, you have clarity on what needs to change. Don’t feel pressured to reach layer four immediately.

Pick metrics you can actually measure. Eirik initially tracked active users and data quality. Rounak measured time to metric. Jake focuses on reliability and uptime. These are all layer two or three metrics, but they’re concrete, measurable, and connected to value.

Invest in stakeholder relationships. All three leaders emphasized proximity to business needs. You can’t measure impact if you don’t understand what your stakeholders are trying to accomplish. Regular conversations, paired work, and shared goals build the context you need.

Use qualitative assessment when quantitative fails. reMarkable’s approach of qualitative impact assessment across three areas acknowledges that not everything can be quantified. Sometimes “enabled a decision that wouldn’t have been possible” is the best measure you’ll get.

Final Words

The four-layer framework isn’t a destination, it’s a tool for honest conversation about what you can and can’t measure. These three companies show that success doesn’t require operating at layer four. Sometimes layer two or three is exactly right.

What matters more than reaching the highest layer is being transparent about where you are, measuring what you can credibly track, and continuously strengthening the connection between your work and business value. As your platform matures and your stakeholder relationships deepen, opportunities to move up the layers will emerge naturally.

The goal isn’t perfection. The goal is progress, one measurable step at a time.

Enjoyed this post? You might like my book, Data as a Product Driver 🚚

In my earlier articles, I explained how data teams in modern companies are getting smaller. Why? Because people across the company are learning to work with data themselves instead of always relying on data experts. But data professionals still matter; they just work in smaller teams that sit directly within different parts of the business. I call these “mini-data organizations.”

I cover all these ideas in my upcoming book, Data as a Product Driver, coming out in the New Year.

Today, I want to share a third idea and a helpful strategy for growing companies that want to use data to inform product decisions and stop seeing data as just a support function. This strategy is called: The Product Quartet.

Beyond The Product Trio

If I got a cent every time I heard someone refer to “the product trio” (Product Management, Engineering, and Design) when planning quarters, setting OKRs, or allocating resources, and completely excluding Data from the equation, I’d be rich by now.

I wish I were exaggerating, but I’m not. I have seen this pattern in companies I’ve worked with or interviewed, I hear it on podcasts, and I read about it in books, too.

People in these three groups sit around the table making decisions about what to build, how to build it, and what success means. And Data? Well, data is somewhere else. Usually acting as a support function and waiting to be asked to contribute when someone finally thinks to include them.

If you’re building anything data-driven today, the trio model is starting to feel incomplete. So what if your teams need a fourth voice for leadership decisions?

Why This Matters Now

I’ve worked with multiple organizations, making the shift from treating data as a support function to treating it as a product driver. These organizations still place product leadership around an outdated model. popularized the Product Trio concept in her book Continuous Discovery Habits (2021), and it works brilliantly when data isn’t core to what you’re building. But once your product has the basic features you think it needs, you need to blend traditional product development with data-informed decision-making to optimize it further.

The Traditional Trio and Its Limits

Let me explain what the trio actually does before we talk about why it needs to evolve.

The trio—PM, UX, engineer—shares responsibility for the core leadership activities that determine whether your team succeeds or fails. I am talking about prioritization, clarifying ownership, risk assessment, trade-off decisions, goal setting, and stakeholder communication.

Each person brings something specific to these decisions:

The PM is the voice of the customer, the orchestra director. They keep the team anchored in the problem and the business context. They ask, “Why are we building this?”

The UX designer/researcher makes the experience usable and enjoyable. They challenge the team to determine whether the solution actually solves the user’s problem in a natural way.

The Software Engineer knows what’s actually possible. They bring reality checks about technical feasibility, implementation complexity, and what the codebase can support.

This works when you can treat data as something you request when needed. The PM wants to validate an assumption? File a ticket with the analytics team. Does the UX designer need usage data? Submit a request.

But when data becomes core to your product strategy, this sequential handoff destroys your speed. By the time someone runs the query and delivers the chart, your team has moved on to different problems.

Enter the Product Quartet

The solution is simple to describe but requires a fundamental shift in how you organize your teams: add a fourth permanent voice to the product leadership structure. The Data Lead.

says in his Product Driven (2025) book: “It starts with engineering leaders realizing they are product leaders.” And I would add: data leaders are also product leaders.

This person—usually a Data Analyst or Data Scientist, depending on your team’s needs—participates in the same leadership activities as the other three. Prioritization. Risk assessment. Trade-offs. Goal setting. Stakeholder communication. But they bring something the other three can’t: evidence-based decision-making from day one.

Let me give you concrete examples of what this looks like in practice.

What the Data Lead Actually Does in a Product Team

During the planning process, the Data lead brings an outcome-driven mentality to the team, as I explained in a previous article: From Feature Factories to Growth-Oriented Teams: A How-To Guide to Outcome-Driven Measurement.

During discovery work, the Data Lead helps validate ideas before anyone writes code. When the PM and UX Leader say, “Based on user interviews, our users struggle with X,” the Data Lead can combine this qualitative feedback with quantitative data to show the scale of the problem, which users it affects, and more. They quantify the size of opportunities so the team can make informed bets.

As a next step, they also help inform decisions on which features to prioritize through validation techniques such as ICE scoring and A/B testing. has a great book on this called Evidence-Guided (2023), which I sincerely recommend.

During delivery and after launch, the Data Lead defines success metrics and sets up measurement. They ensure the team can tell whether what they built actually worked. Without this, teams celebrate shipping features without knowing whether they solved anything or just added more complexity.

The goal is to combine gut instinct with evidence so your team implements successful bets faster and avoids implementing what does not move a metric.

The Four Shifts That Make This Work

But moving from the trio to a quartet requires more than just inviting another person to meetings. First, you need to establish a partnership with the data team from your cross-functional team. Do you have data professionals to ask for help? Are they available? Is anyone available to embed in your cross-functional team? I’ve written about this in this article: Navigating the Spectrum of Centralization vs. Decentralization in Analytics Teams.

Once you have the bandwidth of a data professional, you need to change how your team operates fundamentally. Here are the four shifts I’ve seen work:

1. Establish Clear Authority for the Data Lead

Your Data Lead isn’t there to run reports on demand. They’re there to influence direction through evidence and help your team to plan using outcome-oriented measurement and lead product discovery activities. Give them explicit authority to challenge assumptions and to propose data-based alternatives.

I’ve watched this fail when organizations add a data person to the team but still treat them as an order-taker and dashboard maker. “Can you pull this report?” instead of “What does the data tell us about this problem?” The Data Lead needs equal standing with the PM, UX designer/researcher, and engineer.

2. Build Collaborative Decision Rituals

The quartet should meet regularly to discuss problems together. Not sequentially. Not with one person presenting to three others. Together, working through the problem from multiple angles simultaneously.

Each person contributes their expertise. The PM brings user context and business strategy. The UX person brings a focus on usability and user empathy. The engineer brings feasibility constraints and technical possibilities. The Data Lead brings empirical evidence and analytical rigor.

Decisions emerge from this collective intelligence, not from one person’s domain expertise dominating the conversation.

3. Create Shared Accountability for Outcomes

Stop celebrating feature launches. Start celebrating metric improvements.

In the old trio model, success often meant “we shipped the thing on time.”

With the quartet, success means “we moved the metric.” The team collectively owns the outcome. If the feature ships but doesn’t improve your e.g. fraud detection rate, that’s not a success. If the ML model is technically sophisticated but doesn’t improve conversion rate, that’s not a success.

4. Develop Data Literacy Across All Roles

The quartet works best when it’s not just the Data Lead who understands data. The PM should be comfortable reading dashboards, understanding statistical significance, and knowing when sample sizes matter. The UX designer should grasp how behavioral data complements qualitative research and be able to spot patterns in user metrics. The engineer should understand how their implementation decisions affect data quality and measurement accuracy.

This doesn’t mean everyone becomes a data expert, but each person should develop enough data fluency to participate meaningfully in evidence-based discussions. Eventually, this might lead to the decline of the data organization, but this is a good sign.

Common Objections (And Why They’re Wrong)

Usually, individuals and leadership object to the quartet model for many different reasons. Let me address the three objections I hear most often.

“We can’t afford to embed data people in every team.”

You don’t need to. You can start with your most data-intensive teams. Fraud detection. Personalization. Pricing optimization. Dynamic forecasting. These teams literally cannot function without data expertise in the room.

Other teams can continue with the trio model until they mature into work that requires data as a core driver. You’re not implementing a company-wide policy overnight. You’re evolving your most advanced teams first.

“Our PMs should be data-fluent enough to handle this themselves.”

Eventually, yes. But most PMs today weren’t trained this way. Traditional product management programs focused on user research, competitive analysis, and roadmap planning. Quantitative skills often get less emphasis, if any at all.

Until your PMs build deep data fluency (which takes time), a data specialist fills the gap. And honestly, even with data-fluent PMs, having dedicated data expertise prevents the PM from becoming a bottleneck on all analytical work.

“This will slow down decision-making with another voice in the room.”

Actually, it speeds things up. When the data specialist is in the room from day one, the team gets answers immediately. No waiting for external teams. No context switching. No three-day turnaround on simple queries.

Yes, the initial meeting might take an extra 15 minutes because you’re considering more perspectives. But the overall cycle from question to validated answer shrinks dramatically. I’ve seen this reduce decision cycles from weeks to days. And the best: sometimes you don’t even start building anything because data tells you your idea doesn’t move any metric.

How to Start the Transition

If you’re convinced this is worth trying, here’s how to start without disrupting your entire organization:

First, identify your most data-intensive team. The one that constantly sends data requests to centralized teams. The one where the lack of immediate data access creates the most significant bottlenecks.

Second, find the right Data Lead candidate. Look for someone with analytical skills but also strong communication abilities and collaborative instincts. Technical brilliance without collaboration skills doesn’t work in a quartet.

Third, explicitly establish the new decision-making structure. Document what decisions require quartet input. Create space in calendars for quartet working sessions. Make it visible to the organization that this team is trying something new.

Fourth, reflect and, if possible, measure the impact. How much faster are you validating ideas? How much less time are you waiting for data? Are you making better decisions as measured by outcomes, not just outputs?

Fifth, iterate and adjust. Expand to other teams. The first quarter will be messy. You’ll refine your rituals and processes. That’s expected.

Final Words

The quartet model signals that your organization treats data as a product driver rather than a support function.

The companies figuring this out are moving faster, making better bets, and building products that actually solve user problems instead of just shipping features. They’re not waiting days for data requests. They’re not making decisions based purely on intuition or authority. They’re combining the strengths of product thinking, user empathy, engineering, and data rigor.

I think modern product work needs data fluency right from the beginning. And if your PMs, designers, and engineers aren’t ready to take on that work themselves, you need a data specialist in the room making decisions alongside them.

So let me ask you: are you still running a trio, or are you already moving toward a quartet in your organization? And if you’re still running a trio while building data-intensive products, what’s stopping you from evolving?

Enjoyed this post? You might like my book, Data as a Product Driver 🚚.

Why Data as a Product Driver?

Throughout my career, I have read both product management and data books extensively. Product management books taught me about user research, product discovery, and becoming a better manager, but they treated data as something that happens elsewhere. Data books taught me about data modeling, warehouses, and how to implement ML and AI applications, but they didn’t do that from a product perspective.

I never found a book that bridges both worlds. So I wrote it.

In the book, I detail the strategies for transforming product organizations using data, including outcome-oriented measurement, validating ideas through product discovery, treating data as a product, and more!

Who is this book for?

I wrote this book for executives and senior leaders driving organizational transformation: CTOs, CDOs, CPOs, VPs, and Directors who are struggling to get value from data and data teams.

This book shows leadership teams the importance of making data people more product- and business-fluent, and product people more data-literate.

These challenges and strategies typically affect companies with 1-20 data people and growing organizations, which need to support an increasing number of use cases to inform and drive product decisions.

If you’re asking questions like “How do we organize our data teams?” or “Should we centralize or distribute our data capabilities?”, “How do we make our product teams work with data?” or “How do we actually prepare for AI adoption beyond buying tools?” This book gives you strategies and a framework for answering them.

Having said that, the book also serves product managers, data professionals, and anyone bridging the gap between data professionals and business and product stakeholders. It will help them understand how their role fits within this broader transformation.

Buy the book on Amazon

I am also sharing about the book and the writing process in this blog. Thanks for reading!

After several years living through the same pattern in many organizations, I came to the conclusion that in the most data-mature organizations, two things tend to happen:

First, dedicated data leadership positions eventually become unnecessary. Second, product, engineering, operations, marketing, and other functions increasingly absorb responsibilities that once belonged to specialized data teams.

In younger companies I recently consulted for, these shifts appear even earlier, with core teams assuming data ownership from day one and treating analytical capabilities as a native part of product development rather than an add-on function.

Let’s dissect each statement here to better understand why this is happening.

On the one hand, the main reason for data leadership roles disappearing is that when data fluency truly permeates executive and middle management layers, having someone who exclusively “represents data” at the leadership table becomes redundant. On the other hand, the everyday work of analysts, engineers, and scientists evolves as other roles, such as product managers and software engineers, assume greater ownership of experimentation, insights, and data quality within their domains. Finally, tools in the data space, as well as AI, make data management easier for non-data professionals.

And I believe this isn’t a failure. It’s simply the outcome of an evolutionary trend that has done precisely what it was meant to do.

In this article, I walk you through why companies end up in this pattern, how the data leader role evolves in data-mature organizations, and the implications for data professionals.

Understanding the Evolution

To grasp why data organizations reconfigure, we first need to understand how “old” companies got there, as most progressed through three distinct phases of data maturity.

In the first phase, organizations build their data warehouse. Business Intelligence (BI) teams create reports and dashboards for executives. Data serves primarily for descriptive analytics and financial reporting.

In the second phase, BI teams transform into data platform teams, with ML and AI scientists and engineers joining the crew, and even product analysts and analytics engineers. These professionals work in centralized teams, operating as internal service providers to the rest of the organization. They report to a Head of Data or a Chief Data Officer (CDO).

The third phase marks the transformation in which these centralized structures begin to break down. Organizations stop organizing by function and create cross-functional teams responsible for solving specific user problems or business opportunities. Data professionals embed within business and product teams rather than serving them from a separate unit.

Embedded data people typically adopt a matrix model: they do day-to-day work with product teams while maintaining a dotted line to a functional data manager (i.e., Data Science Manager) for career development and to maintain standards in their function.

However, many newer organizations never build a separate BI or central data team. Instead, product and business leaders who get data work run the core platform from day one (usually under Engineering or the CTO). At the same time, a small set of analysts use easy tools to turn questions into answers. That starting point changes how maturity looks: rather than moving from centralized to distributed, these companies often begin distributed and add central roles, such as functional data managers, only when complexity forces them to.

The New Home for Data Professionals

In mature, data-fluent companies, the “home” for data-specific roles (if they exist as standalone jobs!), such as analysts, analytics engineers, and data scientists, is usually the cross-functional team they support, not the data organization. Their calendar, priorities, and impact live with product and business teams; functional data leadership becomes a chapter lead role focused on craft, hiring, and career paths.

Aside from functional data managers taking on a lighter chapter role, mini data groups emerge inside departments, both in young and mature companies. Some organizations group embedded data people who support related business teams into small mini-data teams. These clusters sometimes have their own data lead, focused on the department’s needs. Their role is narrower and closer to the business, unlike the functional leadership roles of the past.

Meanwhile, the Engineering org often absorbs what remained centralized: the data engineers. Data engineering and the data platform are usually moved under the CTO. Their mission is to offer self-service tools, provide reliable core data, and support governance. They treat the data platform like a product with internal users.

Implications for the Head of Data role

As data literacy spreads, the Head of Data or CDO role changes or sometimes disappears. Where that role remains, it often pivots. In companies that did not create a Head of Data, these accountabilities are distributed across product and engineering leadership from the start.

This evolution creates serious career choices for data leaders. Once the Head of Data role (or CDO) becomes unnecessary, I’ve witnessed several paths open up:

Move into broader operational leadership. Data leaders with strong cross-functional experience transition into roles such as COO or head of product strategy, where they coordinate cross-departmental strategy efforts.

Lead the data platform as a product. Some focus on the centralized capabilities that remain: the data engineering and the data platform.

Become a domain product leader. In areas where data and ML/AI create differentiation, some leaders step into product leadership roles for those domains.

Leave the organization. This happens only when companies mismanage the transition or when leaders resist the shift. It’s not uncommon, and it’s a sign the organization didn’t plan well or moved faster than its people were ready for.

Three responsibilities must still exist

Even without a standalone data leader, three critical functions must have clear ownership. When organizations eliminate the CDO or Head of Data role, they sometimes assume these responsibilities will naturally distribute themselves. They don’t. Without explicit assignment, these functions atrophy, and the organization regresses to pre-transformation behaviors. The three responsibilities are:

Someone in Product Consistently Pushing for Data-Driven Decisions

This person, typically a VP of Product or Chief Product Officer, must actively challenge intuition-based roadmaps. They ensure product discovery and experimentation become standard practice. They ask questions like “What does the data tell us?” and “How will we measure success?”

The product leader must model data-driven behavior personally. They should reference metrics when explaining strategic choices. They should celebrate teams that pivot based on A/B test results.

Someone in Technology Championing Platform Investment

This person, usually the CTO or VP of Engineering, treats data infrastructure as a product with its own users, service level agreements, and continuous improvement cycles. They advocate for sustained investment in the data platform even when business pressure to redirect resources toward customer-facing features.

The technology leader must track platform health metrics and defend maintenance budgets. They also champion the evolution of platform capabilities. As the organization matures, self-service requirements grow more sophisticated. Teams need better tooling, faster data access, and more reliable governance mechanisms.

Someone Ensuring Data Literacy and Governance Continue to Rise

This person, often sitting in Product or Technology leadership, creates formal programs to build this capability. They establish structured data training programs that ensure data skills are systematically spread across the organization.

This responsibility includes governance oversight. As data ownership is distributed across domains, someone must ensure consistency in definitions, quality standards, and compliance practices. They establish cross-domain governance councils led by product teams.

Preparing for change as a Head of Data

If you are a data leader, you need to start being proactive and preparing for the future that I explained in this article, rather than being reactive. That’s why I recommend:

1. Raise data literacy fast. Give teams the skills and tools to be self-sufficient.

2. Develop new leadership skills. Grow in operations, product, or technical strategy so you’re ready for the next role.

3. Document your practices. Create standards and playbooks that survive without central enforcement.

4. Build cross-functional relationships. Your next role will rely on them.

I genuinely believe the future of data isn’t a data organization. It’s a company where every team uses data as naturally as they write code or talk to customers. Data analytics, data science, AI, etc., are core skills, not separate services or functions.

For data leaders, the challenge is to welcome this shift even when it means your own role will change.

Enjoyed this post? You might like my book, Data as a Product Driver 🚚.

When your marketing team needs a quick analysis of a campaign performance, how long does it take to get answers? A day? A week? A month? If you’re working with a centralized data team, the answer is probably: too long. Yet, this simple example illustrates one of the most common scaling challenges in growing organizations.

As the demand for data across the business increases, a single centralized team simply cannot keep pace. Analysts become bottlenecks, priorities conflict, and leaders lose confidence in the data function’s ability to deliver.

That’s why I believe we need a sustainable way to scale data organizations that are able to deliver at speed and with the right business context. Also, in the era of Generative AI (GenAI), I think it should be done without placing a dedicated data analyst, scientist and engineer in every single team.

Let’s explore a better way in this article.

Why Central Data Teams Struggle to Scale

Most companies start data organizations with the classic centralized structure, where all data professionals report into one team. Business units like Marketing or Product, channel their different needs into one shared queue for everything from routine reporting to advanced modeling.

While this structure works well for small organizations, it quickly breaks down under the pressure of growth. The central team becomes a significant bottleneck. Analysts are forced to constantly switch domains and start specializing in a specific area, at the cost of having to hire one analyst for each specific domain.

Why Full Decentralization Doesn’t Always Work Either

Fully embedding a dedicated data professional directly inside each business unit ensures deep integration and business context, but it introduces new risks that often outweigh the benefits.

On one hand, individual experts become isolated and mentorship and career growth becomes more difficult to manage. On the other, without central coordination, individuals begin to define things differently, leading to inconsistencies and confusion.

Finally, organizations run into an inherent capacity problem. It becomes almost impossible to align resources precisely with demand; some experts are over-stretched while others are underutilized.

A More Flexible Alternative: The Mini-Data Organization

So my proposal lies not at the extremes, but in a functional middle ground.

Instead of embedding a single person everywhere, you create small, integrated data teams that support clusters of teams, for example, a department (3-4 teams) dedicated to ‘Customer Growth’ or ‘Core Experience’ that can also leverage a GenAI skillset. These mini-data organizations, typically 3–5 people, function as a cohesive unit and include:

• One or two domain-focused analysts

• A specialist focused on data engineering support

• One or two optional data scientists if the domain requires it

These teams support the department operationally but they functionally report to the same person, a manager within the mini-data team. This manager then reports to the central data organization. This ensures every individual has a clear career path and peer support. They operate using shared tools and definitions, coordinating with a central platform team that guarantees standardization across the enterprise.

Why This Model Works

Ultimately, this model succeeds because it addresses the core, competing demands of the other structures. It provides the focused business context needed for high-impact results while offering the professional framework essential for talent retention and growth.

The structure is inherently flexible, which is a key benefit. By serving several business units, the mini-teams can adaptively shift focus to the most important priorities, effectively addressing resource under- or over-utilization. Additionally, functioning as a true team ensures consistent execution and knowledge sharing.

On top of that, a critical emerging factor that makes the mini-data organization model even stronger is the rise of GenAI.

GenAI tools can significantly automate many basic data tasks, such as generating routine reports, assisting with initial data checks, and converting simple requests into data queries. This allows the dedicated people in the mini-teams to no longer spend time on these low-level activities. Instead, they can focus on more complex and critical business problems that require their deep expertise. This synergy enables smaller data teams to accomplish the work of much larger teams.

What It Takes to Get Started

If this strategic alignment resonates, how do you begin to implement it?

You don’t need to reorganize your entire data team overnight. Start by picking one department that’s struggling or constantly competing for attention from your central team. Form a small squad of 2-3 data people to support just that area for a few months. See what works, what doesn’t, and adjust before expanding the model elsewhere.

On the GenAI side, start with the tasks your analysts and Product Managers complain about the most: usually the weekly repetitive work or simple data extractions. Choose one or two AI tools or features (from tools you already use) that can handle these tasks and let your team experiment with them on real projects.

When PMs understand what GenAI can handle quickly, they’ll stop routing every small question through the data team and save analyst time for questions that genuinely need deeper thinking.

When adopting this model, your core data governance and definitions must remain very stable; otherwise, this semi-decentralization will only amplify existing issues (though not as severely as with full decentralization). Without strong shared standards, you risk inadvertently recreating the same inconsistencies and data silos you were trying to eliminate.

Final Thoughts

The mini-data organization model is the result of data organizations having to adapt to the evolution of businesses and the rise of GenAI.

As businesses evolve, the demands on your data function will fluctuate, and this hybrid approach gives you the flexibility to respond without constant reorganization. Building effective mini-data organizations require investment in the shared platforms, the governance frameworks, the communication channels, and the cultural norms that keep these teams aligned while allowing them to operate with autonomy.

When done well, this model positions your data organization to evolve alongside your business.

Enjoyed this post? You might like my book, Data as a Product Driver 🚚.

Most product management literature will tell you that internal product management is complex. I agree. Data Platform teams might be tracking adoption rates (”80% of teams use our data catalog!”) while leadership questions their return on investment (RoI).

On top of this, your users are colleagues you can grab coffee with or Slack anytime. But you’re building data infrastructure that enables them to deliver business impact, which puts you at least one step removed (sometimes two or three) from the outcomes that actually matter to the company. That’s the paradox of internal platform work: easy access to your users, but hard to measure your impact.

In this article, I walk you through the different types of goals Data Platform teams can use —from platform outputs to business outcomes —and strategies for getting started.

The Four Layers of Platform Goals

I’ve spent my career managing teams that build data platforms. After years of struggling with goal-setting, I’ve found it helps to think about platform goals in four distinct layers, from farthest to closest from direct business impact, as you can see in the following image:

Now, from the bottom of the pyramid to the top, let me introduce the layers:

1. Platform Outputs: measures features shipped, tickets closed, tools implemented.

2. Adoption, Engagement, and Reliability Metrics: measures usage rates, active users, system uptime.

3. Efficiency Metrics: measures time saved, manual work eliminated, decision cycle time reduced.

4. Direct Business Outcomes: measures revenue impact, cost reduction, risk mitigation.

Of course, everyone wants goals at Layer 4 (Direct Business Outcomes). But that’s not always possible for data platform teams. Think of the pyramid as a hierarchy of preference, not a hierarchy of value. Aim as high as you can and be explicit about which layer you’re operating in.

Now, in the following sections, let’s deep dive into each layer.

Layer 1: Platform Outputs

This is where all platform teams start, but where you don’t want to stay for long. Platform outputs are things you directly control and ship. They’re easy to measure but tell you nothing about impact.

Examples of platform outputs include:

• Features shipped this quarter

• Tickets closed

• Tools implemented

• Migrations completed

• Datasets documented

• Machine Learning models deployed

While these are not bad per se, they only show that your team is busy, but don’t articulate how they are helping the organization. At some point, and especially after the ZIRP (zero-interest-rate policy) era is over, leadership starts asking more complex questions about return on investment. When capital was cheap, companies could afford to fund platform work on faith. Now, shipping features without showing their impact is a fast path to budget cuts.

Use Layer 1 goals only when you are starting a new team or dealing with technical debt that must be paid down urgently. Try to move quickly to deeper layers for most of your initiatives.

Layer 2: Adoption, Engagement, and Reliability Metrics

This layer measures whether people actually use what you build and whether it works when they need it. You’re still not measuring business impact, but you’re getting closer.

Examples include:

• Platform adoption rates (percentage of teams using your data platform or its subsystems)

• Active users per month or week

• Query volumes through your platform

• System uptime and reliability (DORA metrics like deployment frequency, lead time, mean time to recovery)

• Reduction in data quality incidents

• API call volumes

• Support ticket reduction

Adoption is a useful metric. But it’s not a measure of success by itself. As Camille Fournier and Ian Nowland warn in their book Platform Engineering (2024): “The risk of using adoption metrics when you are targeting a captive or nearly captive audience is forgetting to build what people want, and instead building what you think they should want and then forcing them to use it.”

Let’s see how this can be improved in the next layer.

Layer 3: Efficiency Metrics

In this layer, you’re measuring whether your platform makes work faster or easier. These metrics show productivity gains such as time saved, manual work eliminated, or faster decision-making.

Fournier and Nowland explain: “Core to the value of platform engineering is the concept of leverage—meaning, the work of a few engineers on a platform team reduces the work of the greater organization. Platforms achieve leverage in two ways: making applications engineers more productive as they go about their jobs creating business value, and making the engineering organization more efficient by eliminating duplicate work across application engineering teams.”

Examples of this leverage include:

• Time from question to insight reduced from 8 hours to 1 hour

• Self-service rate increased from 20% to 60% (freeing analysts for strategic work)

• Decision cycle time decreased from weeks to days

• Time to onboard new data sources reduced from weeks to days

Having said that, and as stated before, there is nowadays a pressing need for data platform teams to deliver positively on efficiency gains. However, it is also a good compromise if you and your senior management peers agree to acknowledge that when your data platform team reduces an analyst’s weekly preparation time from 8 hours to 1 hour, you haven’t necessarily reduced your payroll by seven hours’ worth of salary. Instead, you’ve created capacity for higher-value work, which, at the moment of realizing the efficiency gain, is very hard to measure its impact.

Still, if you want and can calculate the impact of data platform work to the penny, there is Layer 4.

Layer 4: Direct Business Outcomes

This is the gold standard. Your work directly connects to money, risk reduction, or strategic outcomes that the business cares about.

Examples include:

• Ability to link specific A/B tests to revenue increases and then attribute them to the platform

• Cost reduction from infrastructure optimization

• Revenue attribution from recommendation systems or personalization engines

The challenge with Layer 4 is proving causation, not just correlation. It might be easy to attribute cost reduction to the deletion of several unused data assets. Still, it is much more complex to determine which part of a recommendation engine's impact can be attributed to the data platform itself.

If you want to go down that path, you’ll create complex calculations in spreadsheets that assume too much information. However, if everyone in the organization uses the same assumptions (good luck with that!), your attribution tracker won’t provide numbers that Finance can use, but they will still be useful for comparing initiatives.

And another challenge most companies ignore: the cost side of the equation. Let’s say your data platform team costs $1 million per year in salaries. You spend another $250,000 on tools and infrastructure. That’s $1.25 million in annual operating costs. If you implement a data lineage tool that saves analysts time, you need to show that the value created exceeds the corresponding investment.

Next Steps: Moving Up the Layers

So far, I’ve shown you that the four layers of platform goals exist on a spectrum from outputs to outcomes. Your challenge now is moving up that spectrum. Here’s my recommendation on how to do that:

Establish your baseline. Audit your current goals and classify them by layer. If everything sits at Layer 1, you have work to do.

Pick one capability to instrument. Choose something your team already built that stakeholders use regularly. Add basic adoption metrics (Layer 2). Track who uses it, how often, and whether usage grows.

Find one efficiency story. Identify where your platform demonstrably saves time or eliminates manual work (Layer 3). Quantify it, even roughly.

Document your costs. Calculate your team’s annual operating budget, including salaries, tools, and infrastructure. You need this baseline before claiming any Layer 4 outcomes.

Start the conversation. Share this framework with your leadership. Ask which layer they expect platform teams to operate at. Get alignment before you invest months pursuing the wrong metrics.

The goal isn’t reaching Layer 4 immediately. The goal is to operate at the highest level you need and can credibly measure, and to be transparent about the distance between your work and business outcomes. That honesty, combined with deliberate progress up the layers, builds the trust platform teams need to survive budget scrutiny.

Enjoyed this post? You might like my book, Data as a Product Driver 🚚.

If your company sets Objectives and Key Results (OKRs) like “Launch mobile app redesign by Q2” or “Implement five new dashboard features,” congratulations, you’re great at running a feature factory! With these output-oriented goals, you measure what you deliver, but not the impact it creates.

Now, consider outcome-focused goals instead, such as “Increase mobile user activation from 45% to 65%” or “Boost customer lifetime value by 20% through better recommendations.” These goals go far beyond. Instead of tracking tasks, they demonstrate the tangible impact your work has on the business and its users.

This is where data and metrics become essential for product-driven organizations. Without clear metrics, you make decisions based on opinions, gut feelings, or whoever has the loudest voice in the room. Data provides the objective foundation to validate whether your products are actually working, which features drive value, and where to invest next. More importantly, metrics create accountability: they force teams to define success upfront and honestly assess whether they achieved it.

Shifting from outputs to metric-driven outcomes is worth it, but it’s not always easy. In this article, I walk you through the most common challenges organizations face and share practical strategies to overcome them.

I begin with the basics: the difference between output and outcome, plus a quick exercise to help you spot it in action.

What is the difference between outputs and outcomes?

One of the most common mistakes organizations make when starting goal setting with OKRs is confusing outputs with outcomes. The distinction is important to understand, so let’s see if it becomes clearer with the by-the-book definitions and some examples:

Outputs are what you produce. Features shipped, reports generated, experiments launched. They’re tangible, controllable, and comfortable to measure.

Outcomes are what you achieve. Customer behavior changes, business metrics improvements, and user experience enhancements that result from your outputs.

Now, can you guess which of the following goals are outputs vs which ones are outcomes?

1. Increase mobile user activation rate from 45% to 65%

2. Launch redesigned checkout flow by the end of Q2

3. Improve customer lifetime value by 20% through better recommendations

4. Reduce customer churn rate from 8% to 5% within 6 months

5. Run 3 A/B tests this quarter

6. Complete migration of the legacy dashboard to the new platform

You guessed it right if you think objectives 1, 3, and 4 are outcome-based. And while it might be easy to do such an exercise, I recall that I didn’t have it that clear the first time I participated in implementing OKRs more than 10 years ago.

We required numerous iterations, coaching, and asking the right questions to achieve more outcome-based OKRs that would guide our work. Additionally, I recall us improving quarter by quarter by simply reflecting on it and trying to improve, having more metrics to choose from, and calculating KR baselines just in time to set goals. So, don’t worry if you feel a bit stuck right now.

Iteration is essential, and so is simplicity. What follows is my first recommendation for implementing company-wide OKR systems.

How many OKRs should you have?

OKRs were created by Andy Grove at Intel in the 1970s, building on Peter Drucker’s Management by Objectives (MBO) framework. Later, in 1999, John Doerr implemented OKRs at Google, and their popularity expanded. Doerr published what might be the most influential book on OKRs in 2018, Measure What Matters, in which he quotes Andy Grove for the number of Objectives an organization might have:

“The one thing an [OKR] system should provide par excellence is focus. This can only happen if we keep the number of objectives small… Each time you make a commitment, you forfeit your chance to commit to something else. [...] We must realize—and act on the realization—that if we try to focus on everything, we focus on nothing”.

“The art of management lies in the capacity to select from the many activities of seemingly comparable significance the one or two or three that provide leverage well beyond the others and concentrate on them.”

On the number of Key Results, Doerr mentions: “If an objective is well framed, three to five KRs will usually be adequate to reach it”.

So in summary, a few objectives with a few KRs. And then, the community organically adopted the 3x3 framework (three objectives with three key results each) because of its simplicity and elegance.

In such a system, with nine total key results to track, companies can maintain clarity and accountability while still having enough metrics to capture different dimensions of success.

That said, the 3x3 rule is a guideline rather than a hard rule. Some companies may require 2-5 objectives or 2-4 key results, depending on their specific context.

With the company’s OKRs set at approximately 3x3, the next step is to explain the most common dysfunction in organizations adopting OKRs.

The Cascading OKR Trap (And How to Escape It)

Many small and medium-sized organizations (with up to 500 employees) make the mistake of excessive cascading when setting OKRs. They create 3x3 outcome-oriented company-level OKRs, which is good. And then, each department or function creates its own OKRs, and then each team makes its own OKRs.

This creates a complex and unnecessary hierarchy of goals that dilutes focus and encourages siloed thinking.

Picture this scenario: The company sets a KR to “Increase annual recurring revenue (ARR) by 30%.” Then, the Product team creates its own KR: “Launch three major features to drive revenue growth.” The Data team responds with: “Provide analytics support for product feature launches.”

On the surface, this seems logical, but in reality, you’ve created a game of organizational telephone where the original outcome gets lost in translation due to the company’s organizational structure.

The alternative approach is simple: minimize cascading.

Starting with clear company-level outcomes-driven OKRs is great. You can set yearly company OKRs and then break them down into quarterly goals.

But after that, every team should contribute directly to those outcomes rather than creating intermediate goals. If the company wants to increase ARR by 30%, cross-functional units should identify specific initiatives that directly impact that metric.

A cross-functional User Activation team, comprising a Product Manager, a UX Designer, data professionals, and engineers, might focus on improving user activation rates within the first 30 days and measure its contribution to ARR. They don’t need a specific OKR for that.

If there are any activities that they do that are not part of the company’s OKRs, that’s fine too. Just have them written somewhere as other deliverables or operational activities.

When Cascading OKRs Actually Works

I recommend minimal cascading in most situations, but I agree that it may be the only viable option in certain contexts. Cascading makes sense when you have a large organization (think 500+ employees) or when you have distinct business units that operate semi-independently. In these cases, one additional layer of cascading can provide clarity without creating bureaucracy.

For example, if your company has separate divisions serving different markets or customer segments, each division may need its own OKRs that align with company objectives. The key is to limit cascading to one additional layer and ensure that each level maintains a focus on outcomes.

Now, creating and maintaining cross-functional teams can also be challenging, so I outline what typically works in the next section.

How to create cross-functional autonomous product teams

Suppose you work in an organization where a Business Manager is ultimately responsible for deciding what to do and when, and he/she spends the day talking to Engineering, Data, and User Experience to get his/her needs and goals fulfilled. In that case, you are in the opposite spectrum of what a cross-functional autonomous product team should be.

In cross-functional product teams, no single function is treated as a support function, merely answering questions, creating mock-ups, or reports for others to interpret. Cross-functional product teams have the necessary members from each function (engineering, data, product, and user experience) to focus on solving a specific user or business need or opportunity.

What is more important, they have the autonomy to suggest and validate what to work on. For example, suppose the company’s goal is to increase profitability, and the team scope is user recommendations. In that case, the team should have the capacity to ideate, validate, and measure which initiative makes sense to prioritize at this time.

In such cases, there is no need for OKRs to cascade into functions using different wording. What might make more sense is to identify the possible contribution of the team to a given OKR.

While minimizing cascading prevents the organizational telephone problem, you still need a structured way to connect company OKRs to team initiatives; that’s where the W Framework comes in.

The W Framework

When cross-functional teams receive company direction in the form of company OKRs, they need a structured process to propose how they’ll contribute. The W Framework, developed by Lenny Rachitsky and Nels Gilbreth and illustrated next, provides exactly that structure.

The framework creates a four-step conversation between leadership and teams. First, leadership shares context: the high-level strategy and company OKRs. Second, teams respond with proposed plans and initiatives they believe will improve those OKRs. Third, leadership provides feedback and integrates all team plans into a cohesive approach. Fourth, teams make final adjustments, confirm their buy-in, and start working.

This back-and-forth ensures alignment without the rigidity of cascaded OKRs. Teams maintain autonomy in proposing solutions while leadership ensures coherence across the organization.

Most companies run this exercise each time executives share their chosen strategy. Some do it quarterly, others biannually or annually, depending on their planning rhythm and organizational maturity.

Now, you might be thinking: “This all sounds great, but where do I actually begin?” The answer depends on your role within the organization and the timeline you’re working with.

Where to start when implementing OKRs

Your starting point depends on two factors: your role and your planning horizon. I break this down into two scenarios: what to do in the next quarter versus planning for the next year, and how your responsibilities differ whether you’re a team manager or part of senior leadership.

For Senior Leadership: Setting the Foundation

If you’re a CTO, CDO, CPO, or VP of a small to medium organization (500 employees), your first move is to resist a common temptation: don’t request OKRs from every department and team. This creates the cascading trap I described earlier.

Instead, focus your energy on two critical activities:

First, establish clear company-level OKRs. Involve your leadership team in identifying 2-4 objectives, each with 2-4 key results. Start with outcome-based goals whenever possible, but avoid getting stuck in analysis paralysis, seeking perfection. If some of your key results are output-based in your first iteration, that’s fine. As mentioned earlier, companies significantly improve their OKR quality simply by running the exercise quarter after quarter.

Second, ensure that teams connect their initiatives to the company’s OKRs. Rather than demanding team-level OKRs, implement the W Framework. Make it clear that every prioritized initiative should map to at least one company objective. If teams are working on something that doesn’t connect to any company OKR, that’s a signal to investigate whether the work is truly strategic.

For Team Managers: Moving Toward Outcomes

If you’re leading a product team, data team, or engineering team, your approach differs based on your planning cycle.

For quarterly planning:

Start by auditing your current goals. Take some time and categorize each goal as output-based or outcome-based. If most of your goals are outputs (features shipped, reports delivered, systems migrated), you now have clarity on what to change.

For your next planning cycle, try converting just one or two output goals into outcome goals. Instead of “Launch new recommendation engine,” ask yourself: “What user behavior or business metric should this recommendation engine improve?” That becomes your outcome: “Increase average session duration from 8 minutes to 12 minutes through better content recommendations.”

If you don’t have baseline metrics for your proposed key results, don’t wait. Calculate them now using available data. If the data doesn’t exist, identify proxy metrics you can measure today.

For annual planning:

Use the longer horizon to build your measurement foundation. Identify gaps where you lack measurement, then prioritize closing those gaps based on business impact by considering which metrics you can influence and how they are related.

Document clear definitions for each metric you track. Get stakeholders to agree on these definitions. I’ve seen too many debates about whether metrics are improving simply because different teams calculated the same metric differently.

Now, in the next section I present other “smaller” challenges on the process and ways to overcome them.

Challenges and How to Overcome Them

Implementing outcome-oriented measurement sounds easy in theory, but you’ll face resistance and obstacles from various parts of your organization. I’ve encountered these challenges repeatedly across different companies, and I present the most common ones as follows, along with practical strategies to address them.

Missing Metric Baselines

Teams often attempt to set metric targets without established baselines, creating goals that remain in perpetual limbo, such as “Increase active users from X% to Y% (baseline pending).”

Solution: Start with imperfect data. Use proxy metrics when direct measurement isn’t feasible. Run focused “data sprints” to define, instrument, and establish initial measurements for critical metrics.

Teams Don’t Act on OKRs

Teams struggle to translate high-level metrics into actionable daily activities, resulting in “set-and-forget” company objectives with little impact on actual work.

Solution: Increase OKR visibility through weekly check-ins and dashboards. Implement OKR syncs where teams report their current metric status, discuss initiatives that impact metrics, and identify blockers.

Orphaned Metrics

Key metrics remain unchanged when they lack clear ownership, with each team assuming someone else is responsible for improving them.

Solution: Explicitly assign ownership of each key result to a specific team leader. For cross-functional metrics, designate one metric “owner” accountable for coordination.

Technical Debt Prioritization

Outcome-driven approaches can inadvertently marginalize critical non-business initiatives, such as addressing technical debt, that don’t directly impact customer-facing metrics.

Solution: Allocate dedicated capacity (typically 20-30%) to engineering-led initiatives on a quarterly basis. Frame large technical initiatives in terms of business outcomes when possible.

Metric Overload

Organizations track dozens or even hundreds of metrics, creating analysis paralysis as teams try to improve everything simultaneously.

Solution: Limit each team to focusing on 1-3 company key results and metrics during any given period.

And with this list of challenges, you’ve made it to the end of the chapter. The last section summarizes the article and its key takeaways.

Summary and Key Takeaways

Shifting from output-oriented to outcome-oriented measurement represents one of the most important transformations an organization can make. The transition requires patience and iteration. Your first (and second) list of OKRs won’t be perfect. You’ll have missing baselines, some output-based goals, and teams struggling to connect daily work to quarterly metrics. That’s normal. Every organization I’ve worked with improved quarter by quarter simply by running the exercise, reflecting on what worked, and trying again.

Here are the key takeaways:

• Outputs are what you produce; outcomes are what you achieve. Features shipped don’t matter if user behavior doesn’t change or business metrics don’t improve.

• Keep OKRs simple. Follow the 3x3 framework to start with: three objectives with three key results each. More than that creates complexity without adding clarity.

• Minimize cascading. Have teams contribute directly to company OKRs rather than creating cascaded departmental goals that play organizational telephone with your strategy.

• Use the W Framework for alignment. Let leadership set the context and company OKRs; teams propose plans, leadership integrates feedback, and teams confirm buy-in before execution.

I hope this article has been helpful. Please let me know if you have any further challenges or ideas on implementing OKRs in organizations!

Enjoyed this post? You might like my book, Data as a Product Driver 🚚.

In previous articles of the series (transformations #1 and #2), we focused on how to organize Data Analysts, Scientists, and, to a lesser extent, Data Engineers. In this article I finally focus on Data Engineering work by explaining how to scale Data Platform teams.

Having re-organized Data Platform teams of different sizes multiple times in my career in different contexts and organizations, I share here my learnings and a standardized step-by-step process you can follow if you are facing similar challenges.

Getting a good start

How you start a Data Platform team will vary from company to company. I recommend hiring one or two Data Engineers to form a Data Platform team at the same time you hire your first Data Analyst(s).

These Data Engineers will be responsible for the data infrastructure of your company (either bought or built). They will strike a balance between the speed at which decision makers need data and tools to extract value out of it and the rigor one should treat data and its lifecycle. For example, if you let anyone use the data infrastructure at their own will, it will quickly get clogged with dirt and underused tables and documents.

In some cases, Data Engineers may also be in charge of moving the initial data from operational systems to the analytical database and creating the first “datasets as products”. These will be used to visualize trends and extract relevant insights for the rest of the company.

Because of that, it is useful to distinguish between platform, “datasets as product” effort or even data visualization work within the team early. Enablement and governance activities are additional areas where Data Engineers might become overburdened, so keep an eye on these as well.

As the company grows and its data needs expand, the workload of the Data Platform team increases. The company might now need tools to manage the lifecycle of Machine Learning models, tools to perform A/B testing, introduce a data observability tool, aggregate data from new domains, etc. With these new responsibilities, the platform team will need to grow.

Steps to scale a Data Platform team

When a Data Platform team grows from 2 to 5–10 engineers (or even 25), roles and duties get hazy, cognitive load increases and work becomes more specialized. The team will frequently break organically into sub-teams also. People will naturally focus on different areas and a new communication system within the team and with stakeholders will emerge.

What occurs is that the organization attempts to treat everyone as if they are on the same team, but they are not. This typically causes the team to lose focus and can also convert them into a bottleneck in the view of stakeholders.

These issues feel very aligned with the reasons for applying a grow-and-split pattern for forming new smaller and more focused teams. Growing and splitting the Data Platform team allows for the distribution of tasks and responsibilities, preventing overload and ensuring that each tool has the right people maintaining it.

But how to do it? How can you effectively organize a Data Platform team of 7 to up to 25 engineers? Let’s detail five steps to split a Data Platform team:

1. Analyze through the Team Topologies lens;

2. Define capabilities;

3. Group capabilities by affinity;

4. Recommend a new structure and its trade offs;

5. Implement and iterate.

#1 Analyze through the Team Topologies lens

Based on Team Topologies research there are three basic types of teams (and an extra type not relevant for this article):

• Stream Aligned Teams are the primary delivery team which has end-to-end accountability for delivery of a software product or service. Analytics Engineers focused on creating datasets as products fall into this group.

• Platform Teams provide the tools, utilities, and technical services that make it easier for Stream Aligned Teams to do their job, typically delivering “X-as-a-Service” capabilities. Data Engineers focused on maintaining the data infrastructure fall into this group.

• Enabling Teams act as “consultants” that help stream aligned teams to overcome obstacles, typically interacting collaboratively, providing guidance, training,… Whatever roles are working on defining and managing processes, data governance, golden paths,… fall into this group.

In this first step, you should analyze the activities the team is doing through the lens of Team Topologies, for example:

If aside from the data infrastructure, a Data Platform team also owns data assets as products (datasets, dashboards,…) and enablement or governance activities it means that the same group of people covers the work of three (!) different topologies. This results in difficult prioritization, increased cognitive load, lack of focus, individuals being a bottleneck, etc.

Some relevant follow-up questions to analyze the source of the problem might be:

• How big are the efforts on each topology?

• How many people are dedicated to each topology?

• Do we have people that are doing a little bit of everything?

• How many people would you need to successfully maintain both activities?

The outcomes of this step yields a basic idea of what cognitively diverse activities your team is now handling and how this affects their productivity, deliverables, motivation, and so forth.

If you want to explore more about team topologies applied to Data Engineering teams you can read this article by Pedro Gomes Mota: Team Topologies for Data Engineering Teams.

#2 Define capabilities

At this stage, it is obvious that the team needs some division of tasks and the ability for members to focus on a subset of these activities. To nail this divide, examine the capabilities that your Data Platform team currently supports. We understand a capability as:

• A service, product or dataset that allows users to do something.

• Denotes the “what”.

• Encapsulates the underlying functionality.

A “data platform” is already a capability per se (from the perspective of the company), but for the sake of this exercise you should go, at least, one level deeper. Ideally, you should specify capabilities as finely as necessary for the split. The outcome of this step is a list of capabilities your Data Platform team currently supports.

An example list of capabilities for a Data Platform team of 12 to 15 people would be as follows:

• Data storage infrastructure

• Core datasets as products

• Datasets as products developer experience

• Data models/schema management

• Data retention service

• Data deletion service

• Data access policies

• Data observability tooling

• Big data distributed processing

• Batch ingestion service

• Real-time ingestion service

• Notebook tooling for analysis

• Data visualization tooling

• Data infrastructure developer enablement

• Web analytics tool

• CI/CD for Machine Learning products

• Machine Learning model lifecycle management

• Feature store infrastructure and tooling

• Machine Learning platform enablement

• Real-time event tracking data as a product

• A/B test management and result analytics

• A/B test enablement

As an example of the level of detail: depending on the maturity of your platform it might make sense to just list a single capability named “Machine Learning Platform” for Machine Learning related topics. In some other organizations, you would like to separate “CI/CD for Machine Learning products” from “Machine Learning platform enablement” and assess future ownership of these capabilities separately.

#3 Group capabilities by affinity

The prior set of capabilities should be grouped by affinity in this step, first taking into account Team Topologies and then any potential limitations or restrictions your team and organization might have.

Restrictions may be related to:

• Limitations on capacity (the number of people who are available)

• The expertise and interest of those individuals

• The need for explicit optimizations that may result from a bigger data strategy

• In general, any form of trade-off

In the case of the example above there could be several ways of splitting the Data Platform team all with their pros and cons. Three alternatives are presented in the following figures:

Option 1 optimizes for having fewer teams (compared to Option 2 and 3) and separates enablement from platform and stream-aligned work. The “Data Infrastructure” team is quite heavily loaded though.

Option 2 keeps enablement in a separated team and groups 3rd party tools management under a “Data Solutions” team to split the load of the “Data Infrastructure” and “Business Intelligence” teams.

Option 3 clearly separates different specializations (ML vs. A/B testing for example) creating specific teams to focus on those domains. It also optimizes for keeping the enablement work as part of the domain, against team topologies recommendations.

#4 Recommend a new structure and its trade offs

The final step is to present the alternatives to Senior Management and recommend one to be implemented.

In our example case, we believe “Option 3” has the best chances to succeed long term and allow for further growth and scalability of the team. The pros and cons for this choice are:

• We explicitly separate work by domain (A/B testing vs. Machine Learning vs. Data Infrastructure vs. Datasets as Products) to allow individuals to focus and grow in a specific area.

• Even though it means more teams with less number of people each, the capacity we have can support this fragmentation.

• Because enablement work for each domain is tiny and particular, it makes no sense to bundle all enablement work under the same team. We optimize for keeping enablement work in the individual teams responsible for the technology because we believe it will feed back them better.

• We feel it makes sense for the “Business Intelligence” team to be responsible for supplying the core data as a product to third-party analytics tooling as a trade-off between “Data Infrastructure” and “Business Intelligence” teams.

#5 Implement and iterate

After deciding on the best organization, you must communicate and implement the change. Two considerations must be made during this step:

You should be on the lookout for issues of contention and feedback from the new organization. You may wish to revisit the operating model in 3 or 6 months and make minor changes, and be receptive to it.

Because individuals will no longer be participating in the same ceremonies or establishing objectives together, new teams may lose day-to-day interaction with old colleagues. Make sure that the overarching Data Platform team continues to meet on a regular basis for the activities that make sense, such as demos, weekly lunches, socials, and so on.

Final words

In this article we’ve summarized the steps to scale a Data Platform team from the learnings of having done this type of reorganization several times before. For other transitions your Data team can go through you can check the rest of the articles of the Scaling Your Data team series:

• #1 From Support to Growth Oriented Data Teams

• #2 Navigating the Spectrum of Centralization vs. Decentralization in Analytics Teams

Enjoyed this post? You might like my book, Data as a Product Driver 🚚.

The second transition on the “Scaling Your Data Team” series focuses on the amount of centralization or embedding of your Analytics department, as well as how organizations move between the two extremes.

Deciding between centralization or decentralization is usually not a permanent choice. Instead, analytics teams (and sometimes the whole company) transitions back and forth between the two creating what Douglas McGregor, in his book The Human Side of Enterprise (1960), calls an “accordion effect”:

“First, a big movement toward decentralization takes place. A few years later, after the consequences described above have taken their toll, top management decides that things have gotten out of hand, and there is a general tightening up in the direction of centralization. The inability to control a large, complex organization centrally leads after a while to a new attempt at decentralization.”

In the next sections we will go in detail through the different ranges of the spectrum for Analytics teams, its implications, as well as the guiding principles for when you should choose each of them:

• The data organization is centralized

• Analysts are decentralized

• Hybrid model (hub and spoke)

• Hybrid model at department level

The data organization is centralized

Most Data and Analytics teams start as a central function reporting to a “Head of” or Director of Data. This function is responsible for all data-related activities across the organization and, usually, works as a support-function as explained in the first article of the series.

When a central data team grows, it usually does so by organizing themselves “by function”. This means all Data Analysts will report to a newly hired or promoted Data Analysts Manager and all Data Engineers will report to a Data Engineering Manager, for example.

This model can work at the beginning, but eventually Analysts will become a bottleneck. The model will slow down decision-making and will prevent business domains to focus on specific and advanced topics. Analysts will see the need of specializing on a business problem and focus on that for several quarters in order to make an impact.

The feeling that Data Analysts must be decentralized begins to grow.

Analysts are decentralized

The idea of decentralizing Analysts and embedding them in cross-functional teams usually comes with a more general reorganization in the company where product and tech teams stop being organized by function and start being organized by business problem, user journey, domain, etc.

This way of organizing removes the bottleneck problem as the prioritization efforts are kept in the domain. But embedding Analysts does not ensure that you will get rid of the support-function view that other disciplines may have on data people; therefore, it is crucial to remember the steps to switch towards data being a growth-oriented function within the organization.

I think it is important to avoid using the word “embedded” in this model as it creates some separation between data folks and the rest of the disciplines. Data Analysts are simply another component of the cross-functional team and they are accountable for the success of the business domain too, period.

Although the benefits of the model might outweigh the cons, it is important to signal that in this model there is a risk of fragmenting the knowledge and creating silos. Therefore it is important to keep some kind of chapter, guild or center of excellence where Data Analysts can share knowledge and uncovered insights as well as discuss best practices to ensure analyses have the necessary consistency.

Finally, it is important to note that this transition keeps Data Engineers in a central team focusing on Data Platform efforts. (If you want to read more about scaling Data Platform teams you can read the third article of the series: Scaling Data Platform Teams: A Step-by-Step Guide.)

Hybrid model (hub and spoke)

If an organization “fully opens the accordeon” by decentralizing all the Analysts, in some months time it might realize that perhaps some analytics capacity at a central level is needed. This is when the hybrid model comes to the rescue.

A hybrid model, also called hub and spoke, keeps Analysts decentralized but also creates a central analytics function responsible for:

• The overall data strategy

• Taking a proactive attitude towards solving governance issues

• Keeping the Data & Insight community together

• Making sure trainings and onboarding programs are successful

Sometimes they will also offer ad-hoc support and/or help domains that start needing analytics resources (before assessing if hiring a full time person for that domain is needed).

Hybrid model at department level

One recent trend I’ve observed is the fact of creating mini data teams at a level higher than the team entity. This means the mini-data team supports several teams (3 to 5 is usually the number of teams this mini-teams can give support to) within the same department.

Sometimes this transition is forced because the department is going through the same type of transition within the rest of disciplines (merging several teams).

This model is more cost-effective than adding analysts in every single team and it can be good for the department to break existing team silos. On the other hand, you do that at the expense of sacrificing speed since sometimes analysts will not have the priority or focus on a specific team.

One way to try if this is a good model for you is to start small and create a mini-data team in one of the departments of your organization, learn from it and decide if you want to scale this model to other departments or not.

A note on Data Engineering

The majority of Data Engineers in an organization will usually be part of a central Data Platform team. Data Engineers are introduced in cross-functional teams only when the data products in their domain start growing in complexity and use cases. This allows Data Analysts to focus on more complex data analysis and experimentation while Data Engineers are responsible for maintaining the domain data products and bridging the data gap between the operational and analytical spaces.

One of the most difficult aspects of integrating Data Engineers into cross-functional teams is avoiding the need to build parts of the data platform that are needed by the domain but not provided by the central Data Platform team yet. To prevent this you need to establish synchronization points with the central Data Platform team to identify needs and priorities.

When it comes to the Data Engineers in the central Data Platform, the transitions a Data Platform team can go through are explained in the next article of the series: Scaling Data Platform Teams: A Step-by-Step Guide.

Bringing in the support vs. growth dimension

The level of centralization or decentralization of your analytics function is independent of the model you adopt to govern your data organization (support-oriented vs. growth-oriented) so we can visualize both dimensions together and draw the following 2 by 2 matrix resulting in four different operational models:

There are pros and cons to all operating models so let’s detail them in the following sections.

Support function, fully centralized

The bottom left quadrant describes a fully centralized data organization that just works on support requests. I described this operational model in the first article of the series. As I mentioned there, it is not the model mature and data-driven organizations use.

Growth function, centralized

The bottom right quadrant describes a very rare combination: the organization tries to work as a growth-function from a central data department.

Even if this model can work for a while, central Analysts will find it is hard to work deeply and extensively on specific problems because they are not part of the team focusing on those problems. They work as internal consultants and experts (they are working in “growth-mode”) but it will be difficult to have end-to-end ownership of the analytical problem and scale the model.

The solution: decentralize the Analysts.

Support function, decentralized

On the upper left quadrant, organizations consider Data Analysts members of cross-functional teams but they keep being a support-function and only have the time to answer Product Manager and other stakeholders requests.

The amount of toil they handle and/or the lack of being metric (growth) oriented in the team prevents them from working on advanced topics, participating in discovery activities, experimentation…

Growth function, decentralized

On the upper right quadrant, data teams work with a combination of central and decentralized Analysts (part of the cross-functional teams) and have a growth mindset. Some cross-functional teams might even have dedicated Data Engineers too.

This is the model that allows for the best use of data at scale and where most data-driven companies are or are going to as we explained in these two first articles of the series.

Final words

In this article, we have shown the various ways you may organize an Analytics function using solely the centralization vs. decentralization dimension. We also looked at what happens when we combine this dimension with the support vs. growth dimension (explained in the previous article).

This resulted in a four quadrant graph that shows you should move your organization into the “growth and decentralized” quadrant (upper right) if you want to become data driven at scale.

If you’re interested in other articles in this series, make sure to read the first one about shifting data organizations from a support-oriented to a growth-oriented role, and the third and last one about scaling Data Platform teams.

Enjoyed this post? You might like my book, Data as a Product Driver 🚚.

The ability to evolve and optimize how data teams are organized to deliver maximum value, is one of the key characteristics of highly successful data-driven organizations.

Over the years, personal experiences as well as experiences shared by colleagues (coworkers, students, industry leaders,…) helped me identify good practices to design and run efficient data organizations.

I’ve compiled these practices in a series of articles titled “Scaling Your Data Team”. Each piece focuses on a transition, a motivator for change in your organization to which you must adapt. I hope these articles help you if you go through a similar process, and overall we reduce the risk of reinventing the wheel.

In the first article of the series, you will learn the differences between support-oriented and growth-oriented data organizations as well as what mental models and resources you can use to transition from one operational model to the other.

The second article of the series focuses on centralization vs. decentralization and you can read it here: Navigating the Spectrum of Centralization vs. Decentralization in Analytics Teams.

The third and final article of the series offers a 5 steps guide to grow and split a Data Platform team and you can read it here: Scaling Data Platform Teams: A Step-by-Step Guide.

Historically, data teams have been on the receiving end of lots of data requests from other parts of the business. This traditional support-oriented approach keeps the data team busy; but in the long term, it can limit their ability to deliver net new work or prioritize high complexity topics (like deep exploration, advanced analytics or experimentation).

On the other hand, when data is considered a growth-oriented function in an organization, the company values data-informed decision making as a key driver for growth, increased efficiency, cost reduction and ultimately higher profits. In this context, data is not used just as a byproduct but rather as an strategic asset.

Transitioning from one organizational model to another is a significant undertaking that requires changes in business culture, processes, and technology. In practical terms, these are the four areas I believe companies should focus on in order to advance towards data teams being a growth-oriented function:

• Adopt a product mindset for analytics initiatives

• Invest in state of the art technology

• Protect prioritized work

• Develop a data literacy program

Let’s discuss in detail each area of focus.

Adopt a product mindset for analytics initiatives

When data teams are treated as a support function, Data Analysts are primarily responsible for fulfilling requests from other departments to provide data insights on specific topics or questions. Their primary focus is on delivering these insights as quickly and efficiently as possible, without necessarily considering the long-term strategic goals of the company.

On the other hand, a product mindset on analytics initiatives involves treating analytics as an ongoing process, with a focus on having a clear vision that contributes towards business goals, a roadmap and a set of metrics to measure success.

The first step in successfully adopting this product culture is to incorporate data and data people far sooner in the process of defining new work. Data will be helpful in determining which efforts to prioritize and in establishing an incremental and iterative product development approach. The Agile Dual Track or the Double Diamond Model are both excellent tools for this.

Both models are iterative, emphasize user-centered design and are built on the principle of testing and prototyping ideas before deciding to implement them.

This means that many of the ideas that will go through the discovery phase (in the case of the agile dual track) or the solution exploration phase (in the case of the double diamond model) will be discarded and not implemented thanks to qualitative and quantitative research (experimentation, user interviews, fake door tests,…).

If done right, this will save time to do even more discovery and experimentation which will allow you to optimize your product further. Eventually, you will be in a better position against your competition thanks to data and a lot of cumulative data-informed decisions.

Invest in a state of the art platform

Growth-oriented data organizations are built around self-service data platforms. Thanks to these platforms and the content built on top of it, decision makers are autonomous in getting the data they need whether it is via dashboards, notebooks, raw data, etc.

One of the biggest challenges here is to make sure you have the right tool for the right data consumer. Let’s illustrate this with a couple of examples:

• Most business users will not perform a SQL query to get the answers to their demands. Instead, you will need to give them a data visualization tool, a basic and documented semantic layer, and, in certain situations, an already created dashboard.

• Data Analysts won’t invest huge amounts of their time in complex technology to create simple data pipelines; you will need to ease that by adopting easier tools or simplify pieces of your infrastructure.

Purchasing 3rd party tools is not enough in this context. A state of the art platform should also include basic data products (datasets and dashboards) for the most commonly asked questions. This will mitigate the risk of reinventing the wheel every time data consumers need to use data.

Maintaining these data products with high quality (well documented, cataloged, with examples, etc.) will increase the amount of low complexity insights (counts, descriptive analytics, user segmentation,…) that can be self-served across the organization and will allow Data Analysts and Scientists to focus in higher complexity topics.

Protect prioritized work

When moving away from data being a support function, your teams will need to break the inertia of wanting to answer every question that still gets asked to them directly (instead of making the rest of the organization self-served with data).

That is the reason why you need to be very strict at protecting people’s focus to allow them to work on prioritized new initiatives that use data to achieve business goals.

Here are several process, agreements and models you can put in place to achieve that:

• Split the team’s effort between different types of work: business goals work, IT goals (or technical debt), planned/scheduled requests, and unplanned work -bugs-. (Taken from The Phoenix Project book).

• Protect business goals work by using lanes. Each lane (or subteam) focuses on one type of work so people working toward achieving business goals do not need to pay attention to requests coming to your team. (See the article Growing a feature team using lanes for more).

• Reduce unplanned work to just what is critical and cannot wait (high severity bugs). Teach team members to say no (“yes, but not now”) to move from jumping right ahead into helping everyone to actually plan requests.

• When dealing with requests, spend time making data consumers more autonomous and data literate to avoid the same requests coming again and again. Also, always ask why and document everything.

Develop a data literacy program

Last but not least, you will need to start a data literacy program so that people know how to use the tools they have available and the important data assets for the organization.

This program can involve training employees on how to collect, analyze, and interpret data, as well as how to use it to solve real business problems, launch experiments, build Machine Learning models, etc.

Don’t block the creation of the program just because you think it is a huge endeavor and needs to be perfect. You don’t need to build all the pieces of the data literacy program at the same time. Begin small, train a small group of individuals on the most relevant topics, then iterate.

It is important to note that as you add new building blocks to your self-serve architecture (data catalog, experimentation platform, etc.) you will also need to create training sessions for those. Eventually, you will have a collection of training sessions you should also teach to every new employee.

In parallel to this more formal program and regardless of how the data department is organized in your company, the fact of data folks working hand in hand with people from other disciplines (Product Managers, UX Designers,…) will also help increase data literacy. Don’t underestimate this power!

Final words

​​In this article, we have highlighted the four areas of focus that can help data organizations transition from a support-oriented to a growth-oriented model.

We have done that without addressing much how the data team should be organized as these areas of focus are independent of the level of centralization or decentralization (embedding) of your Data Analysts, Data Scientists and Data Engineers.

The second article of the series focus on the transition from centralization to embedding of data folks and, spoiler alert, vice versa; you can read it here: Navigating the Spectrum of Centralization vs. Decentralization in Analytics Teams.

The third and final article of the series focuses on Data Engineering and Data Platform teams: Scaling Data Platform Teams: A Step-by-Step Guide.

Enjoyed this post? You might like my book, Data as a Product Driver 🚚.