👋 Hey, I’m Lenny and welcome to a 🔒 subscriber-only edition 🔒 of my weekly newsletter. Each week I tackle reader questions about building product, driving growth, and accelerating your career. For more: Best of Lenny’s Newsletter | Hire senior PMs | Podcast | Lennybot | Swag After my conversation with SVPG founder Marty Cagan (currently the fifth most popular episode of the podcast and still growing), I saw many reactions to Marty’s difficult-to-hear advice. The strongest response came in a thread by Ben Erez. Ben made the case that feature teams are not innately wrong, and that “feature factory” PMs are real PMs doing important work. More than 200 comments later, with lots of full-throated agreement from readers and listeners, I thought it was worth spending more time on this perspective. With the newsletter and podcast, I like to give a platform to different ways to think about and build product, especially when a perspective seems to resonate with a lot of people. So I asked Ben to expand on his experience and insights in a guest post, which you’ll find below. Ben Erez is a longtime product builder who has worked at almost every stage of a company. He’s been a founder, a first PM at three different startups, and held senior PM roles at Facebook and Attentive. After leading product and design at Continuum (a marketplace for fractional executives), he now partners with early-stage teams as an advisor and interim first PM, helping founders define the PM role before making a full-time hire. For more from Ben, follow him on LinkedIn and check out his podcast, newsletter, and upcoming Maven course. This past March, Marty Cagan joined Lenny on the podcast to talk about his new book, Transformed. I’ve been a longtime fan of Marty’s and enjoyed his previous books, Empowered and Inspired (and have recommended both to others many times). I was looking forward to hearing all about Transformed. Marty’s conversation with Lenny went deep on the future of product management, feature teams versus empowered teams, and the degree to which product managers have agency to transform their cultures. Marty believes that most companies would be better with empowered PM cultures and expressed his views about why feature team PMs are more project managers than product managers. He came on the podcast to get spicy, and he certainly did. At one point, Lenny asked Marty for his response to a LinkedIn post I wrote about why feature factories—businesses that focus on outputs over outcomes—might actually be the optimal product culture for some companies. Marty said that in the long run, this way of thinking leads to building products that nobody likes (e.g. Oracle and SAP). On that point, we’re in agreement. Where our thinking diverges is that I see the feature factory as the right choice for some CEOs to run their companies, especially when those CEOs have a clear and compelling product vision. While I don’t think that feature factories make for better businesses, I do believe that many founders have a clear vision of what needs to be built in order to win; the resulting environments can often feel like feature factories because product teams are expected to execute on top-down directives. And VCs love to back these types of founders (pattern-matching to Elon Musk, Steve Jobs, etc.). I’m not saying it’s fun or enjoyable to be a PM in a feature factory. I’ve been a PM on both types of teams and have talked to hundreds of PMs about their experience. The general consensus is that empowered teams offer more strategic and meaningful work, making them preferable for PMs. My goal in writing this post is to round out the public narrative around feature teams and enable you to form a more nuanced perspective. Counter to the popular narrative, I believe that:
In this post I’ll explain why, and what that might mean for you. What’s a feature factory?“Feature factory” is a term that, I believe, John Cutler coined in 2016 (shout-out, John, for being awesome) to describe a process focused on rapidly producing and shipping features without strategically considering the impact these features have on users and the business. John’s original post lists 12 ways to know you’re in a feature factory, which I boil down to rewarding outputs over outcomes. Feature-factory teams are praised for shipping many features but not for achieving specific goals or moving important metrics. Note: Even in a feature factory that doesn’t explicitly focus on outcomes, there still should be a basic floor around the quality and reliability of the features being delivered to customers. Feature teams vs. empowered teamsThe alternative to the feature factory is a culture that rewards outcomes over outputs. These teams are praised for helping the company figure out what to build, solving customer problems, improving customer satisfaction, moving the needle on key product metrics, and contributing to company goals. Marty refers to teams in feature-factory environments as “feature teams” and the alternative as “empowered teams.” I’ll use those terms in this post. I’ve worked in both environments and personally find empowered teams 10 times as enjoyable as feature teams, a sentiment shared by every PM I know. Yet despite empowered teams being dramatically more popular environments for PMs (stated preference), the majority of PMs still seem to be operating in feature teams (revealed behavior). I dug into this delta and boiled it down to several reasons PMs stay on feature teams:
Regardless of their reasons, many feature team PMs decide to stay. And when they hear the following, they feel frustrated because the validity of their role as a PM is called into question:
I’d like to counter the notion that the only real PMs are those on empowered product teams. I believe that PMs on feature teams are also real product managers. The role of feature team PMsI believe Marty is heavily discounting the product work required for feature teams to be successful. When a feature request comes in, it’s usually vague. Sometimes it’s a single sentence. When a feature team commits to delivering a new capability, the PM is responsible for execution, which means driving the cross-functional team effort to translate the request into a useful experience for the customer/user the feature is intended to serve. Feature team PMs often don’t have a dedicated project manager or program manager they can rely on for tactical execution support, so they need to do it themselves, leading to the misconception that feature team PMs are merely project managers. (They may have to do some project management, but their core work is product work.) In my experience, the product work involved on a feature team and empowered team are largely the same. Here are some of the PM activities you’ll see on both teams:
On an empowered team, PMs take on additional responsibilities:
While I agree with Marty that an empowered team can do everything a feature team can do plus some, feature team PMs do product work. They’re real PMs. Why CEOs value feature teamsSimilar to every other function in a company, the Product function exists primarily to serve the business and its customers. Successful product leaders often help the CEO flesh out their vision and bring it to life by working with PMs to execute at the highest level. Many CEOs (especially founders) want to hire world-class product leaders to help them build winning products, yet they ultimately struggle to create empowered product cultures. Some of these CEOs value execution speed above all because moving quickly is what has worked for them in the past, or has been successful for other leaders they know. Some want feature parity with competitors so that they can close more deals faster. They want filled checkboxes on those side-by-side competitor charts. And sometimes, to catch up to your competitor or to win a big deal, you do need to ship a bunch of features. Here are a couple of scenarios that will sound familiar even to CEOs who want an empowered product culture: Scenario 1: Staying ahead You’re the founder of a company whose competitor launches a new capability. Your customers notice and start asking when you’ll have it. You become paranoid that if you don’t build the capability, you’ll lose customers to the competitor. You decide to build the feature as a defensive play to protect revenue. Scenario 2: Displacing incumbent You’re the founder of a vertical B2B SaaS company attempting to displace a legacy player in a well-known domain with clear jobs to be done. You decide that reaching feature parity on certain must-haves is the only way to win deals. So you fund a multi-quarter feature roadmap. In both situations, it’s the responsibility of the product leader to help the CEO understand the tradeoffs of various paths. The product leader might make the case that the company should be more strategic and customer-focused with its roadmap, and that choosing to fund these long-term roadmaps is reactive. But once a CEO has made up their mind, the product leader needs to commit to the decision. Otherwise they’ll irreparably damage their trust with the CEO. Product leaders who consistently struggle to influence their CEO can either stay for similar reasons as those of feature team PMs or they can leave. This dynamic is part of the reason why the typical tenure of a product executive is one to two years. When feature team PMs try behaving like empowered PMsWith so much hype about the benefits of being a PM on an empowered team, it’s not surprising that some feature team PMs start behaving more like empowered team PMs. Here’s how that tends to play out:
I’ve seen this happen firsthand and have heard it from many other PMs. With that said, I’d like to highlight a story about a product leader (not an individual contributor) who pushed his team to do the empowered product job on top of the feature team job for the better part of a year to show results. Marty describes this as a proven transformation technique called an “outcome-based roadmap,” which could be a reasonable expectation for some teams with particularly strong product leaders.
In summary, I’d caution feature team PMs against trying to behave like empowered PMs without a strong product leader spearheading the transformation and a stomach for a huge amount of work. It’s an uphill battle unless the CEO decides to embrace the empowered culture—a decision that is significantly more likely to occur with a strong product leader present. That said, if you see an opportunity to make this transition in your current role, I think it’s worth considering. It’ll help you build better products and teach you new skills while also providing you with opportunities to gain a new set of experiences and stories that set you up for success down the road. So what’s my advice for feature team PMs?...Subscribe to Lenny's Newsletter to read the rest.Become a paying subscriber of Lenny's Newsletter to get access to this post and other subscriber-only content. A subscription gets you:
|
Search thousands of free JavaScript snippets that you can quickly copy and paste into your web pages. Get free JavaScript tutorials, references, code, menus, calendars, popup windows, games, and much more.
In defense of feature team product managers
Subscribe to:
Post Comments (Atom)
How to debug large, distributed systems: Antithesis
A brief history of debugging, why debugging large systems is different, and how the “multiverse debugger” built by Antithesis attempts to ta...
-
code.gs // 1. Enter sheet name where data is to be written below var SHEET_NAME = "Sheet1" ; // 2. Run > setup // // 3....
No comments:
Post a Comment