When Victoria Ponomareva, a Product Manager at the Sustainability Scale-up EcoVadis, felt it was important to re-energize her product team, their product vision was at the top of her list. As she worked with a newly formed team, many people were now working on a more internal-facing product, and she wanted to avoid getting dragged into the day-to-day business of stakeholder requests and roadmap priorities too soon.
But carving out this time would require a dedication to product vision that isn’t always a given for internal and platform teams. By making a conscious decision to use the practices that make product vision work for customer-facing teams internally, Victoria was able to inspire their team’s efforts for the future.
I’ll use the journey of Victoria’s team as inspiration for your efforts to arrive at a product vision that extends beyond your product’s functionality. In working with dozens of companies, I have seen how the lessons from her journey apply to product teams, regardless of industry, company size, or whether they serve internal or external customers. And I’m confident that you will find that as well.
What Your Product Vision Needs To Do for Your Team
Your OKRs make progress objectively measurable. Your Discovery insights prompt clear decisions. But your Product Vision aims to provoke a genuine emotional response – not an objective one –from your team members.
When sharing drafts for a vision statement, don’t compare it to a blueprint or a textbook definition. Watch the room for expressions or sounds of resonance. That’s when you know you’ve found something. You cannot engineer genuine reactions from a template or AI prompt. It has to come from the people who will live and work by it.
In Victoria’s case, it’s worth noting that platform and backend team members, especially engineers, tend to be more pragmatic than most and will push back on anything that feels fluffy.
“A vision statement needs to elicit an emotional reaction from the team.”
But the emotional bar isn’t lowered because your product is infrastructure — if anything, it matters more, because the customer can seem further away,
Who Are You Envisioning For?
There’s one simple ingredient that prevents the conversation about your product vision from slipping into product requirements: centering what change you want to create for your target audience.
The more technical your product is, the more tempting it becomes to focus on features and services in your Product Vision rather than centering on your users’ behavior changes. In b2c, this error might look like getting lost in functionality details rather than having your vision directly address your target audience.
“When you’re building platform services, it’s easy to lose sight of who the actual beneficiary is. A product vision is how you bring your users back into focus.”
Victoria utilized three practices to trace through to the person whose working life her team’s product ultimately affected in order to avoid this pitfall.
1: Name the user explicitly before you do anything else. Not the service that consumes your API, not the team that depends on your data pipeline. The actual person. In Victoria’s case, that was the procurement professional sitting at their desk, navigating a global supplier network. Getting that name and role agreed on before the workshop begins prevents the conversation from drifting back to technical dependencies the moment things get abstract.
2: Once you know who you’re envisioning for, make them present in the room. Victoria did this by extracting key pain points and quotes from what she calls her team’s “feedback river” — the ongoing stream of customer feedback her product area had accumulated. Bringing those quotes into the workshop gave her engineering team something concrete to react to. Not a persona template or a user archetype, the actual words from the actual human they were building for. For platform teams, especially, this step closes the distance between the team and the end user that the architecture normally creates.
3: With the user named and their voice in the room, use the future-state empathy map to structure the conversation. Rather than mapping where the user is today, Victoria’s team used it to describe where they wanted to take them — channeling everything they knew about the user into a concrete picture of the future they were working toward. That picture becomes the raw material the workshop produces, and the foundation a smaller group can synthesize afterward.
Where to Collaborate Broadly
Inspiring everyone does not mean your vision needs to be decided by committee, and everyone needs to be pleased.
For Victoria, walking this line meant inviting contributions from the full team during an in-person team retreat, but creating a smaller core group that would prepare and drive the workshop, as well as take on the responsibility of synthesizing.
“The benefit is that it keeps the work manageable – you avoid decision by committee, but you don’t lose the collaboration. It’s about having a shared goal, shared context, and brainstorming together.”
The workshop included 18 people, split into four groups, with a total of half a day of working time, including sharing and discussion. For a potentially less tangible topic like Product Vision, it’s helpful to let teams work through a structured output format to channel free-flowing discussions.
Utilizing the Future-State Empathy Map
Adapting a proven user research tool, such as the Empathy Map, to be forward-facing – i.e., imagining future user states rather than documenting current ones gave Victoria’s team a structured way into vision work, which can otherwise feel less productive than shipping features or fixing bugs.
The goal was to use the four quadrants for describing where your user will be, not where they are:
- Which pains will be gone
- Which gains get unlocked
- What they will observe
- What they can now do effortlessly
While tools can be extremely useful, how you approach them with your team dictates their success.
For the logistics of working with an Empathy Map, you will need to rely on your Product Manager. It’s their job to make it time-boxed, grounded in real user insights, and oriented toward tangible outcomes, taking it beyond being a beautiful phrase. This can go a long way in addressing the skepticism that is natural on any newly formed team.
As Victoria puts it, the workshop shapes direction through the quality of brainstorming, the themes that emerge, and the energy in the room. It just does not produce the final statement yet, it’s where the thinking happens.
Where to Drive Decisions in a Smaller Circle
After the workshop, the full team’s input is synthesized by the smaller core group — typically the PM and one or two peers. Their job is to aggregate the empathy maps, group ideas into clusters, and extract the value themes that surface most strongly.
Victoria’s themes from this synthesis were concrete and distinct:
- Complete data trust
- Zero-touch automation
- User empowerment
Each one pointed to a different dimension of the change they wanted to create for procurement managers. Invest in creating this specificity from the broader group work. Because vague themes will produce vague vision statements, which, in turn, will not carry power.
Investing in Creating a Vision Story Before a Statement
Before drafting a single vision statement, Victoria wrote a one-page story. It follows a fictional procurement manager arriving at work with a goal, and shows how they achieve it now compared to how they used to.
The before-and-after is the point. A brief story can capture and communicate that transformation much more easily than a concise statement or the Future-State Empathy map. It forces you to articulate three things in one move:
- who the user is,
- what their reality was, and
- what is genuinely different now because of what your product does.
This is worth the investment before writing any statement. A story you can’t tell compellingly is a sign the vision isn’t sharp enough yet. A story that lands gives you the raw material to distill from.
“I am deeply convinced that any good story is a story of a change, and a vision story is no exception. A good vision reflects a change that you want to bring into your users’ lives. And it doesn’t have to be big and dramatic.”
Scenario Testing Your Vision
From the story that followed the workshop collaboration, Victoria drafted four short statement options — each emphasizing a different value theme. One focused on trust in the data, one on effortless scalability, one on enabling data-driven decisions. Then she brought them back to the team alongside two or three real decisions the team could face. The goal was to test which of these would be the most helpful for the team.
Each breakout group took one scenario and ran it through each vision statement as a decision lens: which statement actually helps you make what decision? A clear frontrunner emerged from the groups’ feedback. The wording was refined based on the team’s reactions in the discussion and the friction of a real decision; one statement felt more inspiring than the others.
Don’t skip the story and go straight to drafting vision statements. Without it, you lose clarity on who your user is and what change you’re actually creating for them — and without that, you have no real basis for deciding which opportunities are worth pursuing.
After working through the workshop, the synthesis, the vision story, and the scenario testing, Victoria’s team arrived at something most platform teams never stop to create: a shared statement they had genuinely stress-tested together, and that had already proven it could guide a real decision.
That’s what makes the remaining work possible. Circulating a vision people helped shape is a different conversation than asking colleagues to align behind something handed down to them. And reaching for it in daily decisions is easier when the team has already seen it work.
Finding the Momentum to Revisit Your Product Vision
There is rarely a perfect moment to work on your product vision. But there are some clear triggers for initiating that work.
The clearest ones are structural:
A team reorganization, a strategic pivot, an acquisition, or new ownership of a product area. Any of these creates a natural break, where the old pillars no longer hold, and the team needs a new shared direction.
Victoria’s trigger was exactly this. Her team had been reorganized around a backend service, with members arriving from across the company. Nobody had full ownership yet. Working on the vision wasn’t a nice-to-have — it was the most direct path to the team actually becoming a team.
The subtler trigger is harder to name but just as important: when your team can no longer clearly articulate who they are building for, or why the work they’re doing matters beyond the next sprint.
Two pitfalls are worth paying attention to. The first is waiting for conditions to be perfect. Vision work is important but rarely urgent, which means it will always lose to operational demands unless the PM treats it with deliberate momentum. Not because the deadline is real, but because without that energy, the effort will lose its drive.
Victoria captures this tension better than most:
“The conditions will never be perfect. You need to light a spark and let it spread. Action creates more clarity than overthinking ever will.”
The second pitfall is initiating this work because you found a compelling framework online. This is more of a distraction than a real trigger. The impulse to revisit your vision should come from your product context, not from someone else’s process looking appealing.
Making Product Vision Stick as a Living Tool
A product vision that lives in a document and gets referenced once at an all-hands can’t serve the job you hired it for. The work of making it stick starts once the team has gotten behind that synthesized statement.
The first step is circulation and sharing it beyond the immediate team. The vision is most powerful when the people around your team understand it well enough to reinforce it, reference it, and hold you to it. Victoria describes this as building internal champions for the change you want to create. That means sharing it with adjacent teams, stakeholders, and anyone whose work intersects with yours.
The second step is integrating it into the rhythm of daily work. Your product vision should be present when your team reviews progress, discusses opportunities, or demos work in progress. Not as a replacement for more tactical tools like OKRs, but for moments of decision-making around fundamental directions. This is where the scenario testing pays off in the long run. A team that has already stress-tested its vision against real decisions has an idea of the trade-offs they are able and willing to make.
For platform teams especially, this presence matters. As Victoria puts it: ‘the vision is most powerful when it’s shared.’ For platform teams especially, that means sharing it with people who will never see the architecture — but whose decisions your work ultimately shapes. Which is the aspect that a more backend-service-focused team can relate to to remind them there is a real person at the end of the chain, even when the architecture makes that person invisible.
Victoria frames it not as a destination but as a starting point:
“I see our work within the squad as a journey and setting the vision for a specific service was a good start of this journey together.”
As Victoria’s experience shows, when a product vision is created collaboratively, grounded in real user insight, tested against real decisions, and shared beyond the team that made it, it creates something no template or prompt can replicate: It makes people feel something about the work they’re doing. And that’s what makes it worth reaching for.