How does a product owner or development team create the vision of their product? Do they just sit and hope an idea pops in their head? Of course not. They use a series of techniques that help them inspire their creativity to get the juices flowing.
The Prototype
When a customer wants a new product, they often have no idea what they want to product to look like, or do. They just know they want it to do something. And it isn't any easier for the development team. The team is left in a position where the customer is either unsure or unclear, and the team is left to figure out how to make it work.
Developing the product vision is a time of discovery, when the team gains as much knowledge as it can about the product, and then doing some experiments to see what sticks.
Remember being in college and working in a study group? You need an idea for a project, but have absolutely no clue what to do. So, everyone gets together, grabs some pizzas, and they brainstorm. They throw out ideas, and hopefully one of them will stick. It works the same way for software development teams.
The most important part of this process is gaining the knowledge needed to throw out ideas that could stick. With this knowledge, a team can build prototypes and mock-ups, and test them to see which of them will work, or "stick."
Prototypes are cheap to build, and easy to throw away. But they bring so much to the table. They help the team imagine what the product should be doing, or what it should look like. They help the team understand what technology may be needed, and if new architecture is required. Basically, the prototype will tell the team whether the product is viable or not, and whether it is financially worth the risk and undertaking.
Key Term!
Spike
An executable mock-up that addresses a specific issue for a product
Experimenting
Experimenting is obviously a key part of developing a product vision, and it is important to experiment in the most organized way possible. The most effective experimentation plan is called the Deming Cycle.
The Deming Cycle is a four-step process, also referred to as PDCA, Plan-Do-Check-Act. It is an iterative process that allows for continuous improvement of products and processes.
Step 1 – Develop the hypothesis. (PLAN)
Step 2 – Validate the hypothesis. (DO)
Step 3 – Review the results. (CHECK)
Step 4 – Fix hypothesis and validate again. (ACT)
This is also known as trial an error, something that every inventor does. Failing is a necessary part of succeeding. Think of Babe Ruth and all of his strikeouts. Or think of Thomas Edison, and all the times he failed before he finally succeeded.
Using Personas and Scenarios
Using a persona helps you select your target customer. If you were on a product team that wants to make hair accessories for teenage girls, you would use a persona of a teenage girl when thinking about the product. You want to be in her shoes -- your target customer. It's almost as if you are acting, or playing a role.
When teams use personas, they make them as real as possible. They name them. They have jobs, or friends, or kids, or whatever it is that will make them relevant to the product. With the right personas, the team can learn how the product will influence a persona's life.
This is done with consumption maps. One map would be an activity done without the product, and the other, with the product in use (in whatever form is envisioned). Using this model can help the team determine whether there is value in the product, or if there are other aspects of the product that would be more successful.
Another effective way to determine whether a product or feature will be valuable is to build a vision box. A vision box is a Scrum invention in which a mock-up of the product package is made. The team chooses a product name and three points that will help in the selling of the product, then places that information on the front of the box. The vision box should remain visible to the team, somewhere in the common work space. This way, when walking by or talking to a team member, seeing the vision box might inspire an idea.
A trade journal review is another method. In this method, the team will write a mock journal article detailing what they would like to read about the product when it is introduced. It is a great team activity that requires a lot of creativity and vision.
Kano Model
The Kano Model is used in product development to help teams choose the best functionality to make the best product. It can tell a team how likely a customer will be when the new product feature is released. The model has three different types of functions:
Basic Functions
Performance Functions
Delighter Functions
Let's use the iPhone again as our example.
Basic functions are what make the phone work. It must power up and turn off, and it must make and receive calls. It must send and receive text messages. That is all that is needed for a phone to be a phone. Of course, these basics are pretty boring, and a customer would likely get bored with such a product.
Performance functions are what make the basic functions work better. A phone must make and receive calls, but the performance can be increased to make those happen quicker. Apple introduced iMessage; an adjunct to text messaging and it was incredibly well received.
Delighter functions are just what they sound like. They delight the customer. An attractive design gets people excited. Being able to personalize the phone with colors and cases is exciting. These can be features that the customer has requested, or features the team envisions. These are also the features that give the product an advantage over its competitors. For example, when Siri was introduced for the iPhone, it was a huge delighter for consumers.
The problems that teams have are to find a way to bundle all three together in a way that the customer sees nothing but maximum benefit. The Kano Model can be used with both the product vision and the product backlog.
It is important to note that the Kano Model states that, over time, delighters will become performance features, and performance features will become basic features. This is why companies must constantly find new delighters to add to the product.
The Original Kano Model Categories
1 – Must-Be Quality – These attributes are taken for granted by consumers and, if not included, the consumer will be unhappy.
2 – One-Dimensional Quality – These attributes make consumers happy when they are fulfilled, and unhappy when they are not.
3 – Attractive Quality – These attributes make people happy, but if they don't happen, people are not unhappy.
4 – Indifferent Quality – These attributes are neither good nor bad, and the customer doesn't care either way.
5 – Reverse Quality – These attributes are the ones that cause unhappiness with some consumers, proving that not all consumers are alike.
The Product Road Map
As more and more product features and incremental updates are released, product visioning actually decreases. However, the product still needs goals and for the creative process to continue. This can happen with a road map. The product road map lets the Scrum development team continue to find goals for future products, and they can view it as a map.
The product road map is a Scrum artifact that demonstrates how the product will most likely move across the upcoming new product iterations, which allows the team to form a dialogue with the stakeholders.
The road map lets companies coordinate the development and introduction of products that are related -- for example, a product line. The product road map should be simple, and state the launch date, the targeted consumers, and the top five features. The rest of the details aren't necessary at this stage, and will be discovered in the product backlog.
The product road map isn't a guarantee, and it isn't actual market research. It is simply how the team sees the product evolving over time, based on what they know at that given time. Product road maps can and do change and evolve, as new information is learned.
The road map shouldn't be built until the product has been launched. It makes no sense to waste the time building out a years-long road map, if the product never becomes reality.
When making the map, include all relevant people, which will include the development team and other stakeholders. And the map should cover a realistic amount of time. Do not do a five-year road map when a six-month one would be more helpful.
Minimizing Product Variants
As a product matures, it might add variants to address different needs of the consumer. For example, Microsoft offers its Office Suite for Home, Professional, and Student. This addresses the needs of the different customers and users who utilize the product.
However, having too many variants can make it more difficult to develop updates that are functional for all variants. It can also be overwhelming for the market, and can led to a bloated product portfolio, which is often very expensive.
Common Mistakes
Creating the product vision is a huge step in the product lifecycle, and you should be careful not to make some simple common mistakes. The biggest mistakes are:
Having No Vision
Prophetic Vision
Analysis Paralysis
The Team Doesn't Always Know Best
Big Is Not Beautiful
Having No Vision
It might seem strange, but some teams begin the product development process without a vision. This is most common when customers request specific features but fail to see how those features connect.
A product development cannot begin without a vision. Work with the customer to build a vision, even if they don't believe one is needed, for instance, for a small feature. Seeing the vision will help them ensure the new feature will be a useful one.
Prophetic Vision
The product vision can detail the future product, but it is entirely possible that future product never comes true. Actually carrying the vision into a product can cause a failed product.
Nobody has a crystal ball. No one can be 100 percent right, 100 percent of the time. When developing a vision, a Scrum team must look into the future and decide what it thinks a product could do and what it could look like. This is obviously not easy, and the only thing we can be certain of is uncertainty. There is no research that can tell you with 100 percent accuracy that a product or idea will be a success. Approximately 25 percent to 45 percent of new products fail, and behind each of them was a product vision and a team that believed in it.
Product managers and development teams must remember that they don't know it all. Development teams are obviously up to date on most technological advances, but customers and users might not be. Don't take a chance and make a product too complicated, just because you think you know what the customer will want.
Analysis Paralysis
We all get there. We get stuck. We overthink to the point that we forget what we were thinking about to begin with. You do not want to do this with the product vision. Too much research can cause the team to get stuck and fail to make progress.
Too much research can also be a waste of time and money, and could end up without a deliverable product. It is important to understand the customer and the market, but not to the extent that the development team's vision is overlooked or forgotten.
Analysis paralysis happens when teams care too much about being safe. Risks must be taken (and mitigated as much as possible), even if the company is against it. Things will not always go right the first time.
Analysis paralysis can be prevented by visioning as little as possible, getting the product to market as soon as possible, and then waiting for customer and user feedback, and going from there. The feedback, whether good or bad, will be a great jumping off point for additional market research.
The Team Doesn't Always Know Best
On the other side, some companies don't do enough research, and rely on their tech know-how to develop the product. This is dangerous, because the company could completely shut itself off from the market.
Companies cannot depend entirely on their own intuition or the intelligence and knowledge of their developers. They may think they know what their customer wants, but research is required. Otherwise, the company could spend time and money making a product nobody will buy. The customers and users should always be a part of the visioning and development process.
Big Is Not Beautiful
Well, sometimes it is. Big sunrises are beautiful. Big ice cream cones are delicious. But big product launches can be scary and incredibly risky. Big launches are expensive and very time consuming, and they can result in a huge failure.
Avoid this trap by doing a smaller launch, or an earlier launch, with subsequent frequent launches. It is better to have a small launch and learn from the customer feedback, than it is to have a huge launch and a huge failure.
Using A Vision Board
A vision board is a great way for a team to look at ideas and add new ones. It allows team members to capture their visions and place them on the board for all to see. All you need is a whiteboard and various colors of whiteboard markers. The vision board will be broken into five groups.
1. The Vision Statement – The statement that clearly describes the vision. This goes at the top of the board.
2. The Target Group – This describes the target market that the product is addressing. The board should list who the users and customers are most likely to be.
3. Needs and Wants – This is the problem that the product is solving. It should list each problem and how the product will solve it. It can also list how the customer gains from the product, and why the customer would want to buy and use it.
4. Product – This should be a list of three to five items that make the product unique, and stand out from competitors. Start with the most important and most valuable, and go down the list from there.
5. Product Value – Why the product is a worthwhile investment for the company, and how the goals will be achieved. Some possible goals could be how to increase sales, enter a new market, reduce costs, develop new brands, or ways to get an advantage over competitors.
Creating the Vision Cheat Sheet
What makes a good product vision? In the end, it comes down to asking some important questions.
1. Does the vision answer a question or solve a problem?
This should be the first question every product manager asks. What is the product going to do? What problem is the product going to solve? Will this product be valuable? If these questions cannot be answered, then the manager must go back to the vision board.
2. Does the vision align with the values of the company?
The product vision statement must align somewhat with the overall strategy of the company. The company must provide the framework that the product will follow, and be willing and able to back it up, if necessary.
3. Can the vision be tested?
Is the vision something that can be tested, using known assumptions of current consumer needs? It is important to have some testable information. This prevents a company from developing a product that no one wants or needs.
4. Can the vision evolve?
The initial product vision might be too broad or vague in the beginning, and that is okay. It will evolve and become more directed with time. Customer feedback is a particularly important part of this process, and will help determining how the product should evolve.
5. Where will the product vision be in five years?
Five years is a long time, but it is a good idea to be able to think about how the product could evolve over a long period of time. Does the product even exist in five years? If the vision solves a problem now, will it still be able to solve that problem in five years? Of course this should only be done for products that have such a long lifecycle.
6. What does the user think?
Product visions can't only be about the company and the customer. Never forget to include the person who is actually using the product. Ignoring the wants and needs of the user will only hurt the customer. Can you imagine Microsoft completely developing Word without doing consumer product testing throughout the process?
The most important thing for the Scrum team is that they have a shared vision of what the future product will look like. The vision should be realistic and focused on the next upcoming product release. It can be helpful to ask customers and users to attend the spring review meetings so they can understand the vision, as well, and give their feedback. Keep the vision board current and visible at all times.
The team should them ask itself the following questions:
Do the products follow shared goals?
How will the goals be achieved and who will achieve them?
The product vision must be so clear that everyone is able to understand it. This means that management must understand it, stakeholders must understand it, and every last member of the team must understand it.
