This is the second post in a series of three that provide a step-by-step guide to how we led the inception workshop. The first was published on July 21.

18F and the Presidential Innovation Fellows’ Digital Acquisition Accelerator launched in early June. Through this program, cross-functional teams from two agencies — the U.S. Department of the Treasury and the Federal Bureau of Investigation — are learning to build two products each using modern product management practices. During week two of the Accelerator, the teams applied what they learned in an inception workshop to shape the vision and strategy around their first products. This is the second of three posts that provide a step-by-step guide to how we led the inception workshop. Read more about proto personas and how teams broke down their problem in the first post.

Day 2: Product vision and strategy

During the first day, we set the stage by creating a set of proto-personas — a listing of assumptions we have about potential users of the product. Because they’re assumptions, proto-personas are based on hunches, not research. We spent the second half of the day working to further understand the problem — to ensure we’re set up to build the right solution. Note that to yield the best results in the workshop below, we recommend you have a skilled facilitator lead the session to avoid leadership by consensus.

If youre interested in facilitating on your own or want to see how we did it, here is the presentation used in this inception workshop.

“The vision should communicate the essence of the future product in a concise manner and describe a shared goal that provides direction but is broad enough to facilitate creativity.” - Roman Pichler

Capturing assumptions and hypotheses

On the second day of the workshop, we set the product vision and strategy and determined the minimum viable product for each team. The goal was to have each team end the day with a detailed list of assumptions about their future product.

Sitting in groups, participants wrote down everything they could about the product on different colored sticky notes, referencing, if possible, the source of their knowledge. Then, with the proto-personas from the first day in mind, the teams wrote down more assumptions about their product. As the sticky notes piled up, the teams clustered similar ideas together and labeled those groups.

A diagram of culstered post-its.
Example of combining and labeling clusters


In this session, teams were taught terms such as a “product principle” (a general statement of value a product embodies) and “product strategy” (how all product principles fit together). They sorted the sticky notes with each group according to these two terms.

Determining the minimum viable product

In the afternoon, the teams determined a minimum viable product (MVP) for their project. An MVP is “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

To identify their MVP, teams first identified key features in their products. A feature is a characteristic of a product or service that helps boost its appeal to potential users. Each product feature was listed on a sticky note, and the team prioritized the features by having each person use dot stickers to vote for the features they thought were the most important. From there, teams identified criteria for a successful MVP including cost savings, user satisfaction, and performance. Participants also identified challenges and risks for their MVP.

A product in a box

At the end of the day, teams were each handed an empty box covered in paper and asked to design their product as if they were selling it as a shrink-wrapped box. Teams created a product name, graphic, bullet points on the front, a detailed feature description on the back, and operating requirements.

This exercise helped teams further define their product vision, which answers the following:

  • Who are the people being served?
  • What is the statement of need or opportunity to fulfill your mission?
  • What is the product name and what is the product category?
  • What is the key benefit and/or the compelling reason to change?
  • How is this unlike an existing product?
  • What is the product’s primary differentiation?

In an environment where requirements change quickly, this focused product vision helped teams remain focused on the critical aspects of the product, even when details changed rapidly.

If youre interested in facilitating on your own or want to see how we did it, here is the presentation used in this inception workshop.

This is the second post in a series of three that provide a step-by-step guide to how we led the inception workshop. The first went over proto-personas and problem statements. The next post, we’ll go over mapping user stories and developing a minimum viable product.