Working without a product vision is not sustainable

Product vision can be a powerful thing. It tells a story of what’s possible and pulls people toward that change. A lack of vision can be insidious. At its best, it leads to missed potential. At its worst, it can lead to unmotivated, burned-out teams and a disjointed product that fails to deliver customer value.

Your product may have started out with a clear vision. The story of what you were doing and why mobilized the team to build a strong MVP. Afterward, your team set out to deliver against a long list of “fast follows,” like adding features cut from the MVP or fixes for problems uncovered post-launch. Over time, the pressure to deliver grew, and the connection between the daily work and the product vision faded. 

Now, it feels like the product roadmap is ever-changing. Teams may find themselves dropping everything to chase after customer requests. They don’t feel empowered to make decisions on their own. The delivery treadmill has shifted your product team into backlog administrators. They spend most quarters trying to catch up on initiatives not completed from previous quarters, bracing for a pivot in priorities. This reactive focus on delivery keeps the team busy but doesn’t move them or the product in a meaningful direction.

If you are in this situation, you are not alone. We’ve worked with many teams who got to this point through good intentions and found it challenging to address the problem. Perhaps your organization fears creating a new product vision will take too long to create, go nowhere, or take your team’s time and energy away from delivery. We’ll show you how to get off the treadmill, regain your footing, and empower your team. 

 

Visualizing your future, one initiative at a time  

At Lab Zero, we believe a shared vision empowers teams. When team members know what problem they are solving and why, they can independently make choices that further their common goals. When a team is involved in visualizing the future, the process builds confidence and fosters collaboration. 

To help organizations integrate visualizing the future into their process, we’ve learned we have to start with a small effort to build trust. Most organizations have an initiative, or challenge they want to address, on their roadmap or in their backlog. Our process involves exploring what the future of that initiative might be rather than taking on the whole product vision all at once. Our goal is to imagine possibilities as a cross-functional team and tell the story of what value those possibilities might bring to our customers. 

This process starts with a few constraints and principles:

• Limit scope  - We limit the scope and context of our exploration so the work can be done quickly. Rather than creating an all-encompassing product vision, we will start by visualizing a goal, initiative, or contained slice of the customer experience. 

• Work collaboratively and socialize everything - Cross-functional teamwork strengthens our ideas, fosters a sense of ownership, and reduces risk. This helps ensure the vision is well-informed and our learnings don’t get stuck in a silo. No one person should have to carry the weight of the entire process. We typically staff our visualization team with someone from product, design, and engineering to make sure multiple points of view are represented. We share what we’ve learned early and often. 

• Timebox your efforts - We estimate how long it will take to understand the problem, develop potential solutions, and validate them. This can be challenging at first. Setting up time to talk to stakeholders, subject matter experts, and customers can take longer than one might expect. Depending on the experience of the team and the complexity of the problem, the team can work through the process in a few weeks. For complex problems, we try to limit the process to a quarter. Your timebox does not have to be rigid, but the team should attempt to adhere to it so that we can move fast. If the process is taking significantly more time than expected, we’ll want to cut scope or limit exploration in order to wrap quickly.

• Understand the big picture quickly - We believe the best solutions come from understanding the high-level view of customer needs, workflows, and the product ecosystem. We admit getting that big picture doesn’t sound like a “small” task, but it is possible to step back and focus on how the pieces of this puzzle relate to each other without having to go into every detail. Be strategic about where to focus your energy. 

• Focus on value to the customer - A feature is not inherently valuable. Value comes from whether or not that feature or the experience it’s a part of solves a problem for our customers. We want to keep customer value in mind while exploring solutions and prioritizing our efforts. 

• Imagine doing more with less - Part of this process is to imagine what an ideal solution could be. At the same time, we have the opportunity to imagine the smallest effort needed to deliver similar value to customers even faster. It might take 6 months to deliver an ideal solution, but what might our solution look like if we had to get it in front of customers tomorrow? Make space to think about opportunities to solve a problem without code.

• Just enough is better than perfect - Through this process, we create a “gesture” that describes what a product or service that solves the customer problem *could* be. We’re aiming for a sketch of a compelling story centered on the value our future state provides the user over build-ready designs that cover every edge case. Our goal is to have something we can share with stakeholders, partners, and customers to learn from. It doesn’t have to be perfect to generate alignment and excitement.

 

A structured but flexible process

Without structure, teams can find it hard to focus. Too much structure can be constraining. It can be hard for teams to respond to diverse problems and needs. 

Our process is made of 4 main themes. If these themes sound familiar, they are based on the standard design and discovery process, revised to emphasize speed and collaboration. For more information on how we’ve tailored our process and tools to support a lightweight vision mindset, check out our guide: Visualizing the Future of Product Initiatives as a Cross-functional Team.

1. Understand the problem and the context - We work to understand and gather information needed to explore ideas. Our goals are to understand the customer needs this work must address and identify who we will partner with to make informed recommendations. This work will help us understand the story of the experience today and get an idea of the most critical parts of their journey that we’ll want to explore.

2. Explore possibilities - We imagine potential solutions around the most critical parts of the customer experience. We aim to envision possible future states, big or small, that are valuable to our customers. Keep in mind these ideas are more like a date than a wedding. We’re here to learn and inspire, not commit to building something. 

3. Validate our recommendations - We test potential solutions with customers to confirm our hypotheses around what’s valuable and usable. Look for opportunities to push ideas further based on what we’ve learned. What might be more valuable to users? What might be more minimal to build? Find opportunities at every stage of work to test ideas, even if it's with an internal team member who can serve as a well-informed customer proxy. 

4. Share the story - Socializing the visualization is a critical part of the process. If a vision happens in a vacuum, it will never get turned into action. Tell the story to leadership, stakeholders, and teams. Below is an example summary created in Figjam. Packing the story up into an easily digestible summary is key. Set expectations for next steps so stakeholders can see how this process translates into value for customers and the organization.

Next Steps

An important next step is to look closer at our ideas around the smallest value increment. What would it take for us to connect a customer with that value tomorrow? Can it be done manually instead of through software? For example, could we email this information weekly or experiment with a small operational change? This emphasis on getting value to customers without building software is one of the ways our visualization process differs from the standard MVP discovery process.

From there, the team should collaborate to determine what to build, when, and what we still need to learn. We expect that product will drive prioritization, and design & engineering will partner on any spikes needed to prepare the ideas for delivery. Remember, the goal of our visualization process was not to create a ready-to-build design, so there will be work to do to translate the vision into an increment the team will deliver on. 

 

Signals of success

Once we transition to delivering on the first increment of our initiative, there are signals we look out for to help us know if our visualization work is making an impact

• The team refers back to the visualization - Listen for it to come up in conversations and working sessions or look for traffic to the documents in Figma or Confluence’s analytics. People will refer to the vision if it is valuable and well-socialized. 

• Customer perception of product value increased - Prioritize measuring the outcomes of each increment with customers. This will not only help us make sure we’re working on the right problems but also help us gauge the effectiveness of our increments.   

• The team perceives the visualization as valuable - Engage the team the same way you would a customer. Ask for their feedback on the process. What went smoothly? What didn’t? These conversations help us tailor the process to our team’s needs.  

If we’re not hearing these signals or see a decline in usage or perception, it may be time to revisit or retire this visualization. While we want visualizations to be something the team can come back to in the future, not all visualizations are meant to be long-lived. Moving on in response to learning something new or having solved the problem is to be expected. Repeating this process with a new initiative gives your team a chance to refine their visualization skills.  

 

Learn more 

For a more in-depth look at the process, how we select candidates for visualization work, and how we build out cross-functional visualization teams: check out our guide, Visualizing the Future of Product Initiatives as a Cross-functional Team, for step-by-step instructions. 

Or check out Tracey's talk at the Bay Area Agile Leadership Network.

 

We want to hear from you

Have you tried this process or something similar at your organization? We want to hear what worked well and what could have gone better. 

 

Photo by Hal Gatewood on Unsplash