Impact-First Product Teams by Matt Lemay - Review
The Feature Factory is Bankrupt: It’s Time to Build an Impact Engine
For the last decade, we’ve been told that if we just follow the right rituals—the perfect PRD, the right Jobs to be Done template, the exact Agile ceremony—success would be an inevitable byproduct.
Instead, we’ve built Best Practice Factories. We are shipping code faster than ever, yet we’re often farther away from actual business value than we were a decade ago. We are doing the work, but are we making a difference?
Matt LeMay’s Impact-First Product Teams is a long-overdue tactical manual for anyone tired of a Feature Factory and ready for an Impact Engine. As a product leader who has spent years scaling teams without drowning them in bureaucracy, I found this book to be a masterclass in operational clarity. It’s not just a book about product management; it’s a manual for building a high-performance system that prioritises results over rituals.
1. The Trap of the “Best Practice” safety blanket
The most refreshing part of Matt’s thesis is his direct challenge to the best practice dogma. In Product Ops, we often fall into the trap of thinking our job is to enforce a standardised way of working across the organisation. We create the templates, we define the cadence, and we police the process.
Matt argues that best practices often become a safety blanket for teams that are afraid of accountability. If the product fails but we followed the “proper” discovery process, nobody gets blamed, right? errrrrr…..
Matt flips this on its head. He shows that the best practice is whatever delivers impact. For some teams, that might be a 50-page technical spec; for others, it might be a napkin sketch and a five-minute sync. By decoupling the ritual from the result, Matt frees Product Ops from being the process police and empowers us to be impact enablers. It shifts our focus from Did they use the template to Do they have what they need to move the needle?
This not only reinforces the almost-universal mantra of Product Ops: It’s different in every business, but it is a call to reduce anxiety around exact standardisation across teams. It is both liberating and productive to be less concerned about every tick box being ticked, and more about teams delivering great products while also feeling good about doing it.
2. Meaningful Goals: Solving the “Translation Gap” of Traditional Cascading Directives
One of the most profound takeaways—and where this book really hits home for anyone in leadership—is how it handles Goals.
In most organisations, goals cascade like a game of xxx whispers*. The board wants 20% revenue growth; the VP wants a new market entry; the product manager wants to ship three specific features. By the time the goal hits the squad level, the Why has been completely stripped away, replaced by a list of deliverables that may or may not actually drive that 20% growth.
(*We all know the game and the phase that was used years ago… that game!)
Matt provides a systemic way to fix - read as ‘remove’ - this Translation Gap. Instead of a top-down mandate of what to build, he advocates for a more 1:1 relationship, showing more directly the impact to be felt. This means:
The Executive Level defines the business impact it wants to see happen.
Product (and/or Squads) defines the technical and user-behavioural impact that will deliver, in part or in whole, the business impact.
There is no chain or layers of goals between to either influence or distract the product squads (though I would argue that if a business wants to separately assign additional outcomes that naturally link to the same initiatives product propose, so long as there is at least one direct link between top level goal and product initiatives.).
Matt refers to Orbital Goals; keeping the product goals within ‘orbit’ - and only 1 step removed from - the company goals. A direct line of sight with no translation needed, and ensuring that a good relationship between product and the business leadership has to be both cultivated and maintained, which can never be a bad thing.
3. The “Good Enough” Paradigm: Efficiency as a Strategic Weapon
In a world of “perfectionists” and “obsessives”, Matt’s take on “Good Enough” is a breath of fresh air. He challenges the idea that quality is an objective, universal standard.
In an Impact-First world, good enough is defined by the outcome. If a hacky, manual process on the backend allows you to validate a $5 or 5% increase in conversion before building a million-dollar automated system, then the hacky process was better than the perfect one.
As leaders, we often let our teams get paralysed by the fear of shipping something that isn’t pixel-perfect or enterprise-grade. Matt reminds us that unnecessary quality is just another form of waste. From a Product Ops perspective, this is about resource allocation. Every hour spent polishing a feature that has already achieved its intended impact is an hour stolen from a problem that hasn’t been solved yet.
And let’s be honest here, Product Ops folks - all of our processes are hacky to some degree… just depends on how closely you look!
4. The Seductive Poison of Low-Impact Work
This is perhaps the most uncomfortable chapter for many product teams. Matt dives deep into why we love Low-Impact Work. It’s easy. It’s measurable. It feels productive.
Checking off Jira tickets? Productive. * Answering 50 Slack messages? Productive. * Refining a UI that already works? Productive.
But as Matt points out, a team that is 100% productive on low-impact work is actually failing the business. Low-impact work is often a defence mechanism against the uncertainty of high-impact work. High-impact work is scary; it can fail. Low-impact work cannot fail because it doesn’t aim for a meaningful change in the first place.
Product Ops has a massive role to play here. We need to build the systems that expose low-impact work. If our dashboards only track velocity, we are incentivising low-impact work. We need to build impact exposure into our rituals, forcing teams to ask: “If we didn’t do this, what would actually happen to our cascading goals?”
5. Accountability: The “So What?” Test
Accountability in product is often a murky concept. Does the PM own the revenue? Does the engineer own the uptime? Matt simplifies this through the lens of Impact-First Accountability.
In an impact-first team, accountability isn’t about doing the work; it’s about owning the change. This is a subtle but massive shift. It moves the conversation from Did we finish the sprint? to Did we change the user’s behaviour in the way we predicted?
For leaders, this makes the ROI conversation infinitely easier. We stop defending our headcount based on the number of features we’re building and start defending it based on the business problems we’re solving. Matt’s framework for One-Page, One-Hour planning is something I’m already working to integrate into our strategic planning templates. It forces the team to define success—and how they will measure it—before a single line of code is written. No more retrofitting metrics to a launch that didn’t land.
6. Product Ops: Steward of the Impact Engine
This is where the book becomes an essential text for the Product Ops community. Product Ops is often misunderstood as Project Management for Product. Matt’s work clarifies our true calling: Product Ops is the steward of the Impact Engine.
How does this relate to the practice of Product Operations in 2026?
Data Democracy: We are responsible for making sure the Impact data is accessible. If a team has to wait two weeks for a data analyst to tell them if their feature worked, they will default back to output-based thinking.
Tooling for Outcomes: Instead of asking Which tool handles our roadmap best?, we ask Which tool helps us visualise the connection between our daily work and our cascading goals?
Communication Rhythms: Product Ops ensures that the Why doesn’t get lost in the noise. We build the rituals that force the So what? conversation at every level of the organisation.
Matt’s writing style is perfectly aligned with the Product Ops Confidential ethos - and my own way of thinking too: it’s direct, it’s grounded in the messy reality of software development, and it has no patience for corporate jargon. If you saw my recent comments on the Product Opscast regarding ‘speaking to the c-suite’, you’ll appreciate this even more! He understands that in the trenches, we don’t need another framework that looks good on a PowerPoint slide; we need a way to help our teams survive the next quarter without losing their sense of purpose.
The Verdict: A Tactical Reset
Impact-First Product Teams is a 10/10 for any product leader who feels like their team is busy but not productive. It is a call to arms to stop playing Product Management and start making a difference.
If you are a VP of Product, read this to remember why you got into this business in the first place—to build things that matter. If you are in Product Ops, read this to understand how to build a system that actually supports the people doing the work, rather than just adding more layers to it.
Matt has proven that the most innovative thing we can do in today’s market is to stop worrying about being “Agile” or “Lean” (and I really do despise that term used as a verb in 2026!) and just start being Impactful.
Best practices are the floor, not the ceiling. Use them to start, but use Impact to lead.
Find out more about Impact-First Product Teams and order now via Matt’s website:
Check out Matt’s episode of the Product Opscast: