This post is the first in a series on how to build legal technology. While LegalTech shares many attributes with its cousins FinTech (financial) and RegTech (regulations), there are many factors that make the legal ecosystem uniquely difficult to build within: ambiguous laws, regimented professional labor markets, maladapted business models and an extremely conservative resistance to change all pose challenges to even the most adept legal engineers. Using scientific thinking along with good design and proper project management, these challenges can be overcome.

One of the most common legal engineering tasks is building legal technology tools for employers and clients. While it is important to be fluent in both law and tech, a legal engineer will make scant progress without a skill not usually associated with engineers: empathy.

Empathy is the first step in understanding a client’s problem. Theories in design thinking say that in order to build useful systems, one must focus on a very specific type of user, and empathize with them in order to understand their needs and struggles. When an industrial engineer designs custom tools for automobile assembly, their intended user is not a “car factory worker”, but might be better described as “assembly station #22 technician, tire and wheel installation”. Legal engineering works the same way.

Who will be using the technology you build? Lawyers inside your firm? Opposing counsel? Clients? Judges? Housing eviction defendants? If the goal is to build a tool that helps domestic violence victims file for orders of protection, the primary needs might be speed and camouflage to avoid detection. A lawyer/client document collaboration platform might need to be ultra-secure before any other factors are considered. Legal engineers (and their project managers) must become adept at defining the needs of their end users.

Empathy and listening must be used together to gain a wide-lens perspective. Experience teaches engineers that the problems clients say they need solving might not be the problems that actually need to be solved.

If I had asked people what they wanted, they would’ve said faster horses.

-Henry Ford

Yes, legal engineers must learn what the law means, and how they can scientifically solve legal problems, but they also must practice a balance of tact, doubt and inquiry to be successful.

It makes sense that you want to implement technology to solve this operational problem. Just so I understand your system as a whole, can you walk me through the other aspects of the problem, even if they aren’t relevant?

-The doubtful, tactful & inquisitive legal engineer

Now it’s time to start juggling the (metaphorical) chainsaws: are you getting paid to do what your client asks, or to actually solve their problem? The two often align, but engineers must be prepared to mollify ingrained thinking and tread lightly on other’s turf as they propose solutions. If you have been brought in as an outside consultant, or even to streamline an established sector of your employer, you may need to tell people they’ve been doing their job wrong. What could more embarrassing? Tact is key.

With a solid grasp of what needs to be done to solve the issue (define the problem), and gotten your clients to agree that it is the problem they would in fact like to solve (obtain buy-in) you now need to ideate solutions. Brainstorming is a common method, where no idea is too crazy, and everything shouted out gets a post-it note on the wall. Identifying analogues has also proven to be effective, especially in the legal service sector. Lawyers are trained to find the similarities between two situations or fact patterns, to convince judges and juries that a previous way of thinking should be applied to the case at hand. In the same way, engineers look far and wide to find comparable problems and their (existing) solutions. Why reinvent the wheel?

With some research under your belt and a handful of new ideas, start whittling down the list and scoping the solutions. What ideas are actually impossible, or impossibly expensive? What will the client never agree to? What has been tried before unsuccessfully? What’s left? Double check your remaining options and select the best combination of feasibility and client satisfaction. Leave all your research and work product readily accessible (don’t throw anything away yet), and present to the client. With their feedback you’ll be able to refine your idea or pivot to a workable Plan B.

To sum up, so far you’ve talked to the client or end user to hear their perspective on the need or problem to be solved, then investigated root causes to ensure the stated problem is the real one. With that agreed, you’ve researched and ideated possible solutions to the problem and vetted the list for the best one(s), then presented your proposed solution(s) to the client. The client has agreed to the proposal, or provided feedback that requires another iteration of the design, and then agreed to the project scope and cost.

Fantastic! Now you’re ready to make a plan, build a team, gather resources and get going. Next up, Post (004): The Work Breakdown Structure (WBS).