How Product and Engineering (Actually) Work Together

Introduction to Product and Engineering Collaboration

Rina Alexin | 00:02.967–00:29.164

Hello everyone. And welcome to Productside stories, the podcast where we reveal the very real and raw lessons learned from product leaders and thinkers all over the world. I’m your host, Rena Lexin, CEO of Productside. And today I have a very special guest. Well, joining me today is Guy Gershoni, head of engineering at genesis IT. sorry. Let me just redo that.

Guy Gershoni | 00:29.164–00:32.781

That’s right.

Rina Alexin | 00:32.781–01:10.638

Joining me today is Guy Gershoni, Head of Engineering at Genesit Consulting. He comes with over 20 years of experience in software engineering, AI and data. He’s led engineering teams across startups and enterprises, helping them scale while staying lean and modernizing their operations to build better products. Guy has been nominated by product leader and now founder, Lee Jia.

as someone who can talk to the very real need for us to break down silos between product and engineering and craft a really powerful partnership. Excited to talk to you, Guy. Thanks for joining us today.

Guy Gershoni | 01:10.638–01:13.229

Thank you very much for having me, Rina Alexin.

Rina Alexin | 01:13.229–01:34.158

So Guy, this is gonna be a unique episode. Why? Because stakeholders matter. Product management cannot get anything done without our partners. And that is why I wanted to invite you on the show. Because we wanna hear from you, from engineering, how do we work better together? yeah, and so that’s what we’re gonna talk about today. But first, I always like to find out what drew you

Guy Gershoni | 01:34.158–01:42.017

Absolutely.

Rina Alexin | 01:42.017–01:47.224

rather than to ProAidic management, but to engineering in the first place. Tell us about your background.

Guy Gershoni | 01:47.224–03:17.793

Well, okay. So I’ve always liked computers better than humans. I think they were a lot more predictable. And I sort of, was introduced to them as a kid. And then I sort of got into IT back in the 90s. And in the 90s, IT wasn’t very fashionable. It wasn’t yet, you know, a good job to do. It was very much the enclave of nerds and sort of, you know, outsiders.

And I very much sort of thought, you know, if I’m going to spend the next, you know, 20, 30 years working, you know, try to make a good living, I’d rather be in the basement with sort of the interesting people. so that’s sort of, honestly, that’s what kind of drew me to IT was just sort of the people who were doing IT at the time, which were really, really interesting in the nineties. And then it sort of evolved from there. And I have to say, I was very disappointed because I remember being told in high school and uni,

that we’d have four major career changes in our lives because the economy was becoming a lot more fluid and flexible. But yes, you’re very polite saying 20 years, it’s closer to 30 years now. I’ve been in IT. But the other thing that really interests me in IT is even though you are doing IT, I’ve explored so many different worlds and domains in that period and also

been exposed to different parts of sort of the IT lifecycle as well. So if you’re a very curious person, IT is a really great place to be.

Rina Alexin | 03:17.793–03:26.19

guy, you know, in terms of what you just said, I feel like most of us feel at one point or another, like we are the outsiders. And so I just wonder how many interesting full basements or full of people there are, but lovely to have you. So you were nominated because you have successfully crafted a great relationship with your product counterparts. Can you tell us about your view of product management?

Guy Gershoni | 03:26.19–03:35.116

You

Guy Gershoni | 03:35.116–03:43.267

Yes.

Guy’s Journey into Engineering

Guy Gershoni | 03:43.267–03:47.576

Yes.

Guy Gershoni | 03:47.576–05:13.516

Look, I think product management is absolutely essential. I think that there is this misconception that engineers just want to stuff well and don’t necessarily care about what they build. But that’s not true. Like when I’ve worked with engineering teams and we’re provided either by the product or ourselves have sort of crafted feedback mechanisms to understand how our product is being used, either

via watching our customers through website metrics, but also talking to various other sort of parts of the business. Engineers are much, much, much happier and more excited about building stuff that people value. And so this is the irony. I remember having this discussion with one tech leader and he was like, we should use this really interesting framework and this very interesting technology stack. And I sort of said, look, it doesn’t really matter. As long as we’re doing, as long as…

we feel we’re actually contributing and adding value and people appreciate it, we can write it in Cobalt for all week here. So I think at the end of the day, if you see engineering teams that are obsessing about framework and tooling, it’s usually because they haven’t been given enough feedback or direction to focus on the bigger picture. But intrinsically, they want to do stuff that’s valuable.

Rina Alexin | 05:13.516–05:21.048

Yeah, I can’t imagine there’s anybody that wants to spend part of their career building something cool and shiny that nobody wants. And that happens too often. I like to think about when we talk from a business perspective, oh, there’s all this money wasted. But I like to think about the careers. Some of the time was wasted building this product. So the best way to avoid that, to your point, is to have a really healthy relationship between product and engineering.

Guy Gershoni | 05:21.048–05:31.628

Mmm.

Yeah.

Guy Gershoni | 05:31.628–05:41.155

Hmm. Hmm.

Guy Gershoni | 05:41.155–05:42.848

Yes.

Rina Alexin | 05:42.848–05:50.42

where both sides really understand their role and what they bring to the table. What do you think makes for a really healthy relationship?

Guy Gershoni | 05:50.42–07:35.445

I think what’s really healthy is, at least a common ground and mutual understanding. Right. So I don’t expect a product manager to have the depth in it knowledge and sort of architecture and stuff like that, that, you know, myself or some of the people working in my team would have, nor do I expect my people to have the depth of understanding of the market and, you know, product market fit and various other sort of, you know, product thinking, but.

I expect both sides to know enough to be able to talk to each other, you know, and ask the right questions. I mean, that really actually, to be honest, Rena, it’s just about asking the right questions. You know, hey, here, you know, this is what we’re trying to do. These are some of the things we think would work in the market. You know, how could we go about implementing them? Hey, by the way, Rena, we’ve got some, you know, enablers at the moment. AWS has released X, Y, and Z. We could easily and cheaply do, you know, this and that. What, you know,

does that open up any opportunities for you? as long as this of this, you know, sharing, asking of questions and shared knowledge and also learning from each other, like, you know, as engineers, we love those aha moments. We love those sort of like pops in the head. And so, you know, when we sit there and look at sort of data of usage or we try and experiment and something unexpected happens, you know.

the engineers will get excited and they love that. And then they’ll start coming in saying, how can we help with that? yeah, sort of bringing that on the journey and some of the most constructive conversations we’ve had as well hasn’t been necessarily about building the features, but building the enablers in order to enable experimentation. And so that’s, yeah, we’ll talk about that a bit later as well.

The Importance of Product Management

Rina Alexin | 07:35.445–07:48.116

Yeah, I want to talk about, I definitely want to talk about experimentation. think that’s really important and both teams need to be, you know, I think very much in sync to do this well because people can run completely wrong types of experiments. However, okay, so I actually want to dig into this. You just said that engineers, we love these like light bulb moments, these aha moments. And I almost wonder if there could be more communication of the wins between product and engineering. So tell me about that. Like what gets

Guy Gershoni | 07:48.116–08:00.888

goshes.

Guy Gershoni | 08:00.888–08:05.26

Yes.

Rina Alexin | 08:05.26–08:16.46

an engineering team really excited that product might be able to, I don’t know, maybe communicate better so that they can get more of those kinds of moments.

Guy Gershoni | 08:16.46–10:43.486

Look, think so engineers, we like numbers and we like objective sort of database decision making. You know, this is what we’re comfortable with. You know, we sort of get trained in big O, the low algorithm analysis, all that kind of stuff. for us to, know, and it’s, you know, very easy sometimes when you’re not in that world to sort of go, I think this is right, because that’s what my gut tells me. Right. As opposed to if you’re sort of sitting there going, Hey, team,

This is the data we’ve collected. This is how we’ve been interpreting the data and why. These are the assumptions we’re making and these are some of the predictions which we need to try and test. That speaks a lot more to how engineers think and get excited. And then, you know, also bringing back and saying, are there ways that you can help me get to, you know, run these experiments or understand, you know, what’s going on better? Because I guarantee you 99 times out of 100, Rina Alexin,

the instrumentation and the observability isn’t there yet. know, a lot of the time when we’re working in healthy companies where we’re sitting there trying to do database decision making and we’re sort of setting these sort of success criteria upfront about, you know, we’re doing this in order to see this kind of shift, you know, the OKR, objective key result type stuff. A lot of the time we have to stop and go, right, well, we need to actually build out the capabilities to measure this stuff because we don’t have that.

And if we don’t measure it, it’s obviously not important. And so it’s sort of just that, I think that sort of hats on. But that being said as well, once that trust is being built, both engineers and products do have very powerful intuition abilities, right? Both of us can sense certain things. So I think that’s important. The other thing that’s really important is not just looking at the short term, but also looking at the broader and longer term.

And the reason that that’s important is because engineering is all about compromises and cutting the right corners. And you can only really do that when you have enough information. So, you one of the things I see, you know, usually when I walk into engineering team, there’s two extremes. There’s the cowboy engineering where things were built and there was no design. And that eventually gets you sort of painted into a corner. And then there’s the other extreme where it’s sort of analysis paralysis. I’m sort of dealing with that right now where it’s just like,

Building Healthy Relationships between Product and Engineering

Guy Gershoni | 10:43.486–11:17.098

look, just write something, you know, like just get, stop worrying about, know, what’s going to happen in, you know, two years time, because if we don’t do something in the next two weeks, we’re not going to be here anymore. So it’s sort of finding that. And what’s important from a, for an engineer and the engineering team to understand is where you feel things are going and where there’s need to be flex flexible and where there’s opportunity to, you know, cut corners or.

there’s no need to sort of dive deeper from a technical perspective.

Rina Alexin | 11:17.098–11:33.27

Yeah, the perfectionists and me like, no, cutting corners, but you’re right. You have to make trade-offs. It’s impossible to go like that. Perfection should not really be the goal. should be just, it should be some, I don’t know what to call it. It’s not perfection. It’s that you have to make it workable, but you have to do so much testing that aiming for perfection at the start is the wrong thing to do. And I actually think that goes in line with experimentation, right?

Guy Gershoni | 11:33.27–11:44.771

Yeah. Yes.

Guy Gershoni | 11:44.771–11:45.599

Yes.

Rina Alexin | 11:45.599–12:11.043

Sometimes when a business decision is made to go in a certain direction, what ends up happening is, well, okay, an executive approved a project and now it’s you’re all in. And there’s so many things that you don’t know yet. And I think that a lot of companies really, and also product and engineering struggle with what is the right experimentation framework.

The Role of Experimentation in Product Development

Guy Gershoni | 12:11.043–12:11.604

Yes.

Rina Alexin | 12:11.604–12:20.31

you cut things down to smaller bite-sized pieces that you can actually tackle as a team in a shorter timeframe. So let’s actually talk about that now, since you brought it up, the importance of experimentation. So what kinds of experimentation frameworks do you like to use that you found successful?

Guy Gershoni | 12:20.31–12:29.486

Yes. Cool.

Guy Gershoni | 12:29.486–14:53.824

I don’t use formal frameworks. I’m going to plead ignorance. it’s more in the sense of we’ll do something. So as I sort of was mentioning, one of my bosses used to have this concept saying there’s too much poo running in production. And that’s a problem. The more code that’s running in production that isn’t very useful, the more vulnerabilities you have and attack vectors and more

a cognitive load to make any changes as well. we talked about, think previously around technical debt and how instead of thinking about debt, which from an engineer perspective is a bad thing because we’re not business people. Business people see debt as leverage and that’s an advantage. We talk about it more as increased risk. So the more guff you have, the harder it is to make changes, the slower and more dangerous it is. And that’s what we talk about technical risk, right?

And so what we do is before you write something, before you put something, you you sit down and you agree together with all the stakeholders, what is going to be the change we want to see, you know, with this feature? So for example, you have a OKR where your objective, which is something that you can measure but can’t directly change, is like, we want to increase conversions by 0.3%, right? And then we are going to sit there and we’re going to do four things that we can do, which we think will

improve conversions, right? And we’ll say if it can do, you know, point two, we’ll keep it. Sorry, we’ll iterate on it. Point three, we keep it. Less than that, just delete it, right? So keep, iterate, delete, kid. And that’s where we sort of sit. That’s the kind of experimentation we’ve done. Okay, we’ve done it. Are we seeing the change we want? If we are, great, let’s build on that. If we’re not, delete it. It’s not important. And I think for me, experimentation isn’t just

what you’re building from a feature, it goes all the way up to as an organization, culturally, is remote working better than hybrid working or in the office working? Let’s not make assumptions, let’s experiment, let’s try and see, and how do we objectively measure our productivity as well? So yeah, it’s sort of a culture of experimentation and being bold enough to say, we know that we don’t know.

Measuring Success and Learning from Experiments

Rina Alexin | 14:53.824–14:59.31

Yeah, so you have to be comfortable with the experiment going the way that you don’t want it to go. there are a lot of times where it’s like, no, I really want to, like you’re saying, increase conversion. And I think this is going to work. And sometimes I find that teams, and maybe you have something to say about this, the experiment that they are conducting might need more time than what they are.

Guy Gershoni | 14:59.31–15:16.046

Mmm.

Guy Gershoni | 15:16.046–15:17.24

Mm.

Rina Alexin | 15:17.24–15:22.392

kind of allowing, you know, maybe conversion data doesn’t come in after two weeks, maybe you need four weeks, right, that kind of experiment. But also just knowing going into something, I like to tell people, try to prove yourself wrong, versus falling in love and trying to find every single reason to confirm your hypothesis. Like your goal is to prove yourself wrong. And then you win either way, right?

Guy Gershoni | 15:22.392–15:38.04

Exactly.

Guy Gershoni | 15:38.04–15:43.308

Yes.

Guy Gershoni | 15:43.308–18:04.046

Yeah, yeah, yeah, a good scientific thinking, right? Like we have the hypothesis, we try and disprove the hypothesis. And then if we can’t, then we know that it’s correct. And you’re right. mean, look, sometimes the answer is as clear as day. Once we did this shopping cart conversion, was absolutely, the original shopping cart was horrible. It took like 30 seconds to click between screens. It was ancient and horrible. And so we sort of quietly wrote like a spa single page app.

This was way back when this was still fairly new. And suddenly the cart was just incredibly snappy. And we saw revenue increase by like 60%. So that was clearly OK. A was B. And we used to do the other. That was an interesting organization because we didn’t have the money to build a lot of automated testing and verification.

and so I was sort of originally brought in because I had a very strong background in developing complex automation test suites. but I sort of went, look, actually where we want to invest is in our nimbleness, our ability to deploy and roll back or roll forward changes quickly in a safe way. then technically it was a very interesting project because we also started doing things like containerization and segmentation and incremental improvements. But our main focus was being able to move fast.

That was really important. And then what we said, well, what inputs do we have that can tell us whether we made a mistake or not? And I hate to say it, unfortunately, our customers were our best testers. But what we figured is that right now, and again, this is one of my mantras is, you I think it’s a US Marines thing of like, just make today better than yesterday. It doesn’t need to be perfect. It just needs to be better than yesterday. So when we started,

you know, the site would have issues and you know, it would take a while for us to find out there was an issue and it would take quite a while to fix those issues. Now, if we could just at least reduce the amount of time to fix those issues, we’re already better. But then we sort of said, hey, you know, the customer service system, we can actually tap into its API and see, you know, if there’s any spikes in traffic. And so we just get into this habit at one stage of just.

Guy Gershoni | 18:04.046–18:36.588

deploying our changes into production, grabbing a coffee, watching the various graphs to see that user behavior is still consistent and there isn’t a spike in customer service. And if that was okay, great. If it was, it’s like, yep, we screwed up, quick roll that back. So even so it wasn’t, as you said, perfect or ideal, it was still light years ahead of where we were. And it gave us the bravery and the…

capital, know, emotional and sort of business capital to sit there and build even better solutions going forward. Yeah.

Collaboration Between Product Management and Engineering

Rina Alexin | 18:36.588–18:43.052

and that’s I is the best

Rina Alexin | 18:43.052–18:54.264

So I’m really enjoying this conversation, especially because at some parts, I feel like I’m talking to a product leader and then you bring in the actual technical aspects of it. And I’m like, no, it’s definitely engineering. This is amazing. But one of the things, Justin, the story you just shared made me think, how often do product managers actually work directly with engineering on the success metrics and the data behind what they’re building? How often does that happen? Or does it?

Guy Gershoni | 18:54.264–19:11.362

It’s just…

Guy Gershoni | 19:11.362–19:37.516

Well, not that often, which is why Lee and I enjoyed working together and recommend each other. Because that was really, for me, the first time that we really were attached at the hip. And Lee and I would have really wonderful adult conversations where it was just like, OK, here are some ideas that Lee had. And by the way, Lee was open. It wasn’t like, OK, I have these ideas.

Rina Alexin | 19:37.516–19:43.392

I’m so sorry. I don’t know how this happened, but my toddler ran into my room. One second, let me get my name.

Guy Gershoni | 19:43.392–19:52.366

No dramas, no dramas, totally understand that.

Mm-mm-mm-mm.

Guy Gershoni | 19:52.366–20:00.223

you

Rina Alexin | 20:00.223–20:07.455

Oh my god. That has never happened. He’s learned how to open the doors. Oh no! I’m so sorry, but he literally ran in and I was like, what is my nanny doing? Oh my gosh. Okay, Robin, who is going to be editing this, please edit this. Oh, she’s a level.

Guy Gershoni | 20:07.455–20:22.998

they get dangerous at that stage. Yes, yes.

That’s good.

Guy Gershoni | 20:22.998–20:28.204

Yeah. Yeah, we’re going.

Rina Alexin | 20:28.204–20:32.174

But okay, hold on, let me actually pause because we’re going to have to repeat that so that we can kind of back in. So I’m basically going to say like, how often does it happen that product managers work with engineering on the data side? And then you can share about Lee as well. Yeah. Go ahead. Take a break. Okay. Hold on.

Guy Gershoni | 20:32.174–20:42.7

Yeah, of course. Yeah, of course.

Guy Gershoni | 20:42.7–20:53.986

Yeah, absolutely. no, absolutely. So sorry, let me just. OK, yeah, we’re ready. Let’s go.

Guy Gershoni | 20:53.986–20:54.06

So you’re gonna ask how often,

Rina Alexin | 20:54.06–21:15.502

Yeah, I’m about to do it. so Guy, just what you’re saying, I’m now thinking like, how often does it happen that product management is actually working directly with engineering on the success metrics and like the data measurement? Because I feel like, it even happen? Does this happen often at all?

Guy Gershoni | 21:15.502–23:38.286

Well, the answer is not very often. This is why Lee and I enjoyed working together so much and have, you know, recommend each other because we were able to have really wonderful, robust conversations together and we both contributed to each other’s area. you know, from engineering side, we’d bring in our perspectives, but also put in our, know, our, customer hats on and he took those in and Lee would also come back with, you know, various

technology solutions he’d seen and said, look, if we integrated X, how would that be? Because a lot of the time too, one of the problems I work with as an engineering leader, engineers tend to like to sort of reinvent the wheel, right? Because you know the wheel is valuable, you know that it’s something that’s very useful. And so having that sorted, it’s very tempting from an engineering perspective, go, now I’m just going to build a better wheel because I know that…

If I build a better wheel, it’s going to have value. And that’s a disaster for most companies, right? And so one of the things I come in is sit with engineering and go, hey, you’re building a customer management system here. No, we’re going to integrate with an existing one or, hey, you’re building a content management system here. No, we’re going to integrate with something else. But then those conversations where we’re sort of going, right, we need to focus our energies on what is unique and builds business IP. Lee was actively involved in helping us

pick sort of other sort of external systems, know, and reviewing them and stuff like that. And then we’d have these interesting discussions where we want to do A B testing about attracting people to the site instead of wasting a lot of energy, you know, building email tracking and blah, blah, blah. Hey, let’s go and use, you know, off the shelf mailing system X. it’s like, okay, with that one there, Lee, they’ve got an API. We can inject the data that we need to sort of make that a lot easier for you to run that.

campaign and if it works great and if it doesn’t, we can move on. So I think it’s sort of these really high quality informed discussions where, and as you said, being brave enough to go, whoops, we’re wrong. I could show Lee some of the skeletons in the closet and he wouldn’t freak out about it. We’d just go, okay, how do we work around those and vice versa. He could tell me candidly about, look, these are things I don’t know.

Building Healthy Relationships in Teams

Guy Gershoni | 23:38.286–23:44.683

Or these are things I’m not sure about and then say, okay, well, how do we can we do something about that? Yeah

Rina Alexin | 23:44.683–23:54.69

Yeah, because I’m just wondering, because at some point in our conversation, you did bring up that there’s a, there often is like a data and success measurement problem. And it feels like, okay, well, engineering also gets excited by seeing the numbers, like the result. So this is, if we’re going to be talking about, well, how do you create really healthy and strong relationships? We need to create more opportunity. I mean, we haven’t talked about like what makes for dysfunctional relationship, but.

Guy Gershoni | 23:54.69–24:00.227

Yes.

Guy Gershoni | 24:00.227–24:13.346

gosh yes, yes.

Guy Gershoni | 24:13.346–24:13.878

Yeah.

Rina Alexin | 24:13.878–24:19.47

We need to create opportunities for those, you know, the celebratory wins. And I’m thinking this is kind of, and I’m sure product, some, not all product managers do this, but this is definitely an opportunity. If somebody’s working on a team that might not have a good relationship, it’s how do you find these like wins that you can celebrate together? Do you have other types of wins or ideas?

Guy Gershoni | 24:19.47–24:40.878

Yeah, yeah.

Guy Gershoni | 24:40.878–27:05.55

Look, mean, we talked about toxic relationships and I admitted to you that I was probably part of the toxic problem in various previous roles. Because once I was asked that, it’s like, how do we bring the team together? What kind of team activities should we do? And I sort of looked at the person very sort of coldly and said, well, if we deliver successful outcomes together, that will bring the team together. And that was frankly, in retrospect, a bit of a…

a bit of an uncool thing to say, but it is true, right? Like I think there’s definitely things we can do from a team building perspective to sort of break the ice, so to speak. But then I like to follow those up very promptly afterwards with like real world, okay, well, we’ve had the escape room fun. We’ve had a lavish dinner with a few sort of liquid lubricants with alcohol and stuff.

but now let’s have these candid conversations. What does success look like? What does it look like from a product perspective? from a product, putting your head on as a product manager, ask the technical team, what would make you excited technically? What would you like to see in the technical solution that would make you really excited? And it might be conversations like everyone’s excited about AI, for example, but what does that mean?

for our organization, where could we meaningfully use AI? And it doesn’t necessarily need to be in the system itself. It might be like, well, Rena, I know you want a status report every week with all this detailed information. Can we work on a AI system that provides you that report at the level you can share with your peers, but requires less input from us? It might be back. And that’s the other thing I think which is really interesting is we focus a lot

on product development on the customer facing systems, but a lot of opportunities for building better businesses and better cultures is about ironing out all the issues on the backend systems. So in one organization, we found out that the sales, the head of sales, she was spending four hours a day just transferring data from one system to another. And we went, well, hang on a second, you you should be spending that time doing other things.

Identifying Dysfunctional Relationships

Guy Gershoni | 27:05.55–27:10.696

Let’s spend a week fixing that problem. You know,

Rina Alexin | 27:10.696–27:28.898

Yeah, that’s why oftentimes when it comes to IT, like specifically internal teams, internal product teams, I think the business stakeholders need to hear stories like this because they’re just, they aren’t necessarily, they’re typically seen as like a cost center versus a commercial, but really they’re enablers, right? So it’s like finding those opportunities are so, so important. Okay, so.

Guy Gershoni | 27:28.898–27:39.211

Yes. Yes. Yes.

Rina Alexin | 27:39.211–28:00.91

I wanna ask you about dysfunctional relationships, right? We haven’t really kind of gone in. You mentioned, okay, it’s two sides get to play, both could be a little toxic, but what do you think causes or maybe are some common issues that you see that are potentially dysfunctional between product and engineering?

Guy Gershoni | 28:00.91–30:24.738

So I was thinking about this. There was a very interesting startup I was involved with, which unfortunately never took off, called Transform to Grow, where there were sort of three of us highly experienced people. And we said, you know, the problem with digital transformations is that sometimes, you know, there’s all this money and effort put into do a digital transformation in the company, but the company isn’t ready for it. There’s various blockers that mean that no matter how much money and energy and

you resources you throw at the problem, it won’t get fixed. It won’t work. Right. And so we were like, how do we identify these problem areas and allow companies to, you know, build the right foundations to do these digital transformations? And long story short, it was basically an extremely detailed questionnaires with the, the, the IP was really how we interpreted the responses for those. you know, it looked at all levels of, um, you know,

the organization from the CX level all the way down to the individual contributor level. And it never took off by the way, because it was such a good diagnostic tool that no one had the guts to let us in and diagnose it because it would also call out issues at management. And the way we split it up was into three parts, which we called MAC. So MAC as in mindset, articulation and capability, right?

Going backwards, capability was the easiest to solve. Guy, you’re not working well with the product team because you don’t understand enough product to have a good conversation with Rena. Let’s send you off to some product conferences or spend an hour with Rena just having a coffee, learning about product. Capability, no problem. Articulation, much more complicated. I’ve got problems in the tech space that

would impact your ability to implement the features you want. But because I’m a hardcore nerd and I can’t communicate to you in your language what those issues are, and you might have also a similar articulation problem. You want certain things to come, features to be there for the product, but because for various reasons you can’t communicate the why, and therefore I can’t understand the what and the how.

Understanding Mindset and Communication

Guy Gershoni | 30:24.738–30:35.658

That’s the articulation. And that’s, again, more solvable. It requires probably more mentoring rather than training. And that we consider. Done?

Rina Alexin | 30:35.658–30:44.346

Repetition, right? Like, repetition, because you’re talking more, you’re getting from the hard skills to the soft skills, right?

Guy Gershoni | 30:44.346–31:52.173

Exactly, exactly, exactly. And mindset is just a completely different mindset, right? You’re coming in with an experimentation, agile, nimble mindset. I come from the old world of, know, telephone infrastructure going, no, that’s not how we do things, Rena. We plan it and then we spend a year and we build it and blah, blah, blah, right? And unfortunately, what we found is once you get to mindset issues, there’s very little you can do.

You know, mean, like at the end of the day. And so that’s where I think it’s really sort of looking at why is this relationship toxic? You know, is it to do with, you know, capability, articulation or mindset? And if it’s mindset, if there’s really like, we are just not on even remotely the same page. Look, there’s still things you can do. Is it is it fear driven behavior? You know, is it that you’re worried that if I

understand too much of what’s going on, I’m going to see problems or vice versa. But yeah, sometimes you just, yeah, there’s not much you can do. Yeah.

Navigating Organizational Dynamics

Rina Alexin | 31:52.173–32:24.312

Yeah, so I do like this. It’s like the hard and then the communication is his own soft feel that, you know, that can be improved, but certainly it’s more complex. But the mindset, honestly, I feel like I have these conversations all the time, even when it comes to how do you change organizations, like the mindset part is the hardest part. And that’s the one that people really struggle with. So you’re saying that exists on a

one-to-one relationship or department level relationship as well, which honestly it makes a lot of Yeah.

Guy Gershoni | 32:24.312–34:44.974

Well, absolutely. And I think you also mentioned previously, and I agree with you, like there’s this misnomer, like product manager has manager in the title. And yet usually product managers have very, very little positional authority, you know? It’s like, and that’s also, you know, this understanding of like, is my authority positional or influential or both? Right? So.

You know, if you walk in going, I’m a product manager, therefore I will boss people and tell them what to do, but you don’t have that positional authority, you’re not going to make many friends. You know, if it’s more influential, then it’s like, well, okay, what’s the compelling story I can give, you know, the engineers that will bring them along on the journey and have them excited about what we’re doing, you know? But it’s also, I’ve seen that where people have, you know, mixed it up.

But there’s also organizational dysfunction as well. Like sort of sometimes where, you know, look, I’m a believer in hierarchical structure, but flat culture. I think what I’ve seen work badly is flat structures because flat structures don’t exist in reality. You know, you can go into a room and say to 10 people, you all have the same level of authority. Go make a decision together.

But what will happen is that they will, you know, suss each other out and henpeck and all that kind of stuff. And there will be a structure emerging there. Right. So it’s better to have an objective hierarchical structure, but then encourage, you know, a sort of a flat culture. And if that’s the case, well, you know, if the engineering manager is the one that’s going to be, you know, taken to task, if the product doesn’t succeed.

then it’s like, okay, well, I, as a product manager need to work with the engineering manager to help them understand how I can make them look good at the next performance review or look good to their boss. know? So yeah, I mean, that for me was the biggest shock arena when I went from being a heads down, bums up sort of keyboard engineer to being a people leader is realizing how much of it is these sort of soft skills and influence. And that’s not easy or as predictable as, you know, writing

Guy Gershoni | 34:44.974–34:46.86

code.

Rina Alexin | 34:46.86–34:56.748

So, Guy, to that point, and when we go into organizations where there is dysfunction between engineering and product, a lot of times product is reporting into engineering. There are these organizational cultures where it’s just whatever engineering says goes, and a lot of product managers in those situations feel like they don’t have a voice. So, I mean, do you have any advice for product managers in that situation?

Guy Gershoni | 34:56.748–35:12.258

Mm.

Guy Gershoni | 35:12.258–35:16.8

Because, yeah, yeah.

Rina Alexin | 35:16.8–35:25.496

Like what should they do? Like how do they get a voice and how do they build that influence with the engineering work?

Guy Gershoni | 35:25.496–37:45.062

So that’s an interesting one because we had this problem in one organization. It was really interesting. We were building a platform, an internal platform for other parts of the organization to deliver customer facing products. And this is interesting because when I walked in, we didn’t have a product manager. And it was really interesting because the team had these ideas about how incredibly useful they’re.

platform was and how all these teams appreciated it. And then when I went to actually talk to the teams, they complained all the time about all the issues about dealing with that team. And so there was this disconnect, right? So short term is one of the things that I did was basically take people from the team individually on these sort of listening tours. So we’d actually go and talk to other teams and have them in the room. And they had to listen to what the customers of their platform were saying. And

It was interesting. Some of them did not like it at all. And eventually ended up leaving the organization because it sort of busted their bubble. But then we did bring in a really great product manager who sat there and he started to just pivot and say, look, let’s talk about how you guys measure success and make sure that aligns with how the teams measure success. Right. It might not be around utilization. It might be around reliability is more important. You know, I mean,

And so that’s where sort of the product manager can adapt to and saying, well, I come out of product management school thinking that customer engagement might be the most important thing for me to drive. But actually when I look at what Guy is the engineering manager is being measured on when he goes and talks to he’s, you know, boss, you know, the CTO, it may be around reliability. Like right now it’s the fact that the website dies every week that Guy’s being, you know,

taken over the coals, hey, guy, how do we measure reliability? What are some leading indicators that can tell us a problem might be coming about? How can we try and alleviate it? So really sort of having that relationship and understanding also that my priorities will evolve over time. However, I also think that’s an organizational problem. Like why, and this is the problem we had in that organization that the CTO didn’t believe that product managers should be in backend infrastructure systems.

Advice for Engineers on Product Management

Guy Gershoni | 37:45.062–38:03.276

We disagreed, my boss and I disagreed on that, the CTO was sort of, so the CTO allowed us to have a product manager, but the CTO never measured our success with the sort of kind of metrics that meant sense to the product manager. If that makes sense.

Rina Alexin | 38:03.276–38:11.694

Tell me more about why you defended the existence of a product manager in that department.

Guy Gershoni | 38:11.694–39:34.751

because I could see that the team was very well-intentioned and wanted to build a compelling product, but didn’t know how and didn’t even know that they didn’t know. And so this is where I wanted someone who had that deep understanding and expertise around extracting that information out because it wasn’t obvious.

you know, and so, and the other thing too, is that even when we say, reliability is a must have when you’re talking about internal platform, it’s not absolute, right? There’s a level of reliability that we need to aim for that’s useful. But then if you go beyond it, you’re wasting time and capital, you know what mean? And so we needed someone who could have this very, you know, mature gray, you know, able to see the gray scale rather than the black and white.

to help us understand, as you said, where all those metrics and measurements need to be and help us keep on top of it. And for me, that was a full-time job. That was not something that I could do as an engineering manager or my engineers could do. We could enable it. We could be participating in the conversations, but it’s a full-time job to sort of really deeply understand what good looked like at that point in time.

Rina Alexin | 39:34.751–39:51.608

Yeah. I think you’re describing exactly what the role of the product manager is at organizations. And so when I hear engineering say there are some instances of companies where they’ve given up on product management and they think engineers should just make all the decisions. I think this is a really powerful reminder of, well, there is a role for product management. It is strategic. It thinks bigger, things longer term, and it helps engineers also

Guy Gershoni | 39:51.608–40:04.652

Mm.

Rina Alexin | 40:04.652–40:06.316

do what they do best. And they will keep on the coding. So, Guy, I so enjoyed this conversation. I already asked you how can a product manager do better with engineering. So I’m going to ask you the corollary. What advice do you have for someone in engineering that’s struggling with product management right now?

Guy Gershoni | 40:06.316–40:25.496

Yeah, exactly. Yeah.

Guy Gershoni | 40:25.496–42:17.1

Yeah, absolutely. it was advice given to me is go and get yourself into that world. As an engineer, you spend the first five, 10 years learning how to build it right. that is really difficult skill to acquire. It’s quite involved and nuanced. And it’s a really interesting intellectual journey going, how do I build it right? How do I build something that’s solid and flexible and

you know, and performant, right? Great, you’ve done that. Now you need to learn how to build the right thing. And I think that, and once, you know, this is the problem, I’ll be really blunt, a lot of engineers can be very arrogant because engineering is extremely deep skilled sort of profession that, you know, and it’s very objectively obvious when you’re doing it right and when you’re doing it wrong. And so they kind of,

and I’m guilty, you kind of think I’m the smartest person in the room, right? And that, you know, the first thing to do is to go, look, you know, that’s dangerous. That’s, as you said before, like that’s a cognitive bias, you’re not. And so, you know, starting to walk in other people’s shoes into, you know, the product manager’s shoes and trying to understand, you know, the business and the stakeholders and the people using your software, because as an old boss used to say, we’re not running a charity here. You know, we’re trying to run a business.

you know, how is what you’re doing contributing to the business’s health and success? That can then open them up to the point that they can really sit down and go, now I can understand, you know, the decades of work that Rena’s put into her, you know, vocation of being a product manager and not only appreciate it, but work with her to leverage that and make, you know, for great outcomes.

Rina Alexin | 42:17.1–42:29.077

Well, Guy, that advice is honestly, it’s music to my ears because at Productside, we talk so much with product managers, encouraging them. You have to walk a mile in sales shoes and engineering and marketing. You have to all this empathy. And to get some of that love back from some of the other departments would be amazing. So Guy, thank you so much for joining me and for sharing so much great advice and wisdom.

Guy Gershoni | 42:29.077–42:33.826

Yeah

Guy Gershoni | 42:33.826–42:40.974

Yeah.

Guy Gershoni | 42:40.974–42:44.48

Thank you, Rin.

Rina Alexin | 42:44.48–42:48.966

How can our audience connect with you after they listen to this recording?

Guy Gershoni | 42:48.966–43:06.826

Okay, well, obviously LinkedIn is the easiest. So, Ghecchoni. I do also have a website which I need to get back to. You reminded me about it called Strategic and Heuristic IT Management. So, shit.management, where I’ve got some articles and we’ll put some more in there.

Rina Alexin | 43:06.826–43:06.826

Wonderful, we’ll include it in the description so that everybody can please connect with Guy and check his website out. And for everyone, thank you so much for tuning into another episode of Productside Stories. If you found our conversation valuable today, don’t keep it to yourself, share it with a friend, and make sure to subscribe to Productside Stories so you don’t miss a future episode.

Visit us at Productside.com for more free resources, including webinars, templates, and other product wisdom repackaged for you. I’m Rena Leixin, and until next time, keep innovating, keep leading, and keep creating stories worth sharing.