Effective product management for remote teams

A few months ago I wrote a post about how we build a product vision and roadmap for Postmark. It’s now almost 6 months later, and I just published a big post on the Postmark blog about how things are going. From roadmap to shipping: effective product management for remote teams is about how we moved from vision to execution, and how we dealt with the many challenges that remote teams bring to the equation. For example, on communication:

As a remote team we have to walk a fine line between working in private and working in public. We see this as a basic sine wave, where balance is extremely important. Work in private too much and you become silo’d and isolated. Work in public too much and it gets distracting for the rest of the team (and you never get time to focus). So we ran with the sine wave metaphor to create a diagram that outlines our ideal approach to private/public working and how we gather feedback.

You can view the post to see this diagram as well as a bunch of other topics:

  • How we made the transition from an exciting grand vision to the daily grind of working on projects and features to make that vision a reality.
  • What tools we decided to use on a day-to-day basis to keep everything running smoothly — and how our use of these tools evolved over time.
  • The challenges and opportunities of being a (mostly) remote team, and how we try to make sure we communicate enough without overdoing it.
  • Some remaining challenges we haven’t quite figured out yet.

Easy features can be very expensive

James Gill has a good overview of How bad features are born:

Most importantly, does this feature deserve to exist? Why are you working on it?

If you’re embarking on a new feature primarily because you’ve seen a competitor release something similar, then you probably haven’t thoroughly considered or even identified the problem you’re trying to solve. If you’re jumping into a new feature because it seems like “it wouldn’t be too hard to do” that’s great, but does it actually deserve to be built right now?

The biggest danger I see is this “it’s easy to implement” argument. A feature might be easy to implement, but that doesn’t make it “cheap”. The problem with implementing even easy features is that they’ll most likely remain in the product forever. That creates the potential for lots of (expensive) maintenance and support.

Also see How Much Does A New Feature Cost?

Effective remote teams over-share

Joe Tullio has some good tips for remote teams in Distributed UX teams: Early lessons learned. This part, in particular, is something I think many teams ignore because it can feel like busywork:

At Google, we have an internal “snippets” tool for posting regular updates on our work, typically at a weekly cadence. Snippets serve to share the latest mock versions, research reports, study plans, hiring updates, and anything else that feels noteworthy.

To be fair, snippets are a diligence task; I’ve been on teams where these updates were neglected for months at a time. However, my far-flung teammates have been instrumental in encouraging the rest of us to share updates, as they benefit greatly from seeing them. We’ve come up with several ways of reminding ourselves to do them, through calendar appointments, shared compilations, and as a last resort, the tried-and-true email nag.

I’ve written about a similar approach we follow in Useful daily standup meetings for remote teams, and I stand by it. The benefits far outweighs the “cost” of spending a few minutes thinking about your day and updating your team about what you’re working on.

Product managers are consensus managers

Des Traynor shines a light on the unglamorous side of the PM role in Q&A: What does a product manager do?

If you look at how actual product managers work in any company there’s a lot more nitty gritty work. There’s a lot of spreadsheets, wireframes. Google Docs, emails, and oh-so-many Slack channels. And they all exist to research, collaborate, dictate, and document consensus on a direction the product is going. But I think if the role was titled “Direction and Consensus Manager” you might not get as many applicants.

You have a machine voice

Tom Dart wrote a really interesting piece on how we change our accents when we talk to machines. From Y’all have a Texas accent? Siri (and the world) might be slowly killing it:

“Most people have what we would call a telephone voice, so they actually change away from their local family accent when they’re speaking on the telephone to somebody they don’t know,” said Alan Black, a Scottish computer scientist who is a professor at the Language Technologies Institute at Carnegie Mellon University in Pittsburgh.

They also have a “machine voice”, he said. “People speak to machines differently than how they speak to people. They move into a different register. If you’re standing next to somebody in an airport or at a bus stop or something, you can typically tell when they’re talking to a machine rather than talking to a person.”

This part on the design of Siri is really interesting:

Black speculated that “one of the reasons they designed Siri to be fundamentally a polite, helpful agent who isn’t your friend but works for you, is to encourage people to be somewhat polite and explicit to her, rather than being very colloquial. Because speech recognition is always hard when you drop into colloquialisms.”

Good design and positive change

Kashmir Hill writes about How Nextdoor reduced racist posts by 75%. Nextdoor tested a bunch of different approaches:

Some just saw the addition of new language: “Ask yourself: Is what I saw actually suspicious, especially if I take race or ethnicity out of the equation?” Some were asked to say in advance whether they were reporting an actual crime or just “suspicious activity.” Others actually had their posts scanned for mentions of race (based on a list of hundreds of terms Nextdoor came up with) and if a post did mention race, the user got an error message and was asked to submit more information about the person.

This is proof that good design can make a positive difference in the world.

Defining the role of Product Designer

Chris Jones posted a really solid overview of The Product Designer Role that’s very much worth your time:

Your next task is to define the product design role within your company. This is an important one to get right. You don’t want to simply recreate an internal version of the agency model. The way that products are created has changed dramatically in recent years and new models for design are a critical part of this.

He goes over what he believes are the 5 core responsibilities of the role:

  1. Product Orientation
  2. Holistic Experience Design
  3. Prototyping
  4. User Testing
  5. Interaction and Visual Design

I can’t help but feel like this is a role we’ll start to see merge with Product Management before long.

The changing role of the record label

There are a couple of interesting articles about Frank Ocean’s new album and how it’s causing a lot of waves in the music industry. The short version is that Ocean found a clever way to get out of his agreement with his label Def Jam, and sign an exclusive deal with Apple Music instead. As Ben Sisario notes in Frank Ocean’s ‘Blonde’ Amplifies Discord in the Music Business, the labels aren’t happy:

“The unprecedented run of exclusives by digital music services has put a tremendous strain on the relationship between artists and their record companies,” said Larry Miller, an associate professor of music business at New York University’s Steinhardt School. “We are seeing that play out in public now.”

In Def Jam Can’t Compete With Apple Justin Charity explains further how Apple has become a giant player in the music industry:

Today, with Iovine’s connections and industry guile, Apple Music is becoming a de facto record label of its own. In just over a year, Apple has struck deals with Drake, Future, Chance the Rapper, and Travis Scott. […]

In response, Universal Music Group, which owns Def Jam, is quickly mobilizing against Apple Music’s exclusive streaming-rights model, which naturally limits the audience for new music. Without this model, Apple Music would be back to a prolonged competition to differentiate itself from its streaming competitors. With it, there’s a new, unprecedented competition: conventional record labels, which ideally develop artists into stars, versus Apple Music, which pays stars well.

I’m going to be in the minority here, but I don’t like Apple getting into the record label business. The entire idea of “exclusive” music releases rubs me the wrong way. And I’m just going to say it — this is the kind of stuff that happens when we get rid of physical media.

The social media lives of teens

Mary Choi’s Wired feature on the social media lives of teens is utterly fascinating. I don’t even know where to begin. Let’s start with this bit from Like. Flirt. Ghost: A Journey Into the Social Media Lives of Teens:

Then there is the rule about likes and comments. According to Lara and Sofia, when your friend posts a selfie on Instagram, there’s a tacit social obligation to like it, and depending on how close you are, you may need to comment. The safest option, especially on a friend’s selfie, is the emoji with the heart eyes. Or a simple “so cute” or “so pretty.” It’s too much work to do anything else. If there’s any deviation, “you have to interpret the comment,” Sofia says. “If it’s nice, you’re like, is this really nice or are you …” “… I don’t know,” finishes Lara. Is the comment sincere? Or slyly sarcastic? Formulaic responses breed zero confusion. Instagram is not a place for tone or irony.

The whole article is full of examples like this that just makes me wonder how complicated it must be to be a teen right now. Of course, it’s not complicated to them, it just seems that way to us old folk. But seriously:

But back to the ladies. After a few mutual photo likes, the flirtation often escalates to emoji. If an emoji with the heart eyes gets another one in return, he says, you’re good. Other positive responses: an ellipsis thought-bubble to convey that she’s thinking about you; the bashful see-no-evil monkey. “‘Oh, thank you! I appreciate it’ is what I get from that emoji,” he says. Any of these responses means he’ll take it to DM (as in direct message). Other emoji are suboptimal. “The thinky face is like, ‘What are you doing commenting on my pictures?’” He says this isn’t a hard no, but it’s not great. The worst emoji—easily—is one you may not expect. “The smiley face,” says Ahmad with a pained expression. “Yeah, that’s the ‘Thank you, but I’m not interested.’”

I did do quite a double-take when I read this though:

Ubakum loves her [Android] phone. Deeply. iPhones for her are too easy, a little basic. “I’m not a fan of user-friendliness.”

I don’t really know what to make of that. It’s a fascinating statement, and I wish I could follow up to understand the sentiment more. If it’s true that a new generation of users don’t want products to be easy to use, what does that mean for us as designers? My head hurts.

Moving beyond Agile

Andy Budd asks, Are we moving towards a post-Agile age?

Perhaps we’re moving towards a post-Agile world? A world that is informed by the spirit of Agile, but has much more flexibility and nuance built in.

This post-Agile world draws upon the best elements of Agile, while ditching the dogma. It also draws upon the best elements of Design Thinking and even — God forbid — the dreaded Waterfall process.

People working in a post-Agile way don’t care which canon an idea comes from, as long as it works. The post-Agile practitioner cherrypicks from the best tools available, rather than sticking with a rigid framework. Post-Agile is less of a philosophy and more of a toolkit that has been built up over years of practice.

This is certainly true for how our team works as well. We took the parts we like about Agile (like autonomous teams, flexible roadmaps, daily standups, small pieces of work), left out the parts we don’t like (like rigid sprints, long backlog grooming meetings), and then mixed in some spicy goodness from other methodologies (like deploying whenever a feature is ready). I’m sure strict Agile works for some teams — particularly in large organizations — but this approach works much better for us. It speeds us up and makes us all much happier human beings.


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