Product managers: don’t play favorites with methods and techniques

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.

Tips for better estimates

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.

“One Laptop Per Child”: a great solution to the wrong problem

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.

Echo chambers and epistemic bubbles, and how to break through

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.

Tracking development uncertainty with hill charts

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.

Social internet, social media, and the move to smaller networks

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.

Why you should (usually) choose boring technology

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.

The humble product manager

When the design community wants to argue about something they fall back on the age-old question, “Should designers learn to code?” In the same way, for as long as the role has existed, the product management community has debated whether or not PMs should be referred to as “the CEO of the product.”

Neither debate will ever be settled — this is just something we do. But Marty Cagan does have a solid addition to this never-ending argument in his post CEO of the Product Revisited. His main point is this:

Now, the strong product manager does not need to be an expert in all of these many aspects of the business, any more than the CEO needs to be.

The key is that, like the CEO, the product manager needs to have a solid understanding of the many aspects of the business, and assimilate all of this information to make informed decisions.

But it is his focus on humility that I want to spend a moment of reflection on:

So going forward I’m going to continue to emphasize the importance of humility and earning the team’s trust, but I will also start emphasizing and embracing the positive aspects of the similarities of the PM role to the CEO.

A call for humility in product management is not something I see very often. This is strange to me, because I find this to be an extraordinarily humbling profession. There is so much to learn and do that I am not sure how anyone can think of themselves as an “expert” in the product role.

At one extreme, PMs need to be confident about the decisions they make. They need to keep learning and growing, and hone their craft constantly. Solid theory and excellent technique need to become so ingrained that they simply become second nature, cornerstones of everything they do.

But equally important — and this is why humility is so important — they need to be open to the possibility that some of their decisions might be wrong. They should hang on to a measure of self-doubt every time they present a new solution to the team or the world. Admitting that someone else’s ideas are better than your own, and making changes based on good critique do wonders to improve products — and build trust within the team.

In the design context John Lilly phrases this in a way that should become a mantra for all product managers: “Design like you’re right; listen like you’re wrong.”

More evidence of the ways technology can be bad for our health

Stories about how technology can be bad for our health is not new, of course. But two articles in this particular genre caught my attention this week. The first is some HBR research showing that Having Your Smartphone Nearby Takes a Toll on Your Thinking (Even When It’s Silent and Facedown):

The mere presence of our smartphones is like the sound of our names or a crying baby — something that automatically exerts a gravitational pull on our attention. Resisting that pull takes a cognitive toll.

A bit more about that “gravitational pull”:

Research in cognitive psychology shows that humans learn to automatically pay attention to things that are habitually relevant to them, even when they are focused on a different task. For example, even if we are actively engaged in a conversation, we will turn our heads when someone says our name across the room. Similarly, parents automatically attend to the sight or sound of a baby’s cry.


In another article, Virginia Heffernan explores the question What Are Screens Doing to Our Eyes—And Our Ability to See?:

Having recently, in my forties, gotten reading glasses, I now find myself having to choose between reading and being, since I can’t read without them and I can’t see the world with them. The glasses date from a time when reading was much rarer a pastime than being; you’d grope for them to see a book, while relying on your naked eyes for driving, talking, walking.

There is no “solution” to this, but as someone who also has reading glasses, I do like her approach to make this weird feeling a little better:

When I pull away from the screen to stare into the middle distance for a spell, I take off my glasses. I try to find a tree. If I’m inside, I open a window; if I’m outside, I will even approach a tree. I don’t want mediation or glass. The trees are still strangers; I hardly know their names yet, but I’m testing myself on leaf shapes and shades of green. All I know so far is that trees are very unlike screens. They’re a prodigious interface. Very buggy. When my eyes settle after a minute or two, I—what’s that expression, “the scales fell from my eyes”? It’s almost, at times, like that.

Easier blog post image management with Dropshare and Amazon S3

I’m always on the lookout for faster ways to upload and insert images into blog posts. It’s the part of the blogging workflow that I dislike the most. Up to now I’ve used a pretty convoluted combination of Amazon S3 buckets and Transmit. But over the weekend, while moving hosting providers1, I finally came up with a really simple image upload workflow that I thought I’d share in case it helps anyone else.

This workflow lets you drag and drop an image to a menu bar icon on your Mac, and then immediately paste a secure, custom domain URL for that image wherever you need it.


Step 1 – Create S3 bucket

Create an Amazon S3 bucket for your image uploads. It doesn’t matter what you name the bucket, but do not add a . to the name. This creates some weird SSL certificate errors later in the process that you don’t want to deal with.

Also make sure you set the bucket to be publicly accessible via the Permissions tab, otherwise you’ll get read errors for your files.

Step 2 – Create CloudFront distribution

Create an Amazon CloudFront distribution for the S3 bucket you just created, so that you can use a custom URL for your images, and make use of Amazon’s Content Delivery Network (CDN) capabilities.

When you go through the flow of adding a distribution for your S3 bucket, leave the “Distribution Settings” section blank at first — we’ll come back to that.

CloudFront settings

Step 3 – Add custom domain for your images

Back on the main Distributions screen, note the CloudFront domain name that was created for your bucket. It’s going to be in the format ***************.cloudfront.net. Go to your DNS provider and add a CNAME for the custom domain you want to use for your images.

In my case, cdn.elezea.com points to my CloudFront distribution at d26fqxuc6*****.cloudfront.net, which in turn links to the S3 bucket I set up earlier.

Step 4 – Add SSL certificate to CloudFront distribution

Now go back to your Distribution Settings in CloudFront. Add your CNAME information, and then click the button to “Request or Import a Certificate with ACM”.

This will take you through the process of generating a free SSL cert to be used with your CloudFront distribution. This is essential if you serve your site over https. If you don’t do this, your images will be served over http and you will get “mixed content” warnings when you embed images in your site.

Change your settings to “Custom SSL Certificate”, and you’re good to go.

CloudFront settings

Interlude – take a breath

If you’ve successfully completed these steps, here’s where you’ll be. Whenever you upload an image to your S3 bucket, you will be able to serve that image via your custom URL over https, and as an added bonus, you’ll be using Amazon’s CDN for super fast delivery.

Now we need to figure out the fastest way to get images into that bucket of yours.


Step 5 – Download and set up Dropshare

There are many sophisticated ways to manage your S3 buckets. But when it comes to uploading an image and getting a URL for it, I haven’t found anything that’s simpler than Dropshare.

In short, Dropshare allows you to establish connections to all your S3 buckets. It lets you upload files by dragging them to the Dropshare menu bar icon, and then the URL for that image is automatically copied to your clipboard. So to add an image to this blog post, for example, I just drag the image to the menu bar icon, then come back to where I’m writing and ⌘-V to insert the link. It couldn’t be easier.

I have a bunch of S3 buckets linked up in Dropshare:

Dropshare

In the case of the bucket I use for this site, note that I entered the bucket name, the domain alias (the CNAME you added earlier), and that I have the “Use SSL” box checked:

Drophsare

This makes the workflow for adding images an absolute breeze. Drag and paste. That’s it.

When you upload an image, Dropshare lets you choose the bucket you want to upload to, as well as if you want to add a landing page and/or use a URL shortener (which I usually don’t, but it’s nice to have the option).

Drophsare

Dropshare is useful for other things too. I have a keyboard shortcut that takes a screen shot, automatically uploads it to an S3 bucket, and copies the URL to the clipboard. That’s great for sharing screen shots in Slack, for example.


I’m not sure how many people have this need to shave a few minutes off their image workflow. But I hope this post is useful for the few of you who do obsess about things like this, like I do. And please let me know if you think this flow can be improved even more!


  1. I’m now with DreamHost and much happier. 

More

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. ...
  7. 117