Identifying the problem you want to solve

This is a chapter from our quarterly, community-led publication, The Bundle. Download volume 2, issue #2 now for the latest insights from scaleup lawyers at Deel, Pitch, Qonto and more.

I joined Luno as the second legal hire. The first few months usually involve finding your feet, and during that time you can start to identify where the pain points are and where legal is really struggling from an efficiency perspective.

Juro was the first tech solution we onboarded at Luno - here are the four questions the legal team sought answers to, so we could make an informed decision.

1. What’s the biggest problem you’re trying to solve?

With Luno, it quickly became apparent in my first few months that we needed a solution for our contract process.

Our contracts were scattered all over the business, many were unsigned or out of date - that was the problem we needed to solve. I created a spreadsheet with some basic contract metrics so we could get an understanding of:

• The types of contracts we were currently managing
• The counterparties we were dealing with
• Relevant contract terms
• Contract values
• Signatories involved - who is signing our agreements? And does that authorization lie in the right place?
• Who was responsible for the relationship with the counterparty

Below is an example of the columns we populate in our spreadsheet.

Most of the time, you’re being sold product features that aren’t solving your problems. Set expectations with the vendor in advance, so they focus on relevant features

2. What are the options?

There are so many tech options out there, but as a lawyer coming from private practice, I wasn’t too familiar with them. I Googled contract platforms, and selected around seven based on their outlook in review websites, like Capterra, SourceForge and G2.

These also helped me map out features and compare capabilities between platforms. We then requested demos with each platform we had chosen.

3. What do you want to get from a demo?

It’s really important to be as specific as possible with what you want to see in a demo. Most of the time, you’re being sold product features that aren’t solving the problems you’ve identified. Set your expectations with the vendor in advance, so they tailor the demo to focus on relevant features.

This comes back to understanding your problem - the more specificity you have, the easier it’ll be for you in the research stage. We had a project document which clearly set out the problems we were looking to solve, as well as what a successful solution would look like.

We supplemented this with a comparison spreadsheet to track progress with different platforms, which you can see an example of below:

For us, the requirement for a contract management platform was really specific in the early stages: we wanted a contract repository. We let that use case develop over time, having seen and understood the various other capabilities Juro had to offer.

We started with a base level usage of the platform before ramping up and broadening the use cases.

This helped us from a cost management perspective, but also in terms of increasing adoption across the business - starting small meant teams weren’t inundated with a new platform they had to learn, and this was invaluable at a scaling business.

If I could offer one piece of advice around tech implementation, it would be to assign a champion to lead the project

4. How do we get buy-in?

Documenting your process as clearly as possible will make getting buy-in from the business much easier.

Having a spreadsheet or a Google Doc that clearly details the following will make it easier for the business to see the value in your time and cost investment:

• The problem - “here’s the issue we’re facing, and here’s how it affects the business”
• The solution - “we’re thinking of implementing a software solution, and here’s why”
• The requirements - “here’s what we need from our tech platform”
• The action plan - “here are the steps we’ll take to make this happen”

It’s also important to try to add data into the equation - quantify the problem wherever possible. When it came to contract automation, the data points we explored included:

• Time spent on contract management across the business. We didn’t have a clear view of what our contracts database looked like, which was a problem in and of itself
• Accumulated risk from not having a contract process in place - do we know who key service providers are and do we have an appropriate agreement in place with them?

Avoid “too many cooks”

If I could offer one piece of advice around tech implementation, it would be to assign a champion to lead the project.

Stakeholder involvement is necessary and important at the stage of identifying and documenting the problems that you’re trying to solve. However, getting every stakeholder involved in the decision-making process is ineffective - not everyone has the same insights as those on the demo.

It’s easy to take several opinions into consideration and end up stalling the project. Instead, cut that work off legal’s plate and assign one person who is responsible for that decision.

By taking the time to answer these questions and assign a champion, time-crunched legal teams can set themselves up for success when implementing tech, and ensure that this investment is also valuable for the wider business

Join our community of in-house lawyers and legal ops teams, for access to the best events, curated content, networking opportunities and the hottest jobs.