AMA: Square Product Leader, Abhiroop Basu on Roadmap Planning

This is an interesting question, but it's rarely a decision an individual product manager makes. Even if you're the only PM in your company, there will be PMMs, business development, sales, not to mention your leadership team who are all part of setting the priority/direction for the company. There isn't any point in you building a feature for existing customers if sales is focused on signing up new users. If you're company is new or young, customer acquisition is likely the bigger priority. In this case, you should focus on building new features to sign up new customers. In contrast, if your organization is more well established prioritizing existing customers will be the goal. Ultimately, though, it won't be you making this decision in isolation. Look to your organizations leadership to see who the target segment(s) should be.

The simple answer is to prioritize the features that will bring your customers the most value and consequently drive the most revenue for your business/organization. Unfortunately, it's rarely that straightforward, particularly if you aren't working on customer facing features. Here are the four steps for prioritization: 1. Solicit input from your partners: It's important to identify what your design, engineering, data science, product marketing, and other cross-functional partners find important. For example, your engineering partners might want to do a tech migration, while your PMM partner might have identified a critical missing customer feature. Together with their input you can brainstorm and create a list of initiatives. 2. Use the RICE framework: Create a table using the Reach, Impact, Confidence, and Effort framework. Reach is for how many people will see the feature. Impact is for the $ impact of the feature. Confidence is the likelihood of execution and/or Impact (0-1). Effort is the level of effort (usually 1-10). The formula you can use is R*I*C/E. For example, let's say you're building a new Android app for your customer base. You know that the app will reach 100 customers, it'll grow revenue (impact) by $50 per customer so a total of $5000, the confidence is medium at 0.5, and effort is 5. Total = 500. You can then benchmark this against a different initiative. 3. Communicate your decision back to your partners: Once you've come up with a priority (either your "top 5", P0/P1, or ordered list) communicate back to your partners and ensure you're all aligned on what's most important.

Prioritizing is one of the hardest tasks for a PM. Balancing the needs of stakeholders, with customer needs, and business priorities. However, only your manager (and their manager and so forth) should have any "control" on your roadmap. Everyone else, should be able to provide In reality, you will find other stakeholders will expect some level of influence. Once you've identified the initiatives for your team, you should use the RICE framework to prioritize them (see my other answer on this topic). This will give you a clear framework when discussing priorities with other stakeholders. For example, if sales is insistent that customers need a specific feature, you can show them that there are other features which have a higher RICE score. This may or may not always be effective, but it's a consistent approach that can be used with everyone. There will be times that RICE scoring will not be enough. In these scenarios, it's important to hear out your partners and give them the opportunity to make their case.

Depending on the team in question the level of detail and approach will differ on how you communicate your roadmap. Here are some of the key teams you'll partner with and approaches you can take to communicate your roadmap: * Core team: For your design, engineering, and data science partners you want to get into the weeds. Typically you want to share every element of the roadmap and more specifically the requirements for each and every feature. After all your core team are responsible for building the features. No detail is too small! Communicate early and often. * Partner product teams: For most larger companies, it's likely you will be working with other teams. For these teams you need to identify which features those teams will care about. You don't need to tell each team about all the features you're building. Highlight the important ones and explain why they need to know about it. * Product marketing: You'll want to share everything customer facing with your product marketing partners and work with them to craft the benefit/value statement for each feature. Your PMM partner is responsible for marketing the features to customers, so it's important they understand the why, what, and how of the feature. They need to know everything, minus the technical implementation. * Sales: Sales will typically work with Product Marketing, so you don't necessarily need to create something separate for these teams. * Customer success/support: Success and support will need to know what to do when things go wrong. So you should have a clear FAQ or table that highlights potential issues with each feature and ways to diagnose it.

One thing I've never had an issue on is coming up with features for a product. If you're ever bereft of ideas, simply go and speak to a customer and they'll provide a dozen ways your product can be improved. But it's important to structure the ideas so you don't get overwhelmed. Here's how you can go about doing that: * Brainstorm with your partners: Setup time with your partners to generate and refine ideas. You can use customer feedback as an input * Vote/prioritize on the top ideas: Give everyone a vote and see which ideas people care about the most * Refine: Go deep on a handful of ideas and come up with a workable problem or hypothesis statement for that idea

Some companies do a great job in providing a public-facing roadmap. At one company I worked at, there used to be a Trello board where customers could add features, upvote, and see what was coming up. It was completely transparent. On the other hand I've worked at companies where we didn't publicly list anything. There are good reasons to do both. At smaller companies being transparent can help build community, engagement, and enthusiasm for your product. You are also at low risk of having bad publicity if dates slip. You should strive to include details of the features, mockups, pricing, and anything else that might be relevant. At larger companies, you'll need to work with your marketing, legal, and sales partners to coordinate what is published. For example, you don't want to list that something is being worked on when sales has communicated a different feature is the priority. It's also important to provide disclaimers so that customers don't use any dates/targets as a means to renegotiate their contract when something slips. Finally, you'll want to make sure that you aren't sharing too many details about a feature until they are confirmed. If there are companies relying on your product for their business then accuracy is critical.