1. Surface Internal Knowledge and Ideas
2. Initial Discovery
3. Frame the Problem and Define a Focus
4. Reduce Costs, Risks and Dev time.
5. Test and Learn
6. Continuous Discovery and Delivering a Valuable Beta.
7. Expectation Beating Results

Surface Internal Knowledge and Ideas

Resolver built their business on championing consumer rights. They intimately understood the problems consumers faced, as well as the ADR industry that existed to help them.

My first job was to surface and organise this internal knowledge in a way the PM, engineers and I could work with, before validating assumptions externally.

There's no better tool for this than User Story Mapping. It's hands on, easy for different types of people to contribute to and gets people thinking about the users and product as a whole. All while enabling me to familiarise myself with the team, their knowledge and the product idea.

Initial Discovery

Now that we had a map of what Resolver thought they needed to build, I was able to see their mental model of the resolution process and pull out the assumptions and hypotheses that drove their ideas. Now it was time to put this knowledge to the test as quickly and cheaply as possible.

Over 2 weeks I carried out over 15 interviews with internal and external experts, ADR professionals (Ombudsmen, mediators and adjudicators) and disputants. As well as some initial competitor and market research.

As I went, I involved the entire product team as much as possible. By planning the research and discussing my findings together, we built an excellent shared understanding of our customers' problems early, which paid dividends in terms of speed, innovation and quality later.

Outcomes:

• A validated user story map filled with invaluable user insights.
• An understanding of key pain points our product needed to solve e.g. ADR providers spent a huge amount of time dealing with the downsides of email, which were difficult to organise and parse for key information.
• An understanding of what our product needed to do to increase the chances of user success e.g. Helping disputants contextualise the dispute and its affects, and keep these in perspective when negotiating, was key to resolving cases quickly.

Frame the Problem and Define a Focus.

As we realised from the story map, this product was ambitious in size and scope. We needed to agree on a focus area, and at this early stage, this meant identifying the areas of greatest value and potential risk.

Outcomes

• Focus persona: Mediator. Mediators are the first experts involved in case resolutions and are a key decision maker in the purchasing process.
• Focus problem: Initial evaluation of a dispute. Evaluating disputes and deciding how to proceed was a huge painpoint for mediators. Often information was incomplete, spread over different systems and took a long time to uncover key details. If we failed to solve this problem effectively for mediators, little else in the product would matter.

Reduce Costs, Risks and Dev time.

Now we'd framed the problem we wanted to tackle, I planned and facilitated a design sprint to help us answer these questions and begin fleshing out designs that would help us test our ideas and assumptions. The product team and key stakeholders, such as sales, marketing and sponsors were involved.

At the end, we were totally aligned not only on what we were doing, but why. And we had a a series of well understood prototypes that would help us test certain assumptions. For example, that a timeline view would be the most familiar and effective way to present case details.

Though we didn't know what the final design would be yet, engineering could begin laying the groundwork.

Test and Learn.

I spent 2 days preparing low-fidelity UIs that would enable us to test our assumptions. These were simply stimuli at this stage, to poke at certain ideas.

The rest of the week, I spent with professional mediators in Europe and North America. Many of whom I'd built a rapport with already from the initial research.

A few key outcomes

• The timeline UI was definitely the right way to go. Every mediator expressed they draw up something similar themselves and they immediately understood what was happening. They also appreciated attempts to show length of time between events.
• Our assumption that it would be nice for mediators to easily split dispute discussions by issues didn't go down so well. They got what we were trying, but it felt constrained and they worried disputants would get confused. In retrosepct this was totally right and an example of where we prioritised the customer over other users of the system... to a fault.

Continuous Discovery and Delivering a Valuable Beta.

We were now confident we knew how to solve the problem of parsing new cases quickly and effectively for mediators. A problem that would help them do a better job, faster. And help us begin sowing the seeds to sell Accord too. This reduced a huge amount of underlying risk in the entire project.

With confidence in where we were headed, our focus turned to delivering something we could sell ASAP.

We had an assumption that, once discussions were being recorded on the ADR provider's Accord instance, initiator's would feel heard and both parties may act more reconciliatory than before. There was a real chance that a guided negotiation process, which was easier to deliver than mediation, may offer real value.

In just a week, working in tandem with engineers, I had designed a simple negotiation process where disputants could clearly state what they wanted or were willing to offer, with reasoning. It wasn't flexible, but it was clear and something we could deliver in a short space of time, in a way that contributed to the longer term vision.

To test it, we got permission from an interested party to import a number of recent cases and have their customers use it to negotiate a resolution. These customers were picked by the provider and informed they were using a beta version.

The results were hugely encouraging, despite it being a small sample of 20 cases. So much so, they wanted to trial Accord with more cases.

Expectation Beating Results

After an intense period of design and development over 6 weeks, we were ready to onboard our first paying customer with a slimmed down version of Accord. Cases would be imported from their existing system, which meant we didn't need to have the case creation functionality to launch.

Within a month, Accord's resolution figures for the negotiation phase were 300% higher than the customer's pre-mediation baseline. A figure that represented a huge cost-saving in admin and personnel. That isn't to say the experience was perfect. There were many wrinkles to iron out with regards to messaging, notifications and solution flexibility. But initial impressions exceeded what'd we'd hoped to achieve so early.

These initial results then fuelled further interest from other ADR providers.

From there, it was a case of improving the product with incoming, live customer data and building out the additional resolution phases, such as mediation and adjudication.