Menu

3 product management links for January 30, 2023

I have a few product-related articles that I wanted to reflect on and write more about, but I just don’t think I’m going to get to it. They’re all really good though, so instead of just archiving those notes I wanted to share them so you can check it out.

1.

Here’s some solid advice from Jason Knight on what to do when your product is a mess and you have to fix all the things all at once:

In a situation like this, you’re going to have to get super-pragmatic. You’ve got lots of fires all burning at the same time and you need to put them out before you can start prioritising ‘properly’. Your goal is to get back on track as soon as possible, and you’re going to have to do a bit of shovelling to get there. Do what you need to get done.

And:

What we’re doing here is looking to put out the fires, and get a variety of initiatives to a base level of quality. You’re very unlikely to be able to make 15 things amazing all at once. Your goal here is to make all ships rise together. This means working with your stakeholders to understand what the minimum viable solution to these issues is, getting brutal with scope, and expending as little precious development time as possible.

2.

Andy Nortrup writes about what he learned about product management from Bonsai:

Similarly, with software products, patience is an important skill to make sure we don’t push the team faster than they can write good code, or make changes to the product faster than you can learn from users’ response to the changes. Patience can help us be less frantic and pay attention to the work in front of us in this season rather than the whole roadmap.

3.

Rich Mironov talks about the differences between products and features, and I especially appreciated this point about what users care about:

Customers don’t care about how hard we worked. Our product either does what the customer needs, or it doesn’t. And it should be priced based on customer value, not recovering our expenses. Users don’t care how much we spent, how big (or great) our team is, margin demands from Finance, remote versus on-site teams, development velocity, scrum vs. kanban vs. XP vs. lean.

Obsession, endless curiosity, and the joy of iterative projects

I love when people get obsessed with a topic and then turn that obsession into an “iterative project” where they do the same thing over and over until the topic has nothing left to give. An example: my friend Dave watches sci-fi movies hundreds of times and obsesses about the typography for his blog Typeset in the Future. I think his post on Alien is my favorite:

The opening credits for Alien are nothing short of a typographic masterpiece. You can watch them in their entirety on the Art Of The Title web site, but here’s the general gist: a slow, progressive disclosure of a disjointed, customized Futura reveals the movie’s central theme over 90 seconds of beautifully-spaced angular lettering.

Dave’s book is also amazing and you should buy it.

Clive Thompson wrote about this topic recently in his essay The Power of Indulging Your Weird, Offbeat Obsessions. His point about the value of following your obsessions is this:

It’s enormously valuable to simply follow your curiosity—and follow it for a really long time, even if it doesn’t seem to be leading anywhere in particular. Surprisingly big breakthrough ideas come when you bridge two seemingly unconnected areas.

A few other recent examples got me thinking about this again. Ander Monson watched Predator 146 times and wrote a book about it. From an interview with him:

In following every rabbit hole of his obsession with the film through to its end, Monson creates a book that is truly one-of-a-kind—not just a dose of nostalgia for movie buffs, but a revelatory investigation for anyone who’s ever really loved a singular piece of culture, enough that it got tangled inextricably in their identity and could never quite be excised. In Monson’s own words: “I believe that if you look long and hard enough at what you loved best at fourteen and how you lived then and what you saw in the world, it will reveal both the world and you.” As the pages turn, a question inevitably arises: What have you loved in the way that Monson loves Predator? And, for better or worse, how has it made you who you are?

A few weeks ago Monson published an essay about a similar project: Sean T. Collins’s “Pain Don’t Hurt”, an out-of-print book of 365 essays about the movie Road House (you can read every essay on his website). Monson starts off by calling this a “bad idea essay”, and if anyone is qualified to say that, it’s the guy who watched Predator 146 times. But he goes on to say this:

The reason I love bad idea essays is not because they seem dumb or bad but that they’re hard. Anyone can write a good idea essay. But only a real pro—or a real fool, and it’s hard to tell which you are when you start one, which is the entirety of the stakes of the bad idea essay—can write a bad idea to its exhaustion/completion. Only after exhausting yourself will you see if it was worth it.

But it’s these paragraphs that really get to the heart of the matter for me:

365 essays about Road House is an idiotic thing, and its idiocy is part of its appeal. I am often moved by iterative projects, because in repeating an action every day or every week or every year you make time a subject. […]

The reason I love iterative projects is that the plot is inevitably the movement of the mind (or the life or the body) through time. Every piece is a technical problem: oh shit, what am I going to do today? And the technical problem just gets harder as it goes deeper: How can I not bore myself on essay 241?


The reason obsessive projects like these—or what Monson calls iterative projects—are so appealing to me is two-fold. One, there is The Sad, Beautiful Fact That We’re All Going To Miss Almost Everything:

Surrender, on the other hand, is the realization that you do not have time for everything that would be worth the time you invested in it if you had the time, and that this fact doesn’t have to threaten your sense that you are well-read. Surrender is the moment when you say, “I bet every single one of those 1,000 books I’m supposed to read before I die is very, very good, but I cannot read them all, and they will have to go on the list of things I didn’t get to.”

Two, if we agree that we’re going to miss almost everything, there is a certain beauty in picking a small number of things you want to know everything about, and then sharing that with those around you. We know from the African philosophy of Ubuntu that “I am because you are”, or:

Humanity is not embedded in my person solely as an individual; my humanity is co-substantively bestowed upon the other and me. Humanity is a quality we owe to each other. We create each other and need to sustain this otherness creation. And if we belong to each other, we participate in our creations: we are because you are, and since you are, definitely I am.

One of the most tangible ways we can “owe humanity to each other” is by crawling deep into the corners of a specific topic and picking out the best pieces of it for the people around us. It’s saying, “I know we’re going to miss almost everything, but on this thing I got you. I’ll go deep so you don’t have to, and I’ll share what I learn so we can both enjoy what makes it special.”

There’s one more thing that really drove this point home for me recently. Substack has an interview up with Nicola Lamb, author of the Kitchen Projects newsletter. Nicola has built a very large following on Substack, and her answer to the question “What have your subscribers taught you?” summarizes this entire post so well. In essence, her audience taught her that we all want to hear about each other’s obsessions:

[My audience taught me] to be unashamedly obsessed with whatever you are into. To not shy away from details and to get deep into whatever it is that you love. Thank you for that.

So maybe this is something for all of us to ponder a bit more. What are you obsessed with that seems so niche that surely no one else would care? I’ll say this: if someone can write a fascinating book about watching Predator, I guarantee that your “bad idea essay” is probably actually a really good idea for an iterative project. I, for one, would love to read it.

Link roundup for January 29, 2023

Internal communications for executives

Some great tips here from Will Larson on how to improve internal communications as a leader. I especially like “Maintain the drip”:

These updates establish a persistent drip of information from you to the wider organization. Some weeks you might have a light update, but rather than folks thinking that you’re not doing much, they’ll be reassured that they are up-to-date on what’s important. Dense updates are good, but it’s the brief updates that reassure the team that you would have updated them if there was something they needed to know.

Read on for the others: test before broadcasting, build the packet, and use every channel.

The importance of setting context as a product leader

I enjoyed David Pereira’s breakdown of The Three Phases of Product Managers—and not just because he got me with his jazz reference. The third phase:

A Product Manager acting as a Jazz Player will set the context, and team members will build upon it. They relentlessly search for opportunities to create something innovative and outstanding. This scenario is more or less like the following:

  • Context: Product Managers bring the proper context to the team. Goal, audience, value proposition, objectives, and strategy. The team can help sharpen the context, and that sets the playing field.
  • Uncovering Opportunities: Everyone in the team has the same voice. They bring potential opportunities and evaluate whether it’s worth investing in them.
  • Learning: Curiosity is what drives them. As in Jazz, the team isn’t afraid to try solutions as fast as possible. They improvise and don’t fear embarrassment, but they’re scared of not learning fast enough.

I also agree with David that the most difficult part about growing into a product leader is the shift from “Conductor” to “Jazz Player” (in the model he shares in the post). And among those attributes, context is the hardest, and remains something I am constantly trying to get better at.

Synthesizing information and providing the necessary context to our teams about projects or decisions take longer upfront, so many leaders skip that part because they have so many other things vying for their attention. But the problem is that if you don’t do that work upfront you’re only going to have to do it later—and in a more time-consuming way. The team will have questions, there will be lots of back-and-forth, and they will likely also be frustrated by the lack of clarity in their work. So don’t skip that part. Don’t just say “here’s what we’re doing”, say “here’s what we’re doing, here’s why we’re doing it, and here’s the data that supports why we’re doing it.”

Ben Balter puts it this way in his excellent article Leaders Show Their Work:

As the ones with that missing context, leaders sometimes naively or inadvertently assume that all that’s required for a change to take effect is to communicate the thing that’s changed, but humans are not servers. Unlike deploying a change to a codebase, a diff isn’t sufficient to truly realize what’s intended. Engaged humans rightfully seek to understand how and why the change came to be and often want to double check their leaders’ work to fully understand how it impacts their own.

Stray Links for January 26, 2023

Engineering maturity models and the importance of a strong foundation above all else

In his article Engineering Maturity Model Mike Fisher shares how he thinks about the importance of different team capabilities when building software organizations. Despite how some maturity models—such as the Capability Maturity Model (CMM)—have been misused in the past, Mike encourages us to look past the process and focus on the principles. Here’s the important part:

[The layers] aren’t stages in that you’re never really finished with any of them but you do need to have the ones at the base stronger and more developed than the ones further up or else you are certain to run into problems. […]

While I do think of this kind of like a maturity model, they are not stages that one achieves and moves on from. These are areas that one must keep returning to and keep investing in, always from the bottom up. Getting over your skis and investing too much in the top, which is very tempting for startups, is fraught. Too many product development teams without continued investment in the infrastructure or deployment pipeline can slow everyone down, proving Brooks’s Law. The important task for Engineering leaders is to determine when and how much investment gets made into each of these layers.

To put it another way, if the base of your infrastructure and deployment pipeline is shaky, an increased focus on product development is eventually going to bring the whole house down. Click through to the article to see Mike’s full model.

Distractions, monk productivity, and the importance of “between-time”

Sometimes the internet seems to think about the same things at the same time. Last week we were all in on meetings (see here, here, here, and here), and this week we’re all talking about distractions. Here are three excellent articles about this topic that all came across my feeds this week.

First, there is a new interview with the father of deep work, Cal Newport (NYT gift article link). He talks about context switching and “slow productivity”—and it’s really good:

I’m trying to develop this notion of productivity that’s based on, at the large time scales, the production of things you’re proud of and that have high impact, but on the small time scale, there’s periods where you’re doing very little. […] So how do you actually work with your mind and create things of value? What I’ve identified is three principles: doing fewer things, working at a natural pace, but obsessing over quality. That trio of properties better hits the sweet spot of how we’re actually wired and produces valuable meaningful work, but it’s sustainable.

Matt Reynolds has a catchy title in Wired: Easily Distracted? You Need to Think Like a Medieval Monk. It’s a fun exploration of how medieval monks were, as he calls them, “the original LinkedIn power users” who kept trying to one-up each other with how distraction-free they were living:

These kinds of stories reminded monks just how hard it was to stay focused. They weren’t expected to be concentration machines. They too would come up short every now and then. “Acknowledging that upfront is a kind of compassion,” says Kreiner. “Monks are really good at being compassionate to each other, and to how hard it was to really follow through on stuff.” Freeing ourselves from distraction is really difficult. We don’t have to feel awful about not always matching up to our lofty goals.

And finally, in a short read Mandy Brown talks about the importance of Between-time:

We live in a world full of distractions but short on breaks. The time between activities is consumed by other activities—the scrolling, swiping, tapping of managing a never-ending stream of notifications, of things coming at us that need doing. All that stuff means moments of absolutely nothing—of a gap, of an interval, of a beautiful absence—are themselves absent, missing, abolished.

If I had to find a thread through all these pieces, it would be this:

  • Not every moment needs to be filled with work that produces output. Cal Newport calls this working at a natural pace: “one with more variability in intensity than the always-on pace to which we’ve become accustomed.”
  • Everyone gets distracted. Have some grace for yourself, and others. And try to distinguish between “distractions” (filling time with stuff) and “between-time”—those real breaks that we all need but get so little of.

More

  1. 1
  2. ...
  3. 30
  4. 31
  5. 32
  6. 33
  7. 34
  8. ...
  9. 202