The Product Quartet: Why Data Leaders Are Product Leaders Too

Modern product teams need data leadership at the table, not on the sidelines as a support function

Photo by Duncan Kidd on Unsplash

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. Teresa Torres 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.

Matt Watson 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. Itamar Gilad 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 🚚.