If you find this newsletter valuable, consider sharing it with friends or subscribe if you haven’t already 👇

🤫 P.S. If you haven’t joined our private online Slack community, get on the waitlist here. More invites going out this week.

Q: One of the more frustrating challenges I've encountered in my role as Head of Design has been the many disparate sources of truth. As one example, the design team has a prioritized roadmap doc created in partnership with product managers AND the eng team has a different roadmap doc (using a totally different tool). That's broken, true?


Yep! Nice work recognizing an opportunity to level up your teams.

Though it's normal for high-growth companies to go through periods where there are more tools than people, and for teams to have a Google Doc who’s sole purpose is to keeps track of all of the other Google Docs, you should always look for opportunities to streamline your tools and processes. This is especially true for roadmap docs.

I like to think of PM as the conductors of an orchestra — they both lead a cross-functional team to create something beautiful. In that sense, a roadmap is like the musical score. It tells everyone on the team who’s responsible what, when they need to start and finish, and how all of the parts come together to create something great. In an orchestra where the violins have one plan and the tubas has another, it does not end well.


To zoom out, what's even the point of a roadmap doc? I see five main benefits:

1. Prioritization: It’s a great forcing function to prioritize all of your team's great ideas 2. Alignment: Everyone on the team can always see what those priorities are 3. Transparency: Everyone on the team can always see who's working on what 4. Accountability: Visible dates and deadlines for each project and person 5. Dependencies: Highlight which tracks of work are dependent on others

If your team is using multiple roadmaps for a single team/project, you substantially reduce each of these benefits.

Note, it's totally fine for individual functions (e.g. the research team) to keep their own internal roadmap to keep track of their internal sub-tasks (e.g. schedule a focus group), but it's vital that your cross-functional teams always come back to a *single source-of-truth roadmap with each team members’s projects and timelines.*

To concretely help you through this process, here's a roadmap template that I personally use, which includes both a flat prioritized list of projects along with visual timeline. For example:


I personally stick to Google Sheets, but there are many tools to choose from. Here are the results of a very unscientific Twitter poll, asking people what project management tool they use:

And finally, a few additional resources you may find useful:

1. A previous post about roadmap templates 2. A three-step framework for solving product problems 3. The Alternative to Roadmaps by Marty Cagan

I hope this gives you enough ammo and motivation to make a change in how your team operates. Good luck!

Inspiration for the week ahead 🧠

1. Read and listen: How to build a breakthrough (also in podcast form) by Mike Maples, Jr. 2. Watch: Thao and The Get Down’s new music video

3. Read: Permanent Assumptions by Morgan Housel — How do you analyze the world when everything feels broken?

That’s it for this week!

If you’re finding this newsletter valuable, consider sharing it with friends, or subscribing if you aren’t already.

Sincerely,

Lenny 👋