Guest blogger, Elena Tsalanidis, Co-founder and COO of Deeligence, offers advice on how to apply the principles of design thinking and lean startup to help develop the right legal tech. 

Many of you out there: lawyers, legaltech vendors or innovation teams, may have a great idea brewing. An idea that will save time, money and make your colleague’s / customer’s lives better. So how do you go from an inkling to a potential solution?

At Deeligence, we’ve spent the last 6+ months on a product development journey using design thinking principles and lean startup methodology. Here’s what we’ve learned:

• Focus on the problem
• Speak to as many stakeholders as you can
• Be flexible about the solution
• Iterate at pace and continually test

Define your problem well

Design thinking involves solving complex problems in a customer-centric way eg. being downright obsessed with the problem.

But wait, what actually is the problem? You must define it clearly and be guided by it: think about what friction points and key themes keep popping up. If you can’t clearly describe the pain you’re alleviating in under 15 seconds, it needs refinement.

For us, we knew that due diligence delivery was awful (four separate M&A lawyers we interviewed called it “a nightmare”), but refining our problem statement was hard. We wanted to capture the archaic processes and inefficiencies that do a disservice to overworked lawyers and their clients. In the end, we synthesised the problem as:

Due diligence processes are largely unchanged from the 1990s. The work is tedious, time consuming and often loss leading. Firms struggle to efficiently coordinate teams, leading to cost blow-outs and a risk of missing deal-critical issues for clients.

It’s punchy, evocative and spotlights our customers’ main difficulties.

Speak to the right people

My co-founder and I wanted to test our assumptions about what we thought were the most problematic parts of due diligence. Using a design thinking approach we tested these through user research eg. lots of listening. We leaned on our networks to hold 50+ interviews across 4 continents.

The right people to interview are those with direct experience of the problem, ideally with differing profiles / geographies. More people = more perspectives. In our case, law firm Innovation Managers, Partners, Lawyers and Clients all have different motivations and issues.

When holding interviews, tailor non-leading questions to each persona. For example, most Partners rarely log into a virtual data room – while this is where Junior Lawyers live during a deal. Equally, Junior Lawyers aren’t aware of recovery rates, utilisation rates and cost blow outs – where Partners are judged and rewarded on these metrics. Ask questions your user knows and cares about.

Collate feedback critically

Often, an outline of a solution starts to appear once preliminary interviews are finished. But now you have a new hurdle: the very clever people you interviewed will have thoughts and advice on your proposal. Some is useful, some is not. To help sort signal from noise, our shorthand is: if one interviewee suggests something then note it and move on. But when three or more people give the same feedback it’s time to take it seriously.

For example, we had an interviewee suggest what our first feature should be. Surprised at his suggestion we drilled down with ‘five why’s’. That is, asking ‘why’ again and again to find his underlying reasoning. It turned out that our feature-suggester was actually thinking about how we could differentiate from other products (helpful, but misguided) rather than explaining the pain of the problem from their personal experience, which is always more truthful and reliable. Remember, no one is living the problem as deeply and broadly as you. Trust your gut.

To help collate the feedback we used tools like Miro to create process maps to better understand a usual workflow. We grouped comments regarding the problem into themes, triaging and sorting to show what users found most painful. This helped us build our product roadmap and know what features to build first.

Align and iterate, fast

With our mental model set, next we used lean start-up methodology to focus on experimenting, testing and iterating. We built cheap, scaled-down versions of our product to test our ideas before incurring any costs.

Our increasingly less embarrassing prototypes that we shared were:

1. 1. Some scribbles on a page. Feedback was brutal. Whole thing went in the bin, started again.
   2. A two day build in a no-code tool. This was something to show rather than anything functional. Feedback was still savage. Closer, but mostly binned. The no-code route was clearly not going to work for our product.
   3. A low-quality series of static screens in Figma (my first time using it). Feedback mixed. Closer now.
   4. Some higher quality screens created by a UX designer with some ‘clickable’ functionality. Feedback much better. Enough confidence to proceed to tech build.

At each stage, we showed the prototype to hear what people thought, and built in feedback into subsequent versions. We held onto the long-term vision and understanding of the product tightly but treated our views about how to get there more loosely.

Final thoughts

It’s important to ensure your product or idea is useful and that you discover this quickly and cheaply. Design thinking and lean startup methodologies are problem-solving approaches that increase your probability of success for your innovative project.

Can’t wait to see what big ideas you generate and build next, one small, incremental piece at a time.

ABOUT THE AUTHOR

Elena Tsalanidis is the Co-founder and Chief Operating Officer of Deeligence. Deeligence equips corporate lawyers with modern workflow tools and helpful automation to save time and scale collaboration. Getting the deal done quicker from data room to final report.