Presenting unfinished legal work to clients: the minimum viable product

When making a piece of software, it’s easy to get excited. You think about all the weird and whacky things you could put into it. You start creating long lists of amazing features, conversations beginning with “what if…” go wild and you start believing you can change the world.

Then, you start baulking not only at the time it will take to implement all of these things but also at the cost of doing so. That’s not to mention the fact that an idea you thought was exciting might not be as exciting to other people (this is called the “IKEA effect” — a cognitive bias in which people place a disproportionately high value on products they created themselves). The concept of a “minimum viable product” is commonly used to deal with these situations (also known as “MVP”).

What is a minimum viable product (MVP)?

There are books describing this in more detail (see e.g. The Lean Startup by Eric Ries), but in summary, this approach involves analysing the core problem you are trying to solve for, and calculating the method that solves that problem with the least possible effort (this is the MVP).

The MVP is not a finished product, but a starting point that is built on continuously. The idea of an MVP is to get something in the hands of users as soon as possible, so that you can get feedback and data that helps you plan further development. This has a few advantages:

• You mitigate the IKEA effect by getting data from actual users, helping you eliminate your own biases from being personally invested
• You potentially avoid time building needless bells and whistles, by getting feedback on your “leaner” version of the product
• You can validate whether you are even solving the right problems for people without the cost and time of fulfilling your entire wish list

I don’t want to overcomplicate terminology, but it is also worth distinguishing between a few other concepts you might have heard:

• Proof of concept. A proof of concept is used to test high level ideas or technical concepts that have to be proved before you can proceed further. For example, if you were developing an AI contract review system, it might make sense to test whether the underlying models can actually review contracts accurately before spending a lot of time on things such as login, user interface etc. You can prove or disprove the concept without building a fully-fledged user interface. Once the concept is proved, the proof of concept is killed and subsumed into the product. If disproved, you’ve just saved yourself a lot of time and expense building something that was destined to fail.
• Prototype. A prototype looks like a semi-finished thing but doesn’t actually work. For example, a screenshot of an app that hasn’t been built or developed yet. The idea of a prototype is that you can put something visual in front of potential users to test concepts, features and designs before you spend a lot of time building them.
• Pilot. The initial rollout of a system, e.g. to a small number of users within an organisation ahead of a wider rollout. A pilot is useful because if things go wrong with an initial launch, it’s better you find out with a small part of your organisation rather than the entirety of it.

Source: https://techmagic.io

Lots of people will disagree with my definitions — for example, I often hear proof of concept and pilot used interchangeably. That’s fine. I don’t think the words really matter. The point is that these are all approaches that help you work smarter and get useful data as early as possible in the process. I’m going to use MVP as a catch-all term in this article, but arguably I should be using the term “lean”. Anyway. Back to it…

MVP has become somewhat of a buzzword in technology generally, but also in legal technology. It definitely has a place in the development of technology, but does it also have a place for lawyers themselves?

A lawyer’s initial reaction

“Would you be happy to put unfinished work product in front of a client?”. When this question is posed to many lawyers, their reaction is one of outrage. This is likely for two reasons.

The first reason is down to personality. Lawyers are often risk averse, and perfectionists. Many of them hate the idea of admitting frailty or knowledge gaps in front of anybody — but especially clients. For many, it’s important to have all the answers upfront. Yet an MVP is an unfinished piece of work — its very purpose is as a starting point for something else. Can any lawyer imagine sending an advice note out to a client that just stops after a few paragraphs?

The second reason is down to the nature of legal work. In software, it’s okay to make mistakes — that’s how you learn. But for a lawyer, making mistakes can have huge consequences. Lawyers spend a lot of time thinking about the various ways in which they could get sued. Being seen to re-trade a position, structure a transaction incorrectly or making flawed arguments in court can have drastic consequences both for the client and for your relationship with the client.

These two things bounce off each other in such a way that lawyers often outwardly reject the very concept of an MVP in the work they do. But should they be so ready to dismiss the idea?

Look at scope, not quality

One of the mistakes I made early on in my career, and that I think is quite commonplace still, is to think that an MVP relates to the quality of something rather than the scope of something. During one of my early projects, our team compromised code quality and user experience in the name of MVP. The end product was buggy and unusable. People stopped trusting the product generally, and us telling them it was “just MVP” didn’t really help them.

Producing poor quality work product doesn’t help you or the user. You should already know that quality matters. The crucial thing I see people miss around MVP is that it is not just about getting something out quickly, but about getting something out that helps you learn as quickly as possible.

This means that the definition of what an MVP is should really be around scope, rather than quality. Its quest should be to validate that you are solving the right thing and deliver the core value people care about— all in the quickest way possible.

For a lawyer, they might already know that clients will not like poor quality work product (e.g. work full of typos, incorrect cross-referencing, making up or hallucinating imaginary cases etc). But what they might not know is what problem the client wants solving, and what the best solution to that problem might be.

Example: work product

For example, let’s say a client has asked a lawyer to look into a potential defence to a claim around limitation periods. There are a few things you could do as a lawyer here:

• High effort. Draft a very long research note about the law around limitation periods (citing all cases and attaching them), how it applies to their case and list further questions that to complete the analysis fully
• Medium effort. Present a bulleted summary of the law around limitation periods and a few more bullets with an initial view of how it could apply. Ask the client if they want a longer, more official note
• Low effort. Carry out some research and make some internal notes. Arrange a 30-minute call with the client to chat things through and decide on the next course of action.

For a few reasons, a lawyer might instinctively jump to the “high effort” option. Lawyers are often eager to impress and look like they are extremely knowledgeable in a given area. This is especially the case with “insecure overachiever” lawyers.

However, a common complaint of clients is that lawyers spend too much time doing things they don’t really care about. Adopting the principles behind the MVP can assist lawyers hugely here. This is because it encourages lawyers to understand (1) what the client cares about and what they want solving, (2) the quickest route to value for them, and (3) any further steps that can deliver more value.

The MVP approach might lead a lawyer to adopt the “low effort” option. This helps the lawyer understand what the client actually wants. For example, in a hypothetical discussion, a client might say a few things, e.g. “this is coming up on a lot of cases right now”, “we had advice on this in the past but I wanted to double check it”, “I need something for the board later tonight”.

Depending on how the discussion goes, you might approach things in a different way. If this issue is coming up a lot, the problem is not confined to this particular case, so you need to produce some work product that is potentially reusable. If they have received advice in the past, it might be that the problem they want solving is verification of that prior advice.

In any case, before you embark on a long research note that might take 10+ hours to create, it might be an idea to work out what the best way of serving the core value is. If the board needs something for later tonight, would a two-page bulleted summary suffice instead of a 43-page note? (Lawyers — don’t worry — a bulleted summary can still be caveated).

A quick foray into “definition of done”

The three options above represent just a few possible variations in scope, but sometimes quality can relate to scope as well.

Software teams often refer to this as the “definition of done” — what are the criteria for something to be considered “done”. For example, have you written automated tests for the code, has it been reviewed by somebody else in the team and has it been fully documented?

For lawyers, having a “definition of done” might also be useful. For example, has it been proof-read, has it been filed to the DMS, is it wrtten in “house style” etc. Lawyers are well-known for over-manicuring work product. For most clients, typos need to be kept to a minimum because the existence of typos indicates the work has not been read through properly before it was sent. It is important to establish what “definition of done” should look like for a specific client to avoid incurring cost in over-perfecting work.

Example: legal processes

Adopting the MVP mindset is arguably more helpful with more complicated processes such as discovery, due diligence or structuring work streams. This is because these work streams often involve interactions with multiple teams and production of numerous pieces of work — all over an elongated period of time.

For example, I still hear of war-stories around overblown due diligence processes. Lawyers spend time producing a lengthy due diligence report, reviewing thousands of documents, without understanding (1) what the client is looking to solve with this work, (2) what the core value is of solving that, and (3) what the quickest way to bring the value might be.

Instead of spending three weeks working to fierce deadlines to deliver a big bang due diligence report, lawyers could instead work with the client to understand why they want this work done (e.g. how much do they know already — is this a verification exercise or being done from scratch, how important is the post-integration angle behind this) and then what the priority areas might be.

The end result might not be a stressful three-week work stream, but the continuous delivering of small chunks of work product over the three weeks, each of which delivers value. In a due diligence process, this could involve focusing on the important counterparties or contracts and delivering a report on those before looking at the less significant risks (if at all). Work product could be delivered over time rather than in one go. This means the client gets value much quicker, and doesn’t feel like everything is moving slowly. The client also gets the chance to give you feedback before you invest time in something they don’t want to pay for.

Look at the principles, not the letter

Presenting unfinished legal work to clients might appear to be a daunting concept to lawyers. But unfinished does not mean poor quality, and it does not mean downing tools and forgetting about it. The key to adopting an MVP mindset is to focus on the principles behind it, and trying to embed these in every step of a lawyer’s work.

Instead of going down rabbit holes a client might not care about, validate whether going down those rabbit holes is likely to bring value to a client. Instead of embarking on a very long thesis, give some bullets to the client first and get their feedback on that. Adopting an MVP mindset allows lawyers to work in a less stressful environment, and to strengthen their relationships with clients.

There are, of course, difficulties around how law firms are setup and the classic personality traits of lawyers. It will be interesting to see how advancements in technology trends can bring about differences in the way lawyers approach their work more generally.