Build the Right Thing, the Right Way: Why the What vs. How Split Matters More Than You Think

Posted on Posted in Agility, Organisation Development, Product Development, Strategy Tagged with , , , , , , , , , ,

The what vs how split is one of the most overlooked but critical distinctions in product development — and misunderstanding it can derail even the best teams.

We’ve all seen it: endless debates in meetings, engineers frustrated by vague requirements, stakeholders confused by delays. Too often, this chaos stems from a simple problem — we blur the line between what we’re trying to achieve and how we plan to do it.

This post unpacks why that distinction matters, what goes wrong when it’s ignored, and how teams can use it to build better products with more focus and less friction.

What vs. How — Defined Clearly

Before diving into the consequences, let’s get clear on the terms:

  • The What: This is the goal — the value you want to create, the outcome you seek, the problem to be solved. It often comes from users, customers, stakeholders, or business goals.
  • The How: This is the implementation — the technical decisions, design choices, tools, processes, and code that bring the “what” to life.

Examples:

  • What: Reduce churn during onboarding
    How: Add progress tracking and a welcome flow
  • What: Improve order accuracy
    How: Introduce barcode scanning in the warehouse app

Simple? Yes. Obvious? Maybe. Practiced consistently? Not even close.

What Happens When You Blur the Line

Many teams suffer from mixing up the what and the how — here’s how that shows up:

Stakeholders dictate solutions

Instead of expressing problems or goals, business leaders hand teams pre-defined features to build. The team becomes an order taker.

“We need a chatbot.” → But why? What problem are we solving?

Engineers push back too late

If the what isn’t clearly defined early, teams spend weeks building something — only to discover it doesn’t solve the right problem.

Roadmaps become feature lists

Product plans are packed with how items — instead of outcome-driven goals. This kills adaptability and creativity.

Why the What vs. How Split Matters

Here’s what gets better when you make the split explicit:

Clarity of Roles and Responsibility

Product managers and stakeholders focus on the what. Designers and engineers focus on the how. It reduces overlap, rework, and confusion.

Empowered Teams

When teams understand the goal — but have freedom to find the best path — they innovate. They own the problem, not just the tasks.

Faster Feedback Loops

By discussing what before jumping to how, teams test assumptions earlier, cut waste, and adapt quickly to change.

Strategic Focus

Focusing on what keeps the team aligned on value and customer needs — not just delivery.

How to Use the What vs. How Split in Practice

You don’t need a new framework — just a few shifts in practice:

1. Frame problems, not solutions

Use problem statements, opportunity trees, or Impact Mapping to explore what you’re solving.

2. Make space for discovery

Before building, give teams time to explore how different solutions might achieve the what. Let learning guide design.

3. Separate planning layers

Use OKRs or goals to define what success looks like. Let backlogs and sprint planning figure out how to get there.

4. Clarify interfaces

Make sure everyone knows who defines what and who decides how. This clarity helps avoid micromanagement and confusion.

Final Thought: Build the Right Thing, the Right Way

The what vs how split isn’t just a theoretical distinction — it’s a practical tool that helps teams ship with purpose, not just speed.

When your team knows what they’re aiming for and has the space to find the best path to get there, magic happens.

🔜 Coming Up Next:

In the next post, we’ll explore how the what vs. how split plays out in team structure and decision-making — including anti-patterns and practical team setups that work.

Read further

1. Inspired: How to Create Tech Products Customers Love

A foundational book that emphasizes the what — customer problems, outcomes, and value — over prescribing how teams should build. Clear on roles, discovery, and empowered teams.

2. Empowered: Ordinary People, Extraordinary Products

A natural follow-up to Inspired, this book goes deeper into how to enable product teams to own the how once the what is clear. Great for understanding the dynamics of modern product organizations.

3. Team Topologies: Organizing Business and Technology Teams for Fast Flow

Focuses on how to structure teams and decision boundaries for optimal flow and autonomy — critical when operationalizing the what vs how split in larger orgs.