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.

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.

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.

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.

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.

This NYT report on the massive political news force Facebook has become is quite something. From John Herrman’s article Inside Facebook’s (Totally Insane, Unintentionally Gigantic, Hyperpartisan) Political-Media Machine:

But truly Facebook-native political pages have begun to create and refine a new approach to political news: cherry-picking and reconstituting the most effective tactics and tropes from activism, advocacy and journalism into a potent new mixture. This strange new class of media organization slots seamlessly into the news feed and is especially notable in what it asks, or doesn’t ask, of its readers. The point is not to get them to click on more stories or to engage further with a brand. The point is to get them to share the post that’s right in front of them. Everything else is secondary.

This is the crux of the matter:

Such news exists primarily within users’ feeds, its authorship obscured, its provenance unclear, its veracity questionable. It exists so far outside the normal channels of news production and distribution that its claims will go unchallenged.

Diana Budds does some great reporting in How Urban Design Perpetuates Racial Inequality — And What We Can Do About It. It’s startling to see how deeply ingrained racism is in the way cities are designed. One of the most effective ways to change this? Diversity and immersion in the needs of users…

Justin Moore, an architecture professor at Columbia University, believes that while designers focus on creative solutions for urban problems, issues that are rarely broached are shortfalls within the profession, like diversity, a deep understanding of the communities in which they’re building, and the methodology of design education.

”There is a need to redesign the designers, and to give them the tools and competencies to work within social constructs and spatial contexts that they are meant to serve. Designers spend much of their academic and professional training to build the spatial, technical, communication, and critical-thinking skills that are needed to do the difficult work of transforming spaces and places. They use their skills, often with good intentions and ‘best practices,’ toward results that may not align with what is needed or wanted in a given context.

I enjoyed answering some questions about prototyping and Product Management in startups from the nice folks at Justinmind recently. Among other things I got an opportunity to share my thoughts about a particular phrase we hear a lot about Product Managers, one that I think is quite dangerous for our profession…

What kind of challenges and opportunities face Product Managers in a software development context?

I think the Product Management role is still incredibly misunderstood (and misused). I’ve never liked the “We’re like mini-CEOs of the Product” thing you often hear. Any metaphor you come up with that implies a hierarchy (such as air traffic controller, shepherd) gives Product Managers an incorrect view of themselves as The Boss™, and serves only to alienate teams.

We might be the final decider on some issues, but it’s not because we’re “above” the team. It’s because our jobs are to know about user needs, business goals, technical needs, and how all of it comes together in a successful product. Our jobs are to listen to our teams in their various roles and make sure that everyone knows what they need to know. And then our jobs are to walk with the team in a direction that everyone understands and agrees on. It’s not “here are your requirements, see you on the other side of design!” We still see way too much of that in the industry.

Until we change that perception, which will require a change in attitude from us as product managers, we’ll continue to be viewed as obstructionists in many companies. Maybe the best metaphor to use is that we’re servants. Servants to our customers, our teams, and the product. That’s the opportunity we have to bring value.

You can read the full interview here.