Direction: Roadmap sets your team direction

Setting direction is one of the most important things you’ll do when building a product and company. A clear direction aligns everyone to work toward the same goals. It helps individuals make daily decisions, teams prioritize projects and all members of your organization feel motivated toward a shared purpose. Without direction, it’s harder to work together, know what to focus on and make meaningful progress.

Roadmaps are a critical tool for shaping this direction. The process of creating a roadmap forces you to articulate a vision and decide how to build toward it. The culminating roadmap sets a path of execution for the near future, slightly in front of you and ideally a bit out of reach. Anyone in your company can look at the roadmap to quickly understand what to work on and why it matters. A glance at the roadmap reveals progress clearly and can help you identify projects that need attention.

Whether you’re part of a three-person startup or one thousand employee company, a roadmap helps you and everyone you work with make better decisions more quickly and focus on more valuable work. Clear roadmaps keep teams aligned even when individuals work independently. Ambitious roadmaps push people to challenge themselves to do their best work. Visible roadmaps motivate individuals by giving them context on why their work matters and create a culture of transparency that builds trust, making collaboration easier and even spurring it serendipitously.

These are the practices to follow when building and managing a roadmap:

• Invest in planning
• Work on substantial projects
• Prioritize for impact
• Review regularly
• Stay flexible

Invest in planning

There are different ways to plan out the roadmap. You'll probably choose a small group of company leaders to build it, unless you're small enough that you can run an effective planning meeting if the full team participates. Carve out meaningful time before your first meeting together to think through company goals and what parts of the product you want to improve most. Use your product intuition. Review customer feedback and feature requests. It's also important to review company metrics such as sign up, activation, retention and revenue so you know how to make trade-offs between features and whether specific areas of the app should be prioritized higher than others.

While you'll build the initial roadmap with a small team, people like to feel included and will feel more ownership if they participate in the planning process in some way. Give everyone a chance to contribute. Let teams propose their own projects and you may even set a window of time for anyone to submit feedback and ideas. Also, talk to your customers. Reach out to customers who have asked for features you're considering prioritizing, especially if you're unclear on the customer need or scope of the project. However you plan your roadmap, it’s helpful to timebox the process and develop a repeatable structure so it becomes easier to create over time.

Work on substantial projects

Ideally, the projects you choose to work on make concrete progress in some way. They may create new functionality, launch a campaign or improve an existing area of the product. Build features to completion and avoid breaking down projects into chunks so small that progress doesn’t feel meaningful. Some projects have to get done no matter what such as building tooling and documentation, so fit these into the roadmap and use them to balance out the type and intensity of work. Sometimes teams will also bundle smaller issues into a project to make it more fun. For example, you could create a project called bug week where the focus would be to work through priority bugs from the backlog.

Prioritize for impact

Use higher-level milestones to help focus work toward more meaningful projects. Prioritize foundational projects first and those that will have the greatest impact on the customer experience. Deprioritize projects that don’t improve the product for customers, help you hit company targets or increase the quality and speed of work.

Once you have a list of projects to work on, adjust the sequence as needed to juggle teammate availability as well as project intensity. Work on a couple of smaller projects after shipping a larger feature to avoid burnout. Rotate project leads so top performers don't feel overburdened and everyone gets a chance to develop project management skills. You should work on as few projects at a time both as a team and as individuals. Ship existing projects before starting new ones. Focus produces higher quality work and shipping builds execution into a habit. Order projects so new work builds on top of previous projects which will make changes feel organic and can have compounding effects. It’s also better to ship three significant projects than to end the roadmap with ten half-completed ones.

Review regularly

Create a routine around reviewing the roadmap and evaluating progress toward projects. You might include roadmap review in weekly team meetings as well as check in directly with project leads. Create an environment that actively encourages project leads to share honestly and ask for help, not just report a status or expected completion date. It's also helpful for company leaders to run less regular check-ins where you look at the progress made on the roadmap as a whole, reprioritize upcoming projects and make other changes based on new information or feedback from customers. A great plan isn't helpful unless you're following through on it and you won't know how well you're doing that without regular reviews.

Stay flexible

The roadmap should feel substantial without being impossible. A balanced roadmap leaves up to a third of total work hours to be spent on bugs, fixes and backlog items. Do your best to estimate projects and expect that it will take longer than you think–it always does. It’s also better to be ambitious and err toward adding too many projects to the roadmap, not too few. A couple more projects than practical will motivate the team to ship. Too few projects can lead you into a trap of working at the speed of the schedule, slowing down momentum.

It’s also helpful to look at roadmaps as living documents that can be updated. Circumstances will change and sometimes you'll need to move a project, add a project or delay one. Just don’t change or shuffle projects too frequently or you'll risk veering away from the original direction or losing momentum.

How we set roadmaps at Linear

We work in quarterly roadmaps. Each quarter has a clear theme to focus the work and help us choose which projects to work on e.g. Q4 2020 Core User Experience.

We choose the focus by reviewing the business needs, product goals and customer feedback and then select projects that fall under that goal. We make sure to keep some breathing room in the roadmap, too. Ideally, the roadmap reflects 60-80% of the possible work and leaves room to work on issues from the backlog, fix bugs and handle unexpected needs.

We spend a couple of weeks at the beginning of each quarter creating the roadmap. There isn’t a strict process but it usually takes a couple of meetings over the course of ±2 weeks to finalize. Between meetings, we discuss feedback and ideas in Slack or over Zoom calls. Once we've settled on the projects for the quarter, we prioritize them in chronological order and assign project owners to the first set of projects. If there isn’t a clear owner, then we leave the project unassigned until closer to the start date since it's too difficult to predict who will be free or when previous projects will close.

We assign a lead to every project. They’re responsible for creating a project spec, leading project team meetings and writing the changelog post. Individual project team members create their own issues within a project though the lead is responsible for making sure the project ships.

We kick off our weekly company meeting with a roadmap review. We go through the list of projects one-by-one in chronological order and each project owner updates the team on the status. If a blocker or issue comes up, we might discuss it quickly or resolve it after the meeting.

Throughout the quarter, it's common for projects to take longer or get moved up or down in the timeline as more urgent or opportunistic work surfaces. This is expected and okay. We also don’t like putting specific release dates on individual projects. We can find an estimated completion date by viewing the graph in the project details sidebar and get a general sense of momentum from reviewing cycles and changelogs. Sometimes a due date is helpful or required, such as for launches where we have to work with external parties or when timeboxing the work helps narrow the scope. It’s easy to keep delaying a launch to tweak the homepage, for instance, but slightly nicer pixels don’t translate to added value for a customer or the company so it's better for the team to focus on product feature work instead. We have to admit, though, we had a lot of fun polishing pixels for the latest release and spent more time than we probably needed to on the Big Sur logo. It was time well spent.