Does your team have an overarching goal for its work—a product vision? Too many teams do not.
The whole point of a project is to deliver a useful product that satisfies its customers. I like to think about projects as a container of some product value. That means that a given release does not need to do everything for those ideal customers, but it needs to solve some specific problems for those customers. Too few projects have a product vision for this release.
The product vision is a concise and specific statement about which problems this release solves for which customers. That's the product vision in Manage It! and Create Your Successful Agile Project. The product vision can help the team decide which trade-offs to make as they rank the problems, what quality means, and when to release which solutions.
Pragmatic project managers and product leaders focus this project's product vision on defining the product strategy for this project, this release. That means the project team needs specific problems for specific users.
Specificity Helps Define the Product Vision
I've seen several problems with trying to craft a specific product vision:
- When the vision is about what we, the producers, wanted from the project. One of those examples is: “Release 6 is about fixing all the things we didn't fix before.”
- Or the vision is not specific and reads like motherhood and apple pie: “Be the best xxx in field yyy.” That's lovely, isn't it? And it says nothing—absolutely nothing—about the value this product will add to a customer's life.
Customers buy or use products because they believe they will receive specific value. That's why it's worth the time to instill as much agility into your project as possible. (See the Project Lifecycles book for more details.)
A Product Vision Helps Define the Customer Value
Instead, the product vision is a statement about the value this version of the product will add to the customer's life. Here are some examples:
- Add six payment options so all of our potential buyers can choose the option that best fits them. (Since this is specific and limited, it might be a relatively short project.)
- Save our customers' retirement funds. (Several years ago, a bank realized their traditional/older banking customers were not opting into the new regulations for their retirement funds. Not opting would cost those people much of their retirement savings.) This specificity helps the product leader decide what to include in this release and what to postpone.
- Use the Customer Success data about the ten most irritating problems in our product and fix them. That will free the Customer Success people to focus on the interesting ways people use/abuse the product to see where the product could go next. (The original estimate for that project was six months. The specificity allowed the Engineering team to finish in five weeks.)
Note: I'm not differentiating between customer and user here. Nor am I differentiating between B2B (Business to Business) or B2C (Business to Consumer) products, because if a product is useful to a customer, it will add value to a customer's life.
Specific product visions can focus the team, including the product leader.
Specific Product Visions Decrease the Chances of a Feature Factory
If your team is doing random features here, there, and everywhere in the product—or worse, in multiple products—they might be a feature factory. But the more specific a product vision is, the easier it is to test that this feature is a useful addition to this project.
That's why product leaders need to learn to think small (how little thinking) and learn to say no to work that does not fit the product vision. See Create More Success: How to Say No to “Everything” to Say Yes to What’s Necessary Now. That same thinking matters just as much for a given project, because the more specific a product vision, the faster the project can start and end.
How to Test a Specific Product Vision
The more specific a product vision is, the easier it is to test it. Here are the questions I use to test the product vision:
- Please give me three names of existing customers who need this value.
- Please give me three names of potentially new customers who need this value.
- How little can we do to complete this vision?
The more we can point to specific people, the more useful the vision is. The how little question helps the product leader and the team make useful tradeoffs. In addition, the how little question might help prevent product bloat.
Bloated products do not add value to your customers' lives. As soon as a replacement arrives, your customers will abandon you. That's why I like to focus the product vision on the value to the customers.
The Product Vision Explains the Customer Value
Some products, such as a new cellphone, require a more extensive product vision. But for primarily software products, it's often more useful to define a small, specific vision that allows the team to release in a few weeks, to maybe a couple of months. The shorter the project, the faster it is to release. That allows the product leader to then define the next bucket of value.
I like to define the product vision in two ways:
- Either the Product Value Team defines the vision and tests it before the team's product leader brings the vision to the team.
- The team and its product leader discuss the vision and then write it down.
It took me longer to write this down than I suspect your team would need to define the product vision. (Insert laughter here.)
Regardless of how long this took me to write down, the key takeaway is this: A product vision helps the team create shorter, focused projects. That focus allows the team to finish faster, which decreases the project portfolio feedback loop. (See Multiple Short Feedback Loops Support Innovation.) Don't allow your projects to grow with “scope creep.” Instead, focus your team with a specific, tested, product vision. Do this in the chartering workshop.
Your team will thank you.
The Project Charter Series
- How to Create a Useful Project Charter in Less Time Than You Think: Overview
- Project Charter Part 1: Write (And Test) a Product Vision for This Project
- Project Charter Part 2: Clarify the Project Driver, Boundaries, and Constraints for This Project
- Project Charter Part 3: How Product Risks Support Your Feedback Loop Choices
- Project Charter Part 4: Define Release Criteria so You Know What Done Means
See my books: Manage It! and Create Your Successful Agile Project for what I already wrote about project charters.