In my experience, I've found the best way to successfully pivot your product vision is to make sure your stakeholders are clear on the why, when, and how. Part of bringing a vision to life is rallying your team and getting your stakeholders excited about what's to come. In my last three roles, I've been hired to lead product teams that have recently gone through a lot of turnover. The designers and engineers appear to be skeptical of product, demoralized, and disconnected from the rest of the organization. Often times, it's my job to build trust and give the team a vision to rally behind.
The why
To successfully pivot your product vision, you have to earn your team (and leadership's) trust. I've found the best way to do that is by clearly communicating why the vision is changing. You will need to support your vision with data and research. For example, I was able to cite customer interviews, data, and other research when I had to shift my team's product vision to increasing creator confidence when drafting content in Confluence. That data was especially important because "confidence" is a hard thing to measure. My engineers were never going to get excited about such an intantible problem like "lack of confidence" unless I could prove creators were struggling and that we would be able to measure success when we built new features.
The when
For leaders and triad partners: communicate early and often.
Creating a product vision requires teamwork. You will likely work with your engineering manager, product designer, and manager to start drafting a new product vision. It's important to share early versions with your triad and leaders so that you can bring them along, get feedback, and make sure you're all going in the same direction.
For your team: communicate when the vision is ready to stand up to tough questions.
As a PM, I've been on the receiving end of a product's vision changing. In my experience, there's nothing worse than a leader telling you the vision is changing, but it's not ready or they don't have answers to basic questions yet. This kind of uncertainty is terrifying and leaves too much time to make assumptions. Will my work be impacted? Are my projects getting killed? Etc.
Instead, your product vision should be very close to done. You'll want to leave room for feedback from your team, but you want to make sure your product vision has been pressure-tested. Why? Because teams need stability in times of transition, and it's your job to rally your team around a new direction. You can't do that if it's easy to poke holes in the logic or your vision falls apart because you don't have enough data behind it.
The how
For leadership, I do this through written documentation, supported by data and research, and then a live presentation where I can answer questions, get feedback, and refine.
For my team, I set multiple AMAs and share my page ahead of time. Earlier in my career, I would often get frustrated when I had to present the product vision and answer questions from engineers multiple times. During Covid, it was easy to assume that no one was paying attention if the majority of my team had their camera off, but I've learned that people need to hear information 2 or 3 times before they can fully digest new information and get to a point where they feel comfortable asking meaningful questions to help them understand the "why" behind a change.
