AMA: Asana Head of Product Operations, Saikat Paul on Product Roadmap & Prioritization

It depends on your company’s stage, but a healthy roadmap usually balances both existing customers and prospects. Earlier-stage companies should prioritize features that unlock growth and new deals, while more mature businesses should focus on retaining and expanding existing customers. More generally, here's how I'd think about it: Think portfolio, not either/or Don’t fall into the trap of choosing one over the other. Treat your roadmap like a product portfolio to get flexibility and balance across your investments. * 30–40%: Existing customer love Quality-of-life improvements, long-requested features, usability fixes * 30–40%: Growth / prospect unlocks Addressing key sales blockers, unlocking new personas or verticals * 10–20%: Strategic bets Platform investments or tech upgrades that enable future speed or scale * 5–10%: Experiments / bets Fast, low-effort ideas with potential upside Use data to prioritize—not just the loudest voice It’s easy to chase whoever’s yelling loudest, but it's better for everyone to look for patterns: * Sales & CS feedback: Signal, but not always urgency. Prioritize when it’s tied to multiple deals or high ARR. * Product analytics: Show where users drop off, get stuck, or underuse features. * Voice of Customer / NPS follow-ups: Reveal pain points in their words—especially valuable when themes repeat. * Revenue impact & strategic alignment: Your ultimate tie-breakers. tl;dr If a feature helps lots of users do something more valuable, more often, it’s probably worth building. If it’s just to close one deal or assuage one upset account… maybe not.

Product and product marketing work best as partners—not folks talking at one another through a wall. PMMs bring market context, buyer insight, and positioning expertise that help shape what you build and why it matters. Involving them early makes the roadmap stronger and easier to launch. Here’s how that partnership usually works: * Co-create roadmap inputs: PMMs bring win/loss data, competitive intel, and market trends to help prioritize high-impact work. * Validate demand & urgency: They help answer, “Is this worth building now?” by tying features to real market signals. * Sharpen messaging early: Collaborate on the story behind a feature as it's being shaped, not after it's built. * Align on GTM plans: PMs and PMMs define launch tiers, enablement needs, and feedback loops together—not in silos. tl;dr Let PMMs into the kitchen early—roadmap reviews, sprint demos, etc. The earlier they’re in, the clearer and more impactful your launches become and the more successful you'll be.

The easy answer is ideas come from everywhere—customers, sales, internal teams, data, market trends, a founder's morning shower epiphany, etc. In reality, what matters most is having a clear system to prioritize them based on impact, not who yells loudest. I don't think you take an idea and then just go and build it. You need to look at the ideas holistically and in a larger context. Are they hinting at a one-off problem or an endemic one? Use all the noise of the requests to triangulate the customer problems. Solve those and you'll be doing just fine.

Enumerating the lenses is easy enough. What's truly difficult is advising on their relative weighting. No single lens wins every time—it’s about balancing them to make smart trade-offs. That balance will change over time depending on company strategy, market context, etc. * Business impact: Will it drive revenue, retention, or efficiency? * Customer value: Does it solve a real pain for a meaningful segment? * Effort & complexity: Can we build it well with the resources we have? * Strategic alignment: Does it support long-term goals or bets? * Urgency / timing: Are there deadlines tied to launches, deals, or dependencies?

It's hard to focus stakeholders on what's truly necessary vs nice-to-have and to complicate things even more, everyone's going to have a different list. Give your stakeholders an easy-to-understand prioritization framework, clear constraints, and educate them on the real-world tradeoffs. Also, remind them that an MVP is a tool for learning, not launching. Couple other things I've picked up over the years: * Anchor on the goal, not the feature list Ask: “What outcome are we trying to achieve in v1?” Shifting the convo from features to outcomes helps narrow scope to what’s truly essential. * Show, don't tell Literally sketch or whiteboard the user journey. Then ask, “Can they complete the core task without this feature?” If yes, it probably goes in a later release. * Use a parking lot (but revisit it!) Create a visible backlog of good ideas for v2+. Show stakeholders their ideas aren’t being ignored—just sequenced. Follow up with them when one of their pet features gets prioritized. * Call it “v1” instead of “MVP” This is semantics but it can work. The term MVP can feel scary and final. People like numbers and continuity- they expect a v2 after a v1.

This is highly dependent on your business and release management, but in my opinion, quarterly roadmaps work great for clarity and alignment—but don't treat them as gospel. As for capacity planning 6+ months out; yes, do it, but be flexible. Don't spend excess cycles on tight estimation and schedules. There's usually limited value in that since we all know things change. Here’s how I think about it: * Use quarters to communicate timing, not deadlines. Grouping by quarter helps with stakeholder expectations and focus, while giving product and engineering room to adapt. * Plan the near-term with confidence. Roadmap items 0–3 months out should be well-defined and resourced. * Treat anything beyond 6 months as directional. Assign rough t-shirt sizes (S/M/L) or themes, not sprint-by-sprint plans. Things will change, and pretending otherwise creates false precision. * Update quarterly, not annually. That way, you're always steering based on what’s real—not what was true six months ago.

Start with why, end with why, and throw some why in the middle for good measure. People can handle change—they just hate surprises and a lack of rationale. Be transparent, tie the decision to outcomes, and show you’ve really thought about the change. Explain why the shift matters, how priorities were reassessed, and what the new plan is.