From roadmap to shipping: effective product management for remote teams

Back in May I wrote about How we built a product vision and roadmap for Postmark. Now that we’re 6 months down the line I wanted to let you know how it’s going. I often read posts like the one I wrote in May, and then I wonder if the teams were actually able to accomplish the goals they set for themselves. We tend to hear less about the parts that didn’t work out — the wrong assumptions and hard lessons learned. Those things are less fun to reflect on, but can be hugely beneficial as we learn from each other as a product community.

So that’s the reason for this post. I’m going to cover a few topics related to those initial vision and strategy meetings we had:

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

From Big Picture to All The Details #

As I mentioned in my post from May, we came back from our team retreat with a vision for the product, and a good first stab at a roadmap to get that vision going. It was time to start working.

Roadmaps have a tendency to fall apart as soon as you start working on them.

It’s important to expect this to happen, and be ready for it — not ready to dig in your heels, but ready to adjust as you go and new information becomes available. That’s the biggest mistake we can make with roadmaps — believing that they’re set in stone (I’ve written about this before in Product roadmaps are safe).

To help us get comfortable with the uncertainty and relieve the unnecessary pressure that roadmaps can be famous for, we follow a very simple approach. We start working on the things at the top of our priority list, and we don’t assign any dates until we are well into development and have the information we need to scope the work accurately. This is a difficult thing to do in most companies, but luckily this idea of focusing on product over timelines is built right into our culture. One of our guiding principles at Wildbit is that we choose quality over speed. “We take our time to do things right with care, research, and expertise.”

We also built a bit of process around feedback loops. 

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.

The image below is a snapshot of our process. You can see a full version here.

This has become the two guiding principles of our product development cycle:

1. Work on what’s most important until it’s done, then move on to the next important thing
2. Strive for a good balance between private work (what we call “deep work”) and public work (getting feedback).

With those two principles in place we started to make good progress, but two issues in particular came up that we had to address.

What happens when there are delays? #

This happens in every software project. Even after we have enough information to put out a solid estimate of the amount of work required to complete a project, delays inevitably happen. We discover something that we should refactor — or a bug in another part of the system that could really help us and our customers in the long run. What then? Do we ignore those things and hit our self-imposed deadline, or stop and do the right thing?

Of course, the answer for us is right there in the choice before us. It really isn’t a choice. We always try to do the right thing, even if it pushed a feature out by a few weeks. We do this not just because it reduces our technical debt and will result in a better feature, but also because this is what keeps our developers invested and motivated. If we’re just chasing deadlines there’s not much to get excited about. But if we have a team who have ownership over the product and how it evolves, that’s a powerful thing.

This doesn’t mean we just keep working and working into the endless abyss. We often discuss when we need to finish up one phase of a project and release it before we move on to the next.

Even though we generally steer clear of calling a first release an MVP because of how the term tends to be abused, we try to release features in manageable chunks to reduce risk and get feedback from customers as early as possible. 

So when delays come up, we deal with them. We discuss the reasons, we make a decision as a team, and then we communicate that decision to the rest of the team and make the necessary adjustments. As a product manager that’s not always easy for me, but I know it’s right.

What about bug fixes? #

This is another ongoing issue in most software companies. Bugs are often submitted by customer support teams in droves, and then promptly forgotten about in a graveyard of a “bug backlog”. This is something we wanted to avoid — we have a goal of having around 10% of our roadmap devoted to bug fixes at all times. But making this a reality proved harder than we expected.

The first thing we tried was monthly “bug fix days”, where everyone takes time off from their feature work to spend on bug fixes. This didn’t work at all, for a variety of reasons that should have been clear to me from the start. The first problem is that, of course, many bugs take longer than a day. So it’s hard to choose one and say, “I’m going to do this thing today.” The other important factor here is that taking a day off from something you’re intensely focused on can really break your flow, which is frustrating. So this just didn’t work for us.

The second thing we tried worked much better. We have a weekly team meeting (I’ll get into the detail of this meeting later on), so we started to add a standing agenda item where I go over our most pressing bugs, and then we discuss who might have time to review or work on those bugs during any given week. This helps us to keep focus on the issues that are affecting our customers the most, and make weekly adjustments as we go. This approach has been working much better, so we’re sticking with it for now.

How we prioritize bugs is a little bit art and science combined. I have a monthly meeting with our customer success team to go through our current list of open bugs to see what they’re hearing and if any customer issues are coming up more than others.

I also regularly go through the list to group similar issues together. Once we have 3–4 issues that are related to each other, that’s usually a good indication that the bug affects a variety of customers in different scenarios, and we should increase its priority. To make this whole process more orderly, there is “Prioritized Bugs” page on our wiki that I updated weekly with the most important issues so that developers don’t have to dig to figure out which bugs are most important.

Once we had an operation that moved along reasonably smoothly philosophically, we had to also address that dreaded issue that no one really wants to talk about: TOOLS. We’re a remote team, we need tools. But which ones are best for us? Let’s dive in…

The tools we use day-to-day to get our work done #

In this section I want to focus on two main topics: (1) how we track our overall progress towards our goals, and (2) how we track the minutia of each feature and project.    

Overall goal progress #

Oh, meetings. So much has been written about meetings, how toxic they can be, how important they can be, how difficult they are to get right. We struggle with the same issues. We used to have a weekly round-table meeting to discuss progress, but we’ve since replaced that part with a daily standup Slack bot called Geekbot (I go into more detail on this decision in Useful daily standup meetings for remote teams). We still have a weekly team meeting, but our focus is now different. We decided to go with an OKR (Objectives and Key Results) approach for the team, and in particular we adopted the matrix approach from Christina Wodtke’s book Radical Focus.

I’m not going to go into the details of the OKR methodology here (that’s what Christina’s book and web site are for!), but I’ll say that this matrix has made our weekly meeting a really efficient way for the whole team to find out how we’re doing and what we’re going to be focused on for the next week. It also keeps us all in sync in terms of our overall goals as a team — the marketing team, for example, has their own goals, but they are in alignment with the overall product goals.

The right side of the matrix tells us how we’re doing — they include our business metrics and measurements for our objectives for the quarter. Every week we discuss how confident we are in our ability to hit our goals for the quarter. The left side of the matrix helps us with planning. It helps the entire team to be informed about what our focus is going to be for the week, and what releases we have coming up in the next 4 weeks. This is information I gather during the week anyway in my regular and ongoing discussions with the team, so it’s not much effort to add that before our meeting every week.

We’re still figuring out what the right objectives and key results are for our team, but the process itself has proven invaluable. It cuts down on unnecessary meetings dramatically while improving everyone’s knowledge about what’s happening across the team.

And even though it’s sometimes difficult to get everyone riled up early on a Monday morning, it’s definitely a good idea to start the week by looking each other in the eye — especially since so many of us are remote. I highly recommend this method and meeting!

Task tracking #

Ok, I’ve put it off long enough. I’m going to say it. 

👏  We 👏  use 👏  Jira 👏

I know. What is wrong with us? Have we even heard of Trello? I hear you, concerned friend, I hear you. But give me a moment to explain, ok?

We did use Trello for a while. The problem with Trello, for us, was that it didn’t allow for the flexibility we wanted to make it work for everyone in the company. Our ideal solution is a system where we can track and prioritize feature requests that come from customers, all the way through the planning and implementation, to informing customers once the feature launches. We just couldn’t get Trello to make that work for us.

So, I know Jira is a seemingly untamable beast. And even though I won’t pretend like we have it all figured out, we have managed to set Jira up in a way that helps us more than it hurts us. For all its UI quirks, Jira has a couple of really powerful things going for it:

• The close integration between Confluence (the built-in wiki) and Jira (not to mention a neat new integration between Jira and InVision) means that we can use Confluence as a way to document meeting notes (including our weekly Dashboard) and have real-time information about Jira tickets available right in the document.
• Those outside the technical teams don’t have to go into the guts of Jira to see what’s happening. We have a couple of roadmap boards set up that shows them everything they need to know about projects at a high level. This is something I really like about Jira. Those of us in the weeds can make fine adjustments to keep track of our tasks, and that will automatically update on the more human-readable (i.e., Trello-like…) dashboards we have set up.
• I love that we can track customer requests and reach back out to those customers whenever something goes live. A customer success team member will see when a status changes to “Released”, and they can then go straight to each customer interaction in Help Scout and respond. It’s not just another “touch point”, it’s also an opportunity to give customers some happy news. And that’s always good for the soul.

As an example of how this works for us, here is a snapshot of the Confluence document we review as a team in our weekly meeting. You’ll forgive me for blurring out our Objectives and Health Checks…

On the roadmap side of things, we have a Kanban board set up with quick filters that let anyone see either the big picture or what their priorities are at any given time:

We could go into a lot more detail, but I think I’ll leave the Jira talk here for now so we don’t get so far into the sewers of task tracking that we can never find our way out again (also see Garrett’s post Process shouldn't be a dirty word). I'll add that for this to work well, it really helps to have a single person (preferably the product manager) who keeps the whole Jira setup up to date and running smoothly. And with that, I'll confirm that this setup works really well for us both as tracking and a company-wide communication tool. It can be done!

Day-to-day process #

Even with all this planning and documentation, getting work done can be challenging. As much as we try to remove distractions and be clear on priorities, this is real life, and real life is messy. I’d say there are two important issues we try to focus on to make our day-to-day work manageable without going crazy.

The challenges of remote teams #

Working remotely is awesome, and I love it. But as anyone who has spent any amount of time working in their basement will tell you, it can get lonely and isolating, and frustrating if communication starts to break down. Like most companies we use Slack pretty effectively to keep our necessary discussions going during the day. We also have a culture where it’s ok to turn on DND (Do Not Disturb) for a while to go heads down on something.

But beyond Slack, we’re out there in the wilderness with most of you, trying to find the perfect apps for (1) company communication and (2) video conferencing. That holy grail doesn’t exist, but we do have a reasonably good setup with Paper (Dropbox) and Honey as our main communication tools (we also use email — uncool but effective). For video conferencing, we recently switched to Zoom and it’s by far the best one we’ve used so far (and we’ve tried them all). 

One thing I encourage our team to do more is be ok with quickly switching from an email/Slack conversation to a 5-minute voice chat to talk through things.

One of the most important features of a good videoconferencing app is that the startup time has to be as close to zero as possible. There needs to be no barrier to switch from chat to voice, and Zoom does a pretty good job at that.

Finding the right meeting cadence  #

This brings me to my next point… In addition to the ad-hoc catchups, how many formal meetings should we have? We’ve experimented with this quite a bit, and currently we like this cadence:

• Weekly product meeting with the founders. I have a weekly catchup with the founders on Friday mornings. We discuss the week’s progress, any issues that need their attention, and current priorities. This is our chance to change the roadmap if needed — did anything happen in the week that means we need to change the order of our priorities? Do we need to add anything to the roadmap? I like this approach a lot because it reinforces the idea that a roadmap is not static. It can (and should) change as often as needed.
• Weekly team meeting and dev sync. On Monday mornings we have a meeting with the entire team to go over the Product Matrix (OKRs etc.). This is followed by a short meeting with all the developers to go over any pressing issues we need to discuss as a team. It’s very important to note that this is not a roundtable status update meeting — that’s what Geekbot is for. This time is used to solve problems on specific projects, as needed, and to discuss the bug priorities for the week. These two meetings generally finish within 45 minutes, which makes it a very efficient use of everyone’s time.

And that’s it. Those are the only regular meetings we have. Yes, there are ad hoc chats, and things like project kick-off meetings in between, but for the most part, we use these two meetings along with Jira and Geekbot to keep everyone informed in a low touch but high information density kind of way.

Remaining challenges #

I alluded to this before, but by no means have we figured all of this out. We’ve made some great progress, but there are definitely still some remaining challenges with running an efficient product development lifecycle as a remote team. Here are the top three things I’d like to focus on for the rest of the year, when it comes to process.

Make decisions faster #

Even though we are a small, dedicated team with autonomy over the product, decisions can sometimes get stuck when we’re not entirely sure if it’s ok to go ahead or if someone else needs to provide input as well. This isn’t an authority issue, it’s that we really do want to make the right decisions, so we want to make sure we get all the necessary input before we go down a wrong path that could have been avoided.

I think here we need to get a little more comfortable with making decisions based on the information we have, and make sure that we take small enough steps so that we can turn around if something does appear to be a mistake. 

Find the right communication balance #

There is a delicate balance between over-communicating (being annoying) and under-communicating (no one knows what’s going on). This is such a fluid thing, and I don’t think any of us will every truly figure it out. The best thing we can do is to feel it out and adjust as needed. I ask the team at least once a quarter about this — how can we communicate better? The key for me is going to be to get more comfortable with the ebbs and flows of communication — some weeks need to be heavier than others, and that’s just the way it goes. 

Find the right tools #

Will we ever find a document repository that everyone likes? Not likely. But I will hold out hope that someday we’ll find something that everyone can at least tolerate. Right now we’re taking Notion for a test-drive and early feedback has been good. But we’ll see…

Summary #

This post is not a comprehensive overview of our product process, but it’s a good reflection of the issues that are top of mind for me at the moment as we find a rhythm that works for us to go from planning to execution, back to planning, and so forth. I feel like a lot has been written about upfront planning in product management, but the day-to-day stuff often gets neglected. There’s so much detail in there that’s worth talking about.

I’d love to hear your thoughts on this topic. Hit me up on Twitter, or even better, write a post in response like it’s 1999 so we can keep this discussion going.