How to find and solve a product problem: Part 1 — Planning

James Routledge
7 min readNov 5, 2020


This is part 1 in a series exploring how to solve a product unknown. In this part, we’ll define an unknown worth solving, how we want to solve it and a basic structure to learning these insights from (potential) users. Onwards!

This work starts with the simple truth, at this point, we have no idea how to solve a customer problem.

As obvious as it sounds, all we need to do is figure out what we don’t know. 😊

Meet Halo — A social network for locals

At, we build an app people use to connect with their local community, think of it as all the group chats based around the topics for where you live collected together in one place.

This is a product that works great for a local community when there are more than a thousand people using it but is pretty much useless if you’re the only local online. For a product like this to survive3, we’d need to uncover how someone outside of an active community can get a great experience from using our product.

We don’t really know the problem to solve (the job customers might hire us for) as our company only worked on the hypothesis that we’d need to “seed” each area. Therefore, we can say that we don’t know the solution OR the problem, initially. That’s important as it means we have to use a different set of processes and tools to get the answers we need out of people.

Step 1— Problem hypothesis formation that focuses on the jobs that create ‘utility.’

Our goal is to find a single-player mode for the product, a type of utility that means anyone can pick up and start hiring our product to do a job for them. For Instagram is was filters on photos, with Pinterest, it’s a personal board filled from all the existing content. This means that whilst we need to go wide with our problem/solution interviews, we’ll only listen for the insights that enable someone to get some value out of local without involving others, this will be our defined problem focus.

We need to find a job that people have a problem with locally that everyone can find utility in that isn’t well solved today. To do this, we need to define who we’re solving problems for. These are sometimes called a customer segment, persona or customer hypothesis. We have oodles of data to tell us this.

If we didn’t know, then it’s a case of building five potentials and having a go to see how each reacts; this is how I’d recommend finding your early adopters at the idea stage.

When Halo first started I literally used to sit in coffee shops so I could listen to people; I then tried to make up who they were in my head to try and understand who was around, our TAM is everyone, so it made sense to go where everyone was and understand their lives :)

Halo’s Personas

From a lot of time speaking to people in our app and the standard customer-development methods, like Google Design Sprints, we know who the early users of our hyperlocal network are, the types of people below account for around 1 in 10 in any area. A population that’s addressable and also safeguards that we don’t build ourselves into a (customer)corner.

New to the area/Born on the street — People who are invested in their local area for a tonne of reasons and in a state where they are curious and happy to lean in when it comes to meeting people or learning about what’s going on. These people are community-driven rather than community transactional with their areas (most residents take their area for granted, are numb, and want to use the community rather than give back; not a good seed cohort)

Eager to make/create better, based on a geofenced place — They love where they live and seek to invest their time/money/effort/attention. They aren’t confident about doing these things unless others acknowledge them.

Community leaders — Connectors in an area; they don’t ‘do’ and work but are always generating value in areas via their proxy’s. These people know all the movers and shakers but lack something they would call their own dominion. They are entirely selfless (truly outstanding human beings), and battle-hardened as getting shit done in local is tough.

I want to point out that not a single demographic is listed above, we could add them to make these people easier to find (i.e. FB ads), but that creates an exclusion bias. In our case, we know the customer well, and I can find these people inclusively and repeatedly.

Step 2 - Finding the right questions

With these people in mind, we now need to build a list of questions we think could uncover the needs/pains/gains that these people feel around being local. The caveat, of course, is that they need to be ‘everyone’ pains; these questions must conduit us to outcomes we believe can serve a large number of people.

Outside of writing this, we put together a list of all the different jobs we think that these people have locally (function, social and emotional ones) using the JobsToBeDone framework.

Jobs we think the above people might have a problem with and are looking to hire a product to help them:

  1. I want to discover who lives nearby.
  2. Find people who’d love to collaborate with me locally.
  3. National things happening in my locality.
  4. Learn more about my area or future areas I’d be interested in
  5. See, meet those nearby like me.
  6. Give me a feeling of community locally (confirm for me what my community is)
  7. Help me find support for my local ideas.
  8. I want to meet a specific group of people locally [techies, singles, parents]
  9. Help me (in real life) meet the locals, people I’d never normally meet, but will because we are locked into the same community.
  10. Show me everything that’s going on nearby both online and offline.

Now we have a bunch of potential jobs that hint at solutions but really they are just an input for creating, the structure above assumes that if we did this job well, anyone could start to use our product in the required Single-player mode.

At this point, speaking to people should be an open conversation, I prefer to structure the chat into three sections and continue ad-hoc until someone reveals a story that has a useful answer. My suggested sections are:

About you — Nothing too personal, merely an introduction by the person (do yours as well)

About the subject area — Building a narrative in the conversation to force our participant to be in the correct frame of mind.

About the job(s) we think people might want to hire products for — A series of aligned questions to think about the problem (if it even exists) and the way people solve it today

When coaching people how to create these conversations I always point to Rob Fitz’s Deck on how to talk to customers.

Step 3 — Running interviews, gathering insights and (in)validating jobs

Assuming that the participants are lined up, and chats are happening, it’s now a case of using the insight we have to test which jobs are truly problems we can be hired for.

When testing these jobs, many people opt for a build-measure-learn model of experimenting, the problem here is that whilst the mental model is fantastic, it never defines done. This is dangerous, it means you can bias conclusions to any level of done and therefore self-validate what you originally thought was the solution (confirmation bias). We avoid this by being really clear on a minimum-success-criteria invented by leanstartup machine used in their Javelin boards.

Essentially, pick a minimum outcome like 6 out of 10 people agree that ‘x’ is true and create a simple failable hypothesis. The reason we use a minimum instead of an absolute like in scientific fair tests is that we as a business have 100s of assumptions where there is no black and white outcome. We’re more than happy with good enough as long as the collective of minimums gets us to the desired outcome in the fastest possible way.

Armed with a model that predicates what we want to know and if it’s good enough we can now seek out the answers we need. Whilst not a hard and fast rule it should be possible learn something new from every interaction. Our goal is a potential job for single-player mode, we don’t care what it is, so everytime something is said that could lead to us being “hired” it’s a potential solution, and should be added to the list.

For Halo specifically, this means we’re looking for a job that 4 out of 5 people want to hire a product for that enables a better experience of local areas.

In the next part of this series, we’ll run interviews customer, share insights and use them to start to test a series of solution hypotheses to discover which jobs are potentials for a hyperlocal networks’ single-player-mode.



James Routledge

Digital and product thinking