Adopt a “Jobs to be Done” framework to simplify a 19-step process to 5 steps
What job is your customer hiring your software to do?
Customers buy products to do a job. By identifying what jobs customers hire your software to do, you can simplify your user experience and increase customer value, engagement, and likelihood that they will renew.
When we started Wunderite, we had a core group of early adopter insurance agents that were engaged, using the software, and giving us feedback. The pain was real and our sales team could sell, but not everyone who bought would engage. To successfully grow into our next venture capital round, we had to figure out how to replicate our early adopter success to a broader insurance agency audience.
At the time, Wunderite was best defined as a system: a collaborative platform to manage risk data and forms. There were a lot of places to click around and there was a lot of data that could be manipulated and shared by the user. But we didn’t have a “Jobs to be Done” mentality. Agents were hiring us to quickly share and complete a form, but we hadn’t identified that yet.
Clayton M. Christensen suggests in Competing Against Luck that when people purchase a product, they’re really “hiring” the product to help complete a job. Feature-rich products are useless if they don’t actually help their users easily complete the job they’re trying to accomplish. When that happens, customers “fire” the product and look to hire an alternative to help solve the problem.
We didn’t want to get fired!
Define the problem
Early at Wunderite, it took an agent 19 clicks before they could start filling out a form–and the user had to memorize what the steps were and where to click next. If an agent had an existing profile they were working on, it would take 14 clicks. The user journey went something like this:
Create a risk profile.
Add basic account information (phone number, address, website).
Add property locations and buildings; automatically pull insurance data from a third party (building material, flood zone, distance to fire hydrant, etc.
Add vehicle schedules; automatically pull vehicle data from the NHTSA (year, make, model horsepower, etc.)
Add other risk data like drivers, equipment, workers comp codes, etc.
Add contacts and collaborators.
Fill out forms. Automatically answer questions using data pulled from the profile.
As our user base grew and we started talking to more agents, we realized most of them were “hiring” us to do one job:
Help me fill out forms faster so I can write more business.
The preliminary profile setup slowed agents down at best. At worst, they got confused and dropped off. Wunderite was at risk of being fired. Agents were hiring us to fill out forms faster and we needed to figure out how to accelerate the process.
Identify the constraints
We had two main constraints: technical debt and engineer availability. We were learning on the fly while building the first iteration of Wunderite and we accumulated some tech debt in the process. Tech debt is similar to financial debt, except instead of your payments being due in dollars, they’re due in engineer man-hours.
You can take out a “loan,” but if you don’t keep up with the payments, it becomes so burdensome that you don’t have any resources to do anything other than service the loan. At some point the loan is due.
In other words, if too much tech debt is allowed to accrue, you end up spending all your time patching the software and trying to avoid a critical meltdown, rather than building new features. Our tech debt situation presented us with some constraints:
A form must belong to a profile. It can’t exist standalone, meaning…
We need to allow agents to create a profile and add a form at the same time.
Our only available resource was a frontend engineer, meaning…
No new backend API calls.
Can’t edit any existing pages.
We can only add overlays or create interstitial pages.
In addition to tech debt, we also had limited engineer availability: everyone on the team was committed to top projects.
Design a solution
Once we defined the problem and identified the constraints (arguably the hardest part of the process), we had a good sense of what the solution should look like: Start a form in as few clicks as possible, given our constraints.
Start a form right from the homepage. Make it obvious.
An obvious “Send or fill out a form” option greets agents Build a connecting page to display our forms library–no fluff or extras.
Keep it simple: users only have one task to do at each step To address the “form must belong to a profile” constraint: include a step to add the form to an existing profile, or create a new one using name only.
Select or create a profile from the same search bar If needed, create a new profile in the background–no additional clicks.
Fill out the form.
At each step of the new flow, users had a single action to complete. We kept the flow simple and sidestepped the technical debt, because there was little interaction with our existing app.
We combined the profile select and create process into a single step. Regardless if our users were starting from scratch or working with an existing profile, the number of steps were the same. With the new focused workflow, our users could start filling out forms in 5 linear steps instead of 19 disconnected steps.
Adopting the Jobs to be done Framework
The project went so well that it became a model for all future features. Three principles guided the process and focused our efforts:
What job is our customer hiring us to do?
Identify the constraints.
Keep it simple.
In the process, we built reusable components that are simple, effective, and scalable. Each new project we commit to can be completed faster by using existing components–building blocks to rely on. With some UX, QA support, and one full-time frontend engineer, we sidestepped months of technical debt and designed, tested, and shipped our top feature or “job to be done” in less than 30 days.