Skip to content

To Set the LegalTech Bar Low, Focus Only on Meeting the User’s Needs

9 March 2024

Venn Diagram 9 Mar 2024

Yesterday I noticed this LinkedIn post by Daniel Yim. It begins, “My legal tech/innovation project failed because,” and then it lists ten explanations—or excuses. Then it says this:

Or....

My legal tech/innovation project failed because it didn’t meet users’ needs.

Which one was it? 😀

I take it that Daniel thinks the latter explanation can serve as the default explanation for legaltech failure. In a comment to his post, he explains that a project won’t meet the user’s needs if it relates to “a problem that they don’t actually care about or [don’t] think is a problem.”

So, in the words of another comment to Daniel’s post, “Innovation flops when it misses what users really need.”

But that assumes that the need to be met is just the user’s need. That’s not necessarily the case.

I wonder where we might find a suitable example … . Ah, yes—contract drafting! In fact, let’s consider the business I’m engaged in, Adams Contracts (a division of LegalSifter).

I’ve created a confidentiality agreement template. I describe in this blog post how it’s superior to anything else you’ll find out there (with the partial exception of various standard-form initiatives). But I’m keenly aware that a significant proportion of those who might use our template won’t do so, because the template seeks to address a need that’s broader than their need.

The contracts ecosystem has, for umpteen generations, created contracts by copying, on faith, from precedent contracts or templates of questionable quality and relevance. As a result, the prose of mainstream contract drafting is sadly dysfunctional, in terms of what it says and how it says it. And instead of being informed consumers of contract language, many of us are copy-and-paste monkeys.

If you’re in charge of an organization’s confidentiality agreements and all you know is copy-and-pasting, what’s your primary need? To keep the copy-and-paste machine humming. It’s unlikely you’d be willing to see it dismantled and retooled. For one thing, you’re probably unaware of the shortcomings in what you’re churning out. And even if you’re somewhat aware of the shortcomings, the consequences of bad contract drafting aren’t immediate, or they’re uncertain (as I describe in this blog post)—if you’re focused on the short term, quality becomes an abstraction.

So the copy-and-pasters among us usually ignore the dysfunction, because they don’t pay the price. It’s those downstream that do. The company. The company’s other contracts personnel. The company’s customers and other counterparties. The courts. The economy. All of us.

So instead of setting the bar low by assuming that it’s always the user’s needs that legaltech should seek to address, let’s recognize that we might need to serve a broader constituency.

Bridging the disconnect between the user’s needs and the broader needs requires convincing the user not only that your product adds value but also that it’s appropriate for the user to consider broader needs. That’s a challenge, but you’re in a better position to meet it if you're aware of it.

(I'm just spitballing here. If I’ve reinvented what has long been recognized in IT theory, please let me know.)