Impact First: How Product Teams Escape the Low-Impact Death Spiral

LeMay's new book, Impact-First Product Teams, asks what individual product teams can do to align their work with business-critical outcomes, however their organizations approach product development. He says the reason is simple: at the end of the day those outcomes are what a team will be judged on. If a CEO or CFO can see that a team is a good investment, the business keeps investing; if nobody can tell, the team sits in a tenuous position.

The immediate trigger is the wave of layoffs hitting product managers and teams. LeMay points to the message Spotify's Daniel Ek sent with the 2024 layoffs, saying the company still had too many teams doing "work around the work" rather than pursuing opportunities with real impact. LeMay recognizes himself in that: he has been on supporting teams and assumed that any work he was given must be critical, otherwise nobody would have hired him to do it.

He adds that the end of the zero-interest-rate era, the expense of hiring and the push for cost savings make that assumption unsafe. Impact also helps in the job market, since the most common resume advice is to show the number. LeMay admits that collaborative people find it hard to claim credit, which is why he frames the product team, not the individual, as the foundational unit of impact.

LeMay's first question to teams is whether they would fully fund themselves if they were the CEO. When he was a product manager he treated his team's existence as a fact of the universe and only worried about finding the next defensible thing to build. It never crossed his mind that someone might look at the team on a spreadsheet and ask why these expensive people were needed.

Most people he asks hesitate, and LeMay sees that as risky because nobody else is better placed to answer than the team itself. If the answer is not a confident yes, the team should ask what to change: its purview, its goals, or the people it needs to talk to. It is better to have that conversation proactively than to wait for someone to have it for you, or at you.

On the "mini CEO" idea, LeMay offers a refinement. The product manager is responsible for the whole team thinking like a CEO, not for being the only one who does. In his consulting work an engineer, designer or researcher has often reached the impact-level goal before the product manager. Drawing on Melissa Perri's definition, he describes the job as facilitating a value exchange between business and customers, and says the best teams get curious about what success means for their particular business, from startup runway to promises made to shareholders.

For twenty years product development has been about best practices, which LeMay values for the knowledge sharing they brought. The downside, he says, is fixation on doing things the right way, and most of that writing sits in a middle layer between business impact and daily work. Teams key on being on strategy, having OKRs and scoring them 0.6 or 0.7, while the real goal of revenue, growth or profit sits far away.

Every time impact is cascaded into objectives, initiatives, bets and strategy, it adds assumptions and risk that the final checklist of features will produce a successful business. When LeMay asks teams how their lowest-level goals add up to their highest-level ones, they look at him as if he had asked something impossible. He has never seen a company where the work could be traced as a clean breadcrumb trail back to impact.

The result, he says, is that teams "sweat the middle" and get stressed when objectives, initiatives and bets are not in perfect theoretical harmony. Going through the motions of doing OKRs or strategy correctly does not guarantee that the work will add up to what investors need to see.

LeMay describes the low-impact death spiral as the dynamic nearly every medium or large company, and many small ones, falls into. It starts with teams taking low-impact work such as little features and cosmetic improvements because it invites less scrutiny and is less likely to break something important. His analogy is a car: you can work on the engine and risk the car not running, or add a paint job and rhinestones that everyone can see and that do no harm.

The trouble comes when ten teams add rhinestones. The product turns into a collection of loosely connected features with dependencies on each other, so building anything gets harder and companies add program-management layers and reorganizations. That makes high-impact work harder still, which pushes teams further into low-impact work until the next round of layoffs.

Breaking the cycle, LeMay says, usually comes down to individual teams being brave enough to look at what matters to the business and seek out high-impact work, even if it means coordinating with many teams or attracting executive attention. Lenny adds the uncomfortable implication: even if executives tell you to build something low-impact, that is no excuse, and you can still be let go eventually.

LeMay illustrates the point with Mailchimp, where he worked for three years before the Intuit acquisition. As the company moved from a single product to a platform organized into domain teams, VP of product Natalia Williams set an ambitious goal to raise the rate at which users successfully send their first email. Many teams hesitated because it touched the commercial heart of the business or would slow the new platform work.

One product manager with a growth background ran research to find where people got stuck and gathered her peers in Atlanta. When the room went quiet, she told them she would haunt them in their dreams if they did not take it on. The teams did it, mostly by subtracting: streamlining the experience and removing steps, the kind of work rarely celebrated like a feature launch.

LeMay calls the required attitude both courage and radical acceptance of reality. Impact depends on competitors, markets and customer behavior outside anyone's control, but teams are accountable for it anyway, and the commercially minded product managers he interviewed were also the happiest. They did their best at work, understood the business model and went home without fighting to do product the right way. He cannot promise a pushback will be rewarded, but cites a dating-app team that told finance early its revenue goal was off track and had it adjusted jointly.

Understanding the business model also shows a company's real priorities better than its mission statement, LeMay says. Following the money and the decision-making helps you judge whether you want to help this company succeed.

Most product managers do not work at big tech companies, LeMay notes. Teams at insurers, banks, consumer goods firms and audio equipment makers often tell him they cannot do product properly because they are regulated, B2B or bound by quarterly targets. He finds that demoralizing, since it implies anything different from five famous companies must be wrong, and it leads to quixotic battles like turning a bank into a search engine.

His alternative is to treat those constraints as the substance of product management. If you are regulated, your competitors are too, so mastering the constraints is a commercial advantage. B2B companies have immediate access to customers and whole systems of users, and quarterly financial targets tell you exactly what the business cares about without cascading it into 45 OKRs.

Lenny asks for a simple way to say this and LeMay offers one: the things you think you are fighting against are usually the things giving your work shape, if you let them.

LeMay's first step, the one where most of his work happens, comes from Christina Wodtke's Radical Focus. Instead of a multi-level cascade from company to department to small team, the company goal is a center of gravity and each team's goal orbits one level around it. Whether you use OKRs, KPIs or a north star metric, he says, it should look like that if done well.

He describes a feature team at a fintech company that had always been told what to build and felt safer for it. When the business set a top-line revenue target and asked the team to say how it would contribute, LeMay asked why the team existed at all. The answer was that a multi-product user has a much higher lifetime value than a single-product one, and the company had the number, so the team could set a goal of converting a specific number of users.

Leadership grasped the goal at once, which gave the team room to make bolder decisions and ask other teams for resources. Asked about revenue goals in general, LeMay says it depends: some startups chase growth or profitability instead. But money is how most teams' impact will be measured, and having no view on why your team is a good investment is a risky position.

To show what a good goal looks like, LeMay recounts a growth team that spent a whole OKR season building a perfect deck of five to seven objectives, then spent a day arguing over 0.6 versus 0.7 scores. When he asked how it all added up to the company's goal of bringing on a million new users, there was silence. The team lead drew a line on a whiteboard with a million at the end and said that anyone 51 percent sure an approach would get them 1 percent closer should advocate for it.

Lenny suggests a test: there should be a simple formula connecting the company goal to yours. LeMay's version is one "why" statement or one mathematical operator, such as upgraded users multiplied by the increase in lifetime value, or a subset of the company's revenue or growth.

His second example is a team rebuilding a company's ad tech platform, which had a deck of goals and two sprawling Miro boards. In a subtractive workshop people repeatedly shortened their statement of the goal and ended with two candidates: a 20 percent profit increase, or growth from 20 million to 100 million pounds. Someone remembered a town hall slide with the larger target, and with only about 10 million pounds earned before an October launch, the team needed 90 million after it.

Rather than freezing, the team started asking the questions best practices intend: could they ship sooner, validate and test more, commercialize earlier, or rebuild individual pieces instead of one big relaunch? LeMay's point is that specific, impactful goals create the urgency that makes people do the discovery work they are supposed to do.

Step two is to keep impact first at every stage, including OKRs, company strategy and epics, so the goal does not get cascaded into oblivion. Lenny notes that teams often set a goal, spend months building and then discover the work has drifted away from what the company cares about.

Step three is connecting every piece of work to impact, which is where prioritization comes in. Teams ask LeMay whether to use ICE, RICE or MoSCoW, but without a specific sense of impact none of them can work. On the multi-product team, a product manager had an ICE matrix with abstract impact scores, so LeMay asked him to express impact as the number of users each option could convert.

One high-effort, medium-certainty idea, redesigning onboarding so people are classified correctly on arrival, could get the team all the way to the goal but depended on marketing and other teams. LeMay argued it was worth pursuing because it was the only option with a real chance of reaching the goal. The practical test is whether impact is estimated and measured in the same unit as the goals, so the team stays honest. He acknowledges this is hard, relentless stakeholder work.

LeMay describes himself as a conflict-averse people pleaser, and says that done well, product management means never saying yes or no. You give people options and help them understand the trade-offs. If the person asking has formal authority, he has never had luck saying no, and they may know things he does not, such as an acquisition or a financial challenge they cannot discuss.

Trying to convince them otherwise can cost trust that may matter later. Instead, show your team's goals, priorities and projected impact. If the request has more impact, build it gladly; if it has unclear impact, discuss how the projection must be adjusted. You then leave feeling less like you lost a battle to an unjust tyrant and more like you gave the decision-maker the information you would want.

Lenny adds that you should recommend a path, and LeMay agrees that options plus a recommendation is the magic formula. In a Mailchimp workshop, product managers role-played selling in one option versus several with a recommendation. With a single option people poke holes out of their own anxieties, whereas with three options and a recommendation each round of back and forth clarifies and strengthens the choices.

Lenny asks whether a team should leave things alone when the business is booming and the CEO is happy. LeMay says teams in good times can be as anxious as those in bad times because they cannot attribute success to their own work, assuming it is down to marketing or the sector. His advice is curiosity: talk to marketing about what is working and use the breathing room to build connections across the organization.

He is saddened when teams look at each other with envy, saying another team is not held to the same standards. He suggests going to talk to them, since a team getting positive attention probably has a reason. That openness puts you in a better position when things plateau or decline, which they inevitably do.

The question he would leave teams with is a gentler version of the funding test: what one sentence would you like to say to the CEO at the end of the year that leaves you feeling awesome about this team's work? Different people answer differently, and surfacing those perspectives and expectations is how you get people building together, like musicians writing a song. His closing hope is that people see their business's commercial realities as guideposts rather than things they must single-handedly change.

LeMay recommends Radical Focus by Christina Wodtke, which he calls the best book on OKRs, and The Wisdom of Insecurity by Alan Watts. From Watts he takes the law of reverse effort, the idea that the harder you try the worse you may make things, which he links to the tendency to overcomplicate goals and strategy. He also quotes Watts's idea that keeping yourself perpetually safe in an imagined future means killing yourself to the present.

His favorite recent product is a compact, lightweight amplifier from a small builder called Milkman Sound that does everything he needs on tour and nothing more. His life motto comes from his mother: no good work is wasted, even if it reaches only a few people. He says that belief led him to stop writing clickbait headlines.

Asked about his music reviewing years at Pitchfork, LeMay talks about his 2003 review of Liz Phair's self-titled album, written at 19 with unearned condescension. He apologized for it in 2019 and says he does not feel good about it. Listeners can find him at mattlemay.com, and the book is Impact-First Product Teams.