Turning a Hypothesis into a Functional App (Part 1) 

 

We have spent nearly four years building GetCalFresh, a service to make it as easy as possible for all eligible Californians to successfully enroll in CalFresh (also known as SNAP or food stamps) and get the help they need to keep their family fed. To date, we’ve helped about 360,000 people across about 33 California counties, about 15,000 applications per month statewide.

But getting from 0 to 1 user, then 10, and 100, in 2014 and 2015 — during that period of significant uncertainty we had to be ruthlessly efficient in testing our ideas. And government programs are a very different context for hypothesis testing than consumer technology generally. This is Part 1 of 2 describing that work.

But getting from 0 to 1 user, then 10, and 100, in 2014 and 2015 — during that period of significant uncertainty we had to be ruthlessly efficient in testing our ideas. @allafarce Click To Tweet

Root Hypothesis: a simpler, mobile-friendly application tool for CalFresh

Our original hypothesis was grounded in a few observations gleaned from following people through the process of applying for CalFresh:

1. Applying on the existing online systems itself was a barrier for eligible clients.

We witnessed people struggle to get through the existing online applications. Why?

• It was very long: close to 200 questions, and they showed questions for other programs, even if the client stated they were only applying for CalFresh. For some, it took several hours to get through.
• Applicants were often confused by complicated language reflecting the details of program rules (for example, phrases like liquid resources).
• Critically, you could not apply online from a mobile device. The existing government websites were not mobile-responsive, and the native apps the government offered did not have the capability to accept applications, despite our finding that more than half of Google searches for “food stamps” or “CalFresh” were on a mobile device.

2. Applying for CalFresh requires an interview with an eligibility worker where they are required to go over many of the questions on the application.

Because the interview is required — and the eligibility worker must go over all of the key questions then anyway — we saw an opportunity to save some of the more difficult questions until the interview.

While some applicants received assistance from community assisters, someone applying on their own had to parse out complex income concepts like “liquid assets” on a web page. And, adding anxiety, someone may worry they’re providing false information when they’re actually confused.

But given eligibility staff, by design, were going to speak with them later in the process, there was an opportunity.

Because the interview is required, and the eligibility worker must go over all of the key questions then anyway, we saw an opportunity to save some of the more difficult questions until the interview. @allafarce Click To Tweet

3. Federal rules required only four fields to constitute a valid application for CalFresh.

The fields are name, address, date, and signature. This is a federal program access requirement.

4. One of our county human services agency partners also wanted a simpler, mobile-friendly application.

During a 2013 fellowship engagement, our county partner, San Francisco Human Services Agency, saw the need for an easier application, particularly one that was mobile-friendly. This partner, who oversaw CalFresh in one county, saw how difficulties of the existing online application actually led to channel-switching: applicants would get frustrated or stuck online, and then would end up coming in person to the lobby. This was both a pain for the client and created a bigger workload for county staff.

All of these factors led to our root hypothesis: an easier (shorter and mobile-friendly) online application could help more people take that first step of submitting an application, and ultimately get enrolled.

Initial test: a functional prototype (zero to one)

Our very first test of the idea was simple. We built a small Rails app that only had one page — a form with those four federally-required fields. When the user submitted, it filled out those four fields on a PDF of the paper application and then faxed it.

Where was it faxed? To our interested county partner’s office fax machine.

The functional prototype (yes, this is the entire app)

So we went to his office, told him to bring up the site on his phone, and fill it out. It took maybe a minute.

A few minutes later — with me frantically refreshing the fax API status on my own phone under the conference table — a fax came through with a 100 percent valid paper application for benefits.

Our partner, the Program Director, called up the head of operations who oversaw the business process for the agency and asked him to come try it. Afterward, he asked, will this increase our workload, only this limited information, and coming in via fax?

The operations head said, more or less, not really. Even when someone applied online, a worker still needed to review and copy much of the information over into the case management system. It would be good to have a few more fields — like all the household members and their vitals — but certainly not a ton more; maybe 10-12 questions total.

From that conversation, we learned two key things:

1. Sending in a filled PDF did not create significant additional effort versus the information coming into their system directly online (for this county’s vantage point at least.)

They were fine not having it come in online, though we quickly agreed that secure email would be a better solution than faxing.

2. More than four questions were needed to effectively serve the client (get them to an interview) but not all 200 were required or useful for efficient application processing.

The key insight was that the truly critical information for the county was comprised of only three things:

• The basic identifying information of all household members: This was important because the first step in the business process was “registering” the application, which involves looking up every household member in a state database. Without that, it would slow the process down significantly, requiring a phone call to the client.
• Phone number: Phone number is not one of the four federal minimal fields, but it’s critical data for a county to get the client scheduled for an interview quickly, since it usually occurs over the phone. Without it, the only way the county can contact the applicant would be via mail.
• A few basic questions about income and expenses: Another early step in the business process is screening an applicant for “expedited service.” For clients with virtually no means, they have a right to have their application processed within three days. These few questions were critical to serving their most vulnerable clients, and for the county to comply with state regulations. But serving them did not require all the details of income and expenses.

The experience of following people through the application process was also relevant as a lesson for anyone working with government. Often, technology in the public sector takes a very, very long time from identification of a need to actual working software. As a result, the tech often ends up off the mark from the original needs expressed. Public servants then often see technology as more generally unresponsive to their (and their clients’) needs.

Even if our approach wasn’t something we planned to scale, having real, working software that could be used immediately replaced the conversation of “Should we do this?” with “How do we get this to work?”

Even if our approach wasn’t something we planned to scale, having real, working software that could be used immediately replaced the conversation of “Should we do this?” with “How do we get this to work?” @allafarce Click To Tweet

Thank you to Dave Guarino, the Director of GetCalFresh, for contributing this piece. If you seek to bring the entrepreneurial spirit to your organization, Lean Startup Co. can help.

Lean Impact RSS