Contents

• Makeshift solutions and committing resources are positive signals

• Unpacking jobs, pains and gains

• Turning problems into opportunities

• What’s next?

Previously when building web apps, I have effectively been “scratching my own itch” and building things that I wanted to see become reality. I didn’t need to explore around the user problem, because I was solving my own problems.

In this instance I am very much solving someone else’s problem and lacking a lot of the context around it. However, one of the reasons I chose this project for the #BuildSell30 challenge was because I have access to talk directly to the user about the problem.

Makeshift solutions and committing resources are positive signals

Having chatted with the user, I learned that the team was already looking into solutions for the problem. Work had even begun with the data team to create some way of visualising the data they they needed.

Initially I was disheartened that the problem may then be solved and this solution would not be needed. I changed my mind, however, and realised that it’s probably a pretty encouraging sign that teams are willing to commit time, resources, and therefore money, to solving this problem.

It’s always very interesting and useful to see how users are solving or working around the problem at the moment—especially if they have cobbled together a makeshift solution. It’s another good signal that the problem is significant enough that they’re trying to solve it as best they can. In this case, they were currently exporting data from PinpointHQ and analysing it in spreadsheets.

Unpacking jobs, pains and gains

At this point I would normally look to build a bit more of an understanding around the problem by chatting with the user; specifically what they are really trying to achieve and what’s stopping them from doing so at the moment.

Luckily for me, the team had already started to work on the problem so they had listed out the issues they were facing in a slide deck. This made it super easy to understand what they were facing and what they wanted to be able to do.

To make the information for actionable, I unpacked the content of the presentation onto a value proposition canvas.

If you’re not familiar with the value proposition canvas, it’s a tool to unpack:

• Jobs: What a user needs to do

• Pains: What is preventing them from doing these or what are the negative outcomes of doing the job poorly

• Gains: What do they need to do a good job or what are the positive outcomes of doing the job well

I love tool because it focuses on the user from the perspective of what they are trying to achieve rather than demographics.

Turning problems into opportunities

There are two parts to the canvas; one has focusses on the customer jobs, pains and gains, and the other hand focusses on how we can resolve those pains and create gains for the user.

This process makes it really easy to understand why you should build certain features, because you can trace them back to the pain they’re resolving or the gain they’re creating.

Some of the key opportunities identified:

• Knowing which stage candidates, as well as a specific focus on diverse candidates, are dropping out and why they’re dropping out of the process would mean we could make changes so that we aren’t losing candidates unnecessarily.

• Tracking time spent at each stage allows us to know how efficient we’re being and identify where we could make changes to improve the process.

• Understanding how the source channel affects candidates conversion rates would be useful so we know where to focus our efforts.

• Being able to filter data by timeframe would allow us to track trend changes over time to see if we’re improving.

• Tracking conversion rates from application to hire and from offer to acceptance would be useful benchmarks to track to see if we’re improving.

If you’d like to learn more about the value proposition canvas, I would highly recommend checking out the video below:

What’s next?

Now I understand the problems that need solving and I have some ideas for how my product can be the solution, I need to see what we can actually build.

Because the project I’m working on is focussed on one platform; PinpointHQ, I am limited by the public APIs they have available. I need to check my product ideas against these APIs to see what is possible.