How to navigate a product ship through a battle

Roman Mazur
Appear Here Product Engineering
7 min readMar 26, 2019

Communication in any organisation is both crucial and hard. At Appear Here, we have tried several approaches to improve our communication between teams and in this article I will share the ones that worked. I am going to use an analogy of a fleet of warships going through a battle to make it clearer.

In startup life a ship called Product faces many storms and battles. As the captain you need to make sure it is always moving in the right direction and never, ever sinks.

There are other allied ships around you (Marketing, Sales, Finance, …) which depend on you and you on them. You need to make sure you help them as much as you can, while still being able to drive forward without sinking the ship.

There is one more team around, the Executive team, watching from the coast. They see the bigger picture and produce a long term strategy direction for you. What they can’t see is the small everyday tasks. The communication from them is always delayed a little as it takes time for the messenger ship to reach your crew. Information gets lost along the way and sometimes the messenger ship can be delayed.

This gives you, as the Product captain, 3 main challenges to focus on:

  1. Product ↔ Product. The Product ship crew stays motivated to move towards their goals despite a constant flood of bugs and ideas for improvements.
  2. Product ↔ Company. The whole fleet trusts your Product ship and knows it delivers value for them.
  3. Product ↔ Executive team. Your ship goes in the right direction and meets the strategy goals provided by the Executive team.

Let’s see how you can improve each.

1. Motivation and speed. A Product crew excited to constantly sail forward.

Focus is one of the most important factors enabling your team to move fast. No sailor wants to spend all their time aboard being distracted by small bug fixes or helping other ships with their requests. They want to put their headphones on and concentrate, get in the flow. But that’s exactly how startups fall apart.

Startup environments are chaotic. Change is a constant and you need to make sure your team is able to deliver under such conditions as for makers, distraction is a disaster. You need to balance your team’s focus on long term strategy projects, with the constant flood of bugs and small requests from other departments.

Distraction in a startup is inevitable. To avoid this getting in the way of your team’s work, you need to eliminate it as much as you can. Here is how we do it at Appear Here.

The Dreaded Bugs

If you move fast you will most probably be under constant fire of bugs. What I found helpful is to have a set of clear rules that define which bugs are a distraction and which are not.

Here is our rule. If a bug blocks the business from operating normally (i.e. the site is down), the bug is expedited. This means all the ongoing work has to stop immediately until a fix is deployed. A hole in your code is a hole in your ship and as with any problem, some bugs are bigger and more urgent than others. Thus, every other bug goes waiting into our backlog and its importance will be evaluated during our weekly bug pruning session. Sometimes we reject it, other times we plan it for later.

This way, only the most severe bugs go into our engineers immediate work flow. The majority of them are shielded from day to day. They don’t become a distraction and get planned together with the rest of the work at a later date.

Rotation Programme

By doing the above you have eliminated a lot of chaos already. When it comes to distractions there tends to be one more problem remaining and it usually bothers only one of your engineers.

With the expedite bugs you need someone who is going to fix them. You also need someone to ask questions while evaluating a new bug or a product request. Is it a quick fix or will it take long? Can we avoid fixing that bug until next week?

Answering a quick question or fixing an expedite bug are both distractions. Even worse, both gravitate towards a single engineer. It might be someone you get along with well and you like to talk to. Most often it is also one of your best engineers.

Rotation programme can help with these.

With a rotation programme, you rotate your go to person within your team regularly, weekly in our case. This way, for the engineer on rotation, it is predictable when they are going to get distracted. The weeks charge on and they won’t get bothered for the next few.

Rotation is also good for knowledge sharing and avoiding the bus factor problem.

2. Trust. Other ships trust you.

Ok captain, so your crew is fine and able to move and deliver within a chaotic environment. The next thing to focus on are other ships around you. They need to know you are there for them and you are not going to abandon them.

You as a product manager are on the frontline, communicating with the rest of the company. You are faced with a never ending stream of various requests from every department and individuals. If you want to be able to focus and deliver, you will need to reject most of what people ask for. How do you keep their trust under such conditions?

By far the most important thing to build trust is to listen to people, log their request and always follow up. Don’t let them wait. Even if it means you are not going to do what they need, you need to tell them. It might be tempting to ignore the requests sometimes, especially during a crazy day. Don’t do that. Here is a good read on how best to reject other people’s requests.

You might also want to build an internal log that shows all the requests that everyone within your company has raised. That log contains all the outstanding requests as well as the rejected ones. The board should be accessible to everyone. Having this transparency improves trust as it allows people to see there are many more and while their request might feel like the most important for them, it might not be the most important thing for the company. This video served us as inspiration for building this process.

The last key thing is to make sure other ships have an understanding of the business value you’re delivering, even if some of their requests are rejected. To achieve that we send a simple monthly product newsletter to the whole company where we highlight what was delivered in the past month. You want to keep it short and simple otherwise people won’t read it. Don’t bullshit around, don’t try to talk about excuses and things you didn’t deliver. No one is interested in that. Just say what was done and what the impact it has had so far. People will appreciate the honesty and simplicity.

The above should help you to keep trust and cooperation between your ship and the rest of the flotilla. Let’s move on to the last piece: communication with the Execs.

3. Direction. Ship stays on course.

Your ship is moving and the ships around you are able and willing to cooperate. Good huh? Anything missing? Strategy! Moving is not enough. Running full speed into a wall doesn’t do any good. You need to move in the right direction.

The exec team’s goal is to figure out what the strategy or direction is. You, as the product leader, need to communicate their vision into your team, while also communicating your team’s progress back, both being equally important. And as my fleet analogy suggests, execs are distant from the micro day-to-day perspective and care mostly about the bigger picture.

At Appear Here, we use quarterly company wide Objectives and Key Results (OKRs) to track teams progress. “The system made famous first by Intel and now by Google asks all employees to outline their major objectives and the quantifiable actions (i.e. key results) it’ll take to achieve them.”, as written by First Round.

Example of how our quarterly OKRs tracking system might look like. Each Key Result is being tracked weekly to give us an overview of the progress and whether we are on track or behind.

Setting clear objectives and key results at the beginning of a quarter makes sure the whole team knows exactly where we want to be in the next 3 months. But 3 months is ~ 63 working days which is 504 working hours. It is very easy to forget about your target goals during your day to day travels and battles, especially in a startup where chaos and change are the de facto standard.

We revisit them weekly to stay on course. Every Tuesday, the product team sits together to go through the OKRs and get a status update on each. The goal is to update the current progress and evaluate whether we are ahead, behind or on track. In case we’re behind we figure out what actions can be put in place to get back on track by the following week.

This OKR document is also accessible by everyone in the company. This gives our Executive team the ability to see the bigger picture and step in if needed. Transparency is, yet again, a friend that helps us with communication.

Final Note

And that’s it! In the post above, I focused on the 3 key communication layers Product Managers need to handle. I talked about how to keep your team motivated under a constant flood of bugs, how to cooperate with other departments and make sure they trust you. And lastly, how to communicate up to the Executive team about your progress.

The processes above are successfully being used to work on product at Appear Here and are a result of many iterations. It has enabled us to move faster and as a result we have added more sailors than ever.

--

--

Roman Mazur
Appear Here Product Engineering

Product @ Appear Here. Ship fast and learn quick 🚀🚀🚀