Avoiding common mistakes by legal tech founders

Slow is smooth and smooth is fast

I’ve worked with a number of startups and spoken to founders in legal tech and other industries, and I’ve seen a number of trends in discussions about how they are setting out.

In this article I’m going to cover off 3 of the mistakes that have the biggest impact on startup success:

• Thinking you are your user
• Not understanding requirements
• Going from requirements to code

The first mistake: Thinking you are your user

A lot of legal tech startups are founded by lawyers who have identified a solution to a problem they have experienced. The mistake is in not first checking that their experience is typical. There are two parts to this.

• Firstly, in understanding the problem domain: in validating that the context in which they have experienced the problem is indeed typical of their target audience and not the result of a particular legal context or workflow.
• Secondly, in understanding their proposed solution, and whether it is dependent upon their current environment or context.

The temptation to just jump into solution mode without first validating these two things is powerful: there will be the first-hand experience of knowing that this is a real problem, causing real issues for the lawyer and people like them. This can be a strong moral driver; a desire to give something back and improve the wider community. A good way to address this tension is to consider how a better understanding of the problem will benefit the development of any solution.

The second mistake: Not understanding requirements

A couple of years ago, I worked with a design agency who asked me to design a website for one of their clients. They talked through what they wanted, and it sounded reasonable, so I asked for the requirements.?

They genuinely didn't understand what I was asking for. I had their notes from their client meeting, wasn't that enough? I gently explained that it wasn't, and ended up giving them an impromptu lesson on how to define and prioritise requirements.?

Clearly defined requirements include:

• a reference number
• the requirement itself: clearly stated, unambiguous
• optionally, a category to help organise the requirements
• some indication of importance. This may be high, medium, low; or MoSCoW: Must, Should, Could, Won’t.

Each requirements needs to be clearly stated, such that someone coming fresh to the document understands what it means. Requirements will change as you work on them: single requirements may be split into two or more. Some requirements may be merged, or delete it because they are duplicates, or found to be unnecessary. Relative priorities may change as decisions are made about what the Minimum Viable Product looks like: what must the product do for a first release in order to be useful??

While the requirements are important and useful, it's also about the process: reflecting on what's necessary and what can be discarded or left to a later release.

The third mistake: Going from requirements to code

Coding is expensive. Not only the per day cost of a developer but also the cost of delivering the wrong thing of developer time bought and paid for but instead used for design or reworking screens.

I once worked for a software firm where (among other things) I designed a module to support a new tax process. During the design process, I had to explain to the project manager why I, as a professional designer who had been contracted to design, was designing. Rather than her, as a project manager and – crucially - a former accountant.

I wish I was making this up.

I'm not a lawyer. Or a builder, a soldier, an accountant, an IFA, or a specialist in any of the other fields where I've worked. What I am is a designer trained in human factors, computer science and business analysis, which means I understand the thing common to all of these fields: how people think and work. How to present information to them in a way that enables them to understand it and make effective decisions from it.

Design, and especially prototyping, moves the requirements into something tangible. It identifies, and provides answers to, the questions that you didn't realise were questions. Like ‘we need a form to capture this information. But how should we capture it? What's the label? What if the user types something totally unexpected? Or nothing at all?’. Large processes need to be broken down into smaller steps, but how big should those steps be and how does the user know they're making progress? How do you keep them engaged?

By identifying and answering these questions, the design process moves the requirements into something tangible. It is a back?and?forth process where the design helps to clarify the requirements, which in turn clarifies the design. The completed prototype can then be tested with real users. While it’s unlikely to be as functional as a real system, it can be created more quickly, and at much lower cost, than a fully coded prototype. It can be changed more easily in response to feedback from testing. And when you're confident in what you have, you can move to development, knowing that your developers will be able to focus on the thing that they're good at.

Founders can get caught up in the passion to deliver, mistaking action for progress. Taking the time to explore and define the problem and solution, and look at different design options, will help you get the right product for the right audience far more quickly. If I can help you with any of this, send me a DM!