Set the vision

We should work toward creating a one-sheet that can easily communicate the vision of the product using simple and direct language. Participation and discussion are key—avoid the classic kickoff where a designated project manager rambles on through a deck of slides.

Building software is simple—creating alignment between individuals is difficult. We wouldn’t be in business if we didn’t excel at our ability to align multiple stakeholders, each with different agendas, and build a collective understanding of the value a new product may bring. After the Devbridge team is done with introductions, the stage is set for the client’s team to present their domain. Cover the

  • challenges they are facing;
  • opportunities they see;
  • risks to their business;
  • desired timeline;
  • underlying motivators; and
  • current landscape of their systems.

As the client presents, write out each individual item on a sticky note and group them on the board accordingly. Later, as the team dives into functional requirements, we can always fall back on the overarching challenges or risks.

Map objectives and agendas toward the outcome
Map objectives and agendas toward the outcome

Client teams have varying levels of alignment in terms of objectives and individual agendas. A VP of sales will drive value by enabling his reps; an operations executive looks at lowering costs through automation. Both may be in the room and provide a seemingly conflicting set of data and requirements. Read the room and drive the decisions through the sponsor—the individual whose head is on the block if this effort goes south (typically the CIO or CPO). While all ideas need to be captured and prioritized, build an awareness of the dynamics in the client’s team.

Our objective is to initiate dialogue between four parties from the prospective client’s team: the subject matter experts, the sponsor, the end users, and the product team. In other words, the people who know the product offering, the people who know the customers, the customers themselves, and the people who know how to build the darn thing.

“Why are we not building the software yet?” —Client

To put it bluntly, the opportunity, rewards, and ability to deliver should become crystal clear throughout the day to the point that the client asks, “Why aren’t we working on this already?”

The duration for vision-setting varies and depends on the alignment that already exists. A senior team can breeze through a vision exercise within an hour if the strategy is narrow enough and the goals are known. When vision-setting lasts four hours, this often indicates an underlying problem. If you can’t explain the vision, why would your customers buy or use the product? Consider a service mapping exercise to paint the process landscape and identify associated opportunities.

Sample vision worksheet

The document should look something like this (with specific examples):

Title and description

  • Centralized customer experience—a mobile application that facilitates A to Z business operations for the customer.
  • Small business lending automation—a platform that automatically underwrites small business loan risk using a centralized rules engine.

Short value statement

These are the underlying motivators that the business has identified.

  • Improve farmer efficiency and profitability by removing a paper workflow and providing just-in-time information to maximize profitability.
  • Loan application to cash distribution in twenty-four hours—allow clients to compete within the lending space by accelerating loan distribution to customers.

Success metrics

The idea is to make these quantifiable, measurable, and realistic.

  • Shorten time to sign a contract from one month to one week.
  • Shorten application to cash timeline from one business week to two days.

Team structure and reporting

Identify all necessary contacts so that once the going gets tough (and it always does), we will know who to call on. Make sure you have identified the

  • sponsor;
  • single point of contact for scope decisions;
  • technical contact for infrastructure, integrations;
  • SMEs; and
  • testing customers/users.

Opportunities

It is always beneficial to have a list of opportunities that can be capitalized on to expand/prioritize/negotiate over the backlog. You have the ability to

  • remarket to existing customers through the established mobile application;
  • upsell additional deals;
  • reduce the number of user errors in loan processing; and/or
  • improve risk models and lower exposure through visualized rule modeling.

Target timeline

The timeline becomes incredibly useful when negotiating scope and start dates, aligning stakeholders, and more. If there’s a go-to-market date, use the timeline to ensure that decisions are made in a timely manner to build and deliver on schedule.

Risks

Risks come into play when establishing nonfunctional requirements and assumptions for the statement of work (SOW). The reality is that change requests are necessary Things happen. Internal teams are late. SMEs are nonresponsive. Third parties lag behind. Establish the bedrock (for what? Not sure what this means), then use it as leverage. We’re in the business of shipping software, not insuring clients’ risk. These risks include the following:

  • Environment availability
  • Third-party integrations
  • SME availability
  • Time-to-market relevance
  • Perceived versus real opportunity

Note: Refine the list of risks throughout the workshop. Establish a baseline, then return and improve as needed.

Example of a product canvas
Example of a product canvas

The Secret Source by Aurimas Adomavicius

About the author

Aurimas Adomavicius is the president and co-founder of Devbridge. When not in the trenches working with clients, Aurimas is an active speaker and writer on product design and engineering best practices.