How to Conduct a Product Envisioning Session

Beyond the items detailed below there are a few simple things we can do throughout the envisioning process that will make the project go smoothly as well. These are listed here:

• Start to capture and define the Domain Language

• Begin to think about milestones and timelines

• Capture high level Epics and Features

• Capture topics to cover in the Exploration phase

• Start to capture any needed research spike around the problem domain and technology

Audience

Envisioning is a business centered conversation. We drill into the problem domain, business goals and objectives, and various other business/mission centric topics. As such it is critical that the customer/partner audience is small and has both the knowledge and authority to speak to these topics. It's lead by the Strategic TPM. PMO facilitates the process. The audience may include:

• Executives

• Department Heads

• Business Leaders

• Technical Leaders

Best Practice(s)

Don’t try to solve the problem at this stage. Don’t even worry about solving the problem. You don’t know enough and what little you do know has yet to be validated. Focus instead on understanding the problem. Ask "why" centered, open ended questions and listen intently.

Envisioning is NOT about technology or defining solutions. Because of this, it is advisable to limit attendance from engineering resources on both sides. Including engineering resources at this stage tends to steer the conversations in a technology focused direction that can impeded long-term success. There is plenty of time to dig into the technology once we understand the problem domain.

Envisioning Topics

The outputs from the Envisioning Session will inform other stages of the project such as Exploration, game plan, ADS and initial product definition. The Envisioning Topics are detailed below:

Business Context

This is about defining the world we operate in from a business centric viewpoint. This information will help us guide the project throughout the ups and downs that are surely to come and will help keep things on the true path. We can also use this information throughout the project to validate our trajectory and success.

Vision

Capture and understand leadership's vision for the project. Don't assume the vision is sound but also don't assume we can change it at this point.

• Tell me about your vision for

Goals

What are the main goals for the project? Focus on the 5 Whys here to drive to the real goal. Use Impact Maps to further qualify goals. Do these goals map back to the Vision?

• What would you like to accomplish?

• What does success look like?

• When do you need to achieve this success?

Challenges

Focus on the challenges the project is meant to address. How do the Vision and Goals address the challenges?

• What challenge(s) does your vision and goals address?

• Why are these challenges important at this particular time?

• What happens if they aren't addressed?

Budget

What is the assigned budget for the project? While this is more of a qualifying question its always good to understand from a cashflow / runway perspective. Another thing to understand here is their procurement process.

• Have you identified a budget for this project?

• How does your procurement process factor in?

Authority

Does your stakeholder have the authority to see this through to the end? Is there anyone else that can pull the rug out?

• Who is the executive sponsor for this initiative?

• How high up the chain is this being reviewed?

• Is there anyone else at the executive level who has influence into our success?

Need

Is there a compelling need for the customer to do this work or are they just kicking the tires? Looks for drivers such as compelling events, end of life, or competitive forces that are pushing the customer to change.

• What is the primary driving force behind this initiative?

Timeline

Does the customer have a compelling timeline or event that must be factored in or are they able to act whenever? No timeline, no urgency.

• Are there any specific dates or timelines we need to factor in?

Problem

Capture details to understand the problem we are trying to solve. We want to eventually get to a one-sentence pitch for the project and a clear and concise problem statement. A great way to capture this is to leverage the Problem section of the Lean Canvas Template

Description

• Why are we talking today?

• How would you define the problem as are trying to solve in 2-3 sentences?

• Who has this problem?

• How does it effect them?

• What are they doing to overcome the problem today?

Use Cases

• Describe 1-2 common use cases

• What is your most prevalent or challenging use case?

User Personas

• What User Personas exist?

• What specific Use Cases do they care about?

Success Indicators

Try to focus on success criteria that changes behavior. Deployment of technology is not a success criteria in and of itself. It's a change agent but we want to focus on the desired change itself.

• How will we define success?

• What impact does this project have on:

  • Cashflow

  • Velocity (product, sales, mission, etc.)

  • Resources (assets and people)

• What does success look like from a Technical perspective?

• What impact will success have on the people?

• How will we measure all of these things?

  • Scale: what are we measuring?

  • Meter: how will we measure it?

  • Baseline: what is the measurement today?

  • Constraint: what is our break even point?

  • Target: what is the desired goal? 

Impacting Forces

What additional forces may have an impact on the overall project?

Constraints

What constraints are likely to impact us during the project? Different than Risks; constraints typically act as guardrails, guiding or influencing our decisions and execution. 

• What Organizational constraints exists?

• How are we constrained by existing or desired technology?

• What Operational constraints should we be aware of?

• Are there any constraints regarding the people surrounding the project?

• What does our Timeline look like?

Risks

• What technical risks should we be aware of?

• What internal risks may arise from the business?

• What external risks may come to pass?

Dependencies

• Are there any technical dependencies?

• Are there any budgetary or business dependencies we should be aware of?

• Are there dependencies on specific personnel or resources?

Technical Context

Just as with the Business Context above; we need to understand the technical world we will be operating in. This will help when it comes to defining a solution.

Key Technologies

• What Tech Stack is the team comfortable with?

• What Key Technologies come into play?

• Are there any existing or previous solutions that you've tried?

Data

• What data and data sources exist today?

• Where is it?

• What format is it in?

• How is it accessed?

Environment

• Do you have an existing Subscription/environment?

• Are there any other cloud or on-premise environments?

Methodologies

• What methodologies is the team most comfortable with?

• What methodologies or processes are you interested in in exploring?

Stakeholders

Capture all project stakeholders. Try and do this for each area below and if you can add them to a RACI chart that's even better.

Business Owners

• Who are the main business owners or key decision makers for this project?

Sponsors

• Who is sponsoring the project?

Engineers

• Who are the engineers that will code-with us?

• What is their availability?

Operations

• Who is involved from Operations?

Feasibility

The most often unasked question by both clients and consultants is: "should we be doing this?" Both sides assume the project aligns with the vision and will effectively solve the challenges. They further assume that the undertaking is worth the effort. We know that these assumptions aren't always true. In this stage the core project team works offline to define the project's Riskiest Assumption(s). This can come from the conversations we've had and the problems and users we've identified in the Lean Canvas. Once we frame these assumptions as Hypotheses we can then develop a few simple experiments to validate and determine the overall feasibility of our project.

Hypotheses

• What is our riskiest assumption? The one that, if not solved, will result in project failure.

• What other assumptions will we want to test?

Verification

• Method

  • How will we run the experiment?

Metrics

• What metrics will we measure (try to take from the ones listed above, if you can't then you may be testing the wrong thing).

Example Agenda

• Mission Domain

  • Vision

  • Goals

  • Challenges

• Problem Domain

  • Context and Description

  • Use cases

    • Personas

    • Success Criteria

• Technical Domain

  • Current State

  • Data

  • Key Technologies

  • Environment

  • Methodologies

• Impacting Forces

  • Constraints

  • Dependencies

  • Timeline

  • Risks

• Team

  • Sponsors

  • Stakeholders

  • Engineers

  • Operations

Outputs

• Project Vision

• Problem Statement

• Project Goals

• User Persona(s)

• Use Case(s)

• Success Criteria

• Constraints

Deliverables

• Initial Project Game Plan

• Initial Project(s) Defined

• Milestone(s) Defined