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:
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 overtime.
There will always be an endless list of projects to build or ideas to pursue on the roadmap. Infinite lists can be hard to prioritize and demotivating to view, so it’s helpful to break down roadmaps into milestones that are based on time, theme or goal.
Time-based milestones give planning and execution a regular rhythm. Examples include monthly, quarterly and annual roadmaps. Shorter milestones are easier to plan and naturally encourage you to scope down projects so they fit within them. Success means realizing most of the projects.
Goal-oriented milestones tie work to specific outcomes. Examples include building a large feature, new design or toward a public launch. Success means completing enough projects to ship or meet the goal.
Thematic milestones define a focus that narrows down the list of projects. Some example themes could be to improve the core experience or drive engagement. When using thematic milestones, it’s helpful add a time or number limit to keep the list of projects manageable. Success means impact that you can see or measure.
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.
理想的情况是，你选择的项目能在某些方面取得具体进展。他们可能会创造新的功能，发起一个运营活动或改善现有的产品。确保完成功能，避免将项目分解过小以至于感觉不到进展。有些东西无论如何都要做，比如构建工具和文档，所以要把这些纳入路线图，用它们来平衡工作的类型和强度。有时，团队也会将一些小 issue 捆绑在一个项目中，以使其更加有趣。例如，你可以创建一个叫做 bug week 的项目，重点是解决累积的高优先级 bug。
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.
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.
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.
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.
我们在每个季度初花几周时间制定路线图。没有严格的流程，但通常需要在 2 周内召开几次会议来最终确定。在会议间隙，我们在 Slack 上或通过 Zoom 会议讨论反馈和想法。一旦我们确定了本季度的项目，我们就按照时间顺序对其进行优先排序，并为第一组项目分配项目负责人。如果没有明确的负责人，那么我们就不分配项目，直到接近开始日期，因为很难预测谁会有空或者之前的项目何时结束。
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.
在整个季度中，随着更紧急或更好的机会出现，项目需要延迟时间或在改变优先级是很常见的。这是预料之中的，也是可行的。我们也不喜欢在单个项目上确定一个具体的交付日期。我们可以通过查看项目细节侧边栏中的图表找到一个估算的交付日期，并从审查周期和变更日志中获得一个总体的势头。有时，一个截止日期是有帮助的，或者是必须的，例如，对于我们必须与外部各方合作的交付，或者确定时间有助于缩小项目范围。例如，很容易为了优化主页而不断推迟发布，但优化几个像素并不能为客户或公司带来更多的价值，所以团队最好把精力放在产品功能的工作上。但我们必须承认，我们在为最新版本打磨像素时有很多乐趣，而且在 Logo 上花费的时间可能比我们需要的要多。这些时间花的值。