Skip to main content

10 Tips for Product Owners on the Product Vision

November 29, 2017

Product Vision
Before we dive into some tips on the Product vision, let's provide a little context first! The Product Owner is the one person in Scrum who is responsible for the success of the Product. Therefore, the Product Owner creates, manages, and owns the Product vision. The Product vision describes the purpose of a Product, the intention with which the Product is being created, and what it aims to achieve for customers and users. The Product vision describes a future state of the Product and what problems it tries to resolve or what ambitions it tries to fulfill.

Having a clear and inspiring Product vision helps in motivating and inspiring people, like the Scrum Team, the stakeholders and customers, and users. It also provides a common understanding of the direction we want to move towards. Besides that, the Product vision also supports the Product Owner in making choices about what to build and what not to build for the Product.

All in all, it's pretty damn important to have a Product vision, so in this blog, we'll cover 10 tips about the Product vision. Also, check out my other blogs with tips for the Product Owner (see the links at the end of this blogpost). I hope you enjoy them!

10 Tips for your Product vision:

1. Be(come) the owner of the Product vision
In my humble opinion, this is by far the most important tip we can share with you. We have met, coached, and trained many, many, many Product Owners and the most successful Product Owners we've met were really passionate about their own Product Vision. We've also met a lot of Product Owners who didn't own the vision, but who were mainly executing the product roadmap, based upon someone else's vision. This makes the job harder, not impossible, but a lot harder. This is mainly because as a Product Owner, you should be motivated by the vision, your heart should start beating faster about it, you should be passionate about the vision and you have to share it, very very often. Product Owners that own the vision and are passionate about it, are typically more successful.

2. Share your Product vision, often
Your job as a Product Owner includes sharing the Product Vision. And sharing the vision again. And again. And again. It is soooo important for people to know why you're doing the things you do. It helps the Developers in making technical choices about architecture for example. It helps the stakeholders in understanding what would be valuable for the product. It helps users to understand why they should use and/or buy your product. The Product Vision is just so damn important!

3. Don't believe your idea is the best idea ever
Being passionate about your Product is awesome! There is one downside to passion, however. We've met quite a few Product Owners who were so much in love with their own Product, that they forgot that they weren't developing the Product for themselves, but for their customers and users. So don't fall into this trap. I'm sure your product idea(s) are awesome, but keep in mind that you're building the Product for someone else. To put it differently, don't think your idea is the best idea ever. Make sure that you validate your vision with stakeholders, the market, users, etc., etc. And release the Product early and often, to get feedback from the users.

4. Develop your vision iteratively and incrementally
Developing an awesome Product Vision is rather complex. It's not predictable, nor easy, nor something you do 'first time right'. It's also not something you should do on your own. So in order to develop the Product vision, collaborate with your stakeholders, Scrum Team, customers, and users! Also, don't try to get it right the first time! Take a couple of iterations to improve your vision. Make it better over time!

5. Adapt your vision as you're learning
Another important tip we would like to share is: 'Don't be afraid to pivot!'. Some of the most successful Products (of recent years) like Facebook, Post-it and Netflix started out with a totally different purpose (vision) in mind. Only because the original purpose failed and the companies adapted their vision, they have now become some of the most successful companies of our time. So don't be afraid to change direction! As you're learning from customers and users, adopt their feedback, and embrace that changing your vision might just be a great idea!

6. Adapt your vision pitch, based upon your target audience
Since you are sharing your vision so often, with many different types of audiences, you should make a tailor-made pitch for your different stakeholder groups! In your pitch, make sure to address the things that are important for them. For some stakeholders, you mainly need to report about the KPI's that are relevant to them. For other stakeholders, you need to be the inspiring (Product) leader, who is representing the Product. And for another group, you may need to focus more on the benefits of the Product for them. So tailor your pitch to your audience!

7. Focus on value for customers and users, not on technology
A good vision is inspiring, motivating, and inviting. An inspiring vision often isn't built around technology or features (there are exceptions of course). It's about resolving a problem or about achieving a dream. So don't make your Product vision (too) technical, focus it around the business (value).

8. Keep your vision short, clear, and inspiring
A good vision is inspiring for people. It's a description of a dream, of a state to become. It's a dot on the horizon that you're working towards. It's also stretching for people. On the other side, a vision statement should also be short and clear for people. By short and clear we don't mean short term. It should be a dream for the long term, but people also need to be able to understand the vision, so it should offer clarity. A nice way to start with your vision statement is by using the vision statement template (see below). Beware: it's just an example to get you started, you don't have to force your vision into this template!

Vision Statement Template

9. Make the vision fit in the companies vision and strategy
This tip may be an open door for many of you, however, the Product Vision should fit within the company vision and company strategy. The other way around also counts. Once you've learned new stuff when building your Product and you've learned that the company strategy might need a pivot, don't hesitate to collaborate with your stakeholders to find out whether or not the company strategy might need to change. To put it short, make sure that you're aligned with the company's purpose and strategy.

10. Validate your vision with stakeholders, the Scrum Team and market
The last tip on the subject of Product Vision is to collaborate on your Product vision with your stakeholders, the Scrum Team, and customer/users from the marketplace. All have interesting insights and valuable input to share with you. They can challenge and support you to make your vision clearer, more ambitious or actually more tangible and clear. Use the knowledge, experience, and insights of your environment to create and validate your Product vision.

So, these are the 10 tips for Product Owners on the topic of Product vision! I hope you enjoyed them and that they'll help you in becoming a better Product Owner!

Also, check out these other tips for Product Owners!
Holy Guacamoly! Are there even more tips for Product Owners? Yes, there are! We've described 60 more tips for Product Owners, to help you to become better in your role! We've defined 7 aspects of Product Ownership on which we have interesting tips to share with you, so check them out:

  1. Agile Product Management
  2. (Product) Vision
  3. Value
  4. Stakeholder Management
  5. Scrum Framework
  6. Product Backlog Management
  7. Release Planning

What did you think about this post?

Comments (14)


Alan Larimer
10:14 pm December 1, 2017

"The Product Owner is the one person in Scrum who is responsible for the success of the Product." Citation needed. This exemplifies traditional business management paradigm.


TruongSinh Tran-N.
01:25 pm December 8, 2017

"accountable" could be more appropriate, as we promote self-organizing and collective responsibility, but accountability remains with PO.


Alan Larimer
07:25 pm December 24, 2017

Once again, citation needed. Promote the the team mentality with shared ownership.
"Everyone focuses on the work of the Sprint and the goals of the Scrum Team."


TruongSinh Tran-N.
05:41 pm December 25, 2017

Think incrementally and iteratively rather than "the book says". Actually, I could just "cite" this article (I assume the author is a PST), but if we take a look at the ScrumGuide "The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team". He/she must have a guesstimate of values of each PBI, and then validate those guesstimate (by releasing), thus ultimately accountable the success of the Product. Imagine the PO wrongly identified high values items, but, but SM and Dev team worked perfectly, all goals and scopes, DoD met; Scrum team produces lots of usable but NOT USEFUL functionalities, and eventually leads to the failure of the product.

Not that I am narrow-minded otherwise, but I would love to have the conversation based on critical thinking, rather than citation and "the book says", because remember, ScrumGuide itself has been revised more than once based on interactive and incremental development from community feedback with critical thinking.


Alan Larimer
08:01 pm December 29, 2017

"The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team" != "The Product Owner is the one person in Scrum who is responsible for the success of the Product."


TruongSinh Tran-N.
10:34 pm December 29, 2017

Could you explain and/or give examples why you think they are not equivalent? Or did you mean literally "string comparison", the 2 strings above is different in any compiled/interpreted programming language? Believe me, I am open-minded, and want to be convinced otherwise; in other words I am NOT the type who "nothing can change my faith".

Nevertheless, I wanted to share "burden of proof" why I think the 2 "quotes" are equivalent, thus I already gave the example above

<<<
Imagine the PO wrongly identified high values items, but, SM and Dev team worked perfectly, all goals and scopes, DoD met; Scrum team produces lots of usable but NOT USEFUL functionalities, and eventually leads to the failure of the product.
>>>

In other words, development team perfectly execute a flawed plan. Do you agree/disagree with the above thought experiment and its consequence? Could anybody else in the Scrum team (Scrum Master, Development Team Member, or even outside Scrum team stakeholders) do anything else to avoid product failure?


Alan Larimer
05:30 pm January 3, 2018

Your own argument is a counter. "Imagine the PO wrongly identified high values items" means that was the issue in that single case; your argument includes the conclusion. Even if the "SM and Dev team worked perfectly, all goals and scopes, DoD met" that excludes the possibility of an external factor: change in technology available, company downsizing, massive market shift, capital shortfall, etc. Why would that fall upon the Product Owner? That's not a thought experiment, but a cherry-picked, sharpshooter, circular scenario.

No specific case translates into the broad statement that "The Product Owner
is the one person in Scrum who is responsible for the success of the
Product." There are too many factors that could affect the success of a product.

This "one person responsible" thinking is the type of traditional, command-and-control, hierarchical, dysfunctional attitude and behavior that the team mentality in the Scrum framework and agile philosophy have been attempting to remedy. Success requires that "Everyone focuses on the work of the Sprint and the goals of the Scrum Team."


doctor van nostrand
07:56 pm July 15, 2019

agreed. reading this article for the first time, right off the bat I thought to myself "whoa, whoa, whoa... wait a minute..."


Tom
06:57 am August 15, 2019

Well received
If I have the opportunity, I will gain more from participating in your course.


TreeFiddy
06:43 pm September 7, 2019

Scrum was designed as a software development project management framework by a couple of software engineers/project managers. This article seems to be trying to morph Scrum into a broader Product Management framework. They are not the same.


Aleksandar Dimitrijević
09:36 am September 24, 2019

Thanks for sharing this article!

In the time when a lot of startups and young/early-stage companies fail because the Product Vision is not clearly defined, aligned with other stakeholders and not appropriately set to remind everyone of it, Scrum.org team really knows how to bring the value and mark why it's important to have the Product Vision defined and set the right way.

Also: IMO, the main focus should be the desires and needs of the end user. Then, come the critical questions like WHY and HOW (are we building this product).

Our team (working on a SaaS tool) found this problem very serious (because of our previous experience) which is why we wanted to pay a lot of attention to helping people get the right knowledge.

So if anyone feels like they could continue the read, here's our article: https://startinfinity.com/p...

Cheers.


Fredrik Wendt
06:42 am June 16, 2020

A bit late to the party, but I just want to "agree" with some of the points above. Which and why?
* the PO role reeks of hierarchical thinking, and in those environments it may help bring agility to decision making, move mandate closer to the team instead of being distributed in the org, ...
* the PO role can be seen as a pattern from Sociocracy 3.0 where the org has chosen to create/develop such a role - fully "Teal-compliant"
* the PO role provides a focus, one of the key ideas/values of Scrum - being able to focus (ie say "No" to things, means the things you say "Yes" to gets more attention)

Is Scrum a silver bullet, universally applicable and always "best in show" or a "best practice"? Is any solution ever universally awesome?
I'd recommend trying not to question Scrum for its superiority and flawlessness, because it just aint.


Saurabh Sharma
03:59 am December 20, 2020

Agree "accountable" is a better choice of word here. But remember product owner is in a way CEO of the product who, irrespective of his (her) own expertise, should take accountability of the product success or failure.
And by the way, failure is NOT such a bad thing afterall, it's an opportunity to learn. As long as failure lead to learning and product owner was able to "pivot" and lead the team/organization to path of success, it's worth it.
Accountability, in either case, is PO's just like the CEO of a company/organization!
It's a BIG role afterall!


Alan Larimer
12:06 am September 6, 2022

I only addressed one of the issues in his argument. Logic presented, yet neither Tra-N nor his upvoters present a counter to my arguments. I would have enjoyed a discussion, however this is the common result. The so-called expert such as Mike Cohn and Glen Alleman have also done so and blocked me from commenting on their work. One of the many reasons that I had to depart the software development world.