Matt LeMay’s post on how to build safety into team communication might not immediately seem that relevant to product management, but Why is Psychological Safety at Odds With the way we Work? is an excellent reminder for all of us:

Now let’s talk about the product managers who are willing to take on the individual risk that comes with creating psychological safety for their teams. These product leaders often don’t have the opportunity to step into those big “visionary” roles – not because they lack vision, but because they are so busy doing the emotional labor of cleaning up after the other product leaders who are making those big, lofty promises. These are the product leaders who earn the trust and respect of their teams by helping leadership understand the real-world trade-offs that go into actually delivering products, even when leadership doesn’t want to hear about it. And here’s the thing: over time, they actually train company leadership to be better! They sharpen their organization’s focus by saying, “You can have this OR you can have that. Which is more important given our goals and constraints?” These product leaders deliver so much value to the companies they work for, and the truth is, they don’t always get rewarded for it.

Over the years I have become more and more convinced that team safety is the most important job a product manager has.

In Getting to the Heart of Digital Accessibility Carie Fisher makes a compelling argument for making accessibility a priority in tech companies. Her conclusion really resonated with me:

Maybe I’m naive, but I’d like to think we’ve come to a point in our society where we want our work lives to have meaning. And that we don’t want to just hear about the positive change that is happening, but want to be part of the change. Digital accessibility is a place where this can happen! Not only does understanding and writing purpose-driven code help people with disabilities in the short-run, I believe strongly that is key to solving the overarching diversity issue in tech in the long-run. Developers who reach Stage 4: Understanding, and who prioritize accessible code because they understand it’s fundamentally about people, will also be the ones who help create and cultivate an inclusive environment where people from more diverse backgrounds are also prioritized and accepted in the tech world.

She mainly mentions developers in this article, but I’d argue that it is very much also the responsibility of product managers to make sure accessibility is always in the discussion on projects. We need to make sure that if extra time is needed for accessibility, we build that into the planning.

Further reading

For some practical advice on how to make emails more accessible, see Accessibility vs. Inclusion: What it Takes to Create More Inclusive Email Marketing Experiences and Email Accessibility: Looks aren’t everything.

For an example of how not to approach this topic, see Should websites be accessible to everyone? Domino’s says no.

Brad Frost argues that design tools are holding us back because “they require a specific toolchain in order to function”. Instead, what we need is closer collaboration:

Tooling can help, sure, but it’s not a silver bullet. To truly address the realities of the medium for which you’re designing, designers and developers should collaborate as equals to solve problems together. That means more talking and real-time collaboration and less time spent throwing static artifacts and Zeplin links at each other.

In The Slackification of the American Home Taylor Lorenz and Joe Pinsker look at how some households are starting to operate more like businesses:

Incorporating Trello, along with Gmail, into the Parker family’s life has been a godsend, in Tonya’s view. It streamlined family communication, helped keep everyone organized, and added a layer of accountability to tasks. Now, instead of wondering if her children forgot to do something, Parker says she can ask, “How are you doing on your checklist?”

This is a fascinating trend. I can understand the use of Trello, and maybe even Slack, but… JIRA? That seems like a lot:

Julie Berkun Fajgenbaum, a mom of three children ages 8 to 12, uses Google Calendar to manage her children’s time and Jira to keep track of home projects.

Ben Nadel proposes A Good Samaritan Law For Engineers At A Software As A Service (SaaS) Company:

How can we instill in our people the unwavering conviction that they have the freedom to create a better user experience?

One idea that popped into my head was to create a Good Samaritan Law For Engineers: an explicit promise by the company that no engineer will ever be fired for attempting to, in good faith, help a user or create a better user experience. And, I don’t mean as an implicit piece of the Tribal Knowledge; I mean as an explicit, codified part of the culture — an entry in the employee handbook — a poster, up on the wall, that any employee can look at and point to and use in their decision-making algorithm.

This should, of course, be true for everyone in an organization, not just engineers. But I like the point about codifying it — making it a principle that’s published, well-known, and ingrained in the company culture.

Katy Cowan’s interview with Frank Chimero is really great from start to finish, and covers so much ground on design and technology and how to think about our work. Frank’s view on the importance of not overworking yourself is refreshing, and we’ll hopefully continue to see more of this kind of thinking:

It’s really easy to think that not working full bore is somehow failing your teammates or that withholding effort is poor work ethic and moral weakness. That thought is worth interrogating, though, and it all seems kind of ridiculous once you get it out in the open. There should be no guilt for refusing to work hysterically.

There’s been a bunch of Evernote post-mortems, but I did enjoy the backstory and humor of A Unicorn Lost in the Valley, Evernote Blows Up the ‘Fail Fast’ Gospel. CEO Ian Small also makes a point about honesty and candor that’s really important for product managers to understand. He talks about how customers reacted when they finally came clean about the app’s quality issues:

Customers responded to his candor with a mix of optimism and skepticism, Mr. Small said. “The fact that we were able to tell the truth — that they already knew to be true — was a change of pace, not just for Evernote but for every tech-company relationship they probably have,” he said.

How we communicate when things go wrong lays your company’s soul bare. Hide behind “sorry for the inconvenience” and other fluffy language, and customers will lose trust. Be honest and show true empathy, and you’ll build stronger relationships.

I also really like this quote:

Now Mr. Small faces the challenge of recruiting engineers to fix Evernote’s “unique collection of bugs,” when they could be riding a bullet train to riches at a newer company. Hot start-ups can spend lavishly on engineering talent; they can always raise more if they’re growing quickly. Evernote has a different, more mature goal. It expects to reach positive cash flow this year, with annual revenue of nearly $100 million. “We used to be a movement,” Mr. Small said. “When we were a movement, we weren’t a business.”

Too many companies try to build “movements” instead of sustainable businesses that provide real value to customers.

👉 Also see Ahead of Its Time, Behind the Curve: Why Evernote Failed to Realize Its Potential.

I listen to The Product Experience podcast every week, so it was such a treat for me to be on the show this week to talk about Crazy Busy Product People. At first I didn’t know what to do — I’m so used to hearing Lily and Randy’s voices that it didn’t seem right to talk back, because that’s not how it usually works! But I did eventually find my feet (I think), and I’m overall pretty happy with how this turned out.

We spend most of our time discussing my article The dangerous rise of “crazy-busy” product managers, but we also touch on remote work and our 4-day work week experiment. I hope you can find some time to listen to the episode, and that you like it!

Jonas Downey argues that nobody really owns anything in a product made by a team. I agree with both his argument, and with how difficult it can be for product managers to make this shift. He gives some advice on how to get used to the idea:

The trick is to change how you evaluate forward progress: the long-term survival of your own contributions is irrelevant. The important thing is that the product is evolving into the best version your team can create together.

The more you appreciate the power of the group over the individual, the sooner you’ll become a more effective collaborator. You’ll be more willing to hear and absorb others’ viewpoints. You’ll be more eager to seek out everyone’s best ideas, instead of digging in and defending your own. And you’ll be able to celebrate other people’s achievements with authenticity instead of territorial resentment.

This is something I tried to articulate last year in a post called The humble product manager:

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.