The benefit of the new
Why lawyers should entertain new ways of doing things probably deserves its own article, but I will try and summarise here. Most firms (hopefully) want to improve how they deliver their services to clients, and also how they operate internally. The combination of these two things can lead to:
- Lower fees for clients. In my view, it’s not true to say that firms have a vested interest in charging as much as they can for their legal fees. Rather, it’s that they haven’t thought about the business advantages of being a reliable firm when it comes to cost, and clients feeling like they are getting value for money. Not to mention reducing all those write-offs clients complain about.
- Better outcomes for clients. Improvements in service delivery might result in, for example, using insights from structured data to take a more realistic approach to “market practice”, or the chances of success (or otherwise) in a litigation claim. These things (and many others) can lead to a better overall outcome being achieved, resulting in clients coming back for more (and bigger) work in the future.
- Fewer errors being made. Errors made in legal practice such as “they attached the wrong signature page to the contract” can have disastrous consequences and are generally the result of sub-optimal processes. They can lead to embarrassment, lost fees, lost clients and sometimes negligence claims. So many legal processes have not been designed from the ground up, instead growing organically. This is why legal tech is a great place to be — there is so much room for improvement.
- Retaining more employees. All of the above give lawyers a sense that they are more than just billing machines. By reducing margins for error, you reduce blame culture and minimise the instances where a lawyer gets that lurching feeling in their stomach where “they messed up”. (Generally, I don’t believe lawyers mess up all that often…I believe it’s the processes (or lack thereof) that are to blame, rather than an individual’s execution of those processes).
The lawyer mindset
A LinkedIn post by Alex Herrity, Director of Legal Solutions at adidas, got me thinking about the relationship between lawyers and “ideas”. Here’s a cartoon contained in the post:
Alex’s post is about the perfectionist nature of many lawyers (which, in many ways is a huge advantage given the work they do). But you can’t go into a bunker and predict whether something is going to work or not. Sometimes you have to just try it.
What is an idea?
Alex’s post is more a sentiment about the execution of ideas. It relies on the idea being a “good idea” in the first place. But I think people often oversimplify what an idea is. Here are some sentiments I often come across that make me think this:
- “I would go on Dragons’ Den [for US readers — Shark Tank], I’m just waiting for that great business idea”
- “I think you guys should introduce [x] feature into your product”
- “The way we construct our product roadmap is to take feature requests from customers and then we decide whether to implement them or not”
All of these sentiments, to me, give this picture of an idea being some sort of bright spark of brilliance that results in a world changing product or business. I have two problems with this.
#1: Ideas are worthless if they cannot be executed
First of all, it’s not that hard to come up with a massive shopping list of features you want added. Here’s a few things I came up with in the space of two minutes:
- A legal tech app that translates a lawyer’s handwritten manuscript markup into track changes in Word
- A task management tool for lawyers that integrates with time recording systems, and pre-populates a narrative based on the task text
- A legal document review tool that is designed not for reading text from start to finish, but lets you skip around and flip around pages easily
Some of these are sort of being built. I don’t personally think there’s much genius in coming up with these things. It isn’t that visionary to say that you think the tech lawyers use needs to be as intuitive as Apple products. Nor is it that visionary to say that lawyers need everything to be smart, served at the right point of need at the right time etc. Yet I often hear these kinds of things regularly at legal conferences, and — somewhat confusingly to me at least — they seem to be met with unanimous appreciation even though they have likely taken mere minutes of thought.
This stuff is easy to say, hard to execute — because they are conveyed at such a high level of abstraction that it is impossible to implement them purely off the back of an idea. The real genius, and value, lies in the details and actually executing them. That’s where the juicy discussion lies, not in coming up with these kinds of statements in the first place.
Sometimes, that is a matter of business priority. There’s a great sentiment expressed in the Lean Startup that you can come up with an idea, give it to a bunch of companies — and they won’t build it. They won’t build it because they are all starved of resource and haven’t factored it into their plans or OKRs for the coming year.
A lack of obvious avenues to execution is, I think, what has driven many lawyers to become entrepreneurs, take control of the situation, and start their own thing.
But perhaps most of all, high level ideas like those state above are simply not executable without further research, analysis and detail. For this reason, I don’t really class any of the above as ideas — or, at least, “good ideas”. This is the second point.
#2: An idea is not just a feature or a solution
In my view, a “good idea” is made up of two parts:
- A problem or pain it solves. This is the starting point. I’ve written about this many times.
- A solution to that problem or pain point. This is the secondary consideration.
The solution part is often the bit that involves tech.
People who are technologically-minded often exhibit a character trait of wanting to build things for the sake of it — a bit like a child with Lego. I should know — I definitely exhibit this character trait. As a result, technologically-minded people often skip the “problem” part, and go straight to the “solution” part.
Funnily enough, people who are not technologically-minded do the same thing, but for a slightly different reason. I think that reason is that many products we love using are like swans gliding through lakes. You see and interact with the beautiful bit — the tech — but you don’t see the feet flapping away under the water. For ideas, this means people often think that things like the iPod were created through a spark of brilliance, with all the “feet flapping” — or in this case, problem identification — completely ignored.
When I started my career in legal technology, I was a solution-jumper. The only reason I am not a solution-jumper today is because the solution-jumping decisions I made turned out to not be so smart after all, for one key reason: any solution, or technology, is meaningless unless it does something of value for someone.
It used to drive me mad when people used to respond to my solution-jumping sparks of brilliance by asking, “what problem was I seeking to solve”. I saw it as delaying tactics, management speak, blue-sky thinking nonsense that was a blocker to my genius.
Yet I have realised, probably too late, that ideas are nothing (and certainly not anywhere near being executable, or worth of execution) without a deep appreciation of the problem you are seeking to solve, or the value you are seeking to deliver. We all need to keep our solution-jumping tendencies in check, because seeing problems through the lens of a particular solution will skew your analysis.
Execution + problems
These two parts of an idea: (1) execution, and (2) problems and solutions, fit very neatly together. While you cannot execute on a high level solution somebody came up with, it is much easier to execute upon an idea that is founded in a tangible problem. Here’s a few reasons why:
- Detail. A solution, similar to the examples I suggested above, need more detail around them. Functionality needs to be developed, questions need to be asked. As it happens, identifying the problems first will answer many of those questions. There will still be unanswered questions, but those will be resolved by reference to the underlying problems and value, not the solution in a silo.
- Value. You can quantify the “thing” you are doing for people — whether it be hours saved, costs recovered etc. A solution, on its own, can’t do that. Establishing the value means your business cases will be more convincing. Establishing value based on problems you have identified through research will mean these business cases will not just be a series of pretty slides, but an accurate representation of reality.
- Prioritisation. Based on the above, you can carry out an assessment of (1) how easy an idea is to execute, against (2) the value it delivers. This helps you say “yes” to some things and “no” to others.
Back to reality
I’m realistic. I know that law firms and legal teams want to encourage their employees to come up with ideas and new ways of working. And I know that it is completely unrealistic for most people to find the time from their busy schedules to identify problems and make their ideas executable.
There needs to be somebody in an organisation who “owns” the idea funnel. This person has an important role, and can do three things to improve the quality of “ideas” they get from the business.
First, they can try and encourage people to express problems, not solutions. A call to action of “tell us your ideas” will probably result in a bunch of people putting solutions on your plate. For reasons discussed above, you don’t really want that. What you want are people’s problems, so that you can then validate those and come up with solutions to them. Instead of “tell us your ideas”, I suggest a process through which people can easily express frustrations they have in their day-to-day lives, and a culture of these not just appearing down a black hole.
Second, and mindful that you will get feature requests and solutions from people, deal with these appropriately. These things are helpful, not because they are features, but because they point you int he direction of a potential problem. You need to not implement features or solutions blindly based ont hese requests, but use them as evidence of an underlying problem. My feature request of handwritten comments and track changes might, for example, lead you to investigate internal document collaboration as a theme. You might come out the other end with a solution that means people don’t need to do handwritten comments anymore, rendering the suggested solution redundant. Who knows…
Third, don’t straight bat people with “but what problem are you solving”. Buried away in solutions can often be good ideas, and asking a question like this (particular to people who might be sketpical of this question) is a very good way of making sure they never speak to you again. Instead, work with them to identify the problem in a more friendly way, e.g. “interesting, so tell me how much better that would be than how you currently do things”.
Akin Gump v. Xcential
I am following, with interest, the lawsuit between Akin Gump and Xcential Legislative Technologies. This appears to be a fight over “whose idea was whose”, and stealing ideas after software demonstrations. I have a few thoughts on this case.
First, legal tech vendors should interact with law firms and legal teams. It is sometimes the expectation of buyers of technology that a software developer can go into a dark bunker and come out with some genius technology with amazing results, without talking to lawyers. I disagree with this, for reasons stated above and previously.
Second, legal tech vendors need to engage properly with potential buyers. I see some software companies go in and ask for feature shopping lists. To me, this is a delegation of product management responsibilities to your buyer — a bad idea. Software companies should be the one with the right skills to take data, process it, and formulate solutions that are well-founded in problems. This is not something you should rely on users to do. People will give you features and solutions, but as a product person, your skill is in diagnosing why they are saying those things, tracing back to problems and then formulating the right solution (which is probably not what was suggested originally).
Third, this dynamic should be made absolutely clear. For all the reasons above, we shouldn’t overstate the importance of a lawyer from a firm who has come up with an idea subsequently executed by another company, or provided feedback on a product. Vendors should be clear on why they are interacting with lawyers, and what the relevant potential buyer is actually getting out of it.
People often overstate the importance of ideas. In my view, good ideas are not moments or sparks of brilliance, but the product of research, analysis and execution. For this reason, I think it is crucial for technology vendors, and internal innovation teams in firms and legal teams, to have people with the right mindset to see what a “good idea” actually is.