18F/18f.gsa.gov

---
title: "Buying better digital products part 1: Proto-personas and understanding the problem"
authors:
- clara-tsao
- amy-wilson
tags:
- digital acquisition accelerator
- acquisition services
- presidential innovation fellows
- procurement
- training
- modern practices
image: /assets/blog/digital-acquisition-accelerator/complete-persona.jpg
excerpt: Recently, 18F launched the Digital Acquisition Accelerator, a 6-8 month program aimed at creating change agents within two agencies to inspire a cultural shift within those agencies. 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.
description: Recently, 18F launched the Digital Acquisition Accelerator, a 6-8 month program aimed at creating change agents within two agencies to inspire a cultural shift within those agencies. 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.
---
Recently, 18F and the Presidential Innovation Fellows launched the [Digital Acquisition
Accelerator](https://pages.18f.gov/digitalaccelerator/), 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](https://18f.gsa.gov/2016/06/15/two-agencies-participating-in-the-digital-acquisition-accelerator-pilot/),
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.”](https://pages.18f.gov/digitalaccelerator/assets/workshop-day-one.pdf) 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.](https://pages.18f.gov/digitalaccelerator/assets/workshop-day-one.pdf)

Day 1: Proto-personas and problem statements
--------------------------------------------

### Proto-personas

Day one of inception kicked off with a workshop to create
“[proto-personas](https://uxmag.com/articles/using-proto-personas-for-executive-alignment)”
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.

<figure>
    <img src="{{site.baseurl}}/assets/blog/digital-acquisition-accelerator/persona-template.jpg" alt="A persona template for participants.">
    <figcaption>Example of template used by participants to fill out key traits of users.</figcaption>
</figure><br>

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:

<img alt="A template for sketching personas to give to participants." src="{{site.baseurl}}/assets/blog/digital-acquisition-accelerator/persona-sketch.jpg"><br>

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:

<figure>
    <img src="{{site.baseurl}}/assets/blog/digital-acquisition-accelerator/complete-persona.jpg" alt="A completed proto-persona" />
    <figcaption>Example of proto-persona</figcaption>
</figure>

### 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](http://bpmgeek.com/blog/what-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)](https://en.wikipedia.org/wiki/Five_Ws) 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.](https://pages.18f.gov/digitalaccelerator/assets/workshop-day-one.pdf)

*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]({{site.baseurl}}/2016/07/26/buying-better-digital-products-part-2-setting-the-product-vision-and-strategy/), we’ll go over setting the product vision and strategy.*