AMA: Meta Director of Product - Horizon Worlds Platform, Mike Arcuri on Product Roadmap & Prioritization

Here's a rough e2e prioritization process: 1. Set context with the team and your stakeholders on the overall business, product stage and strategy, key problems, behavioral data, and user research. 2. Establish roadmap themes based on these key problems, needs, and opportunities. 3. Engage everyone in brainstorming solutions for these important problems and opportunities. 4. De-duplicate ideas and group brainstormed ideas/solutions together. 5. Arrange projects ideas into an ordered list. 6. Sort the list by both effort and impact. 1. Low effort, high impact projects rise to the top. 2. Get help from data science to forecast impact if available, or do your own spreadsheet math to forecast impact. 3. Work with design and engineering to scope the effort. 7. Go through the project list with to make sure the ideas near the top are well understood in terms of product & design, open questions are clarified, and owners to further define the solution are clear. 8. Let anyone on the team argue for or against project rankings (e.g. impact being higher than currently predicted or effort being different than current predicted). 9. Settle on the most impactful projects for the next N months in your roadmap. Use points/capacity from agile or SWAGs of engineering days/weeks vs. team capacity. 10. Vet for not just impact, but also depth of coverage and chance of success for your themes/goals. 1. Would it be better to cut a theme goal and make more impact on fewer things? 2. Avoid "peanut buttering" your investments. Minimal time/effort/solutions spread across too many problems can lead to failing at all goals. 11. Define milestones in the roadmap, and communicate broadly about your planned milestones, goals, and top projects.

In executive conversations about roadmaps, I nearly always express them team's (and my own POV) up front. I also connect the dots from business principles/priorities to the investment themes for the roadmap to the projects and milestones in the roadmap. By doing it in this way (i.e. "here's our understanding of our business position and strategy, here's our understanding of company/broader org priorities, here's how our team's mission and scope will contribute to these..."), I find I get clear feedback about any misalignments along the way. E.g. if your executive sponsor(s) have a different POV on the business position or the company priorities, then there will almost certainly need to be a refresh to the whole roadmap once you correct for the misalignment. If they agree on the context all the way down to the level of your team's mission and priorities... then any discussions/feedback will be about specific projects or milestones and usually about timing, risk-reduction, or success criteria for these. If you're in a startup company or 0-1 product situation, or you're experience some kind of product inflection point or uncertainty... then it's possible you don't have a strong opinion or consensus within your teams and internal partners as to which direction to go with the roadmap. In these situations, I wouldn't discuss projects with execs at all. Instead I'd lead a discussion about the business context and the most reasonable 2-3 options for product strategies and roadmap priorities. Always align on your context and direction first. Then discuss a roadmap based on that aligned direction.

In terms of how to communicate with your internal organization, partner teams, and stakeholders during a pivot, I'd make these internal partners and stakeholders a participating part of the pivot planning process. Once you're through that process and back to executing, then you can communicate timelines and project status internally just like before. How to communicate with an external audience (e.g. clients in a b2b business or consumers in a b2c business) is a decision that usually gets vetted all the way up to the C-level. I've worked in major companies that shared almost no forward-looking roadmaps (either due to the risk to b2b relationships when product plans change, or because of bottoms-up product development culture that's inherently chaotic and hard to communicate to consumers). Some companies also worry about adverse press reactions or competing companies learning about your future plans and competing with you more effectively. But many other companies build strong communities of fans/supporters/customers by communicating somewhat openly about work-in-progress and future releases. Whatever the appropriate amount of future-plans-communication for your business and customers, I'd expect you'd communicate less openly when you're less certain internally about your future direction. E.g. if your customers love something in your future plans, but you're pivoting and may not follow-through, the risk of disappointing these customers and even undermining their trust in your business/brand increases. If your customers hate something about your announced future direction and write-off your business as likely to meet their needs, but you're pivoting and may veer back in an earlier direction... then you may scare off customers that you'd ultimate end up serving. Net-net I think you need a kind of customer strategy for your pivoting. Do you know for sure how your target audience is changing? Can you predict whether part or all of your current customer base is also in your new target audience?

I've worked with marketers who are great at understanding customer and business opportunities. I regularly work with these teams in combination with data science and user research teams to form an "understand roadmap" to answer the open questions that would most help our product progress (about our market, our users, our competition, our brand). At times I've also asked these marketing partners play leadership roles in team roadmap planning and they've done a great job. Other marketers are great at partnering with product teams to hit goals by running online campaigns, driving external events, creating content and educational materials for launches, etc. For these teams, it's best that they sign up for goals that contribute to the top priority product goals and drive overall product success. After all the line between "product" and "marketing" is arbitrary: your customers/users experience every touch point with your product and marketing as a continuum.

Executives that can't provide focus for your team can be a common situation when there's early stage market uncertainty and pressure to do customer discovery and find PMF. Top company leadership feels an intense time pressure (I've heard it described as a holding both a compass and a stopwatch), and so is reluctant to reduce potential segments that could become winners. More than anything here, they're hoping for some signal/data/customer success that could then increase the certainty of focusing on a single target market segment and product direction. A lack of leadership direction can also occur in more stable product/business situations when leaders don't understand the tradeoffs that are implied in what they're asking for. E.g. a leader who's never been a PM, designer, or engineer may just keep asking for more features which could help with sales, expecting the team to push back or explain when they can't do everything asked of them. The solution is in closing the gap in understanding. When leaders ask for too much, the team can't do a good job in serving or even learning about all the different potential customers. Execution suffers and delivery dates slip. Product quality suffers which leads to tech debt and more time wasted fighting bugs and regressions vs. building new things. Here's a template for broaching these topics when requests push you into the danger zone: 1. Boss, you asked for X+Y+Z. 2. Here are the best plans we can come up with for X+Y+Z if timing is fixed and resources are fixed. 3. All of these plans are pretty shitty and will likely result in product failure due to reasons foo and bar. 4. Here's a plan we think is better if we relax the timing constraint or the staffing constraint. E.g. after being asked to pursue many customer segments simultaneously: 1. Illustrate what it looks like in terms of a project roadmap and timeline to try to serve all those customer segments. 2. Be super honest about the risk of failure in all segments. 3. Offer alternatives that relax the timing constraint: 1. MVP learning in all segments simultaneously, but little to no product development until we've chosen the 1-2 most promising segments. 2. Sequencing segments over time: 1-2 segments first so that you can credibly learn about their needs, try to serve them, and evaluate whether you could reach PMF. 3. Serving one segment super well, but doing learning exercises in adjacent segments. 4. Offer alternatives that relax the staffing contraint: 1. Outline what you think is a reasonable number of segments to make a credible effort with >50% chance of success with current staffing. 2. Outline how much increased staffing would allow you to make a credible effort with >50% chance of success on all the additional customer segments.

I answered this partly in the earlier question “We’re pivoting our product, and it’s difficult to plan the roadmap too far out. How do we reset expectations on what product communicates?” TLDR is “it really depends on your company values/priorities and your product and community.” * There are risks to sharing too much detail too early (failed follow-through can erode user community support and/or business partner/channel support). * I personally like to optimize for customers, not competitive intelligence, because if you have happy customers, you have a successful business. * In terms of what to include, you can talk about your product team’s priorities, key problems you’ve identified and are working on, and even hard tradeoffs you’re thinking through with certain customer communities or research groups/advisory councils. But pre-announcing delivery of features by specific dates is probably too much detail and too high a likelihood of backfiring.

One piece of advice: * Understand your product, organization, and company and what each of these needs to succeed. Then do that thing (at your appropriate job scope: product/org/company). A bit more detail: * Consider doing a listening tour of your peers and reports in your first 30 days: * What are they most worried about/hopeful for with you coming in? * What’s the one thing they’d like to see you change? Keep the same? * Your job is always to: * Build the right product. * Build the right team. * But your primary focus in your first year might vary quite a lot depending on your unique role and circumstances... e.g.: * Hire a strong PM team * Turn your current team's performance around * Create a stable roadmap and shield your team from chaos/changing pressures so they can execute * Help your CEO or management chain understand product development schedules and tradeoffs so the business can focus/prioritize better and start delivering more impactful progress * Figure out your market, customer needs, and product jobs-to-be-done * Identify and help resolve dysfunctions between departments

1. I like to start with the product stage, context, and strategy. From these, and your customer data you should be able to determine your priorities * With an early stage, pre-PMF product, you may be prioritizing learning about your customer needs and how well your product is meeting those needs above all else. * When you know your product is meeting some people’s needs or providing some valued entertainment, you can focus primarily on increasing engagement and retention. How can you make your product better in ways that result in longer user sessions, more repeated user sessions? * When your retention curves look good for 30+ days (and ideally 90+ days), it may be time to focus more on growth. 2. You may have a more complex product though. E.g. one with a creator or developer or seller ecosystem and a 2-sided marketplace dynamic. * In these cases, you should be aligned on a strategy that includes sequencing (e.g. how are you getting high quality content to begin with in order to engage consumers? Or, how can you increase awareness and users enough to become an attractive marketplace for producers?) 3. Funnels also make great lenses. * New user acquisition (by channel and campaign, and the UX flow for each) * Retention over time * Conversion or upsell funnels * Social growth (if any) 4. Things like speed of learning, speed of improvement, and iteration velocity also matter to winning in the long run. So you may need to think this through as well. * Example: Is your tech debt getting so high that you’re wasting a ton of time dealing with regressions? Is this driving customers away or leading to low review scores?

We all inherently understand that the farther out you plan, the greater the uncertainty. This was also one of the key themes in the Agile development methodology. But I don’t believe I’ve ever heard someone explain the implications of this in a practical way for product managers. Some businesses may require 5-year financial plans for product investments. Sometimes called LRPs for “long range plans.” These are bullshit as forecasts, but the exercise is useful as a check that this new product could be a profit-making business if it succeeds. E.g. if you can’t spin a credible story that grows the business to a revenue size and profit margin that your business would be interested in, then you know not to waste your time in this endeavor. What I like to do for pre-PMF products or significant pivots to established products is 1. Make a 2-3 year vision/loose plan: This is about painting a picture of a future product and business that are exciting and relevant to your customers and company. This will also engage your team members and stakeholders and help you align with your leadership. 2. Define a successful next year: Sync with company leadership or investors on what success for the next year looks like. E.g. "If we can achieve XYZ, we’ll be happy and keep investing/maybe grow our investment." 3. Make a concrete roadmap for the next 3-6 months: You need clear milestones with exit criteria, sound goal metrics with targets to hit, and prioritized and sized projects. Ideally you'll even have forecasts of the metrics improvements you can expect from your major projects. These 3 artifacts will leave you with an inspiring vision for 2+ years to attract talent and motivate teammates and stakeholders, a clear definition of what a successful year of product advances looks like, and a concrete plan to hit the next set of milestones and goals. They also avoid waste in planning concrete milestones far ahead that will likely be abandoned as you continue to learn and adapt to your market. More on roadmap durations and goals: * Goals: On my teams, we plan 6 months at a time, and take on hard numbers goals (50% chance of success) for each 6-month period. * Certainty: I encourage PMs, engineering managers, and senior folks on the team to ensure they have really clear roadmaps for the first 2-3 months, and then it’s OK to have some unvetted ideas in months 4-6. This serves two purposes: it encourages goals that are hard, ideally hard enough the team’s not sure that they can hit it. It allows the team to keep thinking creatively, keep learning, and swap in better projects whenever they discover and define them. * Capacity planning: If you have hard dates you have to hit (e.g. major marketing moments, hardware device releases, consumer holidays, etc.), it’s an important check. If you ship updates regularly (monthly or faster), capacity planning usually isn’t that important because the team can just continually strive for their goals with the best projects they can think of.

There’s already a planning process in your company, it's just likely a poorly defined/understood one with a lot of downsides. You might start by doing a learning/listening tour, identifying and aligning team members on the current pain points with planning/lack of planning. Then you can explain the reasons why change is desirable, the goals of changing the process, then the new process itself. When you're ready and have some support/buy-in to adopt a new process: 1. Be sure to define the roles individuals and job functions will need to play in the new process. 2. Set a timeline (and recurring expectations) for the new process. 3. Guide everyone through the new process the first 2 times. 4. Hold people accountable to delivering the artifacts of the process. 5. Communicate often and with detail throughout the process. 6. Do retrospectives on the new process, and be open to valid feedback/criticisms and continue to improve over time.

I like to get as much input as is reasonable both internally and externally. * Internal examples of stakeholder input: partnerships, sales, marketing, product support, operations, finance, data science, design, execs… * External sources of roadmap input: press reactions & professional product reviews, app store ratings and reviews, customers support requests, user research, inbound marketing research, and above all behavioral data from your logging/analytics. In terms of gates... during the planning process, you don't really have gates, just the process you follow that encourages all good ideas to flow in, but then rates those ideas by expected impact toward your goals, and level of effort to design/build/test/release. See my other answer to the question about the end-to-end roadmap prioritization process. When the team is executing, not planning, ideally all ideas coming in can wait for your next update or refresh cycle. This might be quarterly or even monthly in a very lightweight way... but since your teams have established goals, new projects will only bump other projects out of the roadmap if they're more likely to have higher impact in achieving the goals. Occasionally there's a disruptive change that should cause you to think through changing the team's goals or an immediate pause/change to work-in-progress in the roadmap. But these should be rare, and very important, because you're going to thrash your team to consider the change/pivot.