Chutzpah

Legaltech News publisher Zach Warren uses this Yiddish word to describe one of the qualities needed to launch a legaltech Startup. In addition, he says, it takes vision and the ability to think oneself into the situation of the desired user as precisely as possible. There's a lot of truth to that.

Many founders fail at even describing their customers. You often hear "all lawyers" or "all attorneys". Maybe one should also generally move away from this customer group-based mindset and instead ask the question, "what pain are you trying to solve with your new product?" Then it's time to show your colors.

One example: from the current study by Wolters Kluwer, one can read that the standardization of contracting is a very important topic for law firms and for corporate legal. But why is that? Is it about the speed at which new contracts can be created, or is it about ensuring quality? In the former case, systems like Bryter or top.legal can actually help by analyzing the most important contracts and putting them into a question-answer grid with all the options provided. In the second case, it is more about the internal workflow and ensuring that all valid templates and text modules are actually stored and, above all, maintained in a defined location and that all employees are obliged to access only these quality-checked modules.

Certainly, the answers will mostly be ambiguous. But the message is: you have to understand your customer very well and know his pains as good as possible before you start developing a new software product. And exactly the same applies to customers facing the introduction of new tools. First define the pain and then deal with possible solutions!

With these meaningful words, Leginnside says goodbye to summer vacation. We will be back in mid-August. Stay healthy!

Don’t filter out your customer

 The two sides of Customer centricity

Yesterday, I involuntarily witnessed a customer phone call. You know, in German-speaking countries, "managers" regard large-capacity compartments of express trains as walk-in telephone booths. The man had to conduct an escalation conversation with a dissatisfied customer. In doing so, he moved very skillfully between appeasement, assurances, but also pressure (“Yes, what am I supposed to do now, I can't change the situation either”). At the end of the long phone call, the customer was satisfied to the extent that the conversation could end on a consensual basis.

Things only got really exciting afterwards, when Mr. Manager followed up in one-on-one meetings and/or conference calls with his employees. The fact that the tone of voice changed depending on the person being talked to is not unusual. Between the lines, however, it was clear that the customer's concerns were dismissed as an annoyance - mistakes happen and capacity problems are externally determined.

If you communicate this to your employees, you can spare the expense of customer centricity programs. It is then a mere mask that does not promote genuine customer understanding, but filters it out. Just like the masks in the pandemic.  Customers in project business, on the other hand, are well advised to invest a lot of energy in contract design - even if it hurts and puts the brakes on. Otherwise, they will be just as defenseless against the supposedly inevitable defects in (software) development as the unfortunate person on the other end of the line was yesterday.

Software: permanent relationship instead of simply purchase

One characteristic of the Corona Crisis is the variety of webinars on offer. Those who wanted to listen actively were able to pick up valuable insights at yesterday's event hosted by Frankfurt-based reinvent legal innovation hub. Guests were David Bloch from Swiss legaltech startup Legartis and Martin Kay from international vehicle supplier ZF.

Legartis offers an AI-driven software for highly automated analysis of legal documents. At ZF, this is in use to speed up the review process of NDAs. What are the key findings?

1. If new software is to be deployed in a highly operational company, it is imperative that it is "ready". That is, the promised functionalities must actually exist and the software must have been extensively tested. If it turns out in live operation that essential functions do not work or do not work sufficiently, it is highly probable that this would be the end of the project. So there is no question of a "minimum viable product".
2. The project is by no means complete once it has been successfully put into operation. Rather, it must be followed by a process of continuous collaboration. It is particularly important to keep this in mind because the entire contract structure and pricing must be based on this.
3. The process change associated with the use of software only pays off if as many relatively uniform and not too complicated documents as possible are to be analyzed.
4. Last but not least: software does not replace people.

The good news: Despite all the challenges that could be read between the lines, the project was judged positively on both sides; consequently, new contract types are now being tackled.