Chapter 9

Rethinking how we work with Product

Not long ago, during a feature kickoff, the product manager proposed a solution and I paused to ask, “What specific user behavior are we trying to shift? What’s the pain we’ve observed?”

We ended up having a great conversation that led to digging into user feedback and support tickets. We kept asking question, then it became clear the initial idea didn’t really address the core problem. We had to take a step back, look at it from a different angle, then ended up with a simpler and much more effective approach.

That moment stuck with me. Good engineering isn't just about building what’s asked, it’s about helping the team think clearly. Sometimes that means pushing back, challenging assumptions, and guiding the conversation toward what truly solves the problem.

Now that AI can handle more of the busywork, it makes this kind of critical thinking even more important.

The Old Way

Traditionally, product and engineering collaborate a careful two-step:

  • Product writes the spec.
  • Engineering builds the feature.

It was transactional. Product defines the “what” and “why” engineering executes the “how”.

This split made sense when coding was time consuming and expensive, and when execution was the primary bottleneck.

But the truth is that it’s no longer the bottleneck.

With AI speeding up implementation, the slowest part of the loop isn’t writing the code. It’s understanding the problem, aligning on the solution, and keeping context from getting lost in translation.

The old way of working doesn't just slow us down, it fragments our thinking.

The Changes

AI changes the shape of the work. Engineers no longer need to wait for fully polished product specs. We can prototype ideas, generate scaffolding, and even explore trade-offs before a single meeting ends.

So what does that mean?

It means the walls between “product” and “engineering” need to come down.

In this new era:

  • Engineers must become better product thinkers.
  • Product managers must become more hands-on with tools and repositories.
  • AI becomes a shared assistant, helping both sides move faster if they speak a common language.

This doesn’t mean PMs should write production code. But it does mean the merge request might come from the product side, not just the engineering one.

And that’s a good thing.

Because the faster we align on the “why” and “what” the better the “how” will be.

The New Collaboration

Here are some practical ways to rethink collaboration:

Work in the same repository

Keep product docs, specs, diagrams, and code in one place. It is your repo. This creates a shared context for both humans and AI tools. When AI can see the whole picture, its suggestions are smarter.

Start with Problem Statements

Don’t begin with features. Start with a clear articulation of the user problem. Engineers and AI tools are both much more effective when they know the “why”.

Create early Prototypes together

With AI tools, engineers can spin up wireframes, flows, or backend scaffolding in hours. Invite product teammates into the loop early to review and reshape.

Adopt an AI-First Mindset

Before breaking down the work, ask: “What can AI help with here?”

This includes generating user stories, test cases, even data queries. Product folks can drive this just as much as engineers.

Define the Guardrails for AI

Both need to agree on the level of quality, scalability, and maintainability expected from AI-generated output. Otherwise, you risk treating AI like magic and getting burned by shortcuts.

Encourage lightweight Merge Requests from PMs

Don’t gatekeep the repo. Empower product to propose changes, text updates, config tweaks, even mock JSON responses. Engineering still owns the final quality, but speed improves when everyone can contribute.

Shift from hand-offs to shared problem solving

Instead of a ticket that says “build X”, co-create the solution. Use Figma, Notion, Confluence or whatever tool your team prefers, but ensure you’re solving problems together, not passing them across walls.

In the AI era, speed comes not just from automation, but from speed of alignment.

Three things to remember:

  • AI accelerates execution, so collaboration becomes the new bottleneck.
  • Product and engineering must work in one loop, not two lanes.
  • The best teams aren’t faster because they code faster. They’re faster because they think together from day one.

Enjoying the book?

Let's me know what you think. Share your feedback, thoughts, and questions in the form below.

Share your feedback