While reading this great interview with the band CHVRCHES I came across a passage that struck me as a good description of how product managers should work. They describe the producer on their latest album like this:

And I think that’s why he’s so good at what he does. He’s not a kind of producer that has one thing that he does and he tries to make every artist do that thing. He steps into the room and tries to figure out the people that are in it and figure out the music they’re making, and then how can he add something to that and offer wisdom and guidance and make it better.

We all have methods and techniques we gravitate towards: Jobs-to-be-Done, Agile, customer journeys, sticky notes… It’s totally fine to have favorite methods that we know inside out and that have worked well in the past. But it would be a mistake to force one of our favorites on a team when it’s not the right thing for them.

One of the most difficult things a product manager needs to do is first understand how a team works and what makes them effective, and then figure out which methods and processes can create the right environment for them to thrive. That’s the skill that sets apart the great product managers from the good ones.

Ah, estimates. That thing we all know we need to do (and get better at), but no one really wants to talk about. Well, Gina Trapani takes the topic head on in a great post called Estimation Is a Core Competency:

Estimates don’t need to be perfectly accurate as much as they need to be useful.

Good estimates create trust among your PMs and business leaders and collaborators. Being able to identify the risks and uncertainties in a project early gives your project team the information they need to plan around those risks and uncertainties.

Are you consistently getting waylaid by unforeseen work mid-flight, or just taking longer to execute on the work you did know about? That creates distrust between engineers and business leaders, and if it happens repeatedly, that distrust compounds and calcifies into resentment— that is, if you’re still in business.

Gina goes on to give some great tips for better (i.e. more useful) estimates.

Do you remember the “One Laptop Per Child” project? The PR event made a huge splash back in 2005, and I remember being really impressed and inspired. As it turns out, OLPC is a textbook example of what happens when an organization has a sincere desire to solve a problem that they simply don’t understand.

Adi Robertson, writing for The Verge, has an excellent history of the project called OLPC’s $100 laptop was going to change the world — then it all went wrong. It starts with this anecdote:

Then, Negroponte and Annan rose for a photo-op with two OLPC laptops, and reporters urged them to demonstrate the machines’ distinctive cranks. Annan’s crank handle fell off almost immediately. As he quietly reattached it, Negroponte managed half a turn before hitting the flat surface of the table. He awkwardly raised the laptop a few inches, trying to make space for a full rotation. “Maybe afterwards…” he trailed off, before sitting back down to field questions from the crowd. […]

If you remember the OLPC at all, you probably remember the hand crank. It was OLPC’s most striking technological innovation — and it was pure vaporware. Designers dropped the feature almost immediately after Negroponte’s announcement, because the winding process put stress on the laptop’s body and demanded energy that kids in very poor areas couldn’t spare. Every OLPC computer shipped with a standard power adapter.

As you read deeper, it becomes clear that they were working on a solution that didn’t take local issues into account at all:

Bender thinks OLPC might have struck more deals if it had focused less on technical efficiency. “Every conversation we ever had with any head of state — every time — they said, ‘Can we build the laptop in our country?’” he says. “We knew that by making the laptop in Shanghai, we could build the laptop [to be] much less expensive. And what we didn’t realize was that the price wasn’t what they were asking us about. They were asking us about pride, not price. They were asking us about control and ownership of the project.”

To put it another way:

OLPC had created a computer that could withstand dust and drops, but it hadn’t accounted for political messiness.

There are many lessons to learn from this story, but most important is almost certainly that a desire to do something good isn’t enough to make a product successful. If you don’t fully understand the problem you’re solving and the people you’re solving it for, your chances of success are incredibly low.

Thi Nguyen’s essay Why it’s as hard to escape an echo chamber as it is to flee a cult is one of the most insightful things I’ve read in a long time. Nguyen argues that echo chambers are very different from what he calls “epistemic bubbles”, and that conflating the two concepts places our focus on the wrong solutions to the problem. In short, the difference is this:

In epistemic bubbles, other voices are not heard; in echo chambers, other voices are actively undermined.


Epistemic bubbles are easy to pop, because all it takes is to introduce previously unheard voices into it. Echo chambers, however, are extremely difficult to penetrate, because at its core lies the belief that everyone not in it is untrustworthy:

An ‘echo chamber’ is a social structure from which other relevant voices have been actively discredited. Where an epistemic bubble merely omits contrary views, an echo chamber brings its members to actively distrust outsiders. In their book Echo Chamber: Rush Limbaugh and the Conservative Media Establishment (2010), Kathleen Hall Jamieson and Frank Cappella offer a groundbreaking analysis of the phenomenon. For them, an echo chamber is something like a cult. A cult isolates its members by actively alienating them from any outside sources. Those outside are actively labelled as malignant and untrustworthy. A cult member’s trust is narrowed, aimed with laser-like focus on certain insider voices.

Or to put it even more succinctly:

An epistemic bubble is when you don’t hear people from the other side. An echo chamber is what happens when you don’t trust people from the other side.

This is a long essay, but I highly recommend reading the whole thing. It was a real eye-opener for me.

I read something recently that struck me as a really good idea for our team. Usually that feeling goes away after a couple of hours (“nah, it’s cool but not a good fit for us”) — but not this time. In Running in Circles, Ryan Singer talks about the knowns/unknowns in a project like a hill:

The most important question for a team isn’t “what is left?” but “what is unknown?” Can you see the edges? Have you gone in there and seen everything that needs to change? The only way to gain certainty is to roll up your sleeves and engage with the reality of problem.

At Basecamp our teams seek out the areas with the scariest unknowns and work on them first. This uphill work requires strategies. We wrote about these in Getting Real. Open the code, spike something that works, load it with real data and try it. When the whole feature is too big to prototype, factor out the most important pieces and spike them.

He has a a nice visualization of it:

He also uses an example from a recent project to show how they map this out:

As they “move over the hill”, different parts of the project become known, and they become more certain about what’s left to do. We’re working on some checklists to identify development risks before we start a project, and this looks like a great way to visualize those risks and track them as you go.

I should stop reading (and writing) about Facebook at some point, but there’s been some really interesting thinking around the social internet in general recently. I especially enjoyed Benedict Evans’s The death of the newsfeed, because it puts into words a lot of things I’ve been thinking about. On the social implications of algorithmic feeds:

One basic problem here is that if the feed is focused on ‘what do I want to see?’, then it cannot be focused on ‘what do my friends want (or need) me to see?’ Sometimes this is the same thing – my friend and I both want me to see that they’re throwing a party tonight. But if every feed is a sample, then a user has no way to know who will see their post. Indeed, conceptually one might suggest that they have no way to know if anyone will see this post.

This is one of the major flaws of algorithmic feeds. People share things so that those things can be seen. But if you can’t tell who will see the things you share, that’s frustrating, and more than a little nerve-wracking. Hence the move back to smaller networks:

I think one could suggest that this is some of what’s behind the suggestions of systemically lower engagement on Facebook newsfeeds, and behind the obvious growth of person-to person chat (most obviously WhatsApp, iMessage, FB Messenger and Instagram – three of which Facebook of course owns). The social dynamics of a 1:1 chat work much more strongly against overload, and even if one person does overshare they’re in a separate box, that you can mute if you like. […]

Messaging can be more private, have less social pressure, and be more fun. A Snapchat story isn’t a permanent record and has less pressure to show off your perfection. Stickers and filters are more fun and spontaneous than Facebook’s rigid blue boxes (and the days of throwing sheep at people are gone alone with Facebooks’ platform). And some of these offer light-weight ways to interact without obligation, which was also a feature of Facebook’s model, but deliver that piece of Maslow in different ways.

On that note, I think the distinction Cal Newport draws in On Social Media and Its Discontents is really important:

There’s a distinction between the social internet and social media.

The social internet describes the general ways in which the global communication network and open protocols known as “the internet” enable good things like connecting people, spreading information, and supporting expression and activism.

Social media, by contrast, describes the attempt to privatize these capabilities by large companies within the newly emerged algorithmic attention economy, a particularly virulent strain of the attention sector that leverages personal data and sophisticated algorithms to ruthlessly siphon users’ cognitive capital.


In the final analysis, I agree with Cal:

I support the social internet. I’m incredibly wary of social media.

This is a fairly old post, but I only recently came across Dan McKinley’s Choose Boring Technology. It is so good.

What counts as boring? That’s a little tricky. “Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.

The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.

He goes on to explain the process you should go through before you try out a new technology.