How legal should collaborate with the product team

When legal works at a scaleup where the product is the business - how can they collaborate with and enable the product team to work as efficiently as possible?

We decided to ask Philipp Kaufold, in-house lawyer at Clark - the digital insurance platform.

Hi 👋 Who are you?

I'm Philipp, I’m the legal counsel and data protection officer at Clark. I handle the general legal requests and legal issues, as well as data privacy and information security compliance.

Why is it important for legal to consider the product side of the business?

Simply put, the product is the business - and especially at tech companies, it makes up the core activity. Understanding the product, and how the product team operates, will help legal better understand the business. 

From a day-to-day perspective, technology products are regulated heavily, so legal needs to understand sector-specific regulations that might affect the business. If legal works at a business building a banking application, for example, they need to understand how banking regulation works. Clark is a digital insurance platform, so I need to understand how insurance contracts work.

How often do you get to collaborate with the product team?

I have weekly touch points with my colleagues in the product team. We focus our meetings around current projects and feature updates - usually the product team approaches me with a feature they’d like to implement, and I research the regulation and compliance around this, and inform the product team of the legal requirements. It also works the other way around, where I proactively review the roadmap and offer information on compliance features the product team needs to implement.

Lawyers should adopt the language of the client. We always have a message and we always want that message to be understood, so we have to take our legal language and translate it into the recipient's language

How do you ensure that you make legal knowledge accessible and understandable to teams, like product, who may not have that legal background?

I have a few steps I usually take:

1. Simplify the problem. When trying to explain a complex legal rule, full of prerequisites and exceptions, I simplify it to the extent that it still works in a product context. 
2. Visualize the problem. I personally like to use Miro for this, but you can use anything, from a PowerPoint presentation to sticky notes on a whiteboard. I build a model of the user journey and how it will be affected by this legal requirement - and in the same diagram I also demonstrate the benefits of addressing this legal issue.
3. Get feedback. I usually arrange a (virtual) workshop where the product team can ask me any questions. 
4. Iterate. Sometimes it’s clear I need to improve the model so they have a better understanding of the visualization. I’ll take their feedback and make those changes. 

Once all this is complete, the product and legal teams can start scoping and defining specific requirements or user stories. 

How did you go about adopting that process? 

It’s almost a design-driven approach to a legal problem; I collaborate closely with product managers and learn from their design techniques. 

Lawyers should adopt the language of the client. I think that's really important in our profession, as we’re always interacting with people who aren’t lawyers. We always have a message and we always want that message to be understood, so we have to take our legal language and translate it into the recipient's language. 

This is something I adopt when I collaborate with various teams in the business - and when it came to collaborating with the product team, I make sure they understand the value of finding a ‘common language’ in the early stages.

And how do legal’s responsibilities towards the product change as the business scales? 

The bigger the business, the bigger the legal and compliance issues. The responsibility also changes in terms of governance; if you have a lean legal team, serving a lean product team, you don't need a lot of governance or processes. That lack of governance and processes can be compensated by the personal diligence of the people you hire. 

Once your team reaches a certain stage, you need to be stricter with organization in the function. And this is where the legal and compliance team can strive to enable product. They can build processes that are flexible enough to allow the product team to do their jobs in the way they are used to doing it.

In the first six months it’s important to talk to product managers; they have this entire management capacity that you, as a lawyer, have an effective way of tapping into

Say the product team is planning a huge feature update - at what stage should legal get involved? And what does that involvement look like?

It makes sense if legal is involved in the roadmapping process, so that they have a high-level overview on the plan ahead. If the product team runs a quarterly roadmap session, then legal should get an update on the objectives at a high level. Both teams should take this as an opportunity to drill down where necessary and get as much information as possible.

For example, if a new feature involves the processing of sensitive data, the product team should assess this and know where to ask for more information from legal. It's more of a collaboration around the features than a strict hierarchical process where legal sends out demands and blocks on certain updates.

Lawyers joining a tech company might never have worked with engineers and developers before. What advice would you give to lawyers joining a tech company for the first time?

Probably the most important: make sure you use the product or service as much as you can. This is the best way to understand how the lifecycle of a product works, and how the product team operates.

In the first six months it’s also important to talk to product managers. The product manager is responsible for taking requests from the leadership team and figuring out: what does this requirement mean for the business? How do we update our product to address this? Who do we need to involve? Who is taking ownership of this project? 

They have this entire management capacity that you, as a lawyer, have an effective way of tapping into. As well as taking inspiration from them, you need to have a good relationship with the product managers personally. They're the ones likely responsible for handling legal’s requirements.

And finally, I would say it’s important to understand how the product-side of the business is organized; you have product management, engineering, quality assurance, information security, and so on. Understanding these different teams, as well as their responsibilities, will help legal identify the right stakeholders for specific issues, and integrate more effectively into the business.

Thanks, Philipp!

Philipp Kaufold is the legal counsel and DPO at Clark. Want to hear more from the visionaries scaling in-house legal? Join our community of 400+ lawyers and legal ops teams.