Case Study: How to Develop Your Product Vision Collaboratively (Part 1)

​Dear Reader,​

This is the first part of a multi-post series on the real-life journey of a product team on re-vitalizing their Product Vision collaboratively.

Product vision isn't a technical deliverable — it's an emotional statement that focuses your team and clarifies your work. Which makes how you approach its creation almost as important as the artifact itself. In this article, I'll show you how to collaboratively approach creating product vision in real life so team members feel the intent behind it instead of just reading the words.

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.

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 on 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.

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.

In next week's newsletter, I will share the next part of Victoria team's journey.

Thank you for Practicing Product,

​Tim​

If you consume one thing this week, make it this...

Who is Tim Herbig?

As a Product Management Coach, I guide Product Teams to measure the real progress of their evidence-informed decisions.

I focus on better practices to connect the dots of Product Strategy, Product OKRs, and Product Discovery.