Use vision topics to facilitate agile conversations
The goals of this article are as follows:
Underestimation is the norm
It's been my experience that most people underestimate both the number and types of conversations and topics needed to actually achieve a shared vision. It's also been my experience that the people who least see the need for having these types of conversations are ironically the ones who actually need them the most because they are usually the ones most guilty of incorrectly assuming what everybody else "already knows".
The good news is that the people who can often be the biggest initial adversaries of vision conversations can end up being the greatest champions of them afterwards. The challenge is getting them to participate enough so they can then see for themselves the results of having these types of conversations.
Without having explicit vision conversations to expose potentially conflicting assumptions, it's possible for nobody to realize those mismatches are there until something in the implementation process forces the issue to come to light. Sometimes this is relatively harmless and occurs early on. At other times it can end up being very costly and can occur quite late in the process in spite of all the types of agile conversations teams will have along the way.
Even when people arrive at decisions they can agree on, it's common for them to struggle to remember all of the details and to also not realize they need to properly communicate those decisions and details out to others impacted by those decisions. This is one of the reasons why I advocate for documenting your vision decisions and why the following quote is so applicable.
"The single biggest problem with communication is?the illusion that it has taken place."
-George Bernard Shaw
Levels of Understanding
The following building diagram represents foundational and supportive relationships for certain kinds of understanding.
For example, to engage in effective quality control, one must understand what the deliverables are. To understand what the deliverables are, one must have some idea of what the intended solution design is and so forth.
When a misunderstanding occurs, it might be identified on one level (ex. when refining a user story) but the source is actually a level or two deeper (such as on the vision clarity level).
The more foundational a misunderstanding is, the more disruption it causes for levels higher up.
The four levels beneath the "building" in the diagram above form not just the foundation for a single project but for any projects that are undertaken at the same time.
Each of the above areas have their own kinds of artifacts with their own sets of best practices for capturing the level of understanding in question. Discrete artifacts that each focus on one area of understanding while relating to each other in defined ways is a much better approach than trying to capture more than one area of understanding in a larger artifact.
Even though the other areas are important, the rest of this article will focus mostly on addressing the "Vision Clarity" section.
What questions must be answered to achieve a shared vision?
I have specific, short-hand topic names for addressing each of the following questions as well as specific techniques for each that I will discuss later in this article. For now, here is a list of the questions you must answer to truly achieve a shared vision for a product, project, or ongoing responsibility:
You also need to address three meta topics:
What a vision document is and what is isn't...
A vision document is not a contract. It's a conversation vehicle. It's a means of clarifying assumptions and capturing the current state of decisions regarding the answers to the question I just listed previously. It can and will change as more information becomes available.
Sometimes a vision document gets mixed in with other kinds of artifacts, let's quickly review what those kinds of artifacts are and why they are distinct from a vision doc:
A vision document is not a project charter or implementation plan. Implementation plans are informed by one or more strategy / vision docs but are their own type of artifact with their own best practices and are about making sure certain types of things (such as business or domain tasks that don't make sense to track in the product / engineering backlog) don't get lost in the shuffle. Think of an implementation plan as a "LADDER"
A vision document is not a requirements document. A vision document should capture the strategic decisions that inform requirements discussions and should be actively used to help level set assumptions and expectations when discussing requirements details, but it's not trying to replace the backlog. Instead, it's trying to help make sure what you have in your backlog is supporting a coherent strategic direction.
The backlog will shuffle around all the time. User stories will be modified constantly, new ones will be introduced, and some will drop off as they are completed or when it's realized a story isn't needed any more. A vision document, on the other hand, helps you have a clearer, more objective perspective as to when certain changes are meaningful and need to be broadcast out or considered much more carefully vs those changes that are simply execution details for specific stories within the backlog.
What does a vision document look like?
As a rule of thumb, most of my vision documents have ended up being only 2-3 pages in length (i.e. roughly the same length as what you might expect for a senior developer's resume). When I have just focused on the first four vision topics (i.e. your "PROP" - more on this later in the article) we're talking about only a handful of paragraphs. When only the first four topics are covered, one can comfortably fit the info into the body of a ticket like an Epic in Jira. When one needs to capture meaningful info on more topics than just the first four, it's usually best to put your vision info into a wiki page like Confluence to help make it easier to read through - then link to that page from the Epic or whatever story grouping/organizing means is at your disposal in your backlog tool of choice.
Even though there is a fair number of vision topics I advocate be addressed, don't let that fool you into thinking you need to write a lengthy document. If the document gets to be too large, it will get in its own way.
You can use the same set of vision topics to effectively establish vision at all sorts of levels - from company wide initiatives to lower level individual team initiatives. But if your vision doc is growing beyond a few pages, it might be trying to contemplate too many lower level details all in the same document - or the initiative you're trying to envision is simply too big. In such cases, consider breaking the subject of your vision up into smaller related vision documents - similar to how you might break up a larger story in your backlog into smaller stories that are more manageable.
The journey towards shared vision includes epiphanies...
The epiphanies stakeholders and team members experience are why the early vision meetings I talk about later on in this article are so important to have. They are also why I personally have trouble with advice I have encountered where creating a product vision is portrayed as merely an exercise in one person writing a paragraph or two of text and that's it. I've found one can usually create such a concise and accurate summary only AFTER paying the price to think through and capture the details of the vision topics addressed in this article with those stakeholders and team members who are immediately impacted.
The rest of this article is broken up into the following sections:
1. Topics to discuss in a vision document
I have used different acronyms over the years to capture the relevant vision topics as I've learned and evolved my approach. Currently, I use the acronym "PROPORTIONAL" to help one remember both the vision topics and the general order those topics should be discussed and / or presented when captured in a document.
There are also three additional meta-topics that will need to be addressed and captured. Two of them will be info in the document and one will be captured by virtue of the document's relationship to other similar documents. These three meta-topics are your "REP" topics:
Relative Priority
Relative priority calls out where the defined effort stacks up against other competing priorities. This is expressed by ranking the defined effort against other defined efforts in a single prioritized backlog. The key here is to not fall for the trap of simply assigning a non-relative priority indicator while avoiding relative prioritization. Otherwise, you will end up with multiple "1", "Top", or "A" level priorities. A single backlog forces priority decisions in a way that simply assigning an indicator does not.
Relative prioritization is something that will happen at least twice - once when you're deciding which efforts to formally define and once when you're first putting a recently defined effort into the backlog against other defined efforts. However, the truth is that priorities will change all the time and the relative priority of an effort can move around a lot over its lifecycle.
Executive Summary
Your Executive Summary needs to be at the TOP of your document so it's the first thing people see, but it needs to be the LAST thing you work on drafting. More on this later.
Point of Contact
Listing the "Point of contact" addresses the need to clearly identify the person who will drive the initial meetings and ongoing analysis for the endeavor. This is presented in the vision doc after the summary and before everything else because it needs to be clear who people should contact if they have questions about the product, project, or ongoing responsibility that the vision is attempting to define.
The importance of your "PROP"
Aside from the three meta-topics, the absolute minimum amount of information you need to define a vision is your "PROP" - meaning your "Problems/potential", your "Recipients of value", your "Outcomes", and your "Product/process changes (bets)" topics. Without these in place, you don't have enough information to fashion a working vision - much less a coherent Executive summary - and you usually won't have enough information to know where that vision would rank in priority against other items.
It's possible for each of the other topics to not necessarily have any immediate content - at least not at first. But the odds are that each vision you work on will eventually have content for most (if not all) of the other topics over time as the vision evolves, as you gain more information and insight about what decisions need to be captured and clarified, and as new questions arise that need clarity while implementing the vision.
Problem / potential summary
This topic attempts to address which problems we are trying to solve and/or what potential we are trying to realize with this vision and what is their relative order of priority. In other words, this addresses what motivated, or continues to motivate, the existence of the product, project, or responsibility.
I say both "problems" and "potential" here because framing everything just as "problems" is not always accurate. Sometimes you're simply trying to take advantage of potential that exists.
I usually have a rank ordered, bulleted list with the order of the bullets reflecting the overall priority order. I also use sub-bullets if there are nuanced items that roll up into the larger items. Sub-bullets are, likewise, listed in priority order when presented. This way, as one gets into tactical details to address the different bullet points, there is an overarching, general priority of what problems we're trying to solve that can help serve as input into how one is prioritizing the analysis and execution approach.
This does not mean we strictly follow this higher level priority to the letter in all of our activities, but it does give us a way to know when we might be getting off track (ex. if our activities happen to be focusing too much on lower prioritized items while the higher ones are getting neglected).
Use sourcing to fend off challenges
Depending on the types of problems identified, you will want to clarify severity / frequency and you may need to link to or acknowledge your sources in your bullet point. For example, if you list a bullet point that a certain type of problem is occurring, you might include a parenthetical explanation as to where the info about that problem came from or perhaps even linking to something (like a sql query that you ran to help identify how frequently a problem was occurring).
Without clear sourcing, two side-effects can occur:
Sometimes challenges are made with the best of intentions and sometimes they are simply a case of "high grounding" (more on that later). Regardless, it can sometimes be hard to remember all of the details about how you and your team arrived at the conclusion that a problem was worth addressing in the first place. It's also worth remembering your sources so that, as a project progresses, you can quickly know how to answer the question "is this STILL a problem?".
If you haven't recorded your sources, challenges from new people becoming acquainted with an effort can end up resulting in unnecessary wheel spinning if you are compelled to go back and re-examine the original motivations over and over again.
Recipients of value
This topic addresses which roles, users, personas, etc., will receive benefits from what this vision is trying to accomplish and what their relative order of priority is to each other. In other words, this attempts to answer questions around whose opinions matter and which voices should be given more weight than others.
This is usually an ordered list with comments about how each persona would benefit from the efforts supporting the vision in question. Listing them in order of priority helps with controlling scope so that people don't fall for the trap of thinking they have to please every customer segment or stakeholder group to the same degree. You will have to make tradeoffs and having a prioritized list helps you do that more effectively and communicate that mindset to others more efficiently.
Do not try to overload your vision doc by defining entire personas within the context of this artifact. Instead, create defined personas or user roles elsewhere in specifically defined and formatted artifacts that are suitable for that purpose and then link to those artifacts here so that the vision doc can focus instead on the prioritization decisions you are making.
Understand the relationship between the Problems / Potential section and the Recipients of Value section
There are times when the section on problems / potential and the section on recipients of value must be combined into a single section because it's the only way to make sense of the two issues. This is when the problems you are trying to solve with your product or process tend to be on the forefront, top layer of the customer experience. However, that's not always the case.
Sometimes it's helpful to express issues using the terms in which they have been identified because the problems are occurring within a service layer that is abstracted out several layers from the end recipients of value. For example, let's say you are having a vision discussion about a project because the main problem that has been identified is there is a 20% error rate in one particular production line for a part - and that part is used along with other parts to make larger, more complex components that are then used in turn to make up a larger piece that, combined with other larger pieces, culminates in the final product that is actually customer facing.
Refusing to frame the problem in terms of the identified production line error rate and instead insisting that you only state the problem from an abstract customer persona point of view has the potential to dilute the focus of every uniquely identified project into the same kind of homogenous, general, all purpose, "how do we make our product better" kind of project. There is a time and a place for such high minded general projects, but taking that approach every single time has the potential to rob projects of their focus and can make any identified problem areas consistently become unfortunately neglected afterthoughts.
Further, projects that are too broadly framed tend to end up as big projects - which brings me to this thought:
The typical enemy of a small project is the attempt to change it into a well-intentioned but larger project.
However, stating the identified problem in terms of the error rate in the problems / potential section and THEN acknowledging in your recipients of value section that reducing the error rate will result in the long run in better downstream customer satisfaction strikes the right balance. The customer impact is not lost and can still serve to humanize the project without the project losing sight of the specific problems that drove its inception in the first place.
At the same time, if you start by identifying problems and then, when you get to the recipients of value section, you see no way that solving the problems materially impacts the customer experience downstream or otherwise, then perhaps you need to reconsider whether the problems are as important as was first thought.
Internal stakeholders and employees are sometimes the main recipients of value for meaningful products and projects and making their experience better can turn around and result in a better customer experience. But failing to properly account for how much a vison's efforts are ultimately affecting the paying customers can result in well-intentioned ideas for work that are actually wasteful "gold-plating" efforts from a business perspective.
Connecting to larger business priorities
It's important for an organization to clarify larger business context questions so that the visions being crafted to support the viability of that organization have some direction. More to the point, if your organization doesn't have a general stated priority order of which recipients of value it's prioritizing over others as it conducts its business overall, then you are at a severe disadvantage when it comes to prioritizing the recipients of value for a product, project, or ongoing responsibility vision within your sphere inside that organizational context.
You might really nail the execution of a vision that solves a problem for a given user persona but the reality might be that persona is actually the business's lowest priority user group at the moment.
An effective organization will not only have some sort of organizational priority for personas / user groups / roles / etc. that it's serving but it should also have the customer journey(ies) mapped out as well so that specific areas of a given journey can be identified as more or less important to focus on. This helps provide some of the meta-direction needed so that individual teams can focus their efforts on the most effective areas.
As you work on establishing visions for your team, you might find you need to "push outward" and start efforts to more formally define organizational vision if such is hazy or ill-defined so that you can be more assured that the visions you are working on are serving the right organizational values.
Outcomes
This topic addresses which measurable outcomes we are seeking to achieve with this vision and what their relative order of priority is. In other words, this clarifies how you will know if your efforts are actually accomplishing anything.
When clarifying outcomes, I tend to use what I call "Outcome statements" in that each statement begins with one of these four words so that it forces the statement to be inherently measurable in some way:
For example, saying "good sales numbers" isn't very measurable. Saying "increase customer conversion rate" is better because it's measurable. Qualifying it further with a specific goal, such as "increase customer conversion rate by 10%" is even better.
Outcomes vs Outputs
There is a significant difference between outcomes and outputs. Often, it is easy to mix the two up and lose sight of why an implementation is being pursued.
Standing up a new website might be seen as a desired output implementation to achieve an outcome like increased conversation rate. However, it's easy in the heat of the battle of executing on a number of priorities to mistake a given implementation as its own success criteria. For example, the statement "we succeeded because we launched the website!" might not actually be true. In reality, if the new website didn't increase customer conversion rate, then was it really a success? Perhaps building the website wasn't a success at all and might even be seen as a failure of misspent time and resources in spite of how well it was built technically.
Taking the time to clarify outcomes is essential so you know if you are actually achieving success or not.
Sanity checks - the ability to measure
One problem you might encounter is that, by forcing yourself to think in measurable terms, you come to realize you don't actually have the necessary processes and tools in place to measure the type of thing you are trying to increase or reduce in the first place. How can you measure what the increase in conversion rate will be if you're not currently capturing the information needed to measure conversion rate at all?
In this way, the section on Outcomes can act as a sanity check as to whether your organization is currently mature enough to even know if it is succeeding or failing in a given area. Perhaps you should engage in a project to set up the ability to measure conversation rate first and THEN tackle trying to increase it with a subsequent project about an additional website rather than jumping straight to building the website.
Some things are hard to measure
Some things are just inherently hard to measure - and that's ok. The point is that you need to be thinking in terms of measuring the right things to help evaluate success. If you don't, because outputs are really easy to measure, it's tempting to only focus on what things are getting built and to lose site of the outcomes those things are meant to serve.
Identifiers
You might find it helpful to use unique identifiers for your outcome statements (such as numbers or letters) to help connect your outcome statements appropriately in the next section.
Product / Process solutions (bets)
This topic involves creating a high level list of the kinds of things we think we're going to change - be they product and/or process changes. In other words, this captures on a high level what your plans are.
Don't fall for the trap of just listing a bunch of functionality you want to implement without contextualizing it though. Qualify what you're planning on doing by calling out which products and processes are impacted and which outcomes a given implementation is aimed at supporting. Specifically, include links here to the artifacts that capture the vision for the impacted products or official process definition documentation when possible and call out the outcomes identified earlier in the Outcomes section (potentially using identifiers so you don't have to repeat the full outcome statements again and again).
As you list a general implementation, which product(s) and/or process(es) it involves, and which outcomes the implementation supports, the result can take the form of a bet. I personally use a table with three columns to capture bets:
This way, each row in the table can be phrased as an implicit sentence using this model:
We are betting that implementing <implementation>, which involves <process(es) / product(s) involved>, will contribute to <outcome(s)>.
Remember, the vision is not the implementation plan. Specifically, your bets should be sufficiently high level so that they can guide an agile discovery, experimentation, and implementation process. If your bets get too low level here, your vision doc ceases to be a vision doc and instead becomes the waterfall style requirements spec many people will already be tempted to think a document like this will be simply because it happens to be a non-user story document with some depth and organization to it.
Here's an example of an appropriate level bet using a simplistic example:
implementation:
processes / products involved:
outcomes:
Here's how this reads as an implied sentence:
"We are betting that implementing an event sign-up form, which involves our event page listings and our event registration process, will contribute to reducing the error rate for event registration by 20%".
This high level bet might then have one or more sub bullets in the implementation column specifying dependencies of the bet such as:
This is not where you will specify all of the low level tasks involved in building that event sign-up form along with their corresponding dependencies and task assignees. That info would belong in the continually evolving implementation plan you will link to from elsewhere in the vision and in your backlog in the form of user stories. Instead, this is where you are specifying the larger pieces.
Solutioning with design and engineering
Notice that the example bet is not remaining absolutely solution agnostic. It's calling out "how" by specifying a form. This section is about calling out which products and processes will change - which does speak to "how" on some level.
This is important because I've seen product people get tripped up over this fact as they argue against specifying any sort of "how" in a document like this. That accusation of premature solutioning would have weight if the following were not true:
Don't fall for the trap of thinking a vision document is purely a product/business concern even though a product person is the one responsible for assembling it. You need design and engineering to have strong input at the beginning stages and throughout. You might choose to delay or heavily caveat any bets coming from your draft meeting with your main stakeholder (more info on that meeting later) so design and engineering can weigh in properly concerning the bets section in the refinement workshop (again, more info on this meeting later on) and beyond.
Putting together a vision doc without design or engineering voices in the mix is a great way to fail as it evokes all of the "throw it over the wall at engineering" problems inherent in a "business knows all" waterfall approach. You want engineering and design involved. In fact, most of the best solution bets you will end up making will come from those voices - not necessarily from the product or business side.
Further, if you aren't specifying on some level what kind of solution bet you're making, the subsequent scope and strategic sections of a vision document lose their teeth. Instead of allowing you to capture very relevant design, strategy, and scope decisions, they become such high-level, abstract exercises that they aren't really worth much in the analysis process. The result will probably be that the vision doc ends up on a shelf somewhere almost immediately after it's drafted to thereafter collect dust and add to the cynical view that strategy documents like this aren't really worth much when the exact opposite is actually true (if they are done right).
Telling the story of where the product has been and where it's going
If the vision is specifically for a product as opposed to a project or an ongoing responsibility, there are two sub-sections I use to help tell the story here within this vision topic:
In this respect, calling out what the product currently does is not capturing a vision for the future but is instead presenting a summary of the past to the present. If I have a number of epics I've created in a tool like Jira that have already been completed and that supported past development of the product, I might have a list of links to them here so stakeholders and team members can go see what has already been developed. I might include a link to the place where release notes have been published for the product. I might include a summarized bullet point list here. The point is that a product vision needs to tell the past, present, and projected future story of a product and this section is the place to describe what the product does currently.
Regarding what the product will do, you might find it helpful to organize your bets in a way that lends them to phased implementation plans. However, if you do, you want to be careful. There's a balancing act here where you want to keep your vision a vision and not turn it into a full scale implementation plan.
Also, the further into the future you go with phases, the less detail you want. Don't fall for the trap of meticulously planning out lots of details for phases that are way into the future. If you do, you have fallen for the waterfall trap of trying to plan everything up front and you will leave no room for continuous discovery and agile adaptation. As you continue to interact with your customers, you might find out some key information or gain crucial insights that reveal your general plans for the future simply don't hold water. That's ok. Adjust your vision doc accordingly when that happens.
Continuous Discovery and a vision document
If you're following the practices advocated by Teresa Torres in her book "Continuous Discovery Habits" where you are consistently talking to customers and constantly updating where you're headed, you might wonder how that would align with the practice of capturing a vision in the way I'm describing. It aligns quite well because her concept of "outcomes" aligns to the "outcomes" section of the vision and her concept of "opportunities" aligns both to the "problems / potential" section and to the "product / process changes (bets)" section. In this way, think of the vision as being an organizer for one or more opportunities that can be found within her concept of the "opportunity tree".
More to the point, it can be easy to focus so much on exploring opportunities that you forget when you need to actually come up for air and let others know what you're doing. Again, a vision not only helps you know where you're going. It also helps you know when to broadcast out information about changes in direction to others who also need to know. There might be whole sections of opportunities (i.e. branches in your opportunity tree) that you can explore and iterate on for weeks on end without ever changing the vision. Then along comes one seemingly small opportunity that is actually part of a whole separate opportunity branch and where you would need to broadcast out information first to specific stakeholders before going too far with your discovery.
For example, let's say you are exploring all sorts of ideas and iterating continuously on a scenario Teresa used in her book - streaming services. Let's say your vision talks about improving total watch time and you're exploring what kinds of presented information will help encourage people to watch something. But then, as you're exploring that, you decide to try out sporting events instead of just movies (again, an example she uses in her book), and you decide you want to do this to see what kind of information needs to be presented for different genres of content.
But let's say that the original vision you're working under only called out feature films, television series, etc. and had sports specifically listed as out of scope because the sports marketing department specifically wants to be involved if their content's presentation is being considered - and they specifically weren't ready right now to participate in a project due to other priorities they are working on. You now know you might need to either create a new vision for exploring sports and prioritize it for some time down the road when the marketing dept can get involved or you need to make your case for why it's important to get the marketing dept involved now even though they have other competing priorities.
The CAPS acronym
Regarding the linking of a bet to the appropriate product vision(s) impacted, I like to use the acronym CAPS as a reminder of the types of things and their names that the general term "product" can also refer to:
Thinking that a product is an application or a software system is not too much of a stretch. However, some components are large enough that they need to be treated like a product unto themselves in that they need their own vision to control their scope.
Processes also have many of the same attributes as products in that they are designed to solve problems, they have recipients of value, and there are various philosophies that must be captured to help govern and control scope as the process design evolves. Don't think that only software products need product thinking and visioning discipline.
The importance of having defined Customer Journey and Service Blueprint artifacts
Linking to applicable processes is especially helpful if you've taken the time to organize your company's processes in a way that connects to the overall customer journey steps and service blueprint processes for your organization. If you've done that, it facilitates quick and easy navigation to review those things for a few moments when thinking about which process you are impacting with your vision.
For instance, if you're totally focused on designing and selling a new product, a simple review of the customer journey that the sales process connects to can remind you that perhaps you forgot to consider return or refund implications for that product. Such simple perspective reminders can lead to more early-game strategizing and can head off lots of late-game scrambling.
In the reverse, when a vision starts being worked on, it's a good idea to link to that vision from the impacted customer journey and service blueprint areas on future-state versions of those artifacts that show people which visions are in flight for which sections . If such grouping artifacts do not exist and/or are not reviewed frequently, it's possible for different groups to end up working on related, overlapping, or contradictory visions without realizing it.
Out-of-scope
This topic is about which functionality needs to be clearly designated as out of scope for this vision (i.e. which things are you intentionally choosing to not take on as part of your work).
List out-of-scope items here that address reasonable scope assumption errors people might make. You should keep this section usable by avoiding the temptation to list every possible thing that's out of scope. At the same time, if you are unsure, let your bias be in favor of listing what's out-of-scope for the sake of clarity.
If you don't have an "out-of-scope" section, there can be a temptation for a project to just grow and grow as new realizations come to bear about needs that can and should be addressed at some point. In other words, rather than trying to make your project do everything, you can put future items in the "out-of-scope" section so that you have acknowledged and recorded them.
Sometimes people fall for the "might as" touch (i.e. like the "Midas" touch from the Greek myth). This is where they say "well, while we're at it, we 'might as' well do this and we 'might as' well do that". In other words, because some sort of organized effort has emerged in the form of the current project, people want to piggyback on to that effort by loading any and everything they see that's going to be needed on to the current project. This is a great way to cause a project to die under the crush of its own weight. Don't fall for this trap. Use your out-of-scope section to keep your projects small and manageable and, on a larger scale, use your vision backlog to capture ideas and areas that can't be tackled now so they are not forgotten.
Finally, depending on the item, you might need to provide some context or commentary for why you are designating something as out of scope. Is it because you never intend to deal with it or is it because it's going to be tackled in a subsequent phase? Noting that can be helpful.
Regulations / Restrictions
This topic acknowledges which restrictions and/or constraints (business, legal, technical, etc.) will require compliance as this vision is implemented.
This is where you would note any mandates, stipulations, etc., that are not up for debate as part of the collaboration process. This topic should not be used for merely stating strong preferences. It should be used sparingly and only to acknowledge actual compliance demands. This usually comes in the form of these specific sub-topics:
Regarding information security needs, an example of a regulation might be "there cannot be any storing of unencrypted sensitive personal info (PII)".
Regarding business tech constraints, one example might be if you are working on a financial services product and it's going to have to communicate with a specific external API to get the information it needs. If you know that attempting to ask for changes to that external API is off the table (ex. for contractual reasons), then you might state something like "communications with the XYZ API must follow the formatting and security guidelines established by that product due to contractual reasons". This way, people who come along later on during implementation and express what they think is a good idea by saying "why don't we just contact XYZ corp and have them change their data input" will know it wasn't personal when their idea doesn't get pursued.
Tenets
This topic includes three areas of philosophical clarification:
Experience guidelines
Regarding experience guidelines, these are high level statements that help guide design. An example might be something like "Each screen must be able to be reached through navigations presented within the product" or other similar kinds of high level guidelines. If there is a style guide available for the product, a link to that might make sense to include here.
System of record clarifications
System of record clarifications are necessary to help establish the proper relationships between products, systems, etc.. If the vision topics addressed in this article are being used specifically for a product vision, clarify here which information the product in question is the system of record for.
Note that sometimes the system of record changes depending on the circumstances and where you are in a given process. For example, one system might be the system of record up until a certain event in a process happens - after which a different system necessarily becomes the system of record moving forward.
"A over B" preference clarifications
Regarding "A over B" preference clarifications, let's understand this by looking back to television in the 1980's for a moment. At that time, Miller Lite ran an advertising campaign where they had a series of commercials - each featuring two people arguing over what was the best thing about Miller Lite. One would argue "Tastes Great!" and the other would retort with "Less Filling!". The joke of the commercial was that these two people would go back and forth repeating their arguments to each other over and over again with no resolution as to which one had the better point.
This same type of conversation dynamic can often play out in business settings when you have two stakeholders who each are advocating a valid position but where the circumstances don't allow for both positions to be sufficiently satisfied. When this occurs, you will often see "circular" arguments where people go back and forth advocating their position over and over again at each other much like the people did in the Miller Lite commercials because they are desperately trying to avoid having to make a hard choice.
When such circular arguments emerge, there comes a need to "break the cycle" by making the hard choice of specifying which of the two values is preferred over the other.
This approach of clarifying which competing value wins out is actually very similar to the approach that the authors of the Agile Manifesto took when they crafted their four key value statements.
Breaking the spin cycle of "A" vs "B" sometimes needs to have someone in a position of authority who can render such a decision if it can't be worked out gracefully by the stakeholders involved. Sometimes that person is the one driving the analysis, such as the Product Manager. However, sometimes it can actually require going up the chain of authority in an organization to get a final decision because the business implications are actually beyond the scope of the Product Manager's authority.
Some products and projects never end up needing any A over B clarifications in their visions while others might need several.
Involvement
Involvement is where where you capture a roster of the anticipated stakeholders and teams involved as well as what their involvement is anticipated to look like.
I'm personally not a fan of a traditional RACI matrix but I am a fan of capturing a roster of involved stakeholders / teams with organic comments about their involvement.
Involvement typically takes two forms:
This section is where one needs to acknowledge who is going to be sought out as information resources so that key voices don't get overlooked or forgotten. It's easy to get caught in the trap of thinking purely about implementation (i.e. who is going to be doing the coding, testing, etc.) and to forget the time and resources involved in the ongoing analysis that needs to happen all throughout.
Of course new voices will be identified along the way, but that doesn't mean you avoid writing out who you plan to involve. Again, trying to keep everything in your head is a great way to overlook key details in the heat of the battle. Capture all of the people, teams, departments, etc. you can think of who it makes sense to consult given what the effort is about and briefly capture what you think their involvement will look like. This is key to help you know what your refinement workshop attendees list needs to look like.
This is also where the conversation around time needs to be captured...
Being wrong but talking about time vs pretending there's no need to talk about it
Often, assumptions around time commitments will be wrong. But it's better to be wrong and start somewhere than it is to pretend the conversation doesn't need to happen.
This is a tricky area because agile frameworks usually assume long lived software development teams that work ongoing in a dedicated fashion through a backlog with a dedicated Product Owner as a continuously available and "all knowing" resource. In other words, with those assumptions in place, there's a default position of any software work being "sunk costs" and thus there's no need to run extensive cost-benefit analysis around it for new development.
However, like I've stated previously in this article, the assumption that the Product Owner will be able to answer every question or have all of the information in all instances is not always realistic.
Stakeholders and subject matter experts (SMEs) have time schedules as well. They are not always 100% available to support an engineering team's execution - often precisely because of the responsibilities that make them SME's in the first place. The warehouse manager is the SME on warehouse operations because she's dedicated to running the warehouse, not because she's continuously available for meetings with the engineering team or the Product Owner/Manager on business logic surrounding one or more stories that happen to involve warehouse operations.
Running effective analysis might involve making adjustments in expectations so that the necessary SME's can be made available. Maybe the warehouse manager needs to be excused from her usual meetings for a few weeks. It's hard to have conversations around what those adjustments might be if there's no general working draft of assumptions around what kind of time commitment is reasonable.
Cost benefit
There's also the issue of overall cost-benefit. Again, initial assumptions will be wrong and will undergo many revisions as the development effort evolves for a given endeavor. However, if there is no contemplation at all of cost-benefit, then it is really easy to continue developing iterative improvements on a given product long past the point when such efforts should have stopped because of diminishing returns and cost overruns.
If cost benefit analysis gets involved or lengthy, this section is where links to more extensive cost benefit analyses would be placed. Don't try to overload this section when a link to another, more focused artifact will suffice.
Obstacles and assumptions
Obstacles are threats that represent actual or potential risks, set-backs, and other challenges you anticipate as possibilities. To keep this conversation topic productive, I specifically avoid, and ask stakeholders to likewise avoid, the temptation to indulge in extravagant scenarios like "what if an asteroid hits the earth". Instead, I focus on acknowledging realistic obstacles that have a somewhat reasonable chance of occurring. This section also establishes a place you can come back to for capturing brief commentary on obstacles as they come up.
Assumptions include fundamental beliefs that, if proven incorrect, will threaten the product or project. For example, if you are creating a vision for an online sales form for purchasing a high dollar item, one assumption you're making is that the personas you're targeting as recipients of value will be willing to use an online form for purchasing something that expensive in the first place. If that assumption is proven wrong, your product idea will most likely fail.
The goal of this section is not to try and meticulously plan out every contingency. Rather, think of it as a place to capture some general comments and thoughts about what you might have to do as a group if you do encounter one or more of these challenges.
As far as specific open questions are concerned, I tend to note those throughout the vision document in the specific area where the question pertains (ex. system of record questions should be noted in the area that captures system of record info) as opposed to consolidating them into a single place like I do with issues. I often highlight those open questions when they are present within a vision doc to call attention to them so that people can see the questions in context within the subject. Such highlights can act as visual reminders as to which sections of the vision are clear and which ones aren't.
Noteworthy events
This can be, admittedly, a vague category. It exists because there will be times when significant events happen that affect the project or product vision and that need to be noted somewhere in order for someone to understand the history. Specifically, this topic is more about explicitly looking back to the past and recording specific, special historical events rather than looking forward - which is different from most of the other topics.
You might be asking - why bother with recording a history? It's because a vision doc needs to provide the essential information and direction stakeholders need now to make decisions now, and some of that involves understanding why certain changes were made in the past.
You don't want to be extensively recording history throughout the vision doc or else it can make the other sections unusable. That's why you will want to use this specific section for that purpose.
You also don't want to necessarily record every change here that was ever made to the vision. This section isn't a traditional waterfall "change log". It's meant to capture heavy hitting changes.
You might be wondering why this section exists when most modern document / artifact solutions provide an extensive change history. For example, if you use something like Confluence, you can go back and see who made which changes to a document over time. But what that doesn't tell you is WHY that person made those changes. It's capturing the WHY that makes this section relevant and distinct.
Types of noteworthy events and what info you might want to capture about them can include the following:
If the history gets to be extensive for whatever reason such that this section becomes unusably big in comparison to the rest of the vision, consider moving it to its own satellite artifact and replacing this section with a link to that artifact.
Alternatives
This topic facilitates a sanity check about what alternatives there are other than executing on the vision as stated. When first crafting a vision, it helps everyone explicitly think through alternatives before moving forward. After work has started, it provides a consistent place to capture outcomes of alternative suggestion conversations that have come up along the way.
There will always be at least one alternative option - the status quo; meaning, if we don't move forward with our plans, what would we be left with?
Each alternative option needs to have four things listed:
领英推荐
Keep in mind that these can change over time. The point is that this is an up to date record of current thinking.
Links
This area clarifies what additional information is available that's relevant. .There are two main categories of links:
Implementation links
As I've already said previously, a vision doc is not an implementation plan. Instead, people need to be able to navigate to the vision and, from there, find relevant info and links to other info - especially the subsequent implementation information.
One problem I've seen in various places I've worked is where people try to combine an implementation plan and some of the vision doc topics into a single comprehensive artifact. Doing this will create several negative outcomes - such as an unwieldy, "ginormous" document and a tendency towards approval processes being brought to bear on lower level details that compromise the kind of agility that is needed to be effective.
Let the product manager/owner and the engineering team have authority to work through the details of implementation while keeping any approvals that might be involved to more of the higher strategic level to maximize agility.
More to the point, trying to combine vision level strategy and implementation level requirements and tasks into a single artifact starts to become "comprehensive" documentation instead of simply trying to provide "sufficient" and appropriate documentation.
If the project will only involve development work, then the implementation plan links might be pointed at something like an epic or epics in a tool like Jira. However, if there will also be numerous business tasks that have their own dependencies within themselves in addition to the user stories, having some sort of evolving artifact or system that is helping keep track of those dependencies might be what you link to here - especially if the tasks involve business stakeholders who actively don't engage with a tool like Jira for their normal task management.
Managing change
Don't think that just because I'm calling an implementation plan a "plan" that I'm advocating a traditional waterfall approach where one foolishly tries to capture ALL business decisions up front and then assumes (incorrectly) that they won't change. Your implementation plan will change all the time and it's expected that will happen.
You will also start off not knowing everything that needs to be done. Initially the size of your plan artifact (which, again, will be separate from your vision artifact) will increase as the number of tasks and dependencies that people didn't account for emerge. Also, new tasks that weren't anticipated will need to be added and other ones will also drop off as people come to realize some tasks aren't necessary. This is all change that's to be expected.
What you need to watch out for is whether the overall number and size of outstanding, uncompleted tasks is trending upwards consistently. Some initial upward trend is to be expected as initial learning takes place, but if the number of new uncompleted tasks continues to go up faster than tasks can be completed, then some scope decisions need to be made. Phase some things out that can be dealt with later and utilize the "Out of Scope" vision topic to capture those decisions.
An implementation plan is not just the backlog
One mistake people can make is to assume the only details that matter are the ones applicable to them. For example, a software development team might think the only thing that matters is the code - so why have any sort of implementation plan captured other than just user-story Jira tickets in a prioritized backlog?
The reality is that there can and will be many business decisions that need to get made throughout the course of the project or the development of a product that the product owner/manager must face and manage in their role that aren't always the direct responsibility of the other team members. These can create delays and dependencies all throughout the process. That's to be expected.
Traditional agile frameworks often handwave away this reality of emerging business dependencies, delays, and complexities in the Product Owner's role by simply assuming there is an all-knowing Product Owner who is always available and always has any answers needed by the engineering team without any significant delay. If this is true for you and your organization, then perhaps the product backlog is all you need. In many cases, this is simply not the reality people experience.
The Product Owner might have to navigate getting decisions out of a variety of stakeholder groups - such as the accounting department or the actuarial department. The Product Owner might have to wait until certain contracts get signed or approvals go through before they will know which kinds of stories to present to the team. The Product Owner might be iterating with no-code prototypes and working with customers to "fail fast" and find solutions that work within the agreed upon vision objectives before they even know which specific stories are needed to execute on a piece of the vision. Tracking all of these tasks and follow-ups needs to happen somewhere for the Product Owner because it's too much to keep in one's head, but the engineering team backlog is often not the place to do that.
There needs to be an implementation plan artifact. That artifact will need to be capable of tracking the dependencies that come up and it needs to be able to change and evolve A LOT over the course of a project. That artifact helps a Product Owner do their job of presenting stories to the team and tracking whether the team has been provided sufficient stories to account for everything that's currently known. That artifact is not the vision doc, but it needs to be linked to from the vision doc (and vice versa) so people can find it quickly and easily.
Creating connectedness and findability
Individual tickets in the backlog need to be connected to the vision they are serving - either through direct links to the vision doc or via links to grouping mechanisms like Epics that subsequently have the links to corresponding vision docs.
The point here is that each story needs to know what vision its serving and anyone working a story needs to be able to easily navigate using a few clicks to the corresponding vision for details beyond what's just captured in a specific user story so they can get the larger perspective. Likewise, in reverse, anyone reading a vision needs to be able to easily navigate towards the implementation details as needed - but trying to put all of these pieces into a single comprehensive artifact is NOT the way to do this.
Info links
The vision doc should be an organizing source of info for people. If someone wants to know about a product or project, they should be able to go to the corresponding vision to learn about it.
However, just like how a vision doc should not double as the implementation plan, a vision doc should not bear the burden of including every piece of relevant information all in a single artifact.
A vision doc is not the instruction manual, nor is it a repository for detailed descriptions of business logic - but it should be the first place you might choose to go to find out where those other things are.
There will be what I call "satellite" artifacts of all kinds that a vision can direct people to in the form of links. These satellite artifacts include, but are not limited to, things like architectural diagrams, process definitions, relevant company policy documents, critical business meeting notes, and so forth. These info links need to be included in the vision doc in an organized way, but they are situated as the final / bottom vision topic section so the list can grow as needed without interfering with the ability to view the other PROPORTIONAL topics.
This info links section is especially useful to the person running the analysis for because it helps them and everyone with whom they share the vision find relevant information quickly that pertains to the project, product, or ongoing responsibility that the vision is contemplating.
Knowing which artifacts you need to link to in a vision also helps you know which artifacts might need links in their content to the vision you're working on. In this way, this section can serve to highlight reciprocal relationships.
Three additional meta topics at the top of your document...
Relative Priority
The information for this is expressed by virtue of the relative positioning of this endeavor's vision against that of other visions competing for attention.
Executive Summary
Your executive summary is a one sentence (30-second) elevator speech that summarizes the vision in a nutshell.
This executive summary section is the first thing I list at the top of a given vision document because it needs to be the easiest thing to find for an executive. However, it's actually the LAST thing I capture - and only AFTER working through all of the other vision conversation topics discussed previously in this article.
The reason for creating the executive summary last is because I've usually found that filling in the summary before working through the rest of the topics reveals that the initial summary people had in mind was actually very incorrect. In other words, the process of working through the topics outlined in this article in the general order that I've outlined has a fundamental impact on how people are thinking about a project or product.
Here's the format for the summary sentence:
Because <problems/potential summary>, we will help <recipients of value summary> to experience? <product / process solutions (bets) implementation summary> so that <outcomes summary>.
To be able to write such a summary, you must have enough info about your first four vision topics so you can adequately summarize them. However, this does not mean you include every problem, recipient of value, outcome, or implementation found in your vision in the content of your summary sentence. Instead, you fashion a working sentence that is conversational in nature.
The purpose of the summary is to facilitate conversations when external stakeholders ask about the product or project. For example, if a stakeholder asks "What is project 'x' about?", the Executive summary allows you to quickly provide a meaningful, brief response. You can then provide additional details if follow-up questions are asked of you.
If you don't have a prepared summary ready, it is easy to fall for the trap of launching into a long winded, winding explanation that is heavy in details. Doing this can actually undermine others' confidence in you. People in higher positions of power (i.e. executives) can be tempted to reason "If this person can't explain it simply in a way I can understand, then perhaps they don't actually know what they are doing."
Have your summary ready.
Point of contact
This is a meta-topic that needs to be settled as early as possible so the initial vision meetings can run smoothly (more info on these meetings to come later in the article). Without addressing this topic, it's possible either the wrong person will drive the initial meetings and subsequent analysis or, worse yet, no one will end up driving them.
The point of contact driving the early vision meetings should also be the point of contact who will drive the analysis
A vision doc should not be kept a secret. It is not simply an "upfront" thing that goes away into obscurity once everyone starts digging into experimentations, implementations, and user stories. It should be actively used throughout the lifecycle of a project, product, or responsibility to clarify questions and set context for analysis conversations. It should be continuously used as questions arise so that decisions can be captured and strategic direction clarified when needed. This is one of the main reasons why whoever is driving most of the analysis of the project or product needs to also be the one driving vision conversations and owning the updates to the corresponding vision document. The subsequent requirements analysis discussions will be informed by the strategy and values that are captured and expressed by the vision.
Don't have someone who's on the outside looking in when it comes to analysis be the one driving vision meetings or owning the vision document. They won't have the perspective needed to recognize whether the answers arrived at and captured in the vision document are sufficient to subsequently aid the analysis work involved.
Specifically, the traditional role of project manager is one that is focused on efficient implementation - but vision document topics are about the strategy behind that implementation. Thus, a product manager, product owner, or business analyst is usually the right role to be driving these kinds of vision conversations as they will be the ones using the vision doc over and over again to set scope and perspective in requirements analysis meetings and other such meetings in an ongoing fashion.
Chicken and egg at scale
Because of the importance of having the right person drive analysis, the subject of identifying the main point of contact can either be straightforward or difficult depending on the context.
If you are in a small, one team setting, it can be pretty clear who should drive a newly proposed effort - but this can get harder in scaled scenarios where ideas or initiatives can cross-cut different departments and different teams. Specifically, you can find yourself in a "chicken and egg" situation where you need enough critical info about a potential endeavor to help you determine who should drive the effort on gathering critical info about the potential endeavor.
The best way to address this is to attack the problem from both ends:
Lots of factors can impact who the best person is to run point on an endeavor. Sometimes it's sheerly a matter of competency and experience - but not always. Sometimes bandwidth or scheduling become critical factors. Sometimes it's simply about the domain or area of responsibility - such as when an idea will impact only one product and there's a clear product manager for that product. Sometimes it's more murky - like when an idea necessarily impacts more than one product and where each product has a separate product manager.
You might discover in the first "draft" meeting (which we will discuss later in this article) that the idea is actually very different than how it was portrayed prior to that point and that it would make more sense for someone else to drive the analysis. That's ok. The point here is that you try to make sure you identify the right person as early on as possible so the endeavor has the greatest chance of succeeding.
Support info needs to be included in the Point of contact section for product vision docs
If the vision is specifically for a product, it not only needs to be clear who the primary point of contact is for answering questions, but also what is the primary means of contact for support requests concerning that product. Perhaps there is a link to a support request form, a link to a Slack channel, an email address, a phone number, or other important info that is essential for people to know who are wanting help and support concerning that product.
2. The role of documentation in an Agile environment
I've found there are some funny attitudes in the Agile community about documentation. Specifically, there is a statement from the Agile Manifesto that gets frequently misinterpreted. It reads as follows...
"Working software OVER comprehensive documentation"
There are many who misunderstand that statement in the manifesto and read it as "Working software WITHOUT ANY documentation" - meaning they think it's saying there's actually no value in any documentation of any kind.
This misinterpretation happens all the time even though the authors of the manifesto specifically accounted for this by stating...
"while there is value in the items on the right, we value the items on the left more".
In other words, it's not that the items on the right have NO value. They have value. It's just that their value is comparatively less than the value of the things on the left. In other words, if we are put into situations where we must choose to pursue one value at the expense of the other, the value on the left should win out.
This means documentation is not bad so long as it doesn't come at the expense of pursing the first value of working software. That's very different than the idea that documentation of any kind has no value.
"Comprehensive" vs "Sufficient"
As you read this article, you might be tempted to think I'm advocating for "comprehensive" documentation - but I'm actually not. "Comprehensive" documentation implies an extent. In other words, there is a difference between "sufficient" documentation and "comprehensive" documentation.
Part of achieving the goal of "working software" is having "sufficient" clarifications to create the necessary context for the kinds of agile conversations that go into making a successful product - but trying to achieve "comprehensive" documentation is not what I'm advocating here.
I've noticed a tendency for people to embrace an "all or nothing" mentality where it is believed that either we are going all in on over the top, waterfall, comprehensive documentation or we're going with no documentation at all. Neither extreme is healthy. There is a balance. Part of my argument in this article is that the proper balance point involves documenting the vision topics outlined here - and that constitutes more documentation than some might want to acknowledge.
Artifact value
Remember that the conversations and shared understanding that are generated during the creation and subsequent updating of a vision doc are what's truly important because they help set up analysis and execution conversations for success. In other words, the process of creating the vision document is as important, if not more important, than the actual document its self.
At the same time, the value of using an artifact to capture vision instead of just leaving it undocumented includes, but is not limited to, the following...
It compensates for the fact that there are a lot of important vision conversation topics to discuss.
People don't have great memories. Keeping all of the related information consistent when it is living only in people's heads and isn't written down anywhere is a tall order.
Using a written document helps clarify explicitly whether something is an actual decision yet or if it is still just an idea being discussed.
It's amazing how often this simple nuance can create so much noise if it's not handled properly. A document helps make this much clearer.
People feel differently about their words when they speak them vs when they hear them vs when they see them written down.
I've lost count of the number of times where someone told me "I need 'x'", then I repeat back to them "so you need 'x'?" and they respond "no, that's not what I need at all." As silly as that may sound, it's actually not silly at all.
The act of phrasing our words and thinking about what we're trying to say interferes with our ability to hear how what we are saying comes across. Often, simply restating back to someone what they have said can help them appreciate how what they said actually sounded - which gives them an immediate chance to correct misunderstandings.
But writing things down can go even further. I've had it happen before where a person made a statement in a meeting. I restated back what they said and they confirmed it was correct. Each person in the room also nodded their head in agreement that my restatement was correct and that the idea expressed was correct. But then, once I started writing that exact sentence down verbatim for all to see in a document I was projecting on the monitor, everyone suddenly started to realize and verbalize why that statement was actually not correct - even though they were convinced it was absolutely right mere seconds ago.
The more people there are involved in the process, the more important it is to document things so people can get consistent information.
If you and three other people are the only ones working on something, it's a lot less pressing to have to explicitly document the number and types of assumptions needed than if you are trying to coordinate the work of multiple teams across multiple departments.
In a scaled situation, not everyone can always be in every conversation all the time to receive nuanced clarifications first hand about assumption misunderstandings as they emerge. Getting the key vision topics documented and presented in a consistent place people can find and be directed to can help cut down on the churn that can otherwise arise if nothing is documented.
When at scale, relying purely on verbal transmission of important vision details can result in different people hearing different versions conveyed in varying degrees of accuracy with different details emphasized at different times as they are conveyed through different conversations.
Don't misunderstand. Conversations are crucial - but supporting those conversations with documented explicit core assumptions is much better than trying to have those same conversations with undocumented, implicit core assumptions. When assumptions are explicit, people will ask better questions and conversations can run much smoother because everyone has a much clearer idea of what the vision is they trying to work towards.
Different people can recall different versions of the same conversation and then realize only later on that they have conflicting expectations as a result.
People's memories can play tricks on them and cause churn in the process. People tend to forget some details while remembering other details in ways that favor their personal biases. Insisting on documenting vision topic decisions in a predictable place and then reviewing them frequently helps create a clear system of record that can cut down on the emotional churn that can otherwise arise from natural faults in human memory.
Capturing vision helps combat organizational "hesitancy"
Organizational decision "hesitancy" is where nobody is willing to ever commit to any strong, specific strategic decisions because they intrinsically know that, without documentation discipline, there's no consistent way to remain accountable to anything more specific than just a few general notions people can keep in their heads.
Personal time management as a metaphor
The results of documenting decisions are very much like the results of keeping a calendar from a personal time management perspective.
There are people you might know who never bother using a calendar or day planner of any kind. Such people might say calendaring is "too much work" or it isn't worth it because "plans change all the time". But what often comes with people who take that approach is that they struggle to commit to even a handful of events - and even then they will feel overwhelmed at those few things they do actually commit to.
This is because people who don't document their plans are trying to keep everything in their heads. They end up wasting brain cycles "re-reminding" themselves of those few things on their plate over and over again instead of letting their calendar do the remembering for them... and it's exhausting. (This concept is explored well in the book "Getting Things Done" by David Allen.)
Any more than a handful of events in the coming week might cause someone to feel emotionally fatigued at committing to anything further because they don't trust themselves to remember anything else.
If one isn't willing to pay the price to keep a calendar but yet still wants to commit to lots of things, then one needs to be prepared for consistently dropping the ball as one naturally forgets to be at specific places at specific times.
However, when someone actively uses a calendar, they can schedule appointments and commitments several days out and at very specific times. They can even squeeze things in between other things. Instead of maxing out at just the few events in a week that they can remember, they can schedule a few events in a day or even in an afternoon and they aren't emotionally overloaded because, again, their calendar is doing the remembering for them.
Even though they know their calendar will change all the time and unexpected events will consistently emerge, they don't throw their hands up in the air and say keeping a calendar is worthless. Instead, they engage in the discipline and continue to update their calendars as needed because they know it's much better than trying to keep everything in their heads.
When plans do change, the flexibility offered is one of allowing people to see the trade offs. Internal dialogues take on much more fidelity such as this:
"If I end up cancelling this meeting, then that means I'll have to reschedule here - and that means this other thing won't get resolved this week... but that's ok with me because this pressing thing that's emerged is more important."
Using a documentation/calendaring system actually allows a person to be MORE AGILE, NOT LESS in how they manage their personal lives. It makes them more aware of the kinds of trade offs they are faced with and, thus, allows them to be much more deliberate as they change plans day to day, hour to hour, or minute to minute.
The same holds true with key decisions captured in a vision document. The number of topics that need to be captured is easily enough topics for people to have trouble remembering nuanced details if no one is documenting the decisions in an organized way.
3. How to set up and use a vision document
The vision topics can be used to define projects, products, and/or ongoing responsibilities
I use the vision topics addressed in this article when defining a project, but I also use the same topics when defining a product vision or an ongoing responsibility for a team. The only major difference is a project has a clear beginning and end while a product or an ongoing responsibility doesn't always have such an identified conclusion.
A vision document can also act as a litmus test for when certain kinds of information should be broadcast out more deliberately to external stakeholders as we shall see momentarily.
Use a singular wiki page or web page as the place to capture your vision doc - NOT an individual file
Use a web page or wiki page (such as a Confluence page) for your vision doc and then consistently refer people to that page using a LINK . This is because the vision will change and can change quite frequently. If people have links to the same page, they will always be referring to the latest version.
If you avoid this advice and use a Word doc, PDF, Excel spreadsheet, etc. and then send stakeholders copies of that file as attachments (either via email or some other means like Slack), know that you will find yourself watching multiple copies of outdated files fly around all over the place as attachments in short order causing all sorts of confusion with your stakeholders.
Even if you try to use versioning numbers to call out which version a file is, if someone is looking at a file, they may not realize that what they are looking at is actually not representative of the latest version.
If your company is small enough that it cannot afford to set up a wiki or web page based source of info (such as Confluence), at least use a simple free solution like a Google doc so you can send people a link to a single, consistent document. DO NOT send attachments.
Use progressive roll-out when drafting a vision
I use an approach I call "progressive roll-out" when drafting visions. This is essentially a fancy way of saying that the more people there are involved in a meeting, the less likely that meeting is to run successfully and effectively without an explicit draft to work off of.
Starting with a room full of people and a blank canvas is a great way to waste a lot of people's time and sprawl around quite a bit before the conversation eventually takes shape - especially if you are trying to keep your projects as small as possible and the initial time it takes to arrive at a draft to a minimum. This applies even if you have a template with the topics in this article called out. If no content has been filled in for those topics in that template, you're essentially starting with a blank canvas.
People are usually better critics than they are creators. Having a draft with content filled in, even if it's rough or incorrect, will usually drive group conversation much faster towards usable outcomes because it gives people something to criticize.
I usually start with two early, important, foundation meetings when rolling out a new vision:
1. Set up a 1 hour "draft" meeting with an identified "main" stakeholder and "maybe" one other key stakeholder to get a working vision draft in place.
This is where you can start with nothing filled in on your template because the audience is small enough for the conversation to still work. One hour is also a nice timebox for a minimum amount of analysis so you can at least produce some kind of draft to use as part of your organization's prioritization process (ex. in case extra steps are needed for you to justify scheduling the second foundational meeting before the appropriate stakeholders can or will attend).
The maximum number of people in this draft meeting should rarely (if ever) be larger than 5. That's because having 1 or 2 stakeholders, plus the product manager, product designer, and engineering lead is about the max a meeting with no draft in place can handle and still be somewhat effective. If you try to add more people beyond this, you'll most likely experience significant diminishing returns.
Avoid the temptation to try and perfect your draft before showing it to anyone. That's usually going to be wasted time. Get a draft together and then get to the second meeting as quickly as you can.
2. Set up a 1 hour "refinement" workshop with whichever stakeholders make sense to invite based off of the info captured in the working draft.
Some of the purposes of the refinement workshop are to start getting feedback about the direction of the vision from others, to answer questions from people who might be involved, and to kickstart conversations amongst impacted stakeholders so that subsequent follow-up discussions have the backing of some initial context if things move forward. But the MAIN purpose of this second meeting is to arrive at a vision draft that's gotten just enough analysis around it with just enough stakeholders to allow it to be prioritized against other visions currently being pursued.
After these first two foundation meetings, things can vary a lot depending on prioritization within your organization and what the details were that emerged in your vision discussions.
It might be that the two meetings produced a vision that actually doesn't align with the organization's current priorities in a way that justifies any further action. That's ok. At least you know sooner rather than later and you've only spent a few hours on it - not days and days - so the cost is relatively small.
If the vision does receive priority, I then expose the vision to more and more people who were represented in the refinement workshop in a targeted fashion as those people become involved in the analysis and execution for the project or product.
Crucial representation in the refinement workshop
I've found that working through the vision topics addressed in this article usually can be done comfortably using the two foundation meetings - with representative stakeholders in the refinement workshop- and then using smaller progressive roll out to targeted individuals for whom representation was present in those initial meetings.
For example, if part of pursuing an initiative means talking to several employees in the warehouse to get some details about processing returns, then Debbie the warehouse manager might have been one of the stakeholders at the refinement workshop so you're good to go to engage with those employees without problems.
However, if proper stakeholder representation doesn't occur in the refinement workshop, progressive roll out can break down. Instead of reviewing the vision with people who were properly represented to begin with, it instead becomes an exercise in springing your vision on unsuspecting people who might have had no forewarning.
These types of coordination challenges are some of the reasons why creating and prioritizing visions within your organization is so important. If the conversations you're trying to schedule are in service of a vision that's been clearly prioritized within your organization (ex. if your vision is servicing an OKR for the quarter), then you have ground to stand on when asking people for their time. However, without that clear strategic backing from a prioritization standpoint, you might start to get unexpected push back from people who didn't realize you needed their time or who might start to balk at the amount of time you are continuing to need from them.
The vision backlog
Perhaps the vision that's been drafted is something worth pursuing, but not yet. If so, then put it in a "vision backlog" of possible endeavors you might pursue later and review that backlog from a strategic planning perspective the same way you review the product backlog when preparing to pull stories in for sprint planning.
It's possible that, if enough time passes, you might find you will end up not needing what the vision was pursuing. If so, then discard it just like you would discard stories from the backlog that end up proving unnecessary.
If you do end up later on coming back to the vision in the backlog because now you want to address the problems the vision was contemplating, you might need to run another refinement workshop to update the vision depending on how much time has passed since it was drafted - but, again, that's usually much faster than trying to start all over again from scratch.
Just like how you prioritize your user stories, you will prioritize the current visions being worked on by a team as well as those in the backlog.
What if you get things "wrong" in your first two meetings?
It's possible to get this whole thing wrong. Perhaps the initial "main" stakeholder wasn't the best choice or perhaps the refinement workshop revealed so many problems in the vision that it has to fundamentally go back to the drawing board. That can happen, but the cost of that kind of failure is relatively low compared to the larger cost of trying to start with a room full of people from the get-go with a blank canvas and a longer meeting duration every time someone wants to kick off a project.
It's also much much cheaper than jumping straight into implementation without any foundation meetings - only to find out later there are key pieces of information or key perspectives from involved stakeholders that one of these early meetings would have revealed and that would have saved lots of extra hours of wasted development.
Caveat for external consulting
Note that the suggestion of progressive roll out is aimed primarily at running projects and products internal to an organization with a bias towards keeping project size as small as possible. Some of what is suggested here might need to operate very differently in situations where larger projects are being initiated with external consultants as one might need to go to greater lengths initially to establish basic contexts in more comprehensive ways under a tighter deadline.
Keep it small
If you find that it's taking longer than a few meetings to get your vision off the ground or if you're finding that the document is growing and growing into something more unwieldy, consider that your vision might be taking on too much or needs to be broken up into smaller, more manageable pieces where possible.
If your organization is working under the assumption that not just strategy but also implementation details can and should all be planned up front and that such planning must be completed and approvals issued BEFORE any actual learning activities and experimentation involved in executing on the project can begin, then there are bigger cultural problems to be dealt with than just project size or the topics addressed in a vision doc.
Know when you need a vision
If you are a product manager in an agile organization where you are actively iterating and experimenting with prototypes and meeting with customers consistently, this article is not advocating that you need a vision doc in place before you even begin each small, simple experiment. However, once you feel like you've landed on something that might have legs and that would need some more dedicated and coordinated effort to go to the next level, then putting together a vision doc as a place to capture key conversation results will help your efforts run much more smoothly.
Test early and often
Keep in mind that any sort of meaningful push towards development should not be based purely on speculation. Just like how a vision needs to progressively roll out, so too should actual development efforts. Test prototypes early on and in small ways before committing to bigger initiatives. Don't think that addressing and documenting the vision topics in this article with various stakeholders means you can get away with planning large amounts of work without testing critical assumptions with your customers early and often. Find ways to test assumptions in small and cost-effective ways and inform your vision conversations with the results of that feedback as early on as possible.
How and why do you use a vision doc to aid analysis?
I usually start any requirements analysis meeting I'm in with a brief review of the purpose of the meeting followed by an acknowledgment of which vision we're actively working towards serving. If the people involved in the meeting have never seen the vision doc, I will pull it up and review at least the executive summary as well as any points directly applicable to the immediate audience before jumping into analysis details with them. I can do this because the vision doc, in spite of the number of topics I advocate, is actually pretty short and the topics help break it up into digestible pieces.
As a general rule, I'm willing to take up to 1/4 of the time allotted for a requirements meeting if needed to review and clarify the vision for the meeting participants. This means I'm willing to take up to 15 minutes of an hour long meeting just to review the vision doc and make sure it's clear in people's heads what we're trying to work towards before jumping into requirements details. Lest you think this is a waste of precious meeting time, the exact opposite is true. This does wonders for my meetings and makes the remaining time way more productive than if we had dispensed with a review of the vision and tried to jump straight into requirements details.
Impact on your meetings
If you clarify the vision at the beginning of a meeting, it gives people the freedom to use their creativity to work towards fulfilling the vision more effectively because they actually know what the vision is. If you don't provide this vision clarity at the beginning of a meeting, two things will tend to happen.
First, all of the burden of scope control for the meeting will rest on you. In contrast, if I have clarified the vision first, I've found that people will actually tend to police each other regarding scope because it is clearer for them what the meeting is trying to accomplish. In other words, everyone (not just you) is suddenly armed with the clarity they need to recognize derailing topics for what they are - unhelpful distractions.
Second, if you haven't shown that the vision is actually a document, the attempts you do make to control the scope of the meeting can come off as personal - as if you just so happen to "like" some ideas and "don't like" others - instead of attempts to honestly and impartially evaluate topics through the lens of keeping to the scope of an established objective vision. If people feel like you're shutting down ideas and discussions arbitrarily, it can quickly create cynicism and disengagement among your stakeholders.
Vision topics can act as alert mechanisms for information broadcasting
It's easy in the back and forth of executing on a project or developing a product for decisions to get made during meetings and in side conversations that are very impactful to other people but that aren't always broadcast appropriately. When you are working in a really small organization and everyone is co-located in an office, this might not be a big deal because everyone will tend to overhear what's going on all throughout your efforts. In other words, the small size of the company helps compensate for potential oversights in broadcasting information.
But in larger, scaled organizations and/or in heavily remote environments, unpublicized decisions have tremendous potential to create resentment when those impacted by the decisions find out about them through unofficial backchannels or find out officially only long after a decision has already been made and implemented.
Part of why this disconnect happens is because it simply doesn't occur to the people involved that others might need to know about a decision. This gets compounded when someone has the positive intention of not wanting to create lots of "noise" in communication channels by avoiding the overload of updating everyone about every detail all the time.
I've found that most of the vision topics identified in this article can act as good criteria for when you should bother alerting others about changes and to what extent you should alert them versus when it's not worth the trouble. In other words, if you're working on a user story and a decision needs to be made that doesn't contradict the core strategies and objectives laid out in the vision, then it's probably safe to make that tactical decision without having to raise awareness among stakeholders. If, however, a change would contradict a specific vision decision, NOW you know you need to at least check with or inform one or more of the impacted people called out in the vision first before moving forward - because either the user story needs to change or the vision needs to.
For example, if one introduces a button on a screen as part of implementing a user story, it might not be a big deal and could be considered simply an implementation detail if nothing in the vision would need to change. But if the functionality behind that new button ends up touching a new major component that was never talked about in the vision - i.e. in your product and process solutions (bets) section - and that component would, by extension, involve reaching out to a team that nobody thought would even need to get involved - i.e. the team isn't called out anywhere in the involvement discussion - then the clarifications in the vision doc now serve as a litmus test for when one needs to bother alerting relevant stakeholders about the change before proceeding.
4. Relating your vision doc to your user stories
Understand the relationship between a vision document and user stories
Agile frameworks actively and correctly resist large batches of work in favor of small, deliverable chunks that support "early and continuous delivery". Specifically, the "I" in the "INVEST" acronym for user stories stands for "Independent" because each backlog item should be independently defined, tested, and delivered. So how do user stories effectively mesh with the notion of projects and project vision when projects tend to inherently imply working in large batches instead of smaller, discretely testable chunks?
Clarifying important high level assumptions and preferences about strategy in the form of vision documents for products and projects becomes important so that the user stories that support those products and projects don't have to individually bear the burden of clarifying those higher level assumptions on their own. A story can simply focus on delivering a small piece of value while being linked to a document that is concerning its self with the bigger picture.
If one chooses to only focus on tactical user stories without addressing the need to clarify strategic business assumptions and preferences, then those assumptions can rear their heads at unexpected times and in dramatic ways. For example, a seemingly innocent sounding discussion around a story that aims at solving a usability problem involving a given screen can end up very quickly transitioning into a heated philosophical discussion about what the purpose even is for the screen as a whole and what should or shouldn't be included on that screen in the first place.
The use of epics
I use epics as tagging and grouping mechanisms for stories. I then either include the vision topics directly in the body of the epic (if the answers don't take up much space) or I have the epic point to the vision doc (such as a Confluence page) for easy reference. This way, every story associated with supporting the vision has a way to navigate to the vision it's serving so there's connectedness and transparency throughout.
Please note that I'm not using the term "Epic" here to necessarily mean a larger project across the enterprise in the way that SAFe (scaled agile framework) uses the term. Instead, I'm using it to denote any situation where you have one or more stories in the backlog where the PROPORTIONAL vision topics need to be discretely answered to give the story(ies) the appropriate context. These usually take one of two forms:
A project for a team is one or more stories aimed at delivering a specific kind of output that needs the scope and discrete priority the PROPORTIONAL vision topics offer. Sometimes a project is solely about a single product over which the team has sole ownership. In that case, the product vision might be what's linked to in the epic. At other times, a project for the team is actually part of a larger endeavor where the team is playing a part in delivering a greater whole involving multiple products across multiple teams.
Projects represent planned work and should have a clear definition of "done" just like individual user stories. The smaller the project is, the better.
An ongoing responsibility represents a category of stories that will flow through the team over the course of time. Ongoing responsibilities are a way of accounting for unplanned work - such as when a critical bug is found that comes seemingly out of the blue and must be dealt with immediately. Unlike a project that has a clear definition of "done", ongoing responsibilities can be long lived - but they still need most of the same clarifications as a project. You need to know what problems you're trying to solve, who the recipients of value are, what the measurable outcomes are you're supporting, what's out of scope, what your philosophical tents are, etc., in order for the responsibility to be properly understood.
5. Using a vision doc to combat antipatterns
Vision docs help combat "grandstanding"
If someone comes in late to the project and says "well why didn't you guys just do 'x' instead?", everyone can quickly and easily see in the "Alternatives" section of the vision if that suggestion was already considered and, if so, why it was decided against rather than having to rely purely on people's memories. If it's not recorded somewhere, it allows latecomers to engage in grandstanding strategies where they attempt to coopt work direction while simultaneously attempting to obtain immediate credibility.
Specifically, if people are stuttering around trying to remember why they decided against a course of action 3 months ago, regardless of how well thought out the decision was then, the appearance of their hesitation now in comparison to the strong confidence of the new person who is boldly making the suggestion creates an opportunity for the new person to take advantage.
Vision docs help combat "high grounding"
"High grounding" is when a stakeholder has the disruptive power to insist that they be in meetings or conversations where technical or process details might be discussed, but where the stakeholder does not have the technical or procedural chops to follow the details of the conversation.
When a stakeholders starts to feel uncomfortable or "in over their head", they might be tempted to start asking seemingly innocent and noble questions such as "who is this for again?" and "what are the outcomes we're looking to achieve by doing this?".
These seemingly good questions can act as cover for the real goal of trying to bring the conversation back up to a level of abstraction where the stakeholder can actually follow what's going on and where they might actually be able to meaningfully contribute - but it comes at the cost of the progress those technical conversations might have made for those doing the technical implementations had their discussions been allowed to play out without the disruption.
When someone starts asking "high grounding" questions in a meeting, depending on how far the "high grounding" stakeholder wants to go, it can make a material difference to pull up a vision doc that shows explicitly what the working answers are to those questions as compared to the appearance of someone trying to recall brief answer summaries off the top of their head.
If you are making sure to review the vision doc before launching into domain or technical analysis at the beginning of your meetings (as I suggested previously), you can even head off such "high grounding" attempts before they start because the people who would be tempted to engage in them would already know that answers to their questions exist in a document that is already available to all attendees.
Vision docs are similar to, but not the same as, project charters
Project charters are the closest thing I've found to what I'm describing here with a vision doc, but they aren't the same thing. For starters, the person who drives the creation of a project charter is usually a project manager, and usually that person will not be the primary person running requirements analysis. This sets up an immediate disconnect between how the document is being constructed vs how it will be practically used during analysis. Also, project charters imply inflexible contract agreements that are established up front rather than trying to establish the beginnings of an explicit conversation vehicle that acts as a living document facilitating ongoing analysis conversations throughout the life of a project.
Defined visions and epics that capture team projects and responsibilities prevent team directional drift and overload
I tend to use a simple tagging system in my backlog (ex. Jira) with my user stories where every individual story has to have a link in it to at least one of my epics. This way, I know every story in the team's backlog is either serving a defined project (be it large or small) or a defined ongoing team responsibility. If a ticket emerges that isn't linked to an epic or where none of the existing epics make sense for that ticket, it sets up a clear way for me to know when a new epic might be needed.
This, in turn, clearly and quickly lets me determine when a new request or story idea is actually representative of a new responsibility, a new product, or a new project that is quietly and subtly emerging. This way, I can rally the appropriate people to get some deliberate vision defined around the emerging initiative and make some proactive decisions about it early on instead of reacting to it only after we've gotten ourselves into something much larger or more complex than we might have bargained for.
Epics facilitate prioritization and bandwidth discussions
By having a list of epics that captures the projects and ongoing responsibilities of a team, it allows me to have a rough, high level priority order representation of what the team is working on and what they are responsible for. This helps greatly when it comes to conversations with management and with other teams because I then have the structure needed to defend the team's bandwidth or to at least discuss it with others if it gets challenged.
For example, let's say the following are epics in priority order for a team with the category of the epic in parenthesis:
Now let's say someone in management comes to you and asks your team to take on the responsibility of maintaining the invoicing system because the team that used to support it has dissolved. Instead of just saying "yes" and then assuming you'll just figure it out as you go, because you have a disciplined epic system, you're armed with the info and perspective needed to ask more telling questions such as:
Without the benefit of having logical groupings of stories - defined using the PROPORTIONAL topics - and where each story is labeled using an epic (or some other labeling mechanism) to tie the story to a simplified, structured, paradigm of bandwidth and priorities, a team can very quickly get overloaded with lots of unspoken projects, responsibilities, and corresponding expectations that management doesn't even realize they are placing on the team in the first place.
When a team has a list of expressly defined projects and responsibilities in the form of epics, that list can function as a very practical expression of and vehicle for modifying team priorities and strategy because it is a list that can be prioritized. That helps me very quickly express to leaders further up the chain what the team is generally working on and in what general order of priority without having to go into an excessive amount of detail - especially if each vision has an executive summary.
If someone wants to give my team a new responsibility, I insist on defining that responsibility in terms of the vision questions presented in this article. Dismissing such attempts at explicit definition in favor of loose conversations about responsibilities creates fertile ground for significant misunderstandings. Hurt feelings and resentment can quickly emerge as a team takes on a new ill-defined responsibility only to find out later on that it involves systems and scope that the person giving the responsibility had in mind, never explicitly communicated, and assumed the team understood when the hand-off happened.
Also, if a team takes on a new project or responsibility, insisting on understanding where that new project or responsibility stands in the prioritized stack rank of the team's existing projects and responsibilities can reveal very quickly what other efforts will be impacted and/or deprioritized.
Such a list also allows the team and the Product Owner to defend themselves when anyone outside the team presumes to question the team's strategic direction. Instead of getting lost in a sea of competing user stories and granular details to try and explain what the strategy is, the Product Owner and the Team have a very straightforward list that explicitly states what the general strategy is. Such a list also facilitates high fidelity conversations with leadership when strategy needs to change.
6. Conclusion
The vision topics presented in this article represent essential scope conversations that need to happen along the way while analyzing and executing in a given area. They resemble, but are not necessarily the same as, a project charter and these same topics can be applied to defining vision for a project, a product, or an ongoing responsibility.
The time it takes to set up a vision is comparatively small and should be done using progressive roll-out to help people have focused, productive conversations. If it's taking too long or the vision is getting too big, consider breaking it up into smaller pieces.
Using the PROPORTIONAL vision topics to clarify the projects and responsibilities taken on by a team helps clarify strategy and facilitates conversations with leadership when changes in strategy are needed.
Neglecting to clarify these topics will put much more pressure on your individual user stories to do the heavy strategic lifting. It also leaves you vulnerable to sorting through lots of small, scattered details as you try to have strategic discussions with leadership about the team's work and direction.
I have never once regretted working through these vision topics on a proposed project, product, or responsibility - but I have definitely felt the consequences of working on endeavors where the people managing them did not want to take the time to address these topics sufficiently.
It may be tempting to look at the number of vision topics laid out here and to dismiss them as "overthinking things". The opposite is true. By not acknowledging the number and type of topics that genuinely need to be defined, captured, and re-examined around an organized effort, one can become guilty of underestimating how complicated products, projects, and the people who work on them actually are.