Vision Driven
Execution
Introduction
The VA Way prioritizes understanding both what we’re building and why it matters, ensuring every product fits into the bigger picture.
As we plan, we balance user needs, business goals, and technical strategies, ensuring we’re creating solutions that meet today’s needs while laying the groundwork for the future.
Every team, whether on the front lines of development or running VA’s core technical infrastructure, should incorporate the attributes below into their work.
Read the attributes below to access the detailed guidance, tools, and resources for each.
Vision Driven Execution Attributes:
1.1 We clearly document a vision for the problem each product aims to solve
OIT aspires to deliver software that comprehensively and effectively addresses the needs of Veterans, their families, and the VA staff who serve them. Teams are expected to document a product vision to ensure:
- Products prioritize the most pertinent issues
- Work scope is clear and focused
High-quality product visions can also serve as a rallying point for product teams, in that they directly tie day-to-day work to outcomes.
Product visions can be very simple, comprising the who, why (i.e., connected to a problem statement), what (i.e., the solution), and how of the product.
Best Practices
- Identify how you will measure how well the product is working
- Define the overall problem and articulate its impact (including affected groups)
- Leverage user research to validate assumptions or hypotheses, then prioritize issues
- Draft a clear vision statement in collaboration with business partners based on the problem and solution identified
- Revisit the vision statement on a consistent basis and update as needed
Guiding Questions
- What is the high-level problem that we are solving for, and why is this important? Is it connected to any unmet needs or known user pain points?
- What is the impact of this problem? Who is affected?
- Is the business partner in agreement regarding our selected solution? What adjustments might we need to make?
- What are possible future problems this solution could address?
Useful Links:
- Link 1
- Link 2
- Link 3
- Link 4
Key Contacts:
- Contact 1
- Contact 2
- Contact 3
1.2 We deeply understand the business functions our software supports, tailoring solutions to real needs
Product teams should work closely with business partners to develop a deep understanding of the functionality their software supports and be able to articulate how end-users typically interact with their software, and the common pain points they encounter.
The purpose(s) of each product will be clearly documented (and regularly updated) as part of the product vision.
Best Practices
- Connect with end-users to ensure solutions are addressing the appropriate business functions (and conduct usability testing throughout the remainder of the software development lifecycle)
- Observe (either live or via recording) people using the product in a real-world setting
- Ensure the business functions addressed by the product are clearly codified as part of the product vision
- Encourage all team members to conduct hands-on tests of the solutions that they are delivering, to better understand the functionality that they are implementing
Guiding Questions
- Who are the key business partners involved in this effort, and how can you involve them more in product development (e.g., encourage attendance at sprint planning, develop product vision together)?
- How can you better involve end-users to understand desired business functionality?
- When does it make sense for team members to start conducting hands-on tests of the products they are developing?
- Have you clearly addressed the business functionalities your product addresses in your product vision? What does the cadence look like for updating and refining the list of functionalities addressed?
- What is different for the business when they have this product?
- What need does this product address? Is this the best, most efficient, user-friendly way to address that need? Does a solution already exist that could address this need?
Useful Links:
- Link 1
- Link 2
- Link 3
- Link 4
Key Contacts:
- Contact 1
- Contact 2
- Contact 3
1.3 We establish clearly defined performance measures to regularly assess our progress in executing the vision
We measure how well we’re executing on the vision by having clearly defined performance measures that we revisit regularly. Teams should prioritize work to improve a key performance measure (KPI) and measure the impact of that work on the KPI.
Key Performance Indicators (KPIs) are an effective mechanism for individual teams. Teams should regularly review and communicate their product’s KPIs.
Best Practices
- Set Key Performance Indicators for your product that show how successful (or not) the product is in achieving its vision as described in attribute 1.1
- If possible, get business stakeholders to agree that these are the correct KPIs
- Regularly measure and report on the current status of each KPI
- Measure the impact of new work delivered on these KPIs
- Prioritize work to be done based on its ability to positively drive a KPI
- Become familiar with enterprise, portfolio, and product line goals and objectives to ensure your team goals align to or further those goals
- Regularly track progress against goals, sharing outcomes with relevant audiences and stakeholders as they become available
- Periodically review measures to ensure they continue to be relevant by continuously assessing end-user feedback, technical team input, business partner input
Guiding Questions
- Are you focusing on the right thing?
- What information do you need to make the best decisions and effectively prioritize work?
- Is this KPI easily measurable, something your team can impact, and aligned with your product vision and roadmap?
- Are you consistently sharing your procress with product line and portfolio leadership for review?
Useful Links:
Key Contacts:
- Contact 1
- Contact 2
- Contact 3
1.4 We plan, prioritize, resource, and fund work based on end-user feedback, business outcomes, and technical strategy
Teams should consider a wide range of potential inputs to prioritize effectively and consistently to ensure that we optimally plan, resource, and fund work.
- End-user feedback: top pain points, feature requests, usability drivers
- Business outcomes: capability needs, legal requirements, reporting needs
- Technical strategy: security requirements, infrastructure, software upgrades
Best Practices
- In planning work, use a framework that prioritizes work to be done using inputs from end users, business partners, and technical needs. Ensure some capacity is being “spent” to regularly make progress on issues important to all three of these areas
- Continuously review your teams planned work to ensure it is in line with product visions
- Regularly look at feedback (see attribute 3.1) and user pain points (see attribute 3.3) to make sure you’re still prioritizing the work appropriately
Guiding Questions
- What change to the product could have the greatest impact to the end user?
- What change to the product could have the biggest impact to the business partner?
- What change to the product would generate the greatest impact on improving the product’s technical footing (i.e. security, tech debt, performance)?
- Who are the relevant business stakeholders, end-users, and technical team members that should provide input?
- Are there any common prioritization frameworks that make sense for your team?
- How often does it make sense to reevaluate your chosen prioritization inputs and who should be involved in those conversations?
Useful Links:
Key Contacts:
- Contact 1
- Contact 2
- Contact 3
Roadmaps are the bridge between the product vision and the achievement of clearly defined performance measures through day-to-day tasks.
Teams should consider several guiding principles as they build out their roadmaps:
- Traceable: All components of the roadmap should be connected to the vision.
- Flexible: The relative sequencing of work is usually more important than the specific delivery dates. Roadmaps should approximate when large pieces of work will be complete, not day-to-day tasks.
- Transparent: Roadmaps should be public to ensure that all impacted teams or individuals are informed and can provide input.
Best Practices
- Align on the work units and overarching timeframe for the product roadmap
- Prioritize each unit of work (see attribute 1.4) and assign a high-level completion date accordingly. Typically, the earliest parts of roadmaps are the most clearly defined. Accept that in software development projects, long-term schedule and cost estimates are best guesses that will likely need to be adjusted as the project develops
- Store the roadmap in Product.VA and share it with business partners and other key stakeholders
- Continuously update and reprioritize the roadmap as needed, taking stakeholder feedback, process changes, or environmental changes into account
Guiding Questions
- How can you cleanly translate product vision performance measures into units of work? Which units of work make the most sense for this product?
- Who should be involved in roadmapping sessions?
- How can you integrate your roadmap into day-to-day work? What cadence is appropriate for your team to update your roadmap?
- What tools might make the most sense for you to document your roadmap?
- Who should be informed about your roadmap? How frequently should you provide updates?
Training
Useful Links:
Key Contacts:
- Contact 1
- Contact 2
- Contact 3
1.6 We collaborate across OIT and VA to define our portfolio and product vision
It is important that all teams collaborate outside their team, portfolio, and product line to ensure they are in full alignment with larger OIT objectives and the work being done in other parts of the organization.
Best Practices
- Attend regular portfolio-level reviews (i.e., where portfolio vision statements and objectives will be released)
- Update product visions as needed per changes to portfolio (and OIT) strategy
- Share back product vision statements with product line and portfolio leadership (e.g., to inform future direction of portfolio vision)
- Participate in meetings and information sharing in appropriate OIT-wide Communities of Practice (e.g. Design COP)
Guiding Questions
- How do aspects of your product vision tie back to the overarching portfolio and OIT vision?
- How can you ensure the portfolio vision is traceable in your product vision and roadmap?
- Where can you prioritize regular collaboration with product line and portfolio leadership to enable a continuous exchange of objectives?
- Are there other teams in another part of the organization doing similar work? Have you considered the impacts of your vision on those teams?
Useful Links:
Key Contacts:
- Contact 1
- Contact 2
- Contact 3
