In their article 5 Best Practices for Running a Successful Remote Team, “Sparky” writes:

All team members should have their working hours posted publicly, so colleagues know when they’re “on the clock,” so to speak. If you have a hybrid environment where some people are remote and others aren’t, this will help alleviate pressure on the remote employees to feel like they always have to be available. […]

It’s also a good idea to schedule daily syncs with remote people, as well as weekly feedback sessions where you can dive deeper into anything that needs a course correction.

I’m excited about this awful advice because I get to tell you one of my favorite Wildbit stories.

I joined Wildbit a week before our yearly in-person retreat. It was a little daunting but really exciting to meet everyone I would be working with mostly remotely. Anyway, one of our team sessions was a discussion about the tools we use, and specifically Slack. Up to that point we had this unwritten convention where everyone would say “Hi!” and “Bye!” in the #general room when they come and go. Remote workers went a bit further with messages like “Stepping away to make coffee!” During our discussion it became clear that no one — no one — liked this. It caused noise, didn’t add any value, and just felt like a chore.

At that point I spoke up and mentioned that I think the reason why remote folks tend to tell everyone when we’re getting coffee or lunch is that we don’t want it to look like we’re slacking off. I said something to the effect of, “I don’t want everyone to think I went to a movie in the middle of the day, or something!” The answer I got to that statement was not what I expected. Someone said, “Well, what’s wrong with that? Maybe you needed to go to a movie to clear your head so you can come back later, refreshed and ready to go!”. If I recall correctly, my response to this was, “Uh, this thing where you guys all trust each other? It’s really weird…”

We all had a good laugh together, but I learned pretty quickly that this is just how the company works. The two things that make Wildbit’s remote culture different are:

1. We all implicitly trust each other.
2. We optimize for asynchronous communication.

We do this because we learned something that should be painfully obvious. When people have the freedom to work when they are feeling their best, they do their best work, and they enjoy the work more.

So anyway, back to “Sparky”. I don’t want to tell people how to live their lives, but that advice really is terrible. It’s the type of advice you give when you believe the purpose of remote work is to replicate an office. Once you realize that the purpose of remote work is to enable everyone to do their best work, everything changes.

I guess my one piece of advice for remote cultures is this: try trusting each other first. Imagine what your work environment would look like if every employee is trustworthy. And if that’s too difficult to imagine, maybe ask why you’re not able to trust your employees.

Even though more and more companies are getting comfortable with remote work, the field of product management still seems to push back against this trend quite forcefully. There is a general sense that product managers can’t do the things they need to do unless they are physically located with their teams. This has some ironic consequences, such as that Slack — a company that builds a tool “where work happens” — doesn’t hire remote employees.

I confess that at first I was skeptical as well. But as we started to work together and make progress at Postmark, my skepticism fell away. I do believe it’s harder to make the product management role work remotely than some other roles like customer success or development. But it is possible, and I believe that companies need to start being more open to hiring remote product managers.

We often hear about the drawbacks of remote work, but it’s important to remember that there are certain things that remote work is naturally better suited for than on-premise work. Most importantly, remote work makes it much easier to develop and instill a rhythm of collaboration and focused time for a team. This rhythm will be different for every team, but I like to think of it as a wave. Here’s one example of what a cycle of private and public work could look like in a team:

Because it’s easier to shut down distractions as a remote worker, the deep work part of that cycle can be immensely efficient and dramatically increase both the speed and quality of work that gets done.

But of course, we can’t ignore the parts of remote work that are challenging and need to be figured out. So in this post I want to share a few lessons I’ve learned over the past 2 years that have helped me to overcome some of the more severe challenges to being an effective remote product manager.

In-person time is still important (but maybe not for the reason we think)

I joined Wildbit at the right time: one week before our yearly in-person company retreat. That gave me an opportunity to meet everyone in person, work together, and most importantly, have meals together. Once you’ve eaten a meal with someone, they’re not an anonymous “colleague” any more. Which means that when conflict arises (and of course it will), you’re way more likely to work through it kindly and respectfully. It’s very difficult to be mad at someone you’ve broken bread with.

The point is that in-person time is extremely important for remote teams. But you don’t need it every day, and the reason you need it is not to get more work done. The reason you need it is to sustain the human relationships that will enable you to get more work done.

When I spend time with our team in person, yes we spend quite a bit of time working together in meetings. But the biggest value for me is the lunches, the coffee chats, and the after-work catch-ups. That’s where we begin to see each other as whole people, and it’s at the core of our ability to work together and grow together.

This is certainly true for the whole team, but it’s especially true as a product manager, where your ability to do your job lives and dies with your ability to have good relationships with the team.

Love your tools (and be prepared to do a bit more of the heavy lifting)

One of our principles at Wildbit is that we optimize for asynchronous communication. We don’t hate meetings. We just value focused work extremely highly, so whenever we can we try to protect that work by giving each person the opportunity to work on something when it’s best for their schedule.

To make this work, you need tools. And those tools have to be light-weight and not a pain to use. Sure, we use Slack (although we’re trying to wean ourselves off it), but most of our collaboration work happens in Dropbox Paper and Basecamp. Those tools are designed for the type of collaboration and asynchronous communication that feels good. It can’t be overstated how important it is for remote teams to love their collaboration tools. If everyone hates the tools, the work will find a way to not get done. You’ll end up blaming “remote culture” and hire an onsite product manager, when the problem lies with crappy tools instead.

The catch is that these tools are just like comments on the internet: if you want them to be useful, you need to be prepared to spend quite a bit of time managing the process and the flow of information. As product manager a big part of my role has become making sure the right people know about things, and the wrong people don’t get distracted by things they don’t need to be involved in. This needs time and care, and doesn’t just happen automatically. The good news is this will still take way less time than “back-to-back meetings” every day…

Make prioritization and planning a team effort (and embrace the benefits of that)

Prioritization and planning of work is difficult under the most ideal circumstances. When you’re working on a remote team, the challenges are even bigger. This is where a combination of the right tools and some deliberate time management can make all the difference. The thing is, we know we do better work when all of our team’s perspectives are taken into consideration — not just in terms of the details of a project, but also what we should work on.

As product manager my role in the prioritization and project planning process is way more traffic controller than it is decider. We use our asynchronous tools to discuss ideas, post and gather feedback on initial drafts of plans, and occasionally even make radical changes to a plan as we learn more from customers and everyone on the team. My one goal is to keep the conversation going. It can be a little chaotic at the start, but I always feel like we end up in a better place than if we used a more traditional prioritization process.

---

Being a remote product manager is not without its challenges. It can be difficult to get the whole team aligned around a common vision, and you’re not always going to be able to get your questions answered right at the moment you want it. But if you can find a way to focus on and nurture the benefits that are unique to remote work, the challenges tend do get pushed to the background.

To put it another way, I understand why people think that product management isn’t a role that can be done remotely. There’s a lot of team communication involved, and of course that can be challenging over electronic channels. But with a slight shift in the lens you view product management through, those challenges fade away as the benefits of deliberate focused work and carefully considered collaboration come to fruition. I’ll say this: it’s totally worth it.

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.”

There is essentially two ways to improve at your job. You either get better at the things you should be doing, or you learn to stop doing the things you shouldn’t be doing. We tend to spend a lot of time and effort on the first aspect—and for good reason. It’s absolutely essential to keep learning. But lately I’ve been consumed with that second part. Day in and day out, at the most inconvenient times, the same question jumped into my head:

What are the biggest mistakes I’ve been making as a product manager, and how do I stop doing those things?

I took some strange detours trying to answer that question. And in the end, the answer I came up with specifically for product management had its origin in an unlikely place: some graduate work I did almost two decades ago. So let’s take a quick detour into information science theory before we return to the matter at hand…

---

One of the first things you learn about knowledge management is what’s called the DIKW pyramid. It provides a model for thinking about the transformation of raw data into something more useful.

• Data refers to facts and observations. They are the spreadsheets and SQL query outputs that come across our desks on an almost daily basis.
• Information is inferred from data, and distinguishes itself from data in that it is actually useful for decisions or action. Company dashboards with business metrics like MAUs are information.
• Knowledge refers to a framework for decision-making based on information, i.e. “we believe that when this happens, we should do something about it”.
• Wisdom is illusive—both in definition and in… well, attaining it. I’ve always liked the definition that says wisdom is knowledge with judgment. Wisdom goes beyond having a framework for what to do, and describes having the judgment required to make the right decisions based on the information and knowledge available.

The model isn’t perfect, but it serves a valuable purpose. There are two aspects in particular that I’ve always found useful to remember.

First, to extract value from data it needs to be transformed into something more valuable, and you don’t get to skip phases. If, for example, you try to go straight from data to knowledge without first organizing the data as information, your knowledge isn’t going to be all that accurate.

Second, confusing one slice of the pyramid for another can be really dangerous. If, for example, you’ve been able to extract some knowledge from information, but you think you’re looking at wisdom, you’re going to make some bad decisions, because you haven’t taken the time to add the necessary judgment to the information in front of you.

---

With that as background, let’s get back to product management. If I think about the times when I’ve made my biggest mistakes as a product manager, it can all be traced back to one of two causes:

• I misidentified data, information, knowledge, or wisdom. For example, if someone on the team who is steeped in our product and its users comes forward with a wise suggestion about where to take the product next, and I jump in with a process to take what I think is some information they provided and turn it into knowledge, I’m operating at the wrong level. Turning information into knowledge is essential, of course (remember, you can’t skip steps). But trying to pull wisdom back to an earlier phase in the transformation process is disruptive and demoralizing. We shouldn’t do that.
• I communicated the wrong slice of the DIKW pyramid to the person or team I was speaking to. For example, let’s say a designer and I go through an extensive usability testing process on a prototype of a new feature. We collect data, we group that data into information, and then we discuss it to extract the knowledge and wisdom we need to make the appropriate changes to the product. The difficult part is knowing what to communicate to who. For some on the team, the end product (the “wisdom”) is good enough. Others, particularly those with good data transformation skills, might prefer to see all the information so that they can give feedback on the knowledge and wisdom we landed on. We need to know the difference of what’s needed by who, and share appropriately.

Knowing the mistakes you tend to make is only half the battle, though. So all of this led me to a statement I’m printing out and putting up above my desk, to help me avoid making those mistakes:

An effective product manager shepherds data from a variety of sources through the transformation of becoming information and knowledge and wisdom. They do so without getting bogged down in unnecessary process, and they only share the relevant parts that each person or team needs to make progress.

I’m sharing this here with the hope that it will resonate with some of you who may have been grappling with the same questions.

There’s one more important point I want to make. From my personal life I know the dangers of wallowing in introspection for too long, so I don’t intend to stay down here in mistakes-land. Wrestling with these questions was a helpful exercise, but it’s not a place I want to get stuck in. So I’m going to head out to that other place for now. You know, the one where we get to learn new things and improve our skills. Maybe we’ll see each other on the road.