I am often asked "how do you decide what products to build?" and "where do good product ideas come from?".

Here are some of the points I cover when answering these questions:

A product idea starts with something that sparks someone's imagination.

I think most people would agree that coming up with a product idea requires imagination. In the context of legal technology, most of us can relate to thinking: wouldn't it be great if [work technology X] worked more like [consumer technology Y]. And for me, that type of thinking is the spark  - a connection between something that is with something that could be.

Once someone has the spark, next is the formulation of a vision for a solution that may or may not exist, which can be turned into a successful product.

So I believe anyone can come up with a good idea. You don't need to be in a particular job or have a particular qualification.

At Clifford Chance, we encourage all staff members wherever they are in the world and whatever their role in sharing their ideas (or even just the beginnings of an idea). We have a website where people can browse others' ideas and submit their own using a straightforward web form that collates key information about the idea. The information is available for everyone to see and comment on, to help with collaboration. We are always particularly interested in ideas that come from client conversations.

It needs to get in front of the right people who can take it forward.

At Clifford Chance, once an idea has been submitted, it is triaged. This is a quick process involving a multidisciplinary team to ensure all relevant viewpoints are taken on board, before allocating the idea to the relevant team to investigate further. The triage occurs at least once a week.

For example, in other situations where someone has come up with their own idea to build and sell, the idea may not need to be shared so early on. But at some point, it will if it's going to be successful. So the proponent(s) must be able to tell the story of why the idea is a good one and what needs to happen next. I think this can be one of the hardest things to do, especially in today's world where people have so little time for listening. 

At Clifford Chance Applied Solutions, part of our role is supporting the person who comes up with the idea tell the best possible story about their idea and fill in some of the inevitable blanks. This way, they stand the best chance of securing the investment to turn the idea into reality.

When deciding to invest in an idea, the first decision is whether it should be built, not how it can be built.

Often people who have an idea are so convinced that the next logical step is to work out how to build it.  However, often someone has already had a similar idea, and a successful product already exists.  

More often and not, there are many "facts" about the need for the product that has been imagined and needs to be verified. I love this part of the process – identifying the major assumptions and then devising "experiments" to find out if we are right or not. In one of our early products, we had assumed that a stand-alone product would be attractive. It turned out that several potential buyers needed integrations with their existing databases, and we had not designed our product to make that easy.

We also often discover that the features we thought were key during this experimental phase turn out to be unimportant and can be dropped. See this product management blog.

Another aspect for Clifford Chance Applied Solutions to consider when deciding whether the idea should be developed is to look at whether it meets certain pre-qualification criteria. These include:

  • Could the product be construed as legal advice in any jurisdictions we are proposing to sell it, requiring us to be authorised or licensed to do so? If the answer is yes, we immediately say no as we are not authorised or licensed to give such advice.
  • Is the product idea in our area of expertise and focus? In simple terms, our purpose is to give broader digital access to some of Clifford Chance's legal knowledge. So we won't take forward ideas that don't do this.
  • Stakeholder support. Anyone who has ever made a technology product would probably say it's harder than you think and requires a huge amount of collaboration. So we make an honest assessment that all relevant stakeholders are bought in.
  • Does it look like the product idea could be made from technologies/platforms we already have capabilities in and have onboarded? We know from experience that the onboarding process can be very time-consuming to ensure we only launch products that meet tough security requirements. And it can be hard to find the right technology skills on short notice. So if we have a choice, we'd rather use existing technologies and platforms.

Next comes the assessment of can it be built and how much will it cost to build

This phase tends to involve a different set of people. Technologists, business analysts and project managers whose job it is to deconstruct the story so far and ascertain if it can become a commercial reality.

It's easy at this stage to forget that we are still deciding. Senior stakeholders may be asking why it's taking so long to launch, and the technologists want to get on and build something so it can feel that the decision has been made and that we are in an implementation phase. For me, it's critical that we give them the story correctly and make provisions for checking they have properly understood it. Otherwise, it's very likely that a lot of time and money is spent building something that no one really wants. Either the product will be canned before launch or, worse still, launched (in the hope that perhaps someone, somewhere will want it and that it can be improved once live). However, launching a bad product invariably means spending even more time and money with little business benefit. I doubt anyone who has an idea wants this outcome.

The importance of checkpoints and governance

In summary, we have a process to maximise the chance of building a product that delivers the intended benefits within our operational constraints*. Like many things that are common sense, it's easy to understand the theory but often hard to deliver in practice, which is why we place huge importance on checkpoints and governance. However, checkpoints and governance often feel like unnecessary obstacles when you are in the midst of an exciting creative process. So we have tried to create some fun around this!

*  One caveat I'd add is that different teams have different operational constraints. This means it could be possible to work on a single (great) idea where the resources are available to go straight to the build phase with a high tolerance to the risk of failure. The covid 19 vaccines are an example of this – governments around the world pumped large quantities of money into the development of several different vaccines to increase the chances of finding a vaccine quickly.