Samantha Ugulava

A product vision statement is a short, concise, and aspirational set of goals for your product. As a Product Manager, you will need to develop a deep understanding of your company, customers, compeititors, and teammates. Research will depend entirely on your level of understanding of these areas. For the past 2 years, I led the Confluence Content Experience team at Atlassian. My team owned the creating and publishing workflow and our product vision statement looked like this: Our goal is to help creators feel confident creating and publishing more types of content on Confluence. For me, I was pretty familiar with my company and product group's vision, and I understood how to motivate my engineering team. Where I needed to spend time was building up my knowledge of our customers and competitiors before writing my team's product vision. Here are a few questions I wanted to answer: * What kind of persona research already exists for Confluence? * What's the difference between a creator, collaborator, and content consumer? * What problems do creators face in Confluence today? * When do creators publish their first page in Confluence? * What % of creators are repeat creators? * How do people create in other tools? * Why do some Confluence users choose to create in competitive tools? Great product vision statements ladder up to your organization's vision, focus on the customer, highlight how your product is different from others on the market, and motivate your team to rally around a shared vision as you collectively try to solve big-hairy problems together.

Product visions should always be customer-focused. I'm not sure that you need to actually show your vision statement to users to get their feedback, but your vision should be informed by the user problems and product goals that your team hopes to solve over the next few years. In order to do that, you need to know your users intimately, and that often requires customer research and reviewing product data. 

Great product visions rally a team around a set of clear and concise goals. That vision represents the team's focus and can be a helpful tool when the team needs to make a decision or is starting to be misaligned. In college, I had a marketing professor who was known by a simple tagline: "Lose your focus. Lose your shirt." No matter how much experience you have building products, it's so easy to get distracted and start to solving problems without proper validation. As Product Managers, it's our job to make sure our teams stay focused on the problems we are trying to solve. I've found that referencing our produt vision is a helpful tool when I've needed to refocus my team when we get off track or need to make a tough decision. I recently led a project where we tried to help users feel confident that their work was automatically saved in Confluence. We had found that creators often used "publish" to save their work, so we set out to give users a dynamic, visual confirmation that work was being saved automatically. As a team, we had to make some tough tradeoffs between user experience and performance. I often reminded our team that our goal was to increase confidence while users created content in Confluence, and all of our decisions needed to help push that vision forward. It helped create a common language for the team as we weighed different options. 

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.

I think the biggest difference between crafting software vs. hybrid product vision statements comes down to scale. It's much faster to build, test, and learn with software product than products that touch hardware. With software, you can scale your product and customer base very quickly, whereas, hardware can take months, or even years to iterate and drive value. Over the course of my career, I've worked on mobile, web, and hybrid (mobile + hardware) products. A few years ago, I worked at Hudl Sports where I led product for Hudl Replay -- a video analysis tool for professional sports teams. The core product was an ipad app, but we were dependent on stadiums having accessible networking infrastructure to create a wired connection between our app and the IP cameras placed around the stadium, otherwise we had to creatively combine 3rd party hardware to establish a wireless connection. Since our customers traveled between cities, countries, and even continents, it was important for teams teams to have a reliable wirless network so that they could use Replay. Hudl Replay's product vision: Our goal is to help teams make data-driven decisions quickly with real-time analysis and instant replay. While the vision statement doesn't specifically mention time or scale, these were major considerations when crafting our goals. Product visions need to be aspirational, but they also need to be achievable. The software side of Hudl Replay made "helping teams make data-driven decisions" achievable given how quickly we could iterate on how our users interacted and worked with video data through our app. But, "real-time analysis and instant replay" was much more aspirational because we were entirely dependent on advancements in hardware. This goal was a much more long-term vision and would take longer to achieve. To make meaningful progress on this goal, we had to either build our own hardware or continue to rely on stringing together 3rd party hardware. Both paths were slow and expensive, but our team was excited about the problem and rallied together to find solutions together.