Legal & product collaboration: best practice

Michael Haynes: Hi everyone, welcome to another Juro roundtable. You might be noticing that your host is a little bit different this week. That's because Tom Bangay has gone on extended paternity leave, so you're left with the B team. I'm Michael Haynes, I'm Juro's general counsel. I was also a two-time Juro customer before I joined, so do hit me up if you've got any questions about Juro.

I think today's roundtable is a really excellent one to kind of start off my hosting career with though. We're going to be talking about how legal can collaborate with product teams. I know that this is a topic that's really, really close to so many people in the Juro community. We've got some amazing tech businesses out there and lawyers struggling to get their heads around the technology and work effectively with products and engineering leaders. And we've got a couple of speakers with us today who are just the excellent examples of people on both sides of the fence when it comes to working with product.

So I think what we're going to do is we're going to cover three things. We're going to start shortly with some introductions. And during those introductions, I'm going to ask you to participate in an audience poll, which you can get to on the kind of apps bar on the right-hand side in Livestorm. But we're going to move on after the introduction, we're going to talk about how we collaborate and embed legal in the product team. And secondly, we're going to talk about how we balance risk, which the lawyers are always worried about, with innovation, which are the things that the product team really wants to do. And then we're going to finish with some audience Q&A. So without any further ado, I'm going to ask Ankur and Clara to introduce themselves. Let's start with you, Ankur.

Ankur: Thanks, Michael. So my name is Ankur. As Michael said, I am a chief product and technology officer at a company called PerkBox based in London. We are an HR tech company who help employers retain top talent, boost employee engagement by providing rewards and recognition, perks, benefits, and well-being offering. I've been building products for millions of users now in Asia Pacific, US, and lately in UK and Europe for now about 18 years. Really looking forward to speaking with Clara and Michael around how we have been doing this for the last 18 years.

Clara Miralles: Hi. Thanks, Michael and Ankur. I'm Clara Miralles. I'm currently working at DocPlanner, which is a tech global company that designs and sells products to make the health experience more human. Currently, I'm the senior product and privacy counsel at the global level. I'm a lawyer by trade, but during my career, I have had several positions that are more like operational positions in which some of them I have worked and supervised systems, tech and product teams. So I have a little bit of both sides. I have been on both sides of the fence, which makes it really interesting. And also I am a privacy enthusiast. So for the last 10 to 12 years, I have been really looking at all the aspects of privacy in technology, but also now more recently in other upcoming topics such as AI and others. So really looking forward to tackle that.

Product collaboration: where to start?

Michael Haynes: Thanks, Clara. It's great to have a fellow privacy enthusiast on. I'm not sure if Ankur is as well. So the poll we took, whilst you were kind of introducing yourselves, tells us that about 80% of legal teams who are represented on this webinar don't have a dedicated product counsel. So there are people like me who are kind of rank amateurs when it comes to trying to work their way through a product process. They don't spend all their time doing it. So I'm really interested to kick off with finding out what's the best way to approach collaboration between legal and product teams. And maybe we start with Ankur, right, from the product side as the recipient of that service.

Ankur: This is very cliché. I won't say it's an advice, but it's one of the things which not a lot of product folks do very often while building products. They need to build relationships. They need to build relationships, especially when they don't need legal teams' help. They need to build relationships early and often. And they need to start working with legal teams right at the conceptualization phase.

What happens more often than not is, and I've seen that I've done that mistake a lot of times, especially at the beginning of my career. We product folks do not treat legal as a stakeholder like sales or marketing. Legal needs to be treated foremost as a stakeholder, as sales or marketing. They need to be actually brought in at the table right from the conceptualization phase of building the product, sometimes even before that. Sometimes even when product folks are even thinking about an idea or bouncing off something, brainstorming something, they need to meet them more often.

Is there a committee like at our company, there's an ISO committee and we meet monthly. Even if there are informal exchange of ideas which happen over there, it helps us bring those informal ideas later on on our bi-weekly conversations. But these are some common things which we need to do more often than not for legal and product teams to collaborate.

Michael Haynes: Thanks, Ankur. And Clara, you've kind of done this role of trying to kind of be the lawyer that's embedded in a product team. How do you go about establishing that close working relationship that Ankur's talking about? Do you have these kind of regular formal check-ins that you're talking about, kind of like a monthly committee, or is it something more ingrained than that?

Clara Miralles: Well, we do have the regular check-ins and I have to say that DocPlanner only had a dedicated and embedded as a counsel in the product team since like January. We are quite a big company. So it's quite common not to have like a dedicated person. So, but the way of embedding the legal department is in the line of what Ankur was saying is that I participate in what they call the OKR definition, the KPIs and the, so it's at inception level among those conversations where the product and the sales and the customer service teams are thinking, what are our priorities for the quarter? That helps a lot because then I can support them from the get-go.

Collaborating with the wider business on product

And I think the key element here is being seen as a business partner. It's a stakeholder, but also a business partner. Someone that when you're bouncing ideas can also give you like a kind of a guide of like, if you're bouncing, you're kind of deciding between A and B, B will be much easier from a compliance legal privacy standpoint. And then let's, you know, so that the teams already know where the complexities are, right? So I think that's what is the success of being at the inception. And then for me is to also not be only at the inception and then once it's done, but just be there for the whole process when they start designing, when they start making like the implementation decisions, when they do the product deployment and when they do the testing, because then you can support all the way and embed yourself freely in what is a development process. And I think that's kind of key to also be able to iterate or adjust because of course, product teams rarely work on a really structured waterfall model. They just are agile and they need to be iterating and then they find a blocker and then they create like a solution, a fast solution and you have to be there involved because you know you have to also be able to to help them modify the course that they have previously defined. That's what I think it's been working really well for us.

Michael Haynes: And do you find it, how easy is it to kind of establish credibility right in those processes as the lawyer? How much of an understanding do you need to have with the technology? The question always comes up, it's like, do I need to understand how to code to kind of do this properly?

Clara Miralles: Absolutely not. I don't have a clue of coding. I am not even trying. But I would say that it is important to clearly understand the product at, let's say, we'll say, architecture level, how it functions. You don't need to know how to code, but you do need to know how, especially in big companies where different products interact and there's this wall of integrations and all this thing, you really need to understand a little bit how each product works at the really high level and how they interact. And that you need to have certain technical, I don't know if skills, but interest. You need to be a really curious person, do the right questions, not be afraid of making dumb questions at the right time. And I think credibility comes with that approach of if I don't understand, I ask, but I'm listening and I'm trying to understand. I'm not just going on like, this is not something I need to understand. So it's a bit of like a negotiation between the two and mentoring and tutoring and being able to share your knowledge without fear of being perceived as not technical enough. We are never going to be as technical as any of the product or tech guys. And that's fine.

Michael Haynes: Ankur, what's your experience with that? You've got lawyers coming into your process. Do they come in with an understanding of the technology, or how do you get there as the product person?

Ankur: I think Clara hit the nail on the head. The expectation would never be to understand at a code level. For that matter, even most of the product guys don't know the product at a kernel level or at a granular level, at a code level. But the functional aspect of the product needs to be understood. And they should not be scared of asking questions. They should not be scared of challenging the preconceived notions.

More likely than not, you would realize that they are actually baked into people's heads. And it has nothing to do with being in product. But a lot of time, it is also dependent on what the company is doing. Nine times out of 10, the company would not have a core competency like IP. If the company would have a core competency like IP, like IP, right? Then perhaps they can actually get a lawyer or a legal person who has an expertise in that specific IP, let's say hardware or self-drive. And that piece, they can either bring in in-house or can outsource. But apart from that, if, for instance, if the biggest work, hypothetically at PerkBox, is contracts, then I would actually work with legal to make that process most efficient. So that is how I would look at it. But even to make that process efficient, legal needs to understand product functionally really, really well. The sales process really, really well. Correct. So it's more about understanding how the function works, rather than what it does, rather than being able to take a spanner to it and start repairing it. That's not agile.

Michael Haynes: And then just talking about this idea of early engagement between legal and product. Like one of the really interesting things I find is like when you end up with OKRs or KPIs kind of set in isolated silos, at your organizations, how involved is legal in the process of setting OKRs for the quarter or the half? And vice versa, how involved is product in influencing what legal should be doing in a particular kind of period? Let's start with Clara.

Legal's influence on product collaboration

Clara Miralles: Well, this is in our company, this is kind of like a really like collaborative approach. Obviously, there are like mostly product drives. Those KPIs or OKRs, whatever you use the term in the company, right? So the product decides what the product needs to do and what is the next feature that you need to develop. So, and then they fix those KPIs. And then what Legal does is kind of like based on what the company needs to achieve, then we set our KPIs because we are a service within the company and therefore, product always drives.

Except for there are some features that are required by law. And there is a negotiation with the product team of like, okay, you need to do, let's say these three features because customers are asking for this and this will add value to the product. But also we need to do these other change because whatever regulation came up. So it's a negotiation of how we make it possible that you embed, like that you give us that technical team to do this. There are companies like DocPlanner that now they're testing a mode where we have what we call a legal tech team that is a technical team that works for the legal department to kind of like work with other teams to embed this more like what we call compliance features, right?

But this requires a big team and this is a new model that we're trying and it works, right? But it's always a negotiation, always a negotiation. And also the legal team has to understand that especially when you launch a new product, many of the times what you're testing is if the product has a value. So you can't, you don't, it cannot be perfect from a legal standpoint. You can't stop it. They need to try it. So sometimes also the agreement is like, okay, let's do a basic launch. Let's try it. And if it works, then we can embed more privacy or more compliance in it. So it's a negotiation of priorities and also of levels of compliance that you need to launch an MVP, for instance.

Michael Haynes: That's really interesting. Ankur, PerkBox, is it a negotiation or a battle or something like that?

Ankur: Yeah, it's very similar to what Clara said. We follow our OKR process wherein the OKRs get defined. They flow in from the organization strategy and then they flow down. So the product strategy itself is fed from the organization strategy and it gets aligned every quarter. And then there would be OKRs where cross-functional teams need to work on. And that's where product or marketing and legal, they would come together and they would start working as a cross-functional team. An example could be, let's hypothetically, let's bring in what are the new innovations which we can do in Q3, let's say July to September from using generative AI. I'm making it up. That's where legal and product need to work together, need to start actually working in this quarter so that they can have a framework on what can be the key results which they can achieve using it. But this is how it happens. There would be a cross-functional team which will try to achieve for it.

Michael Haynes: Great. And one final question on collaboration before we start talking about the risk-innovation balance. How does the feedback loop work between product and legal? What's it like, Ankur, giving feedback to a lawyer and receiving it from a lawyer? And then Clara, I guess the same, what's it like giving feedback and receiving it from the product team? Let's start with you, Ankur, and I'll ask Clara to finish out.

Ankur: Yeah. So I think one of the things which I have realized over the period of time is that we have kind of landed with a process which enables anyone in the organization to feed back into product. We call it a product live log process.

This is an excerpt from the full transcript. To watch the webinar in full, click the preview at the top of this page.