I think this is a really insightful comment (LinkedIn) by Ben Erez about the realities of being a PM in a sales-led organization. It’s worth reading his whole argument because it’s definitely a spicy take. But the crux of it is that sales-led organizations cannot function with empowered product teams (I think everyone who reads this blog knows what I mean by that, but just in case, here’s a refresher).

Here’s a key part of Ben’s argument, and the really spicy part:

I think sales-led companies should embrace the feature factory culture fully; stop evaluating PMs by their strategic contribution (a weight off the PMs shoulders given they never get time for strategic work anyway) and start rewarding PMs based on how many features they ship that the sales leaders care about. This will align the PMs in your org to think and work the way the sales team (and CEO) wants them to work. It’ll kill many unhealthy tensions in the org and get people rowing in the same direction.

Would I want to work in that environment? Probably not.

But most b2b SaaS companies are already sales-led. And there are thousands of PMs in those environments who feel the tension I’ve described. So I think most b2b SaaS PMs would celebrate their company embracing their feature factory and just calling it what it is.

Could this be seen as defeatist? Maybe. But I also think that the “just calling it what it is” part of the argument is really key here. It doesn’t serve anyone—not the product, not the company, and certainly not its customers—to pretend you have an empowered product culture when you do not. So remove the pretense, and just be honest about who you are.

If you want to become an empowered organization, that’s great! But that’s a transformation that has to come from the executive level, and it’s not a short or easy process. So go on that journey, yes! But until then, be honest about what the organization is, make expectations clear to PMs, and reward them accordingly.

The importance of async work and cutting down on meetings to allow for more Deep Work time won’t be new to regular readers of the blog. And yet I can’t resist sharing another article about it… How Asana and Slack’s meeting purges have paid off has the usual methods and recommendations in it (although “Meeting Rest” is a new one to me—read the article for details).

Instead what I want to focus on here is a few pull quotes about the results companies report once they were able to successful reduce their meetings. Here’s Asana:

A few months later meeting lengths had shrunk. Most 30-minute meetings were converted to 15 minutes, some weekly meetings were moved to every other week or month, and others were deleted entirely. That meant each person was saving an average of 11 hours per month, totaling about 3.5 workweeks per year.

And:

The 60 participants saved 265 hours per month in total when reducing unproductive recurring meetings. In the aftermath of our meeting reset, employees are much more strategic and thoughtful about removing items from meeting agendas that can be effectively handled asynchronously.

From Remote:

By cutting down on meetings, we’re not just saving time. We’re also empowering our teams to work on their own schedules. This gives our employees a sense of autonomy and keeps them motivated, fostering a culture of productivity and efficiency.

And finally, Typeform:

We sent another engagement form to the team to see how they were feeling after we made these changes. The ‘ways of working’ score went up more than 10 points. Trimming our meeting time has helped our employees and our customers, which is really satisfying.

It’s worth the effort, friends. Re-evaluate the need for all those meetings. Embrace async. It leads to happier employees and more effective communication in permanent places that can be referenced in the future. And, importantly, it leads to higher quality products because no one has to rush through “actual work” after all their meetings are finally done for the day.

Great points on company culture from the Raw Signal group in You don’t have a culture problem, you have a management problem:

Culture handbooks don’t produce culture, people do. The culture you experience in your organization is a rolling average of the last thousand interactions you’ve had. Every piece of feedback, every conflict, every trade-off is culture. Every hiring, promotion, and firing, too. Those interactions come from everywhere, but a disproportionate number will come from your close peers, and your own boss. Culture may be everyone’s job, but some people have a lot of sway on your local average.

They go on to explain what managers can—and should!—do to take ownership of the culture in their organizations.

This is a fascinating profile of MrBeast and his YouTube empire (NYT Gift Article). It’s extensively researched and presented with a steady hand. The reason I link to it here is I think he would be a pretty good product manager, albeit a litte bit on the obsessive side:

Donaldson stands out for his dedication to understanding how YouTube works. For most of his teenage years, “I woke up, I studied YouTube, I studied videos, I studied filmmaking, I went to bed and that was my life,” Donaldson once told Bloomberg. “I hardly had any friends because I was so obsessed with YouTube,” he said on “The Joe Rogan Experience” last year.

After high school, he hooked up with a gang of similarly obsessed “lunatics” and planned out a program of study. He and his friends “did nothing but just hyperstudy what makes a good video, what makes a good thumbnail, what’s good pacing, how to go viral,” he told Rogan. “We’d do things like take a thousand thumbnails and see if there’s correlation to the brightness of the thumbnail to how many views it got. Videos that got over 10 million views, how often do they cut the camera angles? Things like that.”

That reminds me of the famous 41 shades of blue testing at Google. Also, one thing I never realized about the whole thing is that MrBeast’s pitch is basically “Hey, you do charity just by watching me because I use the money I get for charity, so the more you watch me the more charitable you are.” That is a bit disturbing but also pretty clever.

It might be controversial, but I tend to agree with Kax Uson point about managing feature requests from stakeholders:

I have learned that it’s perfectly alright for stakeholders to have solution requests. And to expect them to bring problems to us is unrealistic.

The post gives some good advice on how to translate solution requests into problems/opportunities that teams can solve:

Speak the language they speak. Talk about the benefits and impact of their requests. If you do build the feature they’re asking for, what value would it provide for the customers/users and the company? Speak in outcomes.

There’s some really good advice for job seekers in Carilu Dietrich’s post 10 Most Important Metrics For Evaluating a Company:

Net Dollar Retention (NDR) is one of the best ways to see if a tech company is healthy and growing. It measures the expansion or contraction of a company’s existing customer revenue over a given period. NDR takes into account the revenue lost from churn and increased revenue from upselling, cross-selling, and renewals from existing cusomers.

I would also add Gross Revenue Retention to that list. It describes how much revenue a company keeps from its existing customers over a specific period, not including any new revenue from new customers. So, if a company started the year with $100 from its existing customers and ended the year with $90, even if they lost some customers but upsold others, the gross revenue retention would be 90%. It helps guage how good a company is at keeping its current customers happy and continuing to spend money, without taking into account any new business they’ve gained.

I promise this isn’t going to become an AI blog, but Marty Cagan’s latest on Preparing For The Future has some solid points on how generative AI might change our profession. Here he talks about the impact on QA:

The new generation of AI-based test automation tools has the promise to revolutionize our approach to ensuring the product is behaving properly. On the other hand, our current approach to quality is largely based on deterministic products.  This means that given a set of inputs we can predict what the appropriate output should be, and we can count on that being true indefinitely.  

Yet for many new products built on generative AI, our products are no longer deterministic, but rather probabilistic.  We can no longer count on the same inputs generating the same outputs.  For many contexts, this is not a problem.  But for other contexts, especially when safety is involved, this will require different approaches to ensure appropriate behavior.

Also, yes please:

For those product managers of empowered product teams, the time spent creating artifacts such as written narratives, roadmaps, PRD’s, and acceptance criteria, as just a few examples, should be significantly assisted by the new generation of tools, some of which are already starting to appear. Even at the very rudimentary level, if the new generation of tools can significantly reduce the time a product manager (or engineer) spends dealing with tools like Jira, that will be a substantial win.

Aniket Deosthali (Head of Product for Conversational Commerce at Walmart) provides a great framework for evaluating AI product opportunities in How to Build AI Products People Want:

The most efficient way to evaluate AI opportunities and unlock the advantages of AI is by using the Consideration x Context framework. Let’s start with some baseline definitions.

Y-Axis = Consideration: The amount of effort required to make a decision.

The more thought you put into a decision, the higher consideration it is. For example, choosing a dish detergent is “low consideration” for most shoppers, compared to buying a car which is “high consideration.” Consideration can be represented as a function of the number of compelling alternatives and the stakes – users’ tolerance for errors, for example.

X-Axis = Context: The volume of abstract concepts AI needs to know. 

Context refers to how many abstract concepts a model needs to know in order to provide a useful response. Does it only need to understand a small batch of data points (like a product catalog), or does it need to understand the entire internet (like ChatGPT)?

He goes on to explain how to plot different solutions on a “Survival Curve.” If you work on AI products this is one of the rare actually helpful articles for PMs in the area of AI and LLMs.