This post was first published on CoderHood as Product Vision, Agile, and Going to the Moon. CoderHood is a blog dedicated to the human dimension of software engineering.
Reading Time: 6 minutes
Vision:\
(noun)\
a vivid mental image, especially a fanciful one of the future.
A Clear Vision
Everyone who lived before witnessing the Apollo 11 mission on July 20th, 1969, could only dream of touching the Moon. In 1865, Jules Verne, a French novelist, had that dream in the form of a novel that he titled "From the Earth to the Moon." He told a story of a group of gun enthusiasts and their attempts to build an enormous space gun to launch three people to the Moon.
It took 104 more years for humanity to find a way to realize that dream. When it happened, it was one of humanity's proudest achievements; a glorious moment that required an immense amount of planning and work.
Many small and significant scientific milestones needed to be realized before we could take that one enormous step. First, in 1609, Galileo discovered that the Moon was a world. That discovery was necessary for us to imagine that going to it was even a possibility. In 1687 Isaac Newton reasoned that a cannon powerful enough could put a shell in orbit. If the round were fired even faster, it would leave earth and go into space. In 1903 the Russian scientist Konstantin Tsiolkovsky defined the Rocket Equation, a mathematical basis for space propulsion. The list goes on and on.
Each milestone by itself wasn't enough to get us to the destination but combined created the necessary critical mass.
The vision that propelled us forward was simple: to put a human on the Moon. The engineering vision was more complicated, but still clear: to build the technology necessary to carry humans to space, keep them healthy, deposit them on the Moon, and bring them back to earth alive. That last part was a significant complication.
Agile and Vision Are Not Enemies
I admit it; space missions and software products are very different things. However, they do have commonalities. They both consist of complex engineering challenges that need to be overcome to reach a goal.
The Apollo 11 mission was planned and driven mainly using waterfall processes. That's how we engineered most things at the time. Today, many engineering problems are approached in a more "agile" way. The agile manifesto lays the foundation for that way of thinking:
Agile Manifesto
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Operating according to the manifesto is common in the software industry. Unfortunately, the manifesto is very vague and open to interpretation, and it is usually misinterpreted. The 12 principles of agile spell out that philosophy in greater detail, but still they leave (by design) much to the imagination:
Agile Principles
- Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
There is no mention of product vision or engineering vision in either the manifesto or the principles. It more or less says that the vision needs to be realized in small functional releases and that plans can and will change along the way.
Unfortunately, agile is often confused with "starting to do stuff without a plan." That is a fallacy that causes huge problems. The manifesto and the principles do not say that you should start writing code without having any idea where the product is going. In fact, beginning with a clear vision is a fundamental of "Agile Project Management 101," but it is also an often forgotten first step.
From the product vision, an engineering team should create an engineering vision. That is a high-level idea of how a product vision is going to be realized.
Taking the first step that comes to mind toward a goal is not the right approach, as it leads to many false starts and wrong paths. Let me give you an example.
Going to The Moon
Let's say that the Apollo 11 mission didn't happen and that your goal is to travel to the Moon for the first time. The "product vision" is the idea of an astronaut planting a flag on the Moon. That is what you want to achieve, or the "what." It is a vision because you can see it in your head. From that idea, you need to imagine how you are going to achieve it; I call that an engineering vision.
In an agile world, you might be tempted to make quick progress by rushing to take the very first action that comes to mind that brings you closer to achieving your goals. For example, you could start by walking in the general direction of the Moon. That might seem like a great thing to do as it gets you closer to the destination. However, while walking in the right direction reduces the physical distance between you and the Moon, it has no chance of success because you cannot walk to space.
Walking is a misguided first step toward a dead-end. Taking a bunch of first steps toward dead-ends is not being agile; it is just lacking the ability or desire to imagine how you are going to reach your goals. In other words, it is lack of vision.
A better first step is to think what it would take to get to the Moon. Imagining how you could do it, even without knowing the details, is the engineering vision that you need to have to reach the goal. That vision keeps you focused. For example, if you envision having to build a rocket, the next steps you take are going to be focused on that concrete goal.
With the focus on a rocket (engineering vision), you can take steps that have a chance to get you to the destination.
That vision is critical. If you envision the wrong thing (for example, walking to the moon), you are going to focus on taking steps in the wrong direction. That is where the agile philosophy comes into play. Applying agile methodologies once you have a vision, you achieve functional intermediate steps while keeping evaluating the course and the overall strategy along the way.
Levels of Software Product Vision
We have seen that the engineering vision depends on product vision. Similarly, the product vision depends on the company vision.
That is because the company vision tells you WHY a product should be built. The product vision tells you WHAT product should be built and, finally, the engineering vision tells you HOW the product will be developed.
Together these three levels of vision give the entire narrative of a product. Having that narrative is necessary to describe the reality of the world after the product is built.
Where Are Marketing and Sales in This Picture?
If you don't know how you are going to market or sell a product (at least at a high-level), the product is going to struggle. Look at how long it took for Twitter to figure out how to monetize their services. For that reason, marketing and sales strategies should be part of the Product Vision.
To expand on the MindMap above:
To make this more concrete, at Amazon the vision of a product starts from a mock press-release. That forces product managers to think about all customer-facing facets of a product from the very beginning. Thinking about market and sale realities has profound implications on product design, and the product design has broad consequences on engineering direction.
Conclusions
Agile methodologies have influenced the way software is built, but have also been applied in naive ways. Their goal is to eliminate unnecessary and costly over-formalizations to enable developers to make progress without having to spell out all the details ahead of time. That should not be confused with sloppily taking a step in a direction that appears somewhat right.
Agile methodologies should not be an excuse to attempt to achieve results without planning or without knowing what we want to build or how we are going to do it. A clear product vision is still critical. Small-batch vision and incremental vision are both oxymorons.
Top comments (2)
Halfway to the Moon we get a note from Customer that the Competition got there first. Striving to deliver Customer's competitive advantage, we decided to aim for Mars instead! While responding to that change, we realized that we lack fuel to get to Mars, but we have just enough to land in Australia! Striving for simplicity, we agreed that we don't need a spaceship and an old fashioned sea ship could get us there. On the bright side, our newly re-designed sea ship had a cutting-edge, spaceflight-ready architecture. On the other side, we didn't have time to update the documentation, but that is ok since we are going to outsource sustaining to our off-shore (no pun intended) team. In the end, we had a nice retrospective meeting. In Australia. We all agreed that we did great but next time we'll do better!
I found the PO's original user story for the Apollo project.