Why legal tech works best when you’ve spoken to the people who use it…

Jack Shepherd
10 min readNov 3, 2021

Get me speaking about legal technology, and I’ll likely mention two things pretty quickly. First, adoption of legal technology is a huge issue. Second, speaking to the people who will use the solutions is the number one “success hack” to delivering an effective legal technology initiative.

Here are my top four reasons on the second of these, namely, why it is so crucial to put users front and centre of anything you are doing with legal technology (or, indeed, any change initiative).

#1: You’ll make better buying decisions

What to base your decisions upon

Assuming you don’t have unlimited money to spend, you’ll have to pick and choose the tools you want to buy. One approach is to base this decision upon what is talked about the most in the market. Read an article recently about chatbots? Go out and buy a chatbot.

This could be a great approach to follow if your primary goal is to generate excitement and publicity. But there is often a difference between what gets spoken about in the press and in marketing, and what would deliver the most value to your business and the people within it who will use the tools. Follow this approach, and you could easily end up buying a tool that sounds good, but nobody actually uses.

Bridging the gap

The list of tools you’ve heard people talk about in the press can be a starting point. But it’s a great idea also to speak to the people who could be using these tools within your business to discover whether they would add value and be used. Fortunately, it’s possible to do that before spending any money.

If you have legal experience yourself, your own views on whether a tool adds value or not should be informative rather than determinative. I say that because if you are influencing the purchasing decision of a given tool, you are just one user — if you are a user of the tool at all. You need to look at what value a tool can bring through the eyes of its users, rather than your own.

(And keep in mind that “user” is probably more widely defined than you think. For example, will the people who support the lawyers also be affected by the tool?).

What the users think of a tool will largely trump your own personal views

The obvious way to ascertain whether a tool will add value or get used by people is to arrange for it to be demonstrated to people. This is better than nothing, but actually I think there’s a better way.

Don’t start with the tool

Instead, flip the whole exercise on its head and approach people on a general basis agnostic of any tools. This means the conversation is less about “is this tool helpful” and more towards “what ways can we deliver value”.

In other words, you’re in problem discovery mode rather than solution validation. For example, you might want to rollout a due diligence tool. You talk to a series of lawyers about their day-to-day work, and find out that (to your surprise) they don’t really do a lot of complex due diligence work.

Despite your excitement around a new due diligence tool, you conclude that this purchasing this tool would not solve a problem people actually have. Best of all, you have concluded that without spending any money on a tool nobody will use.

I have used this diagram previously to illustrate the advantage of looking at things through the lens of value rather than a particular solution

Indeed, it is common to come out of these exercises and be directed to an entirely different problem area. If people didn’t find the due diligence process challenging, perhaps they found drafting contracts or getting documents signed more difficult. Maybe you should look there instead.

Once you’ve ascertained that you are in the right problem area, demonstrations might then be useful in ascertaining whether a given tool addresses that problem. But get the problem area right first.

#2: You’ll make better build decisions

Build for others, not you

I was the product manager for a tech tool that, among other things, helped law firms collaborate on and negotiate documents. As an ex-lawyer, I designed part of the product around my personal workflow, which was to send out a document, receive a document back, and incorporate the changes into the document I had sent out.

My workflow — incorporate the changes into the doc I sent out

I remember one of the first users to use the product being extremely confused when confronted with this workflow. Turns out that in their practice area, it was more common to send out a document, receive a document — but then amend that document rather than incorporate the changes into the original.

Alternative workflow — amend the document you received back

I had made the mistake of designing a product for me, rather than users. Had I done my research properly and acknowledged the diversity of workflows, I could have built the workflow in a way that accommodated both behaviours.

People working in product will probably be thinking “well, obviously”, to what I’ve written here. However, in my opinion this is not always obvious to people who are starting out on their product journeys. As a lawyer making the sudden switch to building products, it is certainly not something that came naturally to me.

Engaging with people as soon as possible — and preferably before build or buy decisions are taken — helps you iron out potential pitfalls that might be more expensive to solve later down the line.

Everything requires some “building”

I used to think “building things” was more intricate and complicated than buying things. Over time, I learned that having a “product mindset” (by which I mean, looking at things through the lens of potential users and finding out what problems they need help with) is helpful for buying decisions, and that “building” is not a principle confined to products you develop yourself. The technical implementation of a solution is just one part of the equation.

Some examples of things to think about alongside the tech. Nearly all of them are supported by understanding users or stakeholders in relation to a given project

For example, knowledge management systems are only as good as the content that goes into them. You need to engage with users to understand what kind of content they need to perform their role, along the lines highlighted above. Then, you need to build that content.

Even a cloud-based “out of the box” SaaS product might require some building. For example, with a transaction management solution, what is your strategy around people who don’t want to change how they work? How are you going to make people feel comfortable using the new solution? Even with these tools, you have to build an adoption plan and a communication strategy.

People often forget all these things “around the edge” of technology. Nearly all of them are informed by understanding users and stakeholders. Trying to secure budget? You need to understand the motivations of the budget-holders. Need to produce support materials? You need to understand what questions people are likely to have.

If the first two reasons were the things that draw you into discussions with users, the third and fourth are great incidental effects that are valuable in their own right…

#3: It helps on a personal level

Relationships

One of the most common complaints you hear in law firms and legal teams when new tools are rolled out is, “it looks like this was dreamed up by IT people rather than lawyers”.

Building trust with users will bridge the gap between innovation/IT teams and end-users

One effect I experience from engaging with users at an early stage is the relationships I build with them. By showing empathy and not presupposing solutions, people feel they are being listened to. It helps build trust with people, and gives them confidence that things are being rolled out with their interests in mind.

Networks

A common theme of my discussions with users of technology is that I leave each session with a bunch of new people I need to speak to. In nearly every session, the participant usually notes something like, “you should talk to Frances from the tax team about this”.

The networking effect of speaking to people — you appreciate all the angles to a given problem space, and build relationships throughout the business

For example, I was once talking to a corporate lawyer about how transactions were managed. Through the conversation, they concluded that there were a number of difficulties corporate teams faced in managing transactions. At the end, they told me about a litigation colleague who was facing the same difficulties. I took their suggestion, spoke to the litigation team, and doubled the potential user base for the product.

The networking effect of these discussions also helps avoid duplication of effort in large organisations. I lose count of the number of times I was investigating a problem area that somebody else in the business was also looking to tackle. Not only can you then take the decision to join forces or handover your work, but it means you meet others in the business with whom you can collaborate in the future.

Reflection

Perhaps more surprising is how much people enjoy talking at a general level about how they work. One of the key pushbacks around engaging with people in the way I am suggesting is that they don’t have time. One thing I have learned is that everybody — and perhaps especially lawyers and their clients— like talking about themselves. There was almost a therapeutic effect people experienced in offloading all the everyday pains they had.

Lawyers are so busy getting their heads down on work, they often quite appreciate the chance to reflect upon their work

When speaking to associates, I often hear comments such as, “we don’t often get time to think about things at a higher level than the client work we are doing”. It is surely beneficial to lawyers — at an organisational level and a personal level — for people to be able to reflect in this way.

When I speak to people for a second time, it is not uncommon for them to remark that they have since reflected on our past discussion. Building an awareness of existing ways of working and questioning them, rather than sleepwalking through inefficient or archaic processes day-to-day, is a great cultural outcome.

Champions

The most obvious advantage of speaking to users prior to making decisions is the ability to build “champions”. Champions are people who are fully bought into the value of a solution and can act as advocates for it.

Change is difficult in the legal industry, with many apprehensive about departing from years of experience working in a particular way. One of the most convincing ways of persuading people to take a leap of faith in a new process or tool is if one of their colleagues has done it themselves. This can generate confidence and, occasionally (albeit rarely, in my experience), a feeling that they will be left behind if they do not keep pace with others.

Champions can act as advocates either through giving testimonials (that you can include in comms plans) or by contributing to word-of-mouth messaging about a given tool. People are more likely to act as champions if they have been involved from the start and have “skin in the game”.

Champions also contribute heavily to the final reason I think it’s worth speaking to users more — feedback loops…

#4: Better feedback loops

People know who to call

A common theme I hear from lawyers and those working in legal teams is that they have feedback and pains around systems, but they don’t know who to go to to pass this onto. People are likely to feel this way if they have had very limited engagement with the people charged with rolling out technology.

At a very basic level, by speaking to users, your name is at least out in the open as somebody to talk to and who is prepared to listen. While IT support desks might be the most obvious way to capture feedback, many people I speak to presume this channel is only usable for short term issues, rather than longer term process improvement issues.

Proactive feedback

While it’s important to know when things are fundamentally broken, it can be harder to get the feedback you need to make incremental improvements to your solution. A network of people who have advocated a solution to their colleagues and superiors is a very effective way of getting this feedback.

These people have skin in the game — they want to see the solution be a success. As a result, they will likely proactively reach out to you with problems they and others are having with the solution. Without engaging with users and building this network, you might have to spend time on mass emails and survey requests that nobody ever responds to…

Metrics

Finally, your ability to establish free-flowing feedback loops with users will help you report to budget-holders (particularly if those people are lawyers who put more weight on what other lawyers think). You can present things like activity metrics, but putting testimonials and the voice of the user alongside them is extremely effective.

Legal technology is merely a vehicle through which we can empower those who work in the legal industry to instil positive change. It makes sense to put those people front and centre, and for projects to not simply be delivered in a black box. Speaking to users helps you buy better, build better, create relationships and encourage feedback loops.

Yet it continues to amaze me how reluctant some people are to conduct the necessary conversations, both in terms of the types of conversations (i.e. it’s more than just “what do you think of this tool”), and the ability to have the conversations at all (e.g. “we need to wait until it’s ready”).

In a subsequent article, I will explore the common pushbacks you are likely to get if you follow the approach I advocate. After that, I will gather together some of my learnings on how to actually conduct these conversations. Until then, I hope I have persuaded you of the value of speaking to end-users at the earliest stages of any process change or tech initiative…

--

--

Jack Shepherd

Ex biglaw insolvency lawyer and innovation. Now legal practice lead at iManage. Interested in human side of legal tech and actually getting things used.