How do you manage and inform the futuristic vision of the product roadmap with current customer requirements / feedback?

Great question. Oftentimes customers’ requests for added capabilities or improvements to current features are already in your product roadmap. When customer feedback corresponds with your product plan, use the volume of requests for a certain feature to prioritize stack and rank, perhaps bumping one feature up and another one down as you plan upcoming releases.

As your company grows and you receive increasingly more feedback from your customers, it can be difficult to decide what’s really worth implementing. Look for recurring requests from customers to cut through the noise.

Your product vision should not be a plan that shows how to reach your goal. Instead, you should keep the product vision and the product strategy – the path towards the goal – separate. This enables to change your strategy while staying grounded in your vision. (This is called to pivot in Lean Startup.)

At the same time, a vision is the prerequisite for choosing the right strategy. If you don’t have an overarching goal then you cannot decide how you best get there with your product team. 

I mentioned the MRD in previous answers, which I think is great at informing individual projects or initiatives. At a higher strategic level, I find that Product Vision docs are valuable at helping PMMs, PMs and other cross-functional partners align on the multi-year vision for the product. Having alignment on where you want to be in the next 3, 5, and 10 years is really important when navigating the day-to-day of customer feedback and product roadmap prioritization. 

I view these as two different things: (1) informing the future vision of the product roadmap and (2) impacting the roadmap in the short term to meet current customer requirements.

An example for #1: A few years ago, I partnered with a PM to dream up a product that was unlike anything else on the market. Once we had a few big ideas, we did some market research with secondary data from analysts. From there, we put together a focus group to get customer feedback and validate the secondary research. We had discussions around a specific problem. We got granular when diving into these pain points and exploring the current attempt to ease the pains. These insights shaped how the roadmap looked for this futuristic vision of the product.

An example for #2: I conducted a win-loss analysis that consisted of interviews and sales data. The results revealed which features were table stakes and preventing us from winning deals. I was able to quantify the losses and put a dollar amount on the features we lacked. An analysis like this helps the PM team see how the features impact sales. Bonus points if you can pair the win-loss analysis with the buy team’s requirements, especially with explanation for WHY each feature is required and explain what the customer expects to solve with the feature.

A few things to consider:

• Seek feedback from high value customers. Winning or keeping those high value customers is critical for business health, and compliments customer retention efforts.
• Your PM is your partner. Set up a regular cadence to learn how they’re dreaming up the product. Get their buyin on your research topics. Having their support from the start will make them more receptive to hearing your ideas later.
• Quantify the feature in dollar amounts. Pair this with a customer anecdote or quote.
• Go deep on customer pain points. Try as hard as you can to know what it’s like to be your customer and face the problem at hand. Understand WHAT the pain is, WHY it hurts, and WHY the current methods to solve the problem don’t work. Knowing their pain points will help you better articulate your ideas to influence the product roadmap.

Current customer requirements are helpful to give us a sense of where they are getting stuck, what are their pain points and unmet needs. A futuristic vision of the product roadmap would ideally extend at least 6+ months out and hopefully remain durable for at least that period. Otherwise, that isn’t a true futuristic vision.

We recently announced our future vision of how Copilot will evolve at Build 2024. For example, we shared that Copilot as a personal assistant is expanding to include team copilot. This is our vision of expanding Copilot beyond a personal assistant to serve entire teams and departments. We are emphasizing that Team Copilot becomes a valuable member of the team and are demonstrating how Team Copilot takes on new roles across a broad set of scenarios including meeting facilitation, collaboration, and project management. This innovation is a result of our customers’ feedback and how we can make it more proactive and powerful.

Managing and informing the roadmap looks like operating as a lawyer and advocating for your client. Collect the feedback, document it, present your business case (quarterly at minimum - early and often is best). And get alignment with a Product Leader or Ops manager on WHEN is the best time for their time to coalesce that feedback into roadmapping decisions. The most successful cross-functional teams had this clearly defined in the New Product Introduction process with t-shirt sizing weighted scaled to help stack rank what made the roadmap from all angles (internal teams) and customer intake flows. Tools to help: proadpad, notion, productboard, airtable. My favorite of the aforementioned are a combo of notion and productboard to capture share and inform roadmapping decisions (with syncs to data lakes/CRMS so it's all data-backed).

It is a PMM's job to represent the market and our customers throughout the product development lifecycle - including roadmap decisions. However, what informs the roadmap, and what makes the roadmap - isn't always the same or that simple. There could be very good reasons for a Product team to prioritize refactoring via application enhancements versus innovations like AI. For instance, maybe the business is pivoting to PLG where more embedded self-serve mechanics are needed to drive mass commercialization? This would take priority and ultimately benefit the customers and market, but are serving the broader GTM business case versus
"market or customer" feedback loops.