Product Manager’s Tool: A Vision-Setting Exercise for the Team

Concrete steps and examples to define a vision with your team in 4 hours and common pitfalls to avoid.

Before we begin

It is essential to realize that this is not yet another “Become CEO in 5 mins” template, nor is it something a product manager can do themselves and then “present” the answer to the team. In contrast, this exercise is only valid when you and your team spend 3–4 hours debating on it, and interestingly enough, that conversation is more important than the final vision statement. Let’s get started!

Preparation

First things first. As a product manager, you should organize a room with a large screen (in case you like Google Docs, Miro, etc.) or a whiteboard and prepare the empty table with the three columns described below. Explain to the team that you aim to fill in the table step by step and end up with the vision/mission sentence — a concentrated statement of value you bring to the company. There is no right or wrong answer to this exercise — whatever the team decides as a vision becomes a vision. Then, history will tell whether this was the right one.

Step 1: “Who are our customers?”

The exercise starts with a brainstorming session: “Who are our customers?” Are they end users? Go deeper: Are they teenagers, moms, or families? Are they drivers or office workers? Be critical and avoid generic “customers” unless you are building something as huge as Google (which you probably are not).

An example from the B2C world is that you own a catering product for families. Your customers are not every person in the world but a specific segment: people with and without kids, couples, or multiple generations dining together.

If you have an internal or B2B product (e.g., a platform), your customers are internal clients, such as the marketing department, payment teams, and UI teams. Or maybe even all the company's developers.

Spend 20 minutes on this part and ensure everyone has a chance to voice their opinion. The list should include 3 to 7 categories; otherwise, you haven’t put in enough effort.

Step 2: “What are their problems?”

The second stage answers, “What problems do our customers have that we, at least theoretically, can solve?” For example, the payments platform team within BikeShop might brainstorm that end users complain about slow payments. At the same time, internal customers mention that the API frequently throws errors and there’s no documentation. So, you write down such problems in the second column. Sometimes, different clients can have similar issues— even better, this means that problems are identified well and they indeed exist.

Since brainstorming time is valuable, irrelevant ideas like “limited selection of mountain bikes” should be dismissed. Notice that this is a very relevant problem for the CEO of BikeShop or a BikeShop supply team but entirely irrelevant for the BikeShop payments team because they can not control the product selection. A PM must catch problems outside of the team scope and get an aligned agreement with the room that this is “not for us to solve.”

Note that as a PM, you are not just a facilitator. Instead, you already spent 2–3 weeks to come to this meeting fully prepared, having surveyed customers and knowing exactly what they needed. So 70% (!) of Step 2 is about “working through” the pre-identified “answers” with the team so that everyone understands and (importantly!) accepts them. The remaining 30% is the magic part — requirements the team comes up with that customers don’t even know they need yet, but once you present them, they’ll want them immediately.

For instance, no one is likely to ask the Instagram image team to add a new compression algorithm based on the internal structure of the eyeball. Still, when the team implements it and speeds up photo display by 1.5 times, customers will be lining up to migrate. This is an example of when the internal team expertise produces innovation before it becomes something clients can consider. Use this magic wisely!

Step 3: “What can we do about it?”

The third stage of the exercise answers the question: “What products/features can we realistically build to solve these user problems?” Again, everyone brainstorms. The PM’s job is not to shoot down bold or slightly crazy ideas (remember that trains, electricity, the internet, and other cool things were initially considered nonsense that no one ever used widely) and not to get bogged down in details.

For example, for a marketing team, this stage might bring up ideas like “a new email platform,” “a flexible template system,” “smart content error checks,” “a recommendation system,” and so on—something concrete but still big enough to spend quarters and years building.

Step 4: The Final Statement

Finally, the last stage is to combine all this into a concise proposal: “We help customers A (output of step 1) solve problems B (step 2) through C (step 3).”

This, of course, isn’t a distilled vision but rather a mix of vision (why) and mission (how we get there). But let’s leave that to the theorists — for practical purposes, it’s a win. You’ve just worked through about 10+30+30 ideas, selected roughly 3+5+5, formulated a sound summary, and effectively cemented them in the minds of the leader and all team members.

Common pitfalls: what can go wrong?

• As mentioned above, a PM is not a mere facilitator, but a person who did the most pre-work and knows what their customers really need. Otherwise the exercise turns into guessing, dreaming and attendees quickly lose trust that this is useful.
• The product manager’s task is to ensure that every team member participates. Politely nudge those who stay silent and make them speak; otherwise, you can deal with their potential internal disagreement for the next few years, and this can harm team velocity more than any bugs, new technologies, and so on.
• A common beginner’s mistake at the last stage is to leave the room without making decisions. For example, a team ended up with 50–70 ideas instead of 5–10, leaving the room without the final summary statement. This renders the exercise useless because, in a week, the details will be forgotten (this is how our brain works), and the direction will remain unclear. Therefore, the product manager’s job is to be flexible yet firm at every stage of the brainstorming, recording key thoughts, cutting off “rabbit hole discussions,” and ensuring that the key decisions (clients, problems, main features, vision formula) are agreed upon. And yes, dear PM, you’ll feel exhausted by the end of the exercise.
• The last mistake is coming up with an overblown vision, which is too big for a team in terms of resources and talent. For example, if a team of 5 engineers decides to compete with Google in the search field, or a team of 3 tries to rebuild the music streaming industry in 3 months, you can be sure this is too much. The PM’s art (not a science!) is to consider constantly: “Can we aim for that, or is it too much?” Remember that a good vision is hard (very hard) but still possible to achieve.

What’s next?

Post the resulting phrase somewhere (a wall, team page, main document), repeat it periodically to yourself and the customers (until everyone memorizes it, which means about 10–20 times), check quarterly goals against the vision as a compass, and in a year — update it.

If you want to practice defining this and other planning horizons yourself, check out a practical PM simulation “Planning and OKRs”. It includes around 50+ exercises and will help you to become much more confident with your main team structure: short (sprints), medium (OKRs), and long-term planning (vision/mission). Reading is good, but actual practice is better ;)