The Reforge team has a long post on How To Master the Art of Managing Up. I find this aspect especially important:

Those who have mastered managing up will package problems in a way that takes their managers’ constraints into account,  including time, lack of resources, or competing priorities. 

Your approach to packaging and communicating difficult situations can make the difference between managing up effectively and just causing more chaos for your manager.

They go on to provide some very good, practical tips for how to package problems effectively.

There’s a lot going on in John Warner’s Speed and Efficiency are not Human Values. It’s primarily a reflection on generative AI tools in the context of being a published author—and well worth reading.

But the reason I am linking to it here is because it gives you an excuse to watch (or re-watch!) what John calls “the greatest guitar solo ever captured on a recording” (he is 100% correct). Here is Prince at the Rock and Roll Hall of Fame induction ceremony in the year both he and George Harrison (posthumously) were enshrined:

Here’s how John describes the solo in his post:

Prince was obviously a highly skilled guitarist capable of blazing speed on the fretboard (like the “Flight of the Bumblebee” guy) and indeed there’s a couple of spots where he just rips through some rapid note runs, but it’s also intensely musical, totally its own thing, while also managing to reference aspects of the solo from the original version (performed by Eric Clapton). […]

A great guitar solo is not about how fast you can play, or your degree of technical skill. It comes from a deeper place.

I know you’re going to roll your eyes, but seriously, the solo and that quote—it comes from a deeper place—inspires me to think a little bit more about the feel of the products we make, and a little bit less about the ”correctness” of fitting a specific mold.

I really like this list of heuristics by Itamar Gilad for how much data you should have before launching product features/improvements:

• Never launch anything solely based on opinions.
• It’s ok to release minor tweaks based on assessment.
• Having supporting data (without testing) is enough to launch only very small, low-risk, easy-to-revert changes.
• Everything else should be validated through tests and experiments. However there are various levels of testing to choose from with different associated costs and confidence levels.  
• How much validation you need depends on: a) the cost of building the idea in full, b) how risky it is, and c) your risk tolerance. 

It’s also the first time I’ve come across his confidence calculator, which looks like a really useful tool (email-gated, though…).

Here’s a good theory by Bruce Daisley about the real reason why productivity might be falling in organizations:

If you want to understand why productivity is falling, we need to look first at high levels of employee turnover. If we want to solve productivity issues the first step needs to be to lower the resignation rate.

We all know well when people quit their jobs a period of unproductivity commences: bosses and colleagues need to cover the work of the person leaving, the recruitment process takes unproductive attention and new starters take months to ramp up. As Ton says, ‘high employee turnover is ruinous for productivity’.

Blaming “low productivity” on the rise of remote work—like some publications are trying to do instead—seems pretty lazy.

Noah Smith’s rumination on how technology has changed the world since he was young really resonated with me:

When I look back on the world I lived in when I was a kid in 1990, it absolutely stuns me how different things are now. The technological changes I’ve already lived through may not have changed what my kitchen looks like, but they have radically altered both my life and the society around me. Almost all of these changes came from information technology — computers, the internet, social media, and smartphones.

He goes through several examples, and comes to this conclusion:

Sometimes technology grows the economy, but more fundamentally, it always weirds the world. By that I mean that technology changes the nature of what humans do and how we live, so that people living decades ago would think our modern lives bizarre, even if we find them perfectly normal.

Like him, when I think about it all and compare it to life in 1990, “I can’t help but feel a little overwhelmed by how far we’ve come.” And yes, I miss some of the things Noah mentions in his post—I have fond memories of “getting lost” with my wife in European cities. But for the most part I am much more in line with Clive Thompson’s thinking in his book Smarter Than You Think: How Technology Is Changing Our Minds for the Better:

Today we have something that works in the same way, but for everyday people: the Internet, which encourages public thinking and resolves multiples on a much larger scale and at a pace more dementedly rapid. It’s now the world’s most powerful engine for putting heads together. Failed networks kill ideas, but successful ones trigger them.

His book is a wonderful perspective on all that we’ve been living through.

The first part Sara Ramaswamy’s Product-Led Growth and UX is just a summary (a good one!), but the “How UX Can Help” sections has some really great insights and ideas, like this one:

While macro conversions (high-level conversion tied to the primary purpose of the site) are often the first success indicators considered, it is, however, important to define and revisit micro conversions, which measure incremental improvements to the user experience. In product-led growth, products are competing at the micro-conversion level. Analyze the conversion user journey and create milestone micro conversions that capture progress toward primary macro conversions. Also identify secondary user actions on site that are correlated with macro conversions.

“Compete at the micro-conversion level” is a really good lens to keep in mind as we improve our products.

I saw two deeply personal posts this week, each related to the dangers of chasing after vanity metrics. First, Justin Andersun tells us about The Ski Lesson, and concludes with this:

We should not lose touch with the spirit of what we’re doing. A job’s essence is to serve the needs of others, and friendship is to support the people we love. Metrics become vanity when they lose touch with that spirit.

Second, fio dossetto writes this about being mindful of vanity metrics:

Vanity metrics are easy to pick and hard to let go of. They can subtly but significantly damage the system for a long time before you spot them, at which point you’ll need to take a hard look at your actions and decide how to course correct. Fast.

Both posts highly recommended!

I think this is the best definition I’ve seen so far of that elusive term “product sense”:

I define great product sense as the ability to do two things without having extensive data (i.e. without running lengthy research upfront):

• Generate many solid, highly profitable ideas for ways to make money
• Intuit whether a product is likely to be successful with a high degree of confidence

The detail of having this sense without extensive data is important. Anyone can get to a great product via guess-and-check. The best product minds reliably take a more direct path.

Ben Balter has a solid post on remote and async work, in which he makes the point that meetings are a point of escalation, not the starting point of a conversation:

A few minutes of reading or a few comments on an issue or Google Doc can often replace waiting days for mutual availability and a dedicated 30-minute block of time. In this sense, you can think of meetings as a point of escalation based on complexity, not as the default starting point for a workstream, initiative, or conversation.

Also see his excellent list of benefits of working asynchronously. Also also see Sisi Wei’s excellent guide on asynchronous participation in brainstorming, including this really great idea:

After the meeting, redesign that shared doc to become a worksheet for people participating on their own time. […]

The document should now read like it was designed for asynchronous participation to begin with. Instructions you may have given verbally – even helpful tips you realized and delivered impromptu – should now be captured as written instructions in the document.