Recently, 18F and the Presidential Innovation Fellows launched the Digital Acquisition Accelerator, a 6-8 month program aimed at creating change agents within two agencies to inspire a culture shift within those agencies towards modern product management practices. This past month, the Accelerator launched its first cohort, consisting of cross-functional teams of contracting officers, developers, program managers, and product owners from the Federal Bureau of Investigation and the U.S. Department of the Treasury. We’re building out this Accelerator with an “open by default” mentality and will share our validated process and learnings as soon as they become available.

A key component of this Accelerator is to make agencies be better “buyers” of digital products within the government. That means we need to decide what it is that these agencies are buying. These decisions are made in our version of the “inception workshop.” While our first week bootcamp focused on the cohort growing an appreciation for modern product management practices, the inception workshop is meant to put some of those principles into practice and to determine what products the agencies would be buying. The outputs of the workshop will be the inputs for a solicitation for vendors to build out the solution.

We take this term from agile development, where inception is the balance between “let’s analyze and specify what we need” and “let’s start coding!” The workshop sets the foundation of what form the product should take. It helps set the product vision while laying out the needs and user benefits of future features.

For our workshop, we focused the teams on the user and problem area, set the product vision and strategy, outlined the product’s minimum viable product, and created a user story map, all in the span of three days. The overall purpose of this workshop is to have the inputs necessary to build a stellar solicitation for vendors to build out the product. We’re introducing a step-by-step recap of each of these three days in a three-part blog series so you can recreate it within your team.

To follow along or replicate this exercise, here is the deck used in this training.

Day 1: Proto-personas and problem statements

Proto-personas

Day one of inception kicked off with a workshop to create “proto-personas” to identify and highlight key users and the assumptions that agency teams have about their needs, goals, behaviors, and motivations. Proto-personas are a variation of personas used to help develop early design hypotheses. It’s important to note that proto-personas help to initiate and reinforce awareness of a user’s point of view during strategic planning internally but should not be viewed as a substitute for talking with actual users.

A persona template for participants.
Example of template used by participants to fill out key traits of users.


First, participants were asked to write down as many users of the product that they could on a whiteboard or poster, and for each user they were asked to create a name then outline that user’s demographic information, needs, and goals as well as behaviors and beliefs, like below:

A template for sketching personas to give to participants.

Then, agency teams determined a series of 5-7 traits to compare across proto-personas. Using these traits, teams narrowed down their options from approximately a dozen to just five personas through dot-voting, where each participant was given a sticky dot to vote for the most important persona.

After teams selected their top priority personas, we captured and digitized them for reference for the rest of the three-day workshop and for the solicitation in the coming weeks. Here’s an example of a completed persona:

A completed proto-persona
Example of proto-persona

Writing problem statements and breaking down the problem

After thinking through their product’s target users in the morning, we kicked off the afternoon with a session to understand the problem each product was meant to solve and how to tackle it in the right way. Within the solicitation process, it’s important to break down and clearly articulate problems to avoid wasting resources and building initiatives that aren’t aligned with core organization strategies. Over the course of the workshop, participants created a problem statement, broke down the problem in several ways, and then took insights from that process to refine their problem statement.

Participants started by drafting their product’s problem statements with the assumptions and understanding of the current problem. Then, teams used the CATWOE Analysis by Peter Checkland to identify the people, processes, and environment that contributes to the problem. If the teams got stuck, they could fall back on the Five Ws (Who, What, When, Where Why and How) to answer fundamental questions about their products. We also brainstormed barriers and constraints to implementing the solution.

In the end, the teams collectively reframed the original problem statement and answered the following questions:

  1. What is the solvable problem?
  2. Who has the problem or who is the customer?
  3. What form should the final solution take? What is the scope (in time, money, resources, technologies) that can be used to solve the problem?
  4. What barriers and constraints exist to solving this problem?

The analyses and discussion earlier in the day led the teams to write robust problem statements that looked at all aspects of the problem. This helped ensure that they’re solving the right problem, and not just a symptom of a problem.

If you’d like to conduct your own workshop, feel free to use our deck to replicate it.

This is the first in a series of three blog posts that provide a step-by-step guide to how we led the inception workshop. In the next post, we’ll go over setting the product vision and strategy.