What is the best roadmap format for a first-time PM?

Now-Next-Later is the best format for a first roadmap. It communicates priority without committing to specific dates, accommodates items at varying levels of detail, and is easy to update as context changes. You avoid contentious timeline debates and focus on what matters most.

How many items should be in the "Now" column of a roadmap?

For a team of 6 engineers, 4-6 items in the "Now" column is the right range. More than that and the team cannot realistically execute within a 4-6 week window. If you start with too many, move the lower-priority items to "Next" after reviewing capacity with your engineering lead.

Should a product roadmap include a "Not Doing" list?

Yes. A "Not Doing" list is one of the most important parts of a roadmap. It explicitly documents what you considered and rejected, with the reasoning. This prevents scope creep and gives stakeholders a clear place to see why their request was deprioritized rather than ignored.

How do I get stakeholder buy-in on a roadmap they disagree with?

Frame trade-offs concretely. Instead of defending your choices abstractly, show the specific cost of alternatives. "If we build Feature X, it delays Feature Y by one month. Here is why I recommend Y first." Data from customer conversations, usage metrics, and competitive analysis makes your case much stronger than opinion.

How long should it take to create your first product roadmap?

Plan for about 4 weeks. Spend the first week listening (customer calls, engineering 1:1s, data review, competitive audit). Use the second week to choose a format and define themes. Fill in the details in week three. Use week four for feedback and buy-in from your CEO, engineering team, and customer-facing teams.

Creating Your First Product Roadmap

How to Build Your First Product Roadmap in 4 Weeks

Creating your first product roadmap takes about 4 weeks: one week of listening (customer calls, team 1:1s, data review), one week choosing a format and defining themes, one week filling in the details, and one week getting buy-in. The Now-Next-Later format is the best starting point because it communicates priority without committing to dates.

You have just been asked to create your first product roadmap. Maybe you are a new PM. Maybe you are an engineer or designer stepping into a PM role. Maybe you have been at your company for a year but roadmapping was someone else's job until now.

You open a blank document. You stare at it. You Google "product roadmap template." You find 47 different formats. You feel more confused than before.

This post is not a theory article about roadmap best practices (for that, see the complete guide to product roadmaps). It is a walkthrough of building a specific roadmap for a specific product, with the messy reality included. I am going to take you through the process I used when I built my first real roadmap, with the mistakes and course corrections included.

The Setup

The product: a B2B SaaS tool for customer support teams (think a simpler Help Scout). The company has 15 employees, $800K ARR, 120 paying customers, and a 6-person engineering team. I joined as the first PM.

Before me, the CEO and engineering lead made product decisions together. There was a Notion board with about 80 items ranging from "add dark mode" to "rebuild the entire ticketing engine." Nothing was prioritized. Everything was technically "on the roadmap."

My first task: create a roadmap for the next quarter that the team could actually execute against. Here is how it went.

Week 1: Understanding the Current State

What I did

I spent the first week not roadmapping. I spent it listening.

5 customer calls. I asked the CEO for introductions to 5 customers: 2 happy ones, 2 who had complained recently, and 1 who almost churned. Each call was 30 minutes. I asked the same question every time: "Walk me through a typical day using our product. What works? What drives you crazy?"

Engineering 1:1s. I met with each of the 6 engineers individually. Two questions: "What is the most important thing we should build next?" and "What is the biggest technical problem nobody is talking about?"

Data review. I pulled usage data (we had basic analytics through Mixpanel). I looked at feature adoption, daily active users, and support ticket volume by category.

Competitive audit. I spent 4 hours signing up for our top 3 competitors (Help Scout, Intercom, Freshdesk) and documenting where they were ahead of us and where we had advantages.

What I learned

The customer calls revealed a clear pattern: 4 out of 5 customers said some version of "I love the simplicity, but I wish I could see which tickets are most urgent without opening each one." The ticket list view was flat. No priority indicators, no SLA timers, no urgency signals.

The engineering conversations revealed something different: 3 out of 6 engineers said the database architecture was becoming a bottleneck. Query times were increasing as customers grew. Nobody was panicking yet, but the engineers could see where it was heading.

The data confirmed both: ticket list was the most-visited page (90% of sessions), and page load times had increased 40% in the last 3 months.

The competitive audit showed that all three competitors had priority/urgency features in the ticket list. We were behind on table stakes.

Week 2: Defining the Roadmap Structure

The format decision

I had to choose a roadmap format. The how to build a product roadmap guide covers the full range of options, but for a first roadmap at an early-stage company, I needed something simple.

I chose a Now-Next-Later format for three reasons:

No dates to argue about. Dates are the most contentious part of any roadmap. At this stage, with this team size, I did not have enough historical data to estimate timelines accurately. Now-Next-Later communicates priority without committing to dates.
Flexible granularity. Some items were well-defined ("add priority badges to ticket list"). Others were still vague ("improve performance"). Now-Next-Later accommodates both.
Easy to update. Items move between columns as context changes. No reformatting needed.

The theme decision

Instead of listing individual features, I organized the roadmap around three themes:

Theme 1: Ticket triage speed. Help agents find and act on urgent tickets faster.
Theme 2: Performance foundation. Address the database bottleneck before it becomes a crisis.
Theme 3: Integration reliability. Fix the 3 most common integration failures (identified from support tickets).

Themes are better than feature lists because they communicate intent. A stakeholder who sees "add priority badges" might wonder "why that instead of dark mode?" A stakeholder who sees "ticket triage speed" immediately understands the goal and can evaluate whether specific features serve that goal.

Week 3: Filling in the Details

The Now column (next 4-6 weeks)

With the format decided, I started filling in the columns.

Items in "Now" needed to be specific enough to start engineering work:

Theme 1. Ticket triage speed:

Priority indicators on the ticket list (visual badges showing P1/P2/P3)
SLA timer visible on ticket cards (shows time remaining before SLA breach)
Quick filters: My tickets, Urgent, Unassigned

Theme 2. Performance foundation:

Database query optimization for ticket list (target: sub-200ms load time)
Add caching layer for frequently accessed ticket data

Theme 3. Integration reliability:

Fix Slack notification delivery failures (affecting 23% of customers with Slack integration)
Fix email forwarding edge cases (14 open support tickets)

The Next column (6-12 weeks out)

Items in "Next" were clear enough to describe the problem but not yet scoped:

Customer satisfaction scoring (CSAT) embedded in ticket flow
Bulk ticket actions (merge, reassign, close in batch)
Database migration to support multi-region deployment

The Later column (3-6 months out)

Items in "Later" were directional, not committed:

Knowledge base / help center for customers
Advanced reporting and analytics
API v2 for custom integrations

The "Not Doing" list

This was the hardest and most important part. I explicitly listed things we were not building this quarter and why:

Dark mode. Requested by 8 customers. Low impact on retention or acquisition. Deprioritized in favor of core workflow improvements.
Mobile app. Requested by 12 customers. Engineering cost is 3-4 months for one platform. The ROI does not justify the investment at our stage.
AI-powered ticket routing. Interesting but premature. We do not have enough data to train a useful model. Revisit in 6 months.

The "Not Doing" list is how you prevent scope creep before it starts. When someone asks "why are we not building dark mode?", you can point to the roadmap. The decision is documented. The reasoning is transparent.

How Do You Get Buy-In on Your First Roadmap?

The CEO conversation

I presented the roadmap to the CEO in a 30-minute 1:1. I expected pushback. I got questions instead.

"Why performance over the knowledge base? Customers have been asking for a help center for months."

My answer: "If page load times continue to increase at the current rate, our largest customers will start churning in 2-3 months. The knowledge base adds new value. The performance work prevents losing existing value. I think we need to do both, but performance first."

The CEO agreed. The data made it easy.

"Can we squeeze in a small mobile app proof of concept?"

My answer: "Here is the trade-off: a mobile POC would take one engineer about 3 weeks. That is the same engineer who would build the SLA timer and quick filters. If we delay those, we delay the ticket triage improvements by a month. I recommend we ship the core improvements first and revisit mobile in Q2."

He pushed back gently, then agreed. The trade-off framing made the decision concrete.

The engineering review

I reviewed the roadmap with the engineering lead and the team. Their feedback:

The database optimization was underscoped. It needed 3 weeks, not 2. We adjusted.
The Slack notification fix was more complex than expected. It required changes to the webhook architecture. We split it into two phases.
The team was relieved to see performance in the "Now" column. They had been worried about it for months and felt heard.

The customer-facing version

For customers and the sales team, I created a simplified version with just the themes and a few key highlights. No internal implementation details. No estimated timelines. Just: "Here is what we are focused on and why."

What Mistakes Did I Make With My First Roadmap?

Mistake 1: Too many items in "Now"

I started with 9 items in "Now." That was too many for a 6-person team to execute in 4-6 weeks. After the engineering review, I moved 2 items to "Next" and adjusted expectations. A good "Now" column for a team of 6 is 4-6 items, not 9.

Mistake 2: Not enough detail on the "Not Doing" list

My first draft did not include a "Not Doing" list. The CEO added 3 items to the roadmap in our first review because there was no explicit list of things we had considered and rejected. Adding the "Not Doing" column prevented this from happening again.

Mistake 3: Treating the roadmap as a finished document

I spent too long trying to make the roadmap "right" before sharing it. By week 3, I was polishing formatting instead of getting feedback. The roadmap improved more in 2 hours of team review than in 10 hours of solo editing.

The Result

The quarter went reasonably well. We shipped 5 of the 7 "Now" items on time. The SLA timer slipped by 2 weeks because of an unexpected dependency. The email forwarding fix turned out to be simpler than expected and was done early.

More importantly, the roadmap changed how the team worked. Engineers knew what was coming and could plan ahead. The CEO stopped adding ad-hoc requests because there was a clear framework for evaluation. Customer-facing teams could set expectations without guessing.

That first roadmap was not perfect. It was not even particularly good by the standards I would apply today. But it was infinitely better than the unstructured Notion board it replaced. And it gave the team something to iterate on. Each quarter's roadmap got better because we learned from the previous one.

The best first roadmap is the one you finish and share. Start there. Everything else is iteration.

Creating Your First Product Roadmap: A Real-World Walkthrough