It began really as an enquiry into what I thought was a “legal-tech” problem. It started with a simple hypothesis born from my own experience as a corporate lawyer. In the broadest sense of the term, most time spend incurred by corporate lawyers is of two types:
First, it is a writing exercise. Drafting documents such as agreements, pleadings, memos and letters.
Second, is a reading exercise. Reviewing, extracting, summarising, comparing, editing and commenting.
For several years now, startups have been at work on the first problem. Not only tech startups, but large law firms and company departments have engaged with software that work with templates and help generate documents faster. Much of this is put together with relatively simpler programming coupled with lawyer friendly user interface that is intended to increase efficiency across the chain. Some of this software also features basic extraction and summaries when documents are generated using familiar formats.
Solving the second problem has taken a different trajectory. Outside of very standardised formats, say such as train or plane tickets or prescriptions and resumes, and ad engines / bots run by big tech - the only software capable of reading any more complicated structured documents are built to specification, if at all.
Between the first problem and the second, the second is the. more difficult to solve and also the problem that consumes more billable hours and more susceptible to error. All this, despite the deployment of white collar armies to tackle the load of documents that need to be ‘read’, understood’, ‘analysed’ or ‘summarised’.
As I delved deeper into how resolving this might look like, it became clearer that it isn’t only a “legal-tech” problem. Reading structured text and understanding them is useful across professions other than the law. Apart from lawyers, a variety of white collar professionals such as in banking, insurance, contract management, government and international organisation heavily expend on deploying human resources at what are essentially “reading problems’. When imagined in such a wide manner, it can seem an intimidating problem.
This is where it appears that legal documents are a good example of “structured documents’ that are complex, vary across samples and yet follow a certain “programmable logic”. It could provide a start to looking at “reading problems” in a structured way that could be applied in other areas. Here you are warned that we are entering areas that are still a matter of “can we get there” rather than “we are already here”. To summarise this theory - while the “reading problem” presents an ambitious set of problem statements to tackle, legal documents are a great starting place to test ideas and have features that find usability. Without first having to reach Mars.
There is more to this idea that I hope to explore in posts to come. Before next time, there are some questions that I would like to leave here:
(a) Do you know of interesting startups tackling the “reading problem” whether with legal documents as a starting point or for that matter, any other structured text?
(b) Is it better to tackle the “reading problem” through enforcing writing formats that make extracting and summarisation easy, or does our experience indicate that formats are bound to vary and we require more sophisticated solutions that are template agnostic?
(c) What would the top funding and technological constraints be, in developing great products that target the “review, analyse, summarise, extract and read” market?
In future letters, I hope to share more on my own journey as well as look at other interesting ideas and startups at the intersection of law, technology and entrepreneurship.
I curated my first substack mailing list to include you because I thought you might be interested - do pass on the word to all those who might be interested in following. If you have an interesting legal tech startup or are considering starting or investing in one, write to me! I would love to hear about it.
Until next time.