AMA: Anima Chief Product Officer, Orit Golowinski on Product Roadmap & Prioritization

Everyone can contribute to the roadmap—sales, marketing, developers, leadership, the board, customers, executives, and even random people on the street with great ideas. It’s crucial to stay open to feedback and solicit input from diverse perspectives. However, there’s a big difference between influence and control. Product managers own the roadmap—they are responsible for the success of the product and its strategic direction. While many voices influence decisions, the final call rests with the PM. How to Prioritize Stakeholder Input? * Align with the North Star – Every request should be evaluated against the product’s core vision and goals. If it aligns, it may enter the roadmap; if not, it should be clearly communicated why it doesn’t fit. * Sales Influence – If a major deal hinges on a feature, it deserves consideration—but only if it doesn’t derail core priorities. If a request misaligns with the North Star, leadership may need to reassess priorities or accept losing the deal. * Saying No When Necessary – Not every request is worth pursuing. For example, at GitLab, when I was working on DORA metrics, I insisted on team-level visibility to empower developers, rather than individual metrics for performance reviews. A customer wanted individual-level tracking, but since it clashed with my product philosophy, I rejected the request outright. * Big-Picture Company Alignment – Roadmaps don’t exist in isolation. At GitLab, I worked closely with marketing when GitHub Actions was released. As the PM for Release, I adjusted my roadmap to prioritize AWS deployment so that the marketing team could have content ready to address competition as soon as possible, which was already planned but was pulled forward to align with broader company goals. A public roadmap (internally at minimum) fosters transparency and alignment. Stakeholders should always know what’s being worked on, why, and how it drives business value.

Executives should have influence over the roadmap, but ownership remains with the product manager. A PM is responsible for making strategic decisions that align with the North Star and business value. Transparency is key—an internal roadmap ensures that stakeholders feel heard, understand where their input fits in (or doesn’t), and see the reasoning behind prioritization. Clarity on the “why” and the impact on business goals strengthens a PM’s position when balancing different perspectives. The ability to articulate a clear, compelling narrative around product decisions is crucial. The more effectively a PM can frame their point of view and demonstrate alignment with strategic objectives, the easier it becomes to stand firm while fostering buy-in from leadership.

One of the key skills a product manager must master is storytelling—the ability to communicate the roadmap in a way that resonates with different audiences. While the core story remains the same, the narrative must be tailored based on who you’re speaking to. There are fundamental elements that should be conveyed to all teams: • The “Why” behind the roadmap—the problem it solves and the reasoning behind prioritization. • The target persona—who the product is for and their pain points. • Business impact—how the roadmap aligns with company goals and contributes to success. • The high-level vision and north star—where the product is headed long-term. However, different teams need different levels of detail: • Development Teams need the most detail but at the right time. They should have a clear view of the short-term roadmap (one or two sprints ahead) while also understanding the long-term direction to inform architectural decisions. Not all details are known in advance, and the roadmap should adapt based on feedback, market shifts, and technical constraints. • Marketing Teams need to understand major upcoming releases and their estimated timelines. This allows them to plan campaigns, content, and launch strategies effectively. • Sales Teams require insight into the roadmap’s impact on selling and retention. They need to know which features can help close deals, what they can promise to prospects, and how to handle existing customers’ requests. • Customer Success & Support Teams need visibility into upcoming changes to prepare for customer questions, training, and support materials. If a new feature is rolling out, they should be ready to assist users effectively. • Executive Leadership requires a high-level view of strategic initiatives and business impact to align with financial planning, investor communications, and company-wide priorities. • Partnership & Ecosystem Teams (if relevant) should be informed about roadmap items that could affect integrations, APIs, or collaborations with third-party providers. A good roadmap communication strategy ensures each audience gets the right amount of detail—not too much, not too little—while reinforcing alignment around the company’s vision and priorities.

A public roadmap makes sense for open-source projects (like GitLab), developer tools, or products with an active, engaged community that values transparency. It should also align with the company’s values and commitment to openness. However, even in companies that share a public roadmap, some areas should remain internal, such as: • Security-related features or anything involving sensitive data that could be exploited. • Strategic, competitive differentiators—cutting-edge features that provide an advantage over competitors may start as private before being disclosed. • Highly experimental ideas that may evolve significantly before launch. In today’s AI-driven landscape, maintaining a long-term competitive edge through secrecy is increasingly difficult. While it may make sense to keep certain innovations private pre-release, the speed of development means that exclusivity won’t last long—so teams must balance transparency with strategic discretion.

A roadmap should provide structure without rigidity—a foundation for change rather than a fixed plan. The tech world is dynamic, and no 12-month roadmap will remain untouched. Striking the Right Balance: 1. Start with the Problem & Persona – A roadmap should be anchored in a deep understanding of who you’re solving for and what pain point you’re addressing. 2. Plan for Learning – Build a quick MVP, collect feedback, and continuously adjust the roadmap based on insights. 3. Keep a North Star – Maintain a high-level vision that defines success and ensures alignment with customer and business value. 4. Adjust Granularity Over Time: • Multi-year roadmap → High-level vision, flexible and directional. • Yearly & quarterly roadmap → Strategic priorities, adaptable based on learning. • Monthly roadmap → More concrete, but still open to changes. • Sprint/Iteration roadmap → Fixed to minimize distractions and allow focused execution. Managing Complexity: • Too much detail too early? Leads to wasted effort as things inevitably change. • Too little detail too late? Causes misalignment and slows execution. • Balance is key → Keep long-term plans high-level and adaptable, while short-term execution remains focused and predictable. The rule of thumb: Anything before development starts is open to change. But once a sprint begins, the team should work without disruptions.

The first step in helping stakeholders focus on their needs is alignment on what you’re building. The “why” is critical—everyone should have a clear understanding of the problem being solved and who the target persona is. This clarity helps prevent distractions; if discussions start to drift, you can always refocus by asking: Does this solve the core problem for our defined persona? Key Steps to Prioritization: 1. Align on Business Value – Do stakeholder needs align with the overall business objectives? If not, they may need to be deprioritized to avoid losing focus. 2. Define Success Criteria – Establish measurable goals early on. When new requests arise, ask: Do they contribute to our success metrics? This ensures every addition serves a purpose. 3. Focus on MVP – The goal of an MVP is to deliver minimal value quickly, enabling early feedback and validation. Keeping it small, focused, and fast to launch is essential. 4. Avoid Perfectionism – It’s tempting to aim for a complete feature set, but this leads to delays. As Reid Hoffman said, “If you’re not embarrassed by the first version of your product, you’ve launched too late.” By maintaining a sharp focus on problem, persona, business value, and success metrics, you ensure that stakeholders stay on course and that the MVP delivers impact without unnecessary delays. Early feedback is the key to refining and improving the product iteratively.