Evolving Our Collaborative Product Development Mantra

For years, if you stepped into almost any product engineering organisation, you’d likely hear a familiar shorthand used to define roles: "Product defines the 'what,' and Engineering defines the 'how.'"

On the surface, it’s a clean, efficient division of labor. It’s meant to create clarity and prevent us from stepping on each other's toes. But as I’ve spent more time in the trenches of building products, I’ve found myself feeling a growing sense of restlessness.

In the noise of rapid delivery and "Agile" cycles, I think these core ideas often get buried. I’m starting to wonder: Does this simple split actually serve us anymore? Or does it accidentally build silos where we should be building bridges?

The Friction in the Machine

When we strictly separate the "What" from the "How," we often inadvertently strip the work of its context.

If Engineering is only focused on the "How," they risk becoming a "feature factory"—implementing solutions without truly understanding the human problem they are solving. If Product is solely responsible for the "What," the burden of the user’s entire experience and the business's strategic success falls on one pair of shoulders, often overlooking the creative technical possibilities or the nuanced user journeys that make a product truly resonate.

This risk is growing as we adopt AI within our development processes. While AI can help us generate the "how" faster than ever, that speed can be a double-edged sword. Without a shared focus on the "Why," we risk accelerating the production of low-value work in a few specific ways:

• The "Hallucinated" Backlog: It is now trivial to generate a comprehensive list of features in seconds. But a backlog filled with professional-looking user stories isn't the same as a validated strategy. We risk building requirements that look right but aren't tied to any actual human need.
• The "Low-Cost" Fallacy: Because AI makes "the work" look cheaper, stakeholders are tempted to ask for "just one more filter" or "five more buttons." This leads to feature bloat, where the speed of generation outruns our ability to say "no."
• The "Autocomplete" Architecture: When the "How" is delivered instantly via a prompt, we might stop asking if the solution is the right one for the user. AI provides the code so fast it can outrun our human reflection on the experience.

I’ve been learning and reflecting on a way to express this that feels more inclusive; a refresher of sorts to ensure that every part of the organisational puzzle can feel a deep sense of pride in what we deliver.

An Evolution: The Why, the What, and the How

Rather than a binary split, I’m curious if we can look at our collaboration through three distinct but overlapping lenses of advocacy:

• Product leads the "Why": This is about strategy, market viability, and customer needs. It’s the constant quest to answer: Why is this worth doing? What is the value we are creating for the customer and the business?
• UX leads the "What": This is about the experience, the interaction, and the flow. It’s the advocacy for the human on the other side of the screen. What does the user actually experience? How do they achieve their goals with clarity and delight?
• Engineering leads the "How": This is about architecture, feasibility, and technical innovation. It’s the foundation that makes the vision possible. How do we build this sustainably, performantly, and elegantly?

This isn't a novel idea. This approach is rooted in the classic Design Thinking framework—the intersection of Viability, Desirability, and Feasibility. It has been championed for years by industry leaders like Marty Cagan and Teresa Torres, who advocate for the "Product Trio" as a collaborative unit of discovery rather than a linear chain of command.

The Context of Scale: Advocacies, Not Just Job Titles

It is easy to assume this model requires a large, mature organization with dedicated departments for Product, UX, and Engineering. But in reality, these are functions, not just job titles.

In a seed-stage startup or a founder-led team, the boundaries are naturally fluid. A founder might be the advocate for both the business "Why" and the user "What," while a lead engineer handles the "How."

The nuance is that regardless of the headcount, these three lenses must be present. Even if you are a "team of one," you must be able to switch hats. If you skip the "Why" to jump straight into the "How," you are vulnerable to the same silos as a thousand-person corporation. The triad is a framework for thinking, not just an org chart.

Seeing it in Action

Imagine a team tasked with "improving the sign-up flow."

In the old model, Product might hand over a list of fields (the what), and Engineering builds the database schema (the how).

In this evolved model, the conversation changes:

• Product (Why): "We’re losing 40% of users at sign-up because the friction is too high. Our goal is to increase the conversion rate so more people can experience our core value."
• UX (What): "To solve that 'Why,' let’s move to a single-field email entry first, then a password. It feels less overwhelming than a giant form."
• Engineering (How): "If we use a specific auth-provider and pre-fetch the next step, we can make that transition feel instantaneous, though it'll take slightly longer to set up the backend initially."

Suddenly, the "How" isn't just a technical task; it's a direct contribution to solving the "Why."

The Magic is in the Overlap

These aren't territories; they are advocacies. We need Product to advocate for the business, UX to advocate for the human, and Engineering to advocate for the system. When those three advocacies clash and collaborate, we find the "sweet spot" of product development. An engineer who understands the "Why" might suggest a technical shortcut that achieves 90% of the value for 10% of the effort—a "How" that Product would never have known to ask for.

Why This Shift Matters

This isn't just about labels; it's about meaning. As automation handles the "how," our value lies in the "why" and "what." By leading with the "Why," we stop being order-takers and start acting as a unified team focused on the heart of the problem.

When we work this way, the result is a shared sense of ownership. We stop shipping "specifications" and start shipping value.

Small Steps Toward Change

If you're interested in testing this mindset, you don't need a massive organisational restructure. You can start by asking three questions in your next kick-off or refinement:

To Product: "What is the specific human problem we are trying to solve today?"

To UX: "How will the user feel when they finish this interaction?"

To Engineering: "Is there a more elegant or sustainable way to achieve that goal?

Navigating the Friction

When you give three distinct roles equal weight, conflict is inevitable. Engineering might say a UX vision is too expensive; Product might say an Engineering "How" doesn't hit the market window.

The key is to remember that the "Why" is the ultimate tie-breaker. When perspectives clash, the question isn't "Who wins?" but "Which path best serves the Why we agreed upon?" Healthy friction is the sign of a team that cares about all three dimensions of the triad.

A Question to My Peers

I don’t want to suggest that this is a dogmatic new rule. I’m still learning, and I’m asking these questions out loud because I want the effort we all put into our work to feel significant. I want us to build things we are proud of, not just things that "meet the spec."

I’d love to hear your thoughts. Let’s figure out how to build more meaningful products, together.