Our goal is to take our target personas from where they are now, to where they want to be

Jeff Patton, User Story Mapping

Building successful software products is hard. Most products fail to gain traction, leaving startups and larger businesses wondering what went wrong.

Some useful snippets of research are emerging that offer us useful insight into why products fail. It’s easier to look at products in a startup setting because there is more data.

One fairly detailed analysis of startup failure was completed by CB Insights and then unpicked in an article by DreamToIPO on Hackernoon. It was clear – failing to get the product right was the number one cause of startup failure.

Image courtesy of www.hackernoon.com

The article looks at various reasons for not delivering the right product:

  • Not understanding the true customer need.
  • Not giving the customer what they really want.
  • Not enough demand.

They surmise “there is no alternative to knowing your audience”. Making errors with technological implementation wasn’t mentioned in the study.

But Surely Building Technology is Crucial?

It is. To bring products to life you need skilled engineers. We have more engineers at MOHARA than any other discipline.

To build a house you need skilled carpenters, joiners, roofers, painters, electricians and plumbers. To build a good house you also need architects, surveyors and project managers. But to truly realise a great vision, you need all of these people all pulling in the same direction, towards an amazing house, because great ideas on how to implement can come from anywhere. An expert plumber or kitchen fitter that understands the required outcome can provide the architect with valuable insight that may not be in the original plan.

Great technologists are important, but without a clearly mapped outcome and a focus on users great results can’t happen. Our focus is:

Great product = great outcomes for users powered by technology

Building a Great Product

We recently worked on a project that looked at the problem of processing subject access requests (“SARs”). GPs are getting a large volume of these requests (basically patients requesting information held on them, enshrined in good old GDPR legislation).

These requests are taking weeks to process, cause significant administrative issues for GPs and mean patients (and the related parties like insurers) need to wait a long time for key data.

To solve this problem we need great outcomes for users (GPs and patients). To do that we need to take heed of Jeff Patton’s advice and:

“Take our target personas from where they are now, to where they want to be”

This opens up a few important questions:

  • Where are they now (GPs and patients)?
  • Where do they want to be?

You can see it’s absolutely imperative that we can answer these two questions before we even think about a project plan or line of code. It is easy to think in terms of requirements, “right, so if we did this it would enable this…..” to think of technology as the solution. But technology isn’t the saviour – a great product is.

Ok, So What Do We Do Next?

Hopefully we’ve got across the point that what you don’t do when faced with this problem is come up with a set of requirements and feed it through to a development team to build.

Instead, you think about getting great outcomes for your users through technology – technology requirements is not your starting point.

In his book User Story Mapping, Jeff Patton talks about understanding users and beginning to think about framing solutions. This is a helpful starting point for understanding how to build great products, so let’s take a look at his points in the context of creating a product to better process SARs.

Processing SARs – Building Outcomes for Users

  1. Frame the problem: We need to understand the real pain points. What exactly is causing the problem for users? Is it affecting relationships between GPs and patients? Is it wasting time? Is it impacting on medical outcomes? There are probably a number of problems and the framing exercise should pick out the core of the problem and address that.
  2. Map the big picture: At the beginning keep the analysis at a high-level; look at the big picture and the macro issues. In this case, there are lots of problems but at its heart there is a huge efficiency problem that is causing myriad problems – the process needs to be faster and easier.
  3. Explore: Once we have a hypothesis of what the problem is we can speak to users: GPs, administrators, IT technicians and patients, to further understand the problem and potential solutions. For example, perhaps the technology isn’t accessible to the users; the GP practices aren’t giving clear guidance on the system or the database infrastructure isn’t able to capture data efficiently.
  4. Slice out a release strategy: Here you’re starting to look at what can be delivered to address the problem. It could be a more accessible app, a better database or a tighter process. Every feature should be designed to meet the specific outcomes you’ve designated as important for users.
  5. Slice out a learning strategy: Split this overall plan into smaller experiments that address the riskiest parts of the project first. For example, if success is predicated on patients adopting a new app then focus on getting the UX right before building out the infrastructure behind it.
  6. Slice out a development strategy: Focus on building out things that allow you to spot problems early. For example, if there are issues with the current database that can open up bigger problems then look at those first.

Notice how the product has been conceived through the lens of users and outcomes and only in points five and six do we start actually implementing technology. And even once the technology is implemented there is a continual focus on whether this provides the outcome we need to satisfy users.

This is not to say MOHARA was the actual product owner. But we needed to know that we were contributing and delivering in an environment where product – outcomes for users, based in technology – was the primary focus.

MOHARA – Your Product Partner

You may have picked up that we put product at the absolute heart of what we do. Great products are a blend of understanding users, focusing on outcome and razor sharp technology implementation – we’ve got you covered for all three.

We can lead you through the pitfalls of product development so that exceptional product is the beating heart of your business or project.

Please get in touch with Ben Blomerley on ben@mohara.co.