Our next speaker who's here with me now, RAA Ashar Le uh vice president of product Legal Practice and productivity at Thomson Reuters going to share more about partnering with your product team.She believes that a key driver of success in making sure the product team and technology team share the same vision and priorities. Please welcome Ravi on this stage. We're super excited to have you here with us today.

Hi, thank you, Anna. And I'm really excited to be here. It's been such a wonderful conference and it's great to see so many women sharing with each other and so motivated. So I'm, I'm really thrilled to be here. Um Joining you all um as mentioned, my name is Ravi Ashraf. Um And I'm at Thompson Reuters just a little bit of background. I am a lawyer by training, I practiced law for 10 years um in the US in New York and Washington DC. And then I joined Thompson Reuters. Um And I've been in product management since then and I have to say I love it. And so today I'm gonna talk about um my experience is working with tech and sort of some of the, the lessons learned and, and what, what has to happen or what goes well when um product and tech teams are, are working together. So I'm just gonna share um these key principles and so these are the things I'm gonna talk about today being one team, um sharing priorities and accountability, sharing your customer and then really communicating. Um And I'm, I'm hoping that there'll be um plenty of time for questions at the end. Uh I'd love to um hear what others think about this as well. So let's start out with the first principle and that is the one team I think.

Um the title of my talk is a bit of a misnomer because it's how can product and tech teams work well together. And I think the idea is that they shouldn't think of themselves as separate teams no matter what the ORG chart says, you know, if engineering rolls up into one part of the business, um and product is in a different part of the business or even UX is into a different leader, uh The, the people working on one product or delivering a project should consider themselves all part of the same team.

Um I've had the opportunity to work on a bunch of different um teams and different structures. Uh And my favorites have been the one where everyone's reporting into the same leader, right? Where the tech lead and the uh the UX lead and the product lead they all have the same boss. They are all moving in the same direction, very similar to, you know, the start up experience. But if you are in more of an enterprise organization working in a large company, it's tough to sort of have an org chart that reflects that way of working. And so I just encourage everyone to think of yourselves as one team and act like one team. Um And that's sort of the greatest, I think predictor of your success. But then what does it really mean to be one team? And I think those are sort of the next principles I wanna talk through. So to my mind, to be one team, tech and product have to share priorities and accountability, right? So for example, everyone should sort of be rowing in the same direction and, and needs to know what the most important things are on the road map or what are the most important customer problems or what are the biggest sort of tech challenges the team is, is handling.

And so if for everyone sort of pointed in the same direction, you're much more set up for success. And so along those lines, my um engineering partner sort of the tech lead for one of my teams, he and I get together with uh our full team at the beginning of every week and we share what the priorities are for that week. The engineers are there, the product owners are there the architect is there, the UX team is there and we, we just actually articulate this week, these are our top priorities. And I think hearing that at the beginning of the week helps everyone align their work towards those right priorities. They could be spending tons of time, tons of story points on something that's actually not pointed towards a key priority. And if, if you understand those priorities, you can redirect your efforts or, or sort of raise your hand and say, hey, I've got something, I'm totally heads down on it and I don't see how it lines up with the priorities. And it's a really good way for the whole team to, to assess that. And similarly sort of the the flip side to that is the team has to share accountability, right?

So that means um if, if uh a deadline is being missed, a ship date is being missed, um Tech team should show up with the product team, you know, if there's a meeting out to stakeholders to explain sort of why is why are we missing this release date or, or what's going on with this environment?

If, if tech partners show up with their product partners at those meetings, it really goes a long way to presenting um the group as one team and it's not just sort of like a product team and they have an engineering team over here on the side that's doing the work, but isn't actually part of that core accountability.

So I've always found that goes really well and it has to go the other way too. Right. If, if the product team hasn't given enough requirements, hasn't given enough specificity to the DEV team and things aren't, um, on, on target or on schedule. I think the product team needs to show up at those meetings where the tech team is explaining why deadlines were missed to say, look, that was our miss. We, we needed to do better there and we're, we're on it going forward. So in addition to that one thing that I've found hugely helpful um in successful teams is if the technology team and, and the product managers share a customer and what I mean by that is tech should not be behind a wall and not get access to customers. And if that's sort of the experience you have or that's sort of the way your organization is structured, you should really raise your hand and ask to learn more about the customer. I fully believe that any engineer or developer who's maybe working on an API or setting up an environment or, or pulling together the architecture for, for a build should be able to articulate how that's going to impact the customer's experience, right? And to do that, you need to be able to explain what the customer's problems are and what the customer's pain points are. Something in the product world that we talk about a lot is falling in love with your customer's problem. Right.

And making it your own problem so that you think about it, you think about how to solve it from that customer's perspective and I think that it should extend to technology as well. One thing that we've done at tr that I've seen pay great dividends is that I invite um engineers dev leads architects to meetings with customers so that they can hear it firsthand. It, it's all well and good to get a summary. You know, if you share like a market research report or customer research report with, with your developers, it it's, it's helpful, they'll understand some of the context but there nothing beats being in the room with the customer and hearing them talk about their challenge and what they need solved.

It really can animate and motivate all the work people are, are doing after, after that, in addition to that, um it, it's good to hear customer feedback as well, right? That tends to go. So beyond the discovery phase of figuring out what the customers challenges are once the product's live or you're doing, you know, you're revamping it or, or something. It's really good to hear that real time feedback that sales teams or account teams are hearing from the customer.

So I always encourage technology people to join those sorts of meetings. And if you're not doing that, raise your hand, ask for that. Uh ask, I think it'll just make everyone so much better at their job and really be able to, again, to share those priorities if they understand that the customer's problems that the product is meant to solve. And then finally, sort of the next key um principle for success is to communicate. I mean, I know that one's obvious we hear that all the time, but I just want to dig into a little bit about what that means. So, so for example, one thing I learned from um my Dev team that I work with is that they need hours and hours of uninterrupted time if they're going to complete a task, right? And so the way that product people work or managers work is that we tend to be in meetings after meetings, after meetings. And so we schedule our days that way, but our, our DEV team is very clear like they can't, if you go to a 30 minute meeting in the middle of the day, it sort of breaks up your whole flow and the whole task you'd set up to challenge gets interrupted.

And so, and that's the way you work, communicate that our team communicated it to us. And so we've set up certain hours, uh you know, Tuesday or Wednesday mornings where we'll have, we can have meetings where we invite the developers or, you know, maybe on Thursday evening, there's a, there's a block of time where we can invite developers, but we are now know not to interrupt the middle of their day and their flow with the meeting.

Um Also, II, I think this goes without saying, but if something's not going right, communicate that early to your, your product partners, let them know, give them a heads up um and come with solutions, right? So if you think something's not going well, product team would totally appreciate it. If you say, hey, this is sort of not, this is going a little bit off the rails or we see some risk here and here's what we think we should do to mitigate it or here's what we need to be able to mitigate it. So those sorts of things, if you put them on the table early, I think that only makes the team better and more equipped to deal with challenges. And then uh sort of another thing that's good practice is to do retros right after the fact, communicate about what went well, what didn't go well, what should we keep doing? What do we need to change? Where do we need more impact or sorry? Um Process. How are we uh delivering all of those sorts of things? Make the team continually get better and better. And then uh another piece of communicating I think is also being comfortable challenging and pushing back, right?

If something's happening, some, the product team is maybe put something together and there aren't enough requirements or you don't understand how it leads to the vision or maybe it's not technically feasible or is not um funded properly. Raise your hand and push back on that challenge. The team.

I think that's always helpful and it leads to better outcomes. And when you do see yourself as one team, it's much easier within that environment to challenge rather than feeling like you're sitting on the outside criticizing another team. You know, I've, I have seven products now that um roll up into my team. So I've had lots of different experiences working with um different types of tech teams, different types of product teams. And I will say a above all to me, the most important thing is that everyone is on the same page about priority. So I, I'll just like hit that one again. Everyone needs to be sort of sharing the same North stars and knowing what is going to deliver the most value to your customers instead of thinking about, you know, feature 53 on the backlog, right? Think about how those things that you're building are gonna help the customer and, and why those are your priorities? So I'll, I'll stop there um to see if there's any questions or um any comments. OK. I see one from Nikita. And how do you encourage free expression during retros, especially when you have a diverse team of tech and product people. Oh, that's such a good question. We often run into an issue like that where we'll have a big retro and then no one will talk, right?

You're like, hey guys, let's get it all out there. Let's figure out what we need to do. And if, if that's what's happening, I think there's a couple of, of, of tools or solutions, one is that you can have sort of one on one conversations ahead of time before the retro. So if you think there's some people who are sort of shy or, or hesitant to speak, I think that's a good way to sort of get them to share their concerns, one on one. And then either represent those concerns at the retro or encourage them to share those because you, when you know that, that they have a concern that they wanted to raise, I think the other way to do that is to model it right? To be brave and say, hey, I don't think this went well and here's why and if people see you do that and see that that actually yields a positive outcome and there aren't terrible repercussions for it, I think that they'll also have the confidence to do that. Are there any other questions? What has been the most complex situation that you have lived with your team? How have you faced it? Wow.

So there's probably a number of them, I always think a really complex situation is in the, in the pre launch period making that go no go decision, right? Like because I always believe that you should launch a product. You know, there's that old saying that if you're not embarrassed of your MVP, you've launched too late, right? Like you need to get your product out there and start getting feedback and get it in customers hands. And I think it, that's always a complex situation of figuring out.

Like, are we there, do we have an MVP? Have we delivered enough value that we can get this out there and start getting customer feedback and start testing what we built um without actually just put shipping something that's not ready, not ready to go live. And so that takes everyone's input, right? You have to have the UX team saying look, we think these are the three minimal things that we have to have in the product before we launch. And you have to have the tech team say these are the sort of functional and non functional things we need before we can be ready to launch. And then you have to have the product team saying these are the sort of use cases or user stories that we need. Um people, we need to be able to deliver before we can launch. And that is always a bit of a dance, right? Because you're nervous but you still want to launch a product. I mean, I guess the other really complex situation is when you don't have enough funding to do what you want to do. But I think we all learn to make do and figure out what you have to shave off of your road map and out of your backlog to do the best um with what you've got? Um OK. I think that's really on all of it for me.

Um If there are other questions.

Hi, Ria, let's take some questions from the chat. Ok. Are there more of methodist techniques? Are there?

Ok. Yeah, there's a ton more for coming. OK. What kind of methodologies in terms? Sorry. So what kind of methodologies techniques are you using to co create with a customer? Um So my favorite one is to do a design session with a customer, right? Where first you do some interviews and you understand if the customer has a particular problem. So the products I build are in the legal space, right? So let, let's say the issue is the customer, say this part of of contracting or drafting a contract is very difficult, right?

We're, we're struggling with that. So you do some preliminary interviews to sort of understand or hear them describe that problem in their own words. And then the next thing I like to do. So then you take that back, you sketch that out. You're like here's our understanding of your problem and then you have a cosign workshop with the partner with the um customer where you say let's look at your problem. Let's talk about what the main challenges are in this sort of design thinking and then what could be an ideal outcome, you know, what would be the, the end state that would work for everyone. And then you sort of prioritize within that to have the customer say if you did this thing, this would help me the most or if you, um you know, if we could have a better integration here that would make our, our life so much better. And so I think it's really, you know, getting out there and white boarding it with customers since the pandemic, we've been using Nero a lot to do it virtually with customers, but it's really getting in the room with them and charting it out and talking about the biggest problems and the biggest impact from solving those problems.

Like what problem could, what could, what should you prioritize in terms of solving? Have you had any failures? And what was the biggest lesson? Oh my God, tons of failures. Um And I think for me, the biggest lesson, especially like sort of growing up, you know, in school, like I was always an a student, always got good feedback and I, I thought that failure was not acceptable, right? If you failed at something that was some sort of reflection on you or like a uh a weakness in you and then you learn that you actually, you just, nobody is perfect. You have to fail at things. It's just the, the laws of probability, things are gonna go wrong. And so that I think was my first big learning is getting comfortable or accepting the fact that I'm gonna fail because that, that was, that didn't come natural to me. And I don't know that it comes natural to anybody. And then the second one is all right. So if I failed, what do I do with this? Right? Anything that comes down to, I have to learn something from this failure, right? Because if you're not learning from the failure, you're gonna continually repeat that. And so that's sort of why retros are helpful with a group, but you should even do a retro with yourself like that meeting I had didn't go well.

Why do I feel like it didn't go well and think about it and sort of reflect on yourself, like, what was I not prepared was the other side sort of, did they have different expectations? You just sort of really figure out, you know, with yourself, what you could have, what you could do better or differently in, in that situation. Do we have any more questions coming in? Thanks to everyone who is um chatting in and participating. I really appreciate that

fantastic presentation. I love how masterful you're moderating the chat. This interaction with our audience is fantastic and I can totally relate about the failure and I think that we should get more comfortable with the failure and also reflect on it.

Yeah, absolutely.

Thank you. Thank you. Great presentation.

Yeah, my pleasure. Thanks for having me and enjoy the rest of the conference everyone.