Monthly focus documents instead of roadmaps

During day-to-day work of an early stage company it's easy to fall into a reactive mode where you want to fix all the feedback and bugs that pop up. I get it and we've been there. It feels very tempting and can be almost addictive. Don't get me wrong, we’re obsessed with user feedback, and you should be as well, but only to a certain degree. It's equally important to have a system in place that allows you to work on bigger projects. Projects that take multiple weeks and move the needle the most. For us, this system is writing monthly focus documents.

Every beginning of the month, we write down what we work on for the next 30 days. We call these one-pagers focus documents, and they help us to spend time on the right things. With the document, we make sure that our fully distributed team aligns on direction and ownership. Everybody on our team is responsible for at least one project throughout the month. They should always know on what they're working and why they're working on it.

Structure

Each document starts with a summary that describes the goal for the month. We don't specify any metrics or growth goals. By this point, we already know what we want to achieve and describe the projects that we bet on. The summary may include a review of the previous month to set the context. Next, is a list of projects. Each project includes an owner, a link to a Linear project and a description.

The first sentence of the description states what we want to build. The rest describes why we want to do it. The owner is responsible for how to finish the work and has the authority to drive the project. Sometimes, the Linear project is pre-filled with user feedback. Otherwise, the owner has the freedom to keep track of their work however they want. Some do it more granularly, others do it high-level. We care about the outcome and trust the individual to manage themselves. We don't follow any religious agile processes.

Unplanned work

The monthly focus document acts as a guidance on what’s important, but you can’t plan everything ahead. There is always some unplanned work popping up that needs attention. We read every single user feedback and try to respond to each of them (a topic for another blog post). With the focus documents, we established a clear ownership of features. If it’s an easy bug that the owner of the feature knows how to resolve, we aim to address it with the next release. If it’s a bigger thing, we decide if it’s more important than the planned work or should be left for later. The advantage when you read all your feedback is that you get an intuition for topics that pop up more often. If it’s something that popped up many times before but was too disruptive to address right away, we try to plan it for the next month. This way we can keep a calm backlog and stay flexible while focusing on a set of goals.

Growing team

By the time of writing this article, our team size was five, and we're hiring. It's going to be interesting to see how the concept of monthly focus documents will work in a bigger team. So far, it has proven as a valuable way to establish trust, ownership and direction across our distributed team.

Generally, doing trumps planning for young startups. However, when you have to write down what you’ll work on, it forces you to make compromises because there is only a limited amount of time and resources available. You can’t know everything upfront, but you should try your best to get ahead of what’s important. While writing your first focus document, ask yourself how you would feel if you have everything accomplished from your list at the end of the month. It will help you to make the right choices.

Try it out yourself and let us know how it works for your team.