Why AI-First Products Require a Different Playbook

Over the last few articles, I’ve been exploring how AI is reshaping product leadership — from flattening organizations to the rise of “Super ICs” to changes in how we lead. In this one, I want to focus on the product itself, and where it may be going.

I’ve worked with complex systems for most of my career. Coming from a web development background, I was already familiar with the layers (data, application logic, interface) and the difficulties of making them work together, especially in legacy environments. But about five years ago, I stepped into a problem that felt different. I was leading the development of a client data platform and identity system, and the work quickly revealed itself as more than integration or interface design. It was an emergent challenge. We were building the foundation for a system that could define, organize, and present information across many disconnected sources, for both employees and customers. Peeling it apart required starting from first principles and questioning assumptions at every layer. That experience didn’t just expand how I thought about product development, it changed how I see the relationship between systems, data, and behavior.

This shift in perspective has stayed with me. It led me to question some of the frameworks we take for granted in product work, especially as systems become more intelligent and less predictable.

The Legacy Product Lens Is Holding Us Back

Many product organizations still rely on assumptions that made sense in an earlier era. They focus on interfaces, organize around backlogs, and optimize for delivery. In meetings I’ve been part of, it’s common to see attention gravitate toward release dates and feature counts, while the underlying systems are treated as technical details to be handled later.

This mindset worked fine when products were mostly static interfaces sitting on predictable backends. But AI-native systems break this logic in three critical ways:

• Outcomes are shaped by the system, rather than directly retrieved from datasets or APIs. Your product generates decisions you didn’t explicitly program.
• Many critical decisions happen beneath the interface. Intelligence often lives in data orchestration, infrastructure, and internal logic.
• The product continues to evolve after deployment. What worked yesterday may behave differently tomorrow.

If the strategy ends at the surface, the system’s behavior may shift in ways that are difficult to trace or influence. That’s the reality when you’re working with systems that learn and adapt over time.

The Limits of the Old Product Playbook

Traditional product tools were built for predictable software and rules-based systems. Let’s look at where some of those tools might fall short with AI:

• Roadmaps often underrepresent the depth of data work. In our case, we were well aware that data quality would be the defining constraint. It shaped nearly every aspect of the project. But the roadmap still had to speak in terms of features and delivery timelines, which meant the depth of the data work was often underrepresented. That disconnect made it harder to communicate why progress sometimes stalled, even when the interface work or model design seemed complete.
• User stories overlook decision complexity. A statement like “As a user, I want to see all my services” seems clear on the surface. In a traditional system, that might involve fetching and displaying data. In an AI-enabled system, it involves interpreting confidence thresholds, resolving identity matches, and making tradeoffs between completeness and accuracy. These decisions are often invisible, but they shape the experience in meaningful ways.

I’m not suggesting we throw these tools out. But they weren’t designed for the kinds of systems many teams are working with now. When the behavior of a product emerges from layers of data, logic, and interaction, we need different ways of seeing the work, and different tools to support it.

What You Don’t See Can Still Shape the Experience

When we were designing the client identity platform, most of the critical decisions never showed up in feature briefs or user stories. Threshold logic, matching confidence, system fallback behavior, these weren’t surface-level design issues, but they shaped the customer experience in fundamental ways.

A user never saw the identity resolution process, but it determined what they could access, what they had to re-authenticate for, and whether the system showed them a complete view of their services. These kinds of hidden decisions live deep in the stack, but they create the conditions for trust, usability, and reliability.

We didn’t frame these as “ethical” concerns at the time, but looking back, I see how subtle changes at the system level could change someone’s experience in real and sometimes consequential ways. And I’ve come to believe that product leaders need to be more aware of those downstream effects, even if they’re not directly responsible for the technical implementation.

You Can’t Own the Product Without Touching the System

In the identity work, it became clear early on that this wasn’t something product could define and hand off. The logic lived across too many systems, data pipelines, legacy integrations, security layers. Designing the product meant understanding how those pieces fit together.

One thing that stuck with me was how much of the product was shaped in conversations I might not have been invited to earlier in my career. Architecture discussions, data flow decisions, and logic buried deep in the integration layer had more impact on the experience than anything captured in the feature list. These weren’t user-facing features, but they defined what the product could actually do, and how reliably it worked.

The projects that worked best had teams sitting together from the beginning. Product, engineering, design, and data science didn’t just pass work between each other. They built shared models of how the system should behave. When we slipped back into handoffs, even small misalignments created big gaps between what we intended and what actually shipped.

Where to Begin: Moving Toward Systems Thinking

This shift toward more integrated product development can feel like a lot, especially if your background isn’t deeply technical. Mine isn’t either. I came into this through web development and learned by working through real system constraints. What’s helped me is not trying to become an expert in everything, but learning how data flows through the entire stack, where decisions get made against business rules, and how those decisions shape what the product becomes.

Here are a few approaches that have helped me get closer to the system:

1. Trace decision paths — Try to follow how a specific piece of information moves through your system. What triggers it, where it’s transformed, and where it shows up in the user experience. This makes it easier to understand what’s really driving behavior.

2. Surface feedback loops -Ask what the system learns from and how it adjusts. Not just user feedback, but signals that affect how the system behaves over time, data recency, usage patterns, edge cases.

3. Sit in upstream conversations — I’ve found real value in being present for architecture reviews, integration planning, and data governance work. You don’t need to lead those discussions, but you do need to hear the tradeoffs being made.

4. Watch for blind spots — In complex systems, small configuration changes can have large downstream effects. Try to identify where your product might quietly drift or behave in ways nobody intended.

5. Change your language — I’ve started being more deliberate about how I describe the work. I talk less about “features” and more about “conditions,” “signals,” and “system behavior.” The shift in vocabulary helps teams think more holistically about what we’re building.

From Managing Features to Understanding Systems

Looking back at my own career, I can see how my focus has shifted over time. Early on, I was immersed in product delivery, building features, managing releases, tracking roadmaps. Later, I moved into product strategy, shaping vision, positioning, and market fit.

But a systems-based approach is fundamentally different. It’s less about defining what the product does and more about understanding how the system behaves. The questions have changed. Instead of “What should we build?” I find myself asking, “How does this system evolve when changes are made upstream, and how does that impact the user?” or “What does the product need to be aware of and adapt to in order to stay useful?”

This way of working doesn’t have a clean playbook, at least not yet. But I think that’s part of the point. Since systems change over time, product leadership has to shift from defining static outcomes to shaping environments that support the intended behavior.

I’m still figuring out what that looks like in practice. But I’ve come to believe that the best products aren’t just well-designed or well-delivered. They’re responsive. They’re adaptable, shaped by how the system performs and interacts with its environment over time.