It is essential that the product owner is able to envision the product, the next product version, or features and new increments. Being able to envision the product makes the product vision statement, which is needed before the rest of the product lifecycle can begin.
The vision can be seen as the goal. The vision is most likely effective if it can answer these questions:
1. Who will buy the product, and who is the target customer? Is the target customer different than the target user?
2. What problems does the new product address? Does it add value to the customer?
3. Which product features are needed for the customer and its success? What will the product look like and how will it excel?
4. How does the product compare with other similar products? Are they similar to products offered by your competitors?
5. What makes the product unique? What is the product's target price?
6. Can the organization design and sell this product?
7. Can the organization make money selling this product?
New products are often a springboard for an entirely new business model. The best example is Apple and its iPod and iTunes products.
Do you remember when the iPod came out? Most people do. It was revolutionary and new and fun and it was hard to believe that we could have all of our music in one place at one time. I know -- it seems silly to even think of a day before the iPod. If you are old enough, you can remember using a Walkman, and being limited to whatever cassette tape you had in the player.
When the iPod was introduced, it was introduced alongside iTunes, a marketplace filled with all the songs you could possibly want to buy. Songs were priced at 99 cents each, and for the first time, you could buy just a song, not an entire album.
At first, there were competitors to iTunes, but they were illegal, and soon Apple made it impossible for those illegally obtained songs to be used on the iPod. If you wanted to use the iPod, you had to use iTunes. So in bringing one product to the market, Apple actually brought two, and opened up an entirely new business model.
What Does a Good Vision Look Like?
The product vision must be able to communicate the feeling of the future product in a way that can be understood, and clear, to the team that is tasked with building it. The vision must be creative enough that it inspires creativity to the development team.
Everyone Loves It and Gets It
A good product vision must be loved and understood by all. The Scrum and Agile development teams are small -- just seven to nine people, and for the product to be a success, everyone must be on board and clear as to what they are bringing to market.
And it isn't just the development team that must love it. Management, stakeholders, users, and obviously the customer, must love the vision, as well. It should excite them. When users hear the vision, they should say, "That is exactly what I need!"
Having a shared vision also creates unity within the group, and galvanizes everyone involved. That excitement is contagious. It keeps the team working as one, and encourages them to want to learn and build more.
If one person on the team has a different vision, or thinks a product would be best developed differently, it will obviously cause a rift in the team. It is essential to the product that the product vision has the entire team working toward a common goal.
The initial vision must describe an engaging goal -- one that is broad enough that it allows the development team to use some creativity. If the vision is inspiring, it will engage the team and inspire them to build something that fits the vision. You don't want to give a vision that it too detailed -- otherwise the team won't feel inspired to think outside of the box.
You also need the vision to be concise. You don't want too many options, or else the team could become disjointed and go in different directions. This is a great time to use the elevator test. Can you explain the vision in the time it takes to ride up in an elevator? If the answer is yes, then it is the right size.
The Minimal Marketable Product
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, as no one has a crystal ball, 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 were a product vision and a team that believed in it.
Since we cannot accurately read into the future, the best choice is to envision the minimal marketable product. A minimal marketable product is one that has the bare minimum of functions to appeal to customer needs. Obviously the new function must be enough to warrant excitement. You wouldn't do a whole product launch for a product that now comes in a new product. The consumer could care less.
When the iPhone was introduced in 2007, it had a touchscreen, which made it completely new and unique. It also didn't have much else. It had the same basic camera as other phones, and had no other special features. More so, there were features other phones had that the iPhone passed on. Remember how long iPhone users complain about not being able to copy and paste? Such a simple function, and yet, Apple left it out in original models.
Why did it do this? Because it had the minimal amount of function to still be exciting. The touchscreen was so new that no one really cared about the other things. Yes, they were "wants," but not "needs." By keeping the features to a low amount, Apple was able to make and ship the phone more quickly, which gave it a huge advantage over its competitors. Which each new model it released, Apple would add new features and capabilities.
On the opposite side, consider the Apple Newton, a product seen as one of the largest failures in history. When the Newton was announced, the public was promised a PDA that could do amazing things. You could keep a full calendar, take notes, it could ever recognize your handwriting!
When it was finally shipped and used, it flopped. It was too big and heavy. It was clunky and unattractive. And most importantly, it couldn't recognize handwriting. So the one important thing it was supposed to do -- failed. The product flopped and Apple quickly pulled it from the market. Apple failed because they tried to do too much at once.
A minimal marketed product has many benefits. One is that the product can be launched quickly, which gets it to the market fast. In addition, functional attributes can be worked on until they are perfect -- no Newton mistakes. The product will cost less to make, which means it will have a higher return on investment. The company will get paid for the product sooner, which improves cash flow.
In addition, by getting the product to the market quicker, it gives the team a chance to get customer feedback, listen to that feedback and make changes accordingly. Also, if a minimally marketed product fails, less is spent on it, especially if it has to be pulled from the market. As crazy as it sounds, it allows the team the possibility of failure, which can help for future iterations.
Since no one knows the future, the vision should only cover what the next product will do -- not what it could do down the line. When the first iPhone came out, the goal was not to be the number one cell phone maker in the world (although I am sure most hoped for that). The goal was an innovative new cell phone that used a touch screen. Even the largest of visions must be taken one small step at a time.
Once the team has the vision, it is turned into a shippable product. When consumers use the product, the team gets feedback that it uses for future features and iterations. In Scrum, sprints are used to tackle each of these new features that are suggested, and because of the short term of the sprints, the team will know whether the vision for the product will work or not. If it doesn't work, the vision isn't working, and it needs to be re-thought and adapted.
A vision can take place over more than one release. A great example of this is the Google Chrome browser. The product team knew what they want the browser to do, but for functionality reasons, it slowly rolled out different versions. With each new version, it was able to learn and capture feedback from users.
Remember - Less Is More – Keep It Simple
This is an incredibly important premise in developing a successful product vision. You might think that a product with a ton of features will surely out perform and out sell a competitor's product, but this is rarely the case.
Simple is good. Simple works. Simple sells. Steve Jobs famously said, "Innovation is not about saying yes to everything. It's about saying no to all but the most crucial features." And this is definitely the case with tech products and software. In fact, simplicity is one of the 12 principles on the Agile manifesto.
Have you ever heard of Occam's razor? In the 14th century a Franciscan friar named William of Ockham developed a theory. His theory was that, when given a choice between many different designs, the simplest one should always be chosen. This theory is known as Occam's razor, and applies when considering the vision for software development.
Think of a razor, for example. A razor has one job: to shave hair. Companies over the years have tried to come up with hundreds of little features that would change or improve the razor. Can you really improve a razor? Does a pink razor work better than a blue one? To this day, the best selling razors are inexpensive disposables.
If a team has an idea for a new feature, they must ask whether that feature is crucial to that product being a success or not. If it isn't crucial, it should be thrown out. Remember, the customer wants a simple product.
Remember buying your first iPhone or other smartphone? Using the new touchscreen interface was a big deal and a learning experience for most. Imagine if we had been given a ton of other features as well, for example, Siri, video recording, and multi-touch. It would have been overwhelming, and many people may have felt it was too complicated to use.
The same can be said for user interfaces. Look at Google. Google uses the same search screen that it has for years, making only finely tweaked changes. It is very basic. It uses basic, primary colors (except on occasion). The screen has their name, the search box, and a few other small options -- and that is it. When you go to Google's search page, you know exactly what to do and what to expect.
Now, take a look at Yahoo. Yes, it has the same search bar, but the page is also cluttered with news, photos, videos, and vertical and horizontal menu bars. It is busy. You didn't go to Yahoo for news. You didn't go to Yahoo for photos or videos. You went to do a search.
The same can be said for Bing, which is Microsoft's search engine. Initially it tried its own thing, but failed. It tried to offer too much, when all people wanted was to search for something on the Internet. Their site is still pretty basic, but it could never compete with Google. This is why Google has the largest market share in the industry.
Customer Needs and Product Features
An important part of the vision is the features of the product. They are often the heart of the vision and require close attention. Deciding which needs are most important will help form the vision, as those needs are "the means to an end" for the product. In order to meet those needs, the product feature is critical.
When Apple was developing the iPhone, it knew it needed to be different than all the other cell phones on the market. It had to be new and visionary, because that is what Apple is all about. At this time the Motorola Razr was the most popular phone, and Nokia had the largest market share for cell phones.
So Apple decided it needed something new. A touch screen. It was a new idea that would make using phones much easier. In a way, Apple was able to think of what the customers NEEDED, before the customers even realized it themselves. It wasn't a functional requirement for the phone. All a phone must do is make and receive calls. But as a feature, the touchscreen completely changed the ballgame for the cell phone industry. It was so new, that most people didn't even imagine it was possible yet.
When devising a product vision, you want to separate the features from the functional requirements. Basically, you are separating what the customer needs and what the customer wants. Obviously a customer NEEDS a cell phone that can make and receive calls. A customer WANTS features like a touchscreen.
When working on the vision, the team will want to have a list of both features and required attributes. Once it has a list of possible features, those should be listed and prioritized. It most likely isn't possible to enact all features, so deciding which ones would work best for the vision is the best plan.
When looking at this list, the team should ask itself the following questions of each feature on the list.
1. Is this feature worth sacrificing others for?
2. Should we try to keep this feature?
3. Should we sacrifice this feature for others on the list?
By doing this, the team isn't trying to tackle too many features at once. Just think of the iPhone again, and how each new release brings new features. We can only imagine which features never made it to the actual phone. But by focusing on ONE feature, they were able to excel.
Every time a new iPhone is released, many people hope for stronger glass, or glass that will not shatter when dropped. It is well known that Apple has been looking into this feature for years. But for whatever reason, that feature hasn't made it to the final product yet.
The Use Of "Pet Projects"
Many large tech companies like Google and Amazon encourage their developers to work on pet projects. These projects are not sanctioned or supported by the company; they are simply new ideas that development teams think could become a viable product.
This allows independence and freethinking, and can be very successful for the companies. For example, in 2005, half of all the products released by Google were once independent pet projects of their developers and other employees. The team that originated the idea continues to work on the project, and since it was literally theirs from inception, they are more likely to be successful with it.
A great example of this is Google's Chrome browser. It was once simply an outside idea of a couple of Google engineers, and now, it is one of Google's largest products, and has name recognition worldwide. Google never intended to be a web browser. It wasn't a business they were interested in, and they wanted to concentrate on their search business.
The same thing happened with Gmail. Google wasn't even considering an email service, especially one that was totally based online and not attached to an ISP, as they originally were. But some Google engineers had an idea, and Google let them run with it. Gmail is now the largest email service in the world.
Another example is the yellow sticky note. Such an easy idea, right? An engineer at 3M who was trying to develop a sticky adhesive for aerospace parts invented it. Obviously, he was unsuccessful. But, he found the product was able to stick and unstick to surfaces without leaving a residue. He knew that product was in some way valuable, and eventually, the yellow sticky note was born. Had management at 3M not allowed the engineer to work this side pet project, a quintessential American product may have never been born, and 3M would have missed out on one of its most successful products.
