In this Big Interview, Fourthline's CTO, Ralph Post, interviews Matt LeMay, product leader, consultant, and author of Impact-First Product Teams.

LeMay brings hard-won, reality-tested thinking to one of the most pressing questions in product today: How do teams connect what they ship to what truly matters to the business? His answer challenges the process-first orthodoxy of modern product culture, from Agile ceremonies to OKR theatre, and asks teams to focus, above all, on the work that is most critical to the survival and growth of their business. 

LeMay’s career has included acquisitions by Google and Intuit and strategic advising to Spotify.

As Fourthline's CTO, Ralph Post leads the company's product and technology organization. He oversees the teams responsible for turning complex identity verification and compliance challenges into scalable, high-performing product reality. It is a role in which the tension between process and impact is felt every day, and where the questions LeMay poses land with particular force.

Post sat down with LeMay to explore what it truly takes to shift a product organization from a feature factory into one that earns its place at the business table, and what leaders at every level must do differently to make that change stick.

Q: In the book you argue that product teams need to shift from being ‘feature factories’ to being ‘impact-first.’ In your experience, what is the single biggest mindset shift a product manager needs to make to pull this off?

I think the big mindset shift at play is working through the (very real and understandable) fear of being held accountable for things outside of your control. A lot of product teams bemoan being treated like ‘feature factories,’ but then get scared when they’re asked to be accountable for something other than delivering features. And I get it! Being told “go build these features that the executives want” isn’t terribly motivating.

But being held accountable to customer-level outcomes and business-level impact is truly, genuinely scary–because those are not things your immediate team can control. You’ll probably need to work with other teams. You’ll probably need to create shorter feedback loops, test and learn to make sure you’re on the right track. You might even need to advocate for bigger strategic changes with executives who are convinced that their plans are beyond reproach. And, scariest of all, you might do everything right and still fall short.

But that’s it. That’s the job. That’s what good product managers do. The urgency they bring to their teams doesn’t come from executive mandates. It comes from the live messages they’re pulling in from their markets, their customers, the broader world.

Q: You’ve written about the danger of ‘process theater’, where teams get so caught up in perfectly executing Agile, Scrum, or OKR frameworks that they forget to ship actual value. How would you audit a team if they have fallen into this trap?

I’m a big fan of doing process deprivation studies; suspend some of these rituals for a week, and see what teams miss and only then re-design the processes they need around those specific deficits. I remind people all the time that these frameworks are all made up–they emerged from the specific needs of specific organizations at specific moments in time. The takeaway from ‘The Spotify Model’ or ‘The Basecamp Model’ should be ‘organizations can develop and constantly evolve purpose-built ways of working”, not ‘if we simply adopt processes from [company x] then we’ll be as successful as they are, even if our business model and org structure are completely different.’

Q: A lot of product managers, especially in a B2B context, struggle with commercial awareness because they feel disconnected from revenue or sales. How can a product team start naming numbers and measuring business value if their day-to-day metrics feel fuzzy or out of their direct control? How do teams distinguish a credible impact estimate from a number invented to justify existing plans?

That last question is key, and it’s exactly why I called the book Impact-FIRST product teams. If you’re reverse-engineering your team’s impact from a list of outputs you’ve already promised to deliver, then you are not an impact-first team. If you’re starting with an understanding of what the business at large expects from your team and then figuring out what you might build to deliver it, then you are in fact putting impact first.

As the question suggests, actually getting to an understanding of what the business at large expects from you is rarely as linear or straightforward as you’d hope it would be. It often requires a lot of uncomfortable conversations outside of your immediate team or product area. But it’s often through those very conversations that you uncover the most critical context for your team to succeed in the eyes of the broader business.

Q: You pose a question in your work: ‘If you were the CEO, would you fund this team?’ If a PM asks themselves this and the honest answer is ‘probably not,’ what should their very next step be?

Talk to the team, always. The book is called Impact-First Product Teams not Impact-First Product Managers because goals–and accountability for achieving those goals–often rest at the cross-functional team level. If you think your team is collectively falling short of its expected return on investment, you should navigate that conversation collectively.

Q: Let’s say, Sales has promised a feature to close a major deal. The product team believes another investment would create more value across the customer base. How should that decision be made, and who should be accountable for it?

This is exactly the kind of scenario where an impact-first approach is most valuable. If sales is measuring their impact in the monetary value of the deal, and you’re measuring your impact in story points or Jira tickets–or even in instrumentation and adoption metrics, you are always going to lose that argument. If you can look at impact dollars-to-dollars, the decision is more likely to land on whatever is best for the business at large–which is the right place for it to be regardless of who ‘wins’.

Q: What must a CEO, CPO or CTO make clear before they can reasonably hold a team accountable for business impact? Where does team initiative end and leadership responsibility begin?

This is such a good question, and a really tough one. The reality in a lot of organizations is that the consequences of low-impact work disproportionately fall on the folks executing that work, not the folks doing the strategy and planning behind it. (i.e. when a company lays off teams for doing ‘work around the work’ the person who hired them to do that work rarely goes with them!)

The challenge, I think, is to incentivize a focus on collective outcomes rather than individual responsibilities. I’ve seen that done through material incentives like profit-sharing, and through more implicit structures around how goals are set and how work is celebrated. In either case, this involves a lot of transparency about what we are trying to achieve, how we are measuring up against it, and what decisions we’ll need to make as a result.

The reality is that an organization’s collective outcomes do eventually affect everybody. I often say that, if your company goes out of business, you’re not going to keep getting a paycheck because you hit your individual OKRs or did scrum ‘the right way’. 

Q: Can you explain what the ‘low-impact death spiral’ is, and what are the early warning signs that a product team is starting to slide into it?

It’s the self-compounding spiral that occurs when teams are incentivised–implicitly or otherwise–to ship easy, isolated, and ultimately low-impact work. And if your organization measures success primarily by velocity, or the number of features you can ship, or even the number of people simply using a given feature, then you’re already in it, and it’s only going to get worse.

In most organizations, there really isn’t much incentive to do impactful work. The work that touches the commercial core of the business tends to be high-risk, high-visibility, high-dependency work. It’s not work that can be done ‘quickly’ nor is it work that can be done outside the roving eye of executive scrutiny. (The ‘Eye of Sauron’, as one team I worked with described it.) Look at it this way: if you had a choice between getting your hands dirty and trying to fine-tune a car’s engine, or bedazzling that same car with beautiful rhinestones, which would you choose?

The problem is that, if you put enough rhinestones and glue on a car, you won’t be able to lift the hood and access the engine at all. The more low-impact work we do, the more dependencies and crud we have to manage to do the work that really matters. And if our organization is pushing us to “ship” and “move fast”, that leaves us with nothing left to do except for more low-impact work. Around and around it goes, until the next round of layoffs.

Q: Once a team realizes they are stuck in that low-impact cycle, when they feel they are just churning out features that nobody uses or cares about, how do they practically break out of it and regain trust with leadership?

Unfortunately, teams that are in the low-impact cycle are often the ones that have the most trust with leadership. They’re the team that “gets s*** done.” They’re the team that put the most rhinestones on the car–and when the car wouldn’t start, they were the team that whispered about how the engine team isn’t really “product-led”.

The challenge, again, is that you can only get so far at a company that makes bedazzled cars that don’t go anywhere. Eventually, reality catches up with you. I often tell teams I work with that the challenge is not to stop delivering things or to fight back against an output focus, but rather to make the connection between outcomes and output as clear and accessible as you can. “Yes, and” your way through executive feature requests rather than fighting against them.

Q: If AI makes shipping features faster and cheaper, does it help teams escape the low-impact death spiral, or accelerate it? What would you look for to tell the difference?

It 100% accelerates it. I’ve never seen more low-impact, low-value, nobody-wants-this features being shipped than I'm seeing now. And if the cost of tokens goes to zero, it gets even worse. There should be real urgency to put systems in place that halt and break the death spiral–but instead, I’m seeing more urgency to “adopt AI” and to “ship faster”–which, of course, is only going to make things worse.

Q: If there is just one core takeaway or behavioral change you want a product leader to implement tomorrow morning after reading your work, what would it be? For one, what should they stop doing?

Ask yourself, honestly, if the teams you lead would have any incentive to tune the engine rather than bedazzling the hood. And ask yourself what you would need to change to begin shifting those incentives.

This has been the latest installment in Fourthline's Big Interview series: Ten questions, asked by our leaders, answered by the people who move them.

Read more: Fleur de Roos interviews writer, Anna Boogaard.