Transcript: Asaf Shochet Avida & Stas Wishnevetsky | Product and R&D, All on the Table: A Special Episode

Eyal David: [01:15] Hi friends, it's Eyal. You've reached Product Builder, and here you can listen to the most interesting product conversations. My journey began in 2012 when I learned what product is at my own startup. Since then I've worked in the industry, and since 2017 my company has been advising a wide range of companies. My drive is to help all of us get better as product people. And before we start, if you enjoy listening to Product Builder, please rate us five stars on Spotify. It'll give me great feedback that the podcast gives you value, and it'll make me very happy. So yalla, let's start. Hey friends, what's up? With us here are Stas and Asaf, I'll introduce them in a sec, today is a special episode, we're basically a forum of three. I'll introduce you quickly, say hello. Hi, hey. So yes, there are people here. So with us here is Asaf Shochet Avida, who comes to us from Evinced, he's basically a front-end tech lead, and Stas Wishnevetsky, who is basically director of engineering at Melio. Hey guys. And we're going to talk about, basically, expose all the crap and all the things that sit in the relationship between product and dev, and the guys here came to represent dev, it's going to be a super interesting conversation. So Asaf, tell us a few words about yourself, what else do you do besides Evinced?

Asaf Shochet Avida: [02:36] So besides Evinced, I'm mainly a father of three, and I also love giving talks, at conferences, I write a bit. At the last React Next, with Eitan, right? Right, at the last React Next, there's a conference, TestCon, which will be in Latvia,

Eyal David: [02:56] where we'll also talk about accessibility, I'm doing a six-hour workshop, a cool day. OK, it's worth noting that basically Evinced is an accessibility company, and that's where the expertise comes from. And Stas basically, beyond Melio, go ahead and say a few things about yourself, and we'd really love it, but also basically taking this whole product and dev thing and taking it a step forward, right?

Stas Wishnevetsky: [03:16] So maybe tell about that too. Yes, so it happened that recently I've found this topic more interesting, I'm also writing an interesting blog post about it now, and I'll also be a guest on a panel at a meetup happening at the end of the month. Where is it? At Madrachim, at Madrachim, at Madrachim, at Madrachim, tasty pizza, beer too.

Eyal David: [03:37] So we'll definitely put a link to that post in the show notes when it's out, and we'll also give your details to hear more about that meetup. OK, so really before we start, and we really have a lot to talk about, I want, because I'm also not used to interviewing two people, so we'll be very, we'll keep it tight time-wise. I want to hear from both of you, each in turn, since you've worked with quite a few product people during your careers, you both have fairly long careers. What are the most important skills in product management, in your opinion?

The most important skills of a product manager

Stas Wishnevetsky: [04:14] I think maybe the most important skill is the ability to research. There's a lot of learning in doing product. Basically you're maybe born with this profession of the ability to learn and to nail down work into scope and priorities, but you don't know the whole industry, you're not born to be, say, in the accessibility industry. And only when you enter some business domain you don't know, then the research you do is maybe the application

Eyal David: [04:46] of the most important ability in order to be effective in the role. That's also something that pretty much meets dev, right? Because if the research isn't deep enough, if the requirements aren't updated enough, then basically pushback starts and questions start, and then suddenly, right? Maybe we'll expand on that later. Anything else you might want to raise?

Asaf Shochet Avida: [05:08] There are all kinds of other skills, say the ability for verbal communication is very important. The work is very cross-functional, you work with all kinds of professions, it can be legal, sales, engineering, so the ability to be effective in conversation, and also in written communication, is very important. Stunning. Asaf, anything from your side? I think product is one of those roles where you're a bit of a salesperson, and it's not so clear to you who the customers are, because there are, and it's also not so clear what you need to sell, because it's something different every time. Meaning, it could be that right now you need to, you know, sell the feature to the developers, because you're a manager, but you're a manager with very particular authority, you're not the developers' direct manager, but you need to get them to do things not out of the whip, but out of understanding and buy-in. On the other hand, afterwards you need to hear their feedback and sell upward why the thing will cost what it'll cost, in the right way. Meaning, you need to know how to reflect all sides and also bring your own input.

Eyal David: [06:08] There's a matter of communication here, a bit of negotiation, a broad view, a very interesting role. So that's it, I was messing with you a bit. Look, now we'll take it back, and now let's say, let's basically talk about the things that bother you most in product. What are the most cardinal problems with product people that drive you up the wall?

The source of tension: when product steps into the "how"

Stas Wishnevetsky: [06:28] Who wants to start? That's an excellent question. I think, like, I also, I think we'll talk about this more later, and I'll also talk about it in the post I'm writing, and I think it's also the point that drew me most to this topic. There's a lot, a lot of tension between product and engineering, and there are, like, all kinds of ways to break it down, we'll talk about it, but the tension happens because these are two professions that together collaborate to get something out the door. And what bothered me most in product, and today I already know how to integrate it and understand where it comes from, is product's need to scope the content. And sometimes it also crosses some line, a boundary, where the engineers feel product is also getting into how to do something. And that's a source of very big stress, it can create very unpleasant work between the teams, it can, like, disrupt relationships, and it can also hurt the product.

Eyal David: [07:29] Because, like, basically beyond someone stepping on your toes, basically, and telling you what to do, maybe you also don't believe in the solution?

A shared KPI: product as engineering's API to the business

Asaf Shochet Avida: [07:36] That's, if we say, there's a question parallel to what you asked me, what do you think is the most important trait of product? And there's also such a question to ask engineers. And the engineer will probably say the most important trait is his ability to plan and execute this thing being built. And when, say, a person from another profession comes along who, like, feels very involved in defining what we build, and then also the how, then it feels like being trampled, it feels like being stepped on, and it also feels like the perspective product takes in making some proposal is a perspective that's not optimal for the KPIs, say, that matter to engineering. Maybe that's really also the thing, the KPIs aren't always the same KPIs for both sides. So following what you said about KPIs, there really is some anomaly here, something that can be so, can not work so well. Meaning, if there are certain KPIs for product and other KPIs for engineering, for example, say, yes, hypothetically, say if product's KPI is how much... Conversion. Yes, for example the product's conversion, how many bought, how many clicked on something, and on the other hand engineering's KPI is the number of bugs. OK? If, and sometimes it can line up, but if it's completely different, then there's some problem in the process. Because the very, very best case, meaning, as engineering, as someone who wants to look at engineering a bit at a high level, I very, very much want product KPIs. Why? Because, again, out of trust in engineering's abilities, meaning, I assume that if we work toward the same KPI, then now I as engineering know how to translate it. For that matter, if now the company wants to reach as much conversion as possible, maybe the key is quality, maybe not. Maybe now the key is quick and dirty. Yes? Meaning, so if what matters to the company, by the way, everyone's KPI should basically be the business, that's basically what matters. Meaning, product is basically the bridge between, for me as R&D, yes? It's my API to the outside, to the business. So if now the business is, for example, running some campaign, yes? Where I know a certain part of the product will be reached from some landing page, then I need to know that, I need to optimize it and not all of, not the rest of the product, do monitoring for that part, and then we'll be able to reach that state, at the expense of other things. But once the API is connected, then the KPI is connected too, then the story is also very, very clear, and then product's selling job is also very, very easy, because basically he says, listen, there's a company-wide campaign here, and this is what needs to be done. Dear engineers, what needs to be done? How do you propose? It's kind of funny, what you're talking about is basically aligning expectations at the end of the day. What I'm talking about is aligning expectations, but aligning expectations at the level of, you can't see the hands but you imagine there's a chain in the hands, yes? If you're aligning expectations basically between business, product and engineering, and here too we say engineering as if it's one person, but aligning within engineering is also a whole saga of its own, yes? Especially as the organization grows. But if there's one objective function, it aligns the whole organization. Once it starts splitting,

Eyal David: [10:44] then power struggles start here too. That's something that, right, and it's something that maybe in startups, I don't know, I've worked a lot with startups in the past, very small startups, usually the team really knows where it's going. Maybe it's different, if you have the Ukrainian developer in Ukraine and he's not so connected to the business, then maybe it's different, but usually precisely in very small organizations, what you're describing now, everyone aimed at one goal and basically focusing on it, really happens. And in big companies it probably gets lost. Did you have a story like that recently? A story where we're all in the same direction. The opposite.

Asaf Shochet Avida: [11:18] Ah, where we're not in the same direction? Ah, all the time. No, it happens, of course, of course, it happens at this company too, at other companies too, yes? It's something that, that needs to be worked on. Yes? It's communication that belongs to every organization, if you're cross-country, cross-time-zone, and communication today is, meaning, not everyone comes to the office together, which I'm in favor of, by the way, but in the end, in the end, in the end it's communication, yes? Communication is the most painful part of an organization at every level, between departments, within departments. I can give an example where it does work, for example, yes? If you're doing a launch now, not lunch the meal, a launch of a new product, then, meaning, it doesn't need to be something pompous, it doesn't need to be something where you now send emails to the whole company, work on this thing, no, but even at the level of, now we're doing a demo for a customer, so before the demo is shown to the customer, you tell the engineers, listen, we're about to present the product to a big customer, engineers, please check it beforehand, everyone will be aligned on the same thing, the bugs we're going to fix are the bugs related to the demo right now. In the end that'll help the business, and it's a really, really small example that can be implemented in a big company too.

Eyal David: [12:24] Right, and it also basically gives a lot more trust, maybe, between both sides, when you talk in such a language. There's also an element here of ownership, I think, that once you explain to the other side, or to all sides, if you're going to build a building, OK? Both in the planning stage and in the execution stage, everyone's aimed at the building standing, and meeting the standards, and in the end we'll sell it. There'll be good ownership at the different stages, basically by the different players, because everyone's moving toward the same point, and each is responsible for one specific thing that's supposed to get us there. If you don't communicate that, as you say, then it also hurts the sense of ownership, and that's so important. OK, I'm saying, the building example is really good, because if you've ever seen a building being sold,

The building, the neighborhood and the Stripe analogy

Stas Wishnevetsky: [13:11] then you don't build the whole building and then start all the interior finishing and all the exterior finishing and all those things. First thing, you make a model apartment. A model apartment. Right? That's the first thing you do. Because you say, what's everyone's motivation? Yes, probably in terms of schedule, it's probably most logical to work in stages. First the skeleton of everything, I guess the shell needs to go up, I don't know anything about construction, yes? But first the skeleton of everything, and then all the infrastructure, and then all the plumbing, and then everything, and at the end bring in the painting for everything together. But the vector here is sales, that's very, very clear. Yes, the owner wants to sell. So first thing, you make a model apartment, bring in the finishing people, the interior designer, something like that. So it's a knockout. Yes. And then you continue. On the other hand, but like, I connect with the construction analogy, it's interesting, but most of the companies we work at, and most of the companies that exist in the industry, don't build a building, they build companies for building buildings. Meaning, the definition of done of where you finish, say when you build, it's a building, and then you sell it, and we're done. There's another building to build. But that's not how it is at a company, say, fintech companies, cyber companies. You build products where you always start with an MVP and expand and expand. It's basically building a building that never ends. Building a neighborhood. Yes, yes. And then, like, say, new neighborhood elements come in. Suddenly, like, OK, education solutions, playgrounds and so on. Things expand. In our work too, say, there'll be some MVP, something basic like that at a startup through which you can raise investors, and then you try to create more means to get customers, and then you enable more and more features, more functionality and so on. So it always expands. There's a competing analogy to the building, about payment methods. Say we're working at Stripe in its early days, and relatively early on they're like, OK, let's connect, say, the credit card payment method. And like, Engineering did some design, and built some system, and it's possible, and everything's fine. And then, say, suddenly a weird player comes in: OK, now we want to add the option to pay by bank transfer. Which is like, it's a completely different model. Like, the flow of funds is different, it's like, even the APIs are different. If, say, at the start you made APIs like authorize and capture, then like, those are words that aren't relevant at all for bank transfers. And there are difficulties there, and I think a lot of the tension between product and engineering is that when you come with a goal of, say, building a building, then you know where you finish. You finished the building, it's done, there's the model apartment. Like, it's clear to everyone, there's a solid line about where you finish. But at Stripe, say, it's not clear where you finish. You start with credit cards, then banks will come, then things will come, then Bitcoin.

Eyal David: [15:54] But what you're describing here is basically staging, right? After all, at each such stage there's a definition of done, each such stage is a building, it's an extension of the building, right? It is possible, with good alignment of expectations, and I've seen this happen many times, to build a platform too, or to build, like, a pile of services that basically get added to the neighborhood.

Stas Wishnevetsky: [16:14] Totally. I think one of the points where KPIs become an interesting topic of conversation between product and engineering is in viewpoints that are slightly different between product and engineering. Say, when the engineer at Stripe got the task of implementing an API for credit cards, questions came up for him like, and what comes after? There'll be bank transfers, because maybe I want to think here about some abstraction that, like, says a payment is a payment, regardless of the end method. And if, say, the scope decision is a product one, then it's possible that, like, we're focusing on what the business needs right now. Because sometimes product's considerations in a business KPI are, like, conversion, reaching the customer as fast as possible, seeing, like, usage by users. And in engineering there are slightly more complex KPIs, which are also lagging, also measuring them takes longer, like dev velocity or quality, which is what, say, interested that engineer at Stripe, about how I can also enable bank payments in the future. And then it kind of, like, touches the tension between the two functions. And usually what eases tension like that, I've seen this happen too, is having a very, very strong vision from the product side, or the business side, and then things are easier, easier to answer, things fall into place more when those questions get answered. They also, this probably doesn't happen on day one of Stripe, it really happens after there's already, after there's already something, right? Yes, yes. I'll point to another thing basically among the tensions, I think in the end it's a concentration of the things we talked about, and it all stems from some missing alignment of expectations. The thing I feel most is really the... there's basically the matter of the most basic time estimates, right? What is it, all the time estimates. Let's talk about time estimates. The easiest part of engineering. Which is also very tied to how, I see it as a muscle, really. Like, it's something that in many teams I worked in starts out very bad, over time we improve together, it also really touches trust. There are really funny stories here you could tell about these things, estimates that fall short, estimates that were even faster than we thought, because someone simply thought about things a bit differently on the other side and surprised us.

Eyal David: [18:39] What do you recommend on that side? On time estimates? On tests, yes, how to approach it? I can see a few things, but... You have a trick that always works, just give a bombastic estimate.

Time estimates, design reviews and aligning expectations

Asaf Shochet Avida: [18:51] But then you basically hurt, or in the end, you hurt the trust, you also hurt the product, usually, OK, so product will step back, say, fine, this is what I can get, let's cut, usually we'll come back with a worse product. Right. I think the key here, something that's here, is that this is a really hard problem. Yes? Meaning, predicting the future is a hard problem. Because it basically means, in order to know, from the engineers' side, in order to estimate effort it means I have to understand what they want me to do, assume it won't move, and it will move. Second thing, to know roughly what the solution is, and to know what my capacity is. Each of these is something that takes time to understand. Yes? To know my capacity as a developer is one thing, how much and how much, how much and how much with this feature including several developers, at several levels, in several teams, where one of them suddenly has on-call, one can suddenly commit for a week, but they actually shift him to another task, and then they get angry at me as the feature owner, why isn't this progressing? But he's not on my team. Meaning, it's really, there are a lot of variables here. What often helps lower the flames a bit, because often it really becomes, as you said, it becomes kind of a, this blame war, is again the word alignment of expectations, or sharing. For example, if I, as engineering now, have a feature I'm responsible for, I'll invite product to the design review, so they understand my problem space a bit more. So I can tell them now, listen, I need to create here, again, say, from the front-end world, I now need to create five new components that don't exist, and also make them accessible, so it'll take me X time. Let's think together, like, what can be done. Right, and I'll say, OK, listen, it'll take me X time, maybe we can save a bit, say, thirty percent, still, so that's seventy percent of that X time I mentioned, say, trying to optimize, and I have another integration here with another team, and the other team needs something else like that. So I'll come, meaning, I put things on the table as openly as possible, and I'll add some buffer for unit tests, end-to-ends, yes, all kinds of tests that need to be added. Now we're in this together, it's not that I'm telling you, this is the picture I have, take a look. You think we'll cut, I'll also come, I too as engineering will come to you with suggestions. That's it, that's it, that's it, I'll say. Listen, the feature, and this is the thing I must do, when I get a feature, is to think now, put myself in product's shoes, in a moment I'll say why that's also not good, yes, to put myself in product's shoes and see from this feature what I can cut out. Meaning, if I now as a customer receive this, what here can be valuable to me in a first drop, second drop, third drop, yes, I, in my alignment of expectations with product, I'd expect product to come with that, but I understand that's also not always the case, because product really doesn't know the effort delta for each of the buttons. Maybe there's some small button that product thinks is very, very complicated, doing an export to some format, say, of a table, and I say, listen, we did that in another product, it'll take me a day, let's add it, yes, and it can also be the other way around. Now you said you'd touch on the downside of this, a few came to mind, but... So the downside is basically a bit about what my perception of product is, that it's not good product, product in the way I work, product where I feel that, like, really, the alignment of expectations with them is good, OK? Which is, product needs to bring, again, my problem, some data, some point of view I don't have, OK? Because if we're now talking only about the UI/UX, and I say, in my opinion the button should be up here and that should be down there, and he says, no, in my opinion this is down and that's up. So OK, so what, we're now in power struggles, like... forget it, OK, take it. Meaning, we're talking about something theoretical, UI/UX-ish. What can win that argument, or otherwise, listen, product can say, listen, I showed this to three customers. All three liked the first option. OK, I have nothing to say. Excellent, you checked, great. You brought data from outside, or alternatively, you brought analytical data. When we have another product where it's the opposite, and there it doesn't work, so let's do something else here. OK, more information. Or the business said, we have to deliver this by tomorrow, so just do the fastest thing. OK, that's also input I don't have as someone looking at the bits. Yes, if you bring information from outside,

Eyal David: [23:13] that's, here the cross-pollination is really not about the correctness of the feature, or correctness in quotes, yes, of the UI, being globally correct like that.

Confidence in estimates and balancing budget vs. scope

Stas Wishnevetsky: [23:23] Yes, look, I think that's always true. Still, there are things there are no answers to, and then, you know, and it really is mutual work, actually I as product really appreciate hearing all the team members from the side, and together forming something that makes sense, and also in terms of the ROI of how much it costs, that it makes sense. So it's totally cross-pollination, I think, in that respect. On the back-end side, Stas, there's also a lot of logic that maybe we can think about how to slim down, or how to, so you also come with suggestions that way. Yes, actually, like, the point of time estimates is a very sensitive point, especially for engineering managers early in their careers, it's a point where there's a lot of discourse between product and engineering managers, about: suppose we do X, how much will it cost, how long will it take, and conversations of that kind. I think a pragmatic way, which once I understood it, it lowered, neutralized a lot of the pressure around these questions for me, is the understanding that basically in time-estimate conversations, the dimension you can play with is confidence. And with product, in stages, the planning process is something iterative, it's not, like, time and we're done. There's an annual or quarterly planning process, or one for the next iteration, the next sprint, the next two weeks, and these processes constantly change in their need for accuracy and confidence. So when they come, when we plan the quarter and sit between product and engineering, and we think about this feature, another feature, the really ballpark time estimates of small, medium, large, or eight weeks, four weeks, two weeks, are something that can give the orders of magnitude or the understanding of whether it's worth it or not worth it business-wise to enter this adventure. That's basically what product needs, product will always want to find the best benefit between the amount of time I'll invest, which is basically budget, and... the effort itself. Yes, and like, what do I get from it? Which business KPI will I advance, and by how much? Actually, if the question you asked at the start was what's product's most important tool, then maybe it's this, basically. It's the ability to balance between budget and scope. ROI, basically.

Eyal David: [25:47] You prioritize according to it. And do you feel that from the product side, the product people you've worked with, the estimates from the business side are usually correct? Do you get them at all? Is there a dollar sign on every feature you do? After all, it's not always black and white. If we also talk about, there are things we do to improve user experience, there are things we do for technical debt in general, right?

Stas Wishnevetsky: [26:13] Yes, actually, I think it's very hard to put a price or a potential gain that will come. There are companies that are really good at this, there are companies where the data is so available that you can really know. I remember, say, in the past at Wix, every feature goes out as an A/B test, and you can really measure the KPI and the impact of every feature, and also defensively, the impact of a feature on KPIs that are potentially unrelated. And you can do a lot of research, even before you go into a certain feature, to estimate the gain you'll get from this project, and then kind of balance between the effort and the KPI. But there are projects that aren't like that. Also especially in accessibility, say, it's not... it's not necessarily that you go into improving accessibility or working to accessibility standards because of profit. There are things that are simply necessary. Or GDPR, or security, there are all kinds of concerns in our kind of work.

Eyal David: [27:12] Like a house's foundation, so it won't fall, it doesn't create business profit, but it's necessary. That's really true, you know what I thought when you talked about Wix, for that matter, a company that works with A/B testing. OK, so you always put some estimate on how much it's worth for us to focus on this feature now, maybe you even put some, some t-shirt size or dollar size or whatever on it. You never quantify the matter of, OK, it won't succeed the first time, and then we'll iterate, it'll take time, it'll take development time, a second time, a third time, as someone who's been through it, you never account for that, and that's a thing, a dimension, the dimension of risk, that's never accounted for. If we're also talking about alignment of expectations, that, in my opinion, is something that would help a lot. So I think beyond that, there are always also tensions, you mentioned it just over coffee before, of, OK, when do we prioritize things that matter to dev at all? When does that get in, right? So the whole world of prioritization is very tough. Is it something where today you feel there's more focus on scalability, so maybe it gets more emphasis, basically?

How to prioritize tech debt and infrastructure projects

Asaf Shochet Avida: [28:17] I think there's a lot of value. Just as I expect product to know how to translate their requirement into a language I understand, meaning, take the goal of selling the product 500 times over and translate it into... make five buttons, yes? Or build a new API, I expect Engineering to know how to take the backlog and know how to translate it into product's language, and then I'll be effective. I'll give an example. Please. OK? Say I now have, again, in the front-end worlds, I have an infrastructure library of components. Say, just an example. OK? Now, to introduce it, and there are several products, and one of the products doesn't use this library, names don't matter. Fine? Now, this project of getting it to use it is a project that'll take time, X time, order of magnitude, say, just say, it'll take half a year. OK? I'm exaggerating. Fine? For me to prioritize it, yes? I want product to understand why I want to push this. Yes? Why this will ultimately lead to higher velocity? Because it'll lead to collaboration between the teams. It'll lead to all of us working on the same tech stack. It'll lead to better accessibility, because we'll use components that are in the shared library. Accessible. And they're already accessible, yes? So if I need to work really, really hard to convince product, meaning, I set that for myself as a challenge, that's the right way to work. To get them into the backlog. There are simply things that aren't interesting, tickets that are very small, that take a day or two of work, even up to a week, not worth the time. There's a budget for technical backlog, we'll do them. The big things, I want to prioritize them not under the table, I want to prioritize them also so that product in the end can tell me, listen, you did this, why, where's the collaboration? Yes, meaning, that they help me do the control, because product in the end is a body, I'm using military terms, it's a steering body, it's a body that also exercises some oversight over engineering, and over the processes too. I want to stop you mid-example and ask a question,

Eyal David: [30:22] so OK, you introduced something like this, say, and succeeded, are there some KPIs on it? After all, everything we do comes to serve something, right? We all also work at the same company, we all have the same business goal, to build the building and in the end sell it, but how, like, the goals are a bit different in this kind of project, so how does it pay off? So for that matter, here the KPI is,

Asaf Shochet Avida: [30:42] meaning, maybe it's softer, to digest it, for example, that I want to see that within three months of finishing the project, product now has the ability to prioritize, meaning, to shift resources between two teams to the same project. For example, or for example, if we look at it for a second, then you're saying the quality level will go up over time, right? So for example, the UI designer, yes, or the UI specialist, won't need to design the component twice, because as soon as he tells the dev team, add a drop-down here, they'll say, ah, OK, we already have a drop-down, don't dig, no need to dig into it, we'll take what exists, and that's it. I want to touch on a point, give some analogy, the KPI in engineering, sometimes they try to do it with metrification, like for example velocity, or what you said, say, if we change the component in a way that in the future makes it easier to make it accessible, and it integrates better. These are things that are sometimes very hard for product to prioritize, because their need is more strategic than tactical. It's a bit like how to bridge the budget gap in the State of Israel following the war. You can raise VAT, that's an accessible, easy, fast solution, and it immediately brings money into the coffers, and there are things like, strategically we want to raise the productivity of all Israel's residents, and invest in that, it's also a bigger investment in effort, and also its ROI is further away. And for product, when the KPI, say conversion, is an essential and important KPI, then doing some accessibility improvement in a certain component that will improve development speed in the future is something that's very easy for product to decide not to prioritize. And it may well make sense. The difficulty, I think, and I'm curious to hear from you, how you do it, how you convince product, how you get across the point that now is the right time to raise the productivity of Israel's residents, or to improve the component. First thing, maybe now isn't the right time. Could be. Maybe this project needs to go out to beta in a month, and now isn't the right time, and I accept that. Yes? Meaning, my opinion is an opinion, it may be right, maybe the timing is wrong, maybe the project is wrong altogether, maybe it's a project that'll go in another direction and won't need this. But if it does, it all, it all comes down to the point of trust. Meaning, I expect product, meaning, not to believe me blindly, yes? It's not a matter of believing without checking, but to understand that the motives, if our motives are the same, we're both thinking long-term. Meaning, if there's, like, engineering thinking short-term and product thinking long-term, that's a problem. If there's engineering thinking about what will help us in three years and product cares about now, now, now, that won't work either. Right, totally. What we might agree on, thinking for a second in a slightly more entrepreneurial head, is...

Eyal David: [33:33] On the face of it, what you're describing here, in this hypothetical case, basically creates risk for the company, right? There's a chance that over time, basically, the less accessible the interfaces are, customers won't necessarily decide to stay, it can hurt against competitors, yada yada yada. You can build an actual case like that and present it, and then decide, and then after you basically understand the dimension of risk, you can also decide when it gets in. In general, there are companies I've worked with that dedicate, from the... precisely to prevent this, they dedicate basically some period during the year that's defined and must happen, and in it they really do things of this kind, so that can also help, in my opinion. And tell me, in this hypothetical case you just described, so how, like, how did things come together? Right, and we'll see. But what did you actually do in that respect? Did you go and basically raise it, did you raise the argument?

Asaf Shochet Avida: [34:25] So basically I try to build, meaning, first thing, to come, there are cases where R&D is the product. Meaning, R&D needs to come, I now have a case, I build a PRD. Because I say, this, meaning, I can't manage to do an integration. I say, what does that mean? What are the stages? What's my definition of done for this integration? Because an integration between two systems can also take forever. I say, no, I have some first stage. This is stage two, this is stage three. The first stage has value in itself, tell me, is there budget only for that? We'll go for it, I'd prefer up to stage three. But if there's budget for the first stage, I'll take it.

Eyal David: [35:04] First of all, I'm pleased that so far we've talked and the word Kubernetes hasn't come up, except for... Not AI either. Not AI either, right, which is maybe a bit of a shame. When we basically talk about alignment of expectations, then what else comes up from this conversation is that you need to speak the same language. You basically also expect the product side to know how to talk technically, basically,

A shared language, trust and a North Star

Stas Wishnevetsky: [35:25] at some level. I think there's also the reverse expectation, for engineering to talk product. That's the rest of the sentence. Yes. Exactly. I think that as our careers progress, like, say, as engineers we develop either into a role of technical leadership or people leadership, you're more exposed to interfaces with different professions, like, say, product, or sometimes also data, or we, God forbid, DevOps and Kubernetes, but that's sometimes needed too, or AI, and then you learn to do some of the abilities of those professionals, and you also develop a shared language for how to work together with them. I think earlier we talked, we touched on trust a few times. I think when trust exists, then you can really build systems together in a kind of harmony, where we speak in the same terms, and we're planning the same building we'll eventually build. But in the meantime, trust is something that takes time to build, in private relationships too, like couples and things like that. But in the meantime, the approach of splitting the resources, as you mentioned earlier, say, there are many companies that as some rule of thumb split between the product backlog and the technical backlog, like 80%-20%, 20% tech backlog, and then the prioritization and the product work on that backlog will be done by engineering. I think it's a pragmatic, short-term solution, not bad at all, but it's totally not, like, the vision. I think something that can help a lot in building that trust, or that kind of collaboration between product and engineering, is somewhere in relatively early stages of building the product, to sit together on some North Star, on some guiding star, where we're aiming, both from a product point of view and from an engineering point of view, and reach agreements. And when those agreements exist, it's some contract or common denominator, so that every time the discussion pops up of let's add an API for credit cards, and should we now also support banks, then we can pull this North Star out of the drawer, or a constitution like in a country. It'll be amended. Amended. And address whether it's the time or not the time, whether it's necessary, whether we'll get there anyway.

Eyal David: [37:50] Wow, I absolutely love that you compared it to a couple's relationship, so maybe, just, I remember, for example, really, when I was an employee at Fiverr, they'd take us to workshops like that, and really, like, they tried to connect the two sides, and it was excellent, actually. That's something that... just, today in your day-to-day life, in your work basically with product on your side, do you basically have relationships like that?

Stas Wishnevetsky: [38:13] Yes. Do you know the term work wife? Yes, that's a sensitive point, my wife, say, really hates that term. And it helps me, actually, that my wife is in HR, so like, I have a lot of ability to consult on these things at home too. But there is, this relationship at work, it's a relationship of partnership. It's no coincidence that in software organizations we usually see a technical lead together with a product lead. They're pairs. Because together these are two professions needed to lead any such business unit or whatever, and the collaboration between them, their ability to communicate effectively and their ability to trust each other, that the arguments each one brings for or against also look from some point of view at the other side too. When that trust is built, they can even replace each other in some sense.

Eyal David: [39:11] Startups rise and fall on this. Basically the first thing you look for is a CTO, or the opposite, and if that trust or that relationship isn't there. Totally. Replacing doesn't sound interesting, do you know such a case?

Stas Wishnevetsky: [39:25] Yes, say, it happened to me quite a few times that I didn't have that partner, I didn't have, say, a product counterpart. And then, say, the team members, it's very important to them that some vision gets built, where we're going, what's the goal of this product, after the building is built, what the neighborhood will look like. Did you let ChatGPT write you a vision? Yes, this was before ChatGPT. But say, today it's easier with ChatGPT, as you say. And that's a point that's hard to do when you don't have the product counterpart, and then sometimes you find yourself doing it, or as you, sorry, said earlier, you find yourself writing a PRD. Like, product isn't your profession, but you feel that sometimes it's necessary for certain uses. And also, you probably won't do it as well as product would, but it does improve some angle of this project you're trying hard to push.

Eyal David: [40:21] I think that's very interesting, because there's also the situation here where R&D writes the PRD, which is a non-technical PRD, which is a PRD, that's another sub-topic, yes, where R&D identifies that a product requirement is missing here, so it builds a product document. And then there's a bit of a question of who made you the boss, on the one hand. On the other hand, meaning, it can create calm, it'll create calm in Engineering when there's a vision, but it can also be the wrong vision, yes, where here, meaning, you come with a lot of confidence to develop the wrong thing, because you wrote yourself the requirement.

Asaf Shochet Avida: [40:57] Meaning, it's a case where, say, early on I happened to do it, and in a way, these are the cases where I, meaning, it's fun, it's nice, today there are also great tools to write things like that, but often it's actually what causes you to miss the goal, because you don't have the big picture. Right. I think, guys, up to here we've touched on a lot of points,

Eyal David: [41:23] and if we sum them up, at the end of the day they come down to alignment, really in a couple's way, basically alignment of expectations, a shared language and trust. It's really, do you have any recommendations, how can you, Stas, you raised it a few times, but are there some recommendations we can sum up here, that basically can accelerate this process, if someone is in a bad relationship? I have,

Recommendations: no nonsense, shared wins and EQ

Asaf Shochet Avida: [41:45] a recommendation for both sides, which is not to deal with nonsense. OK, what does not dealing with nonsense mean? There's a rule of thumb that's been established at many companies, which says that tasks that are, say, a day or two long, you don't need to talk about them, you simply need to do them. OK, why? Because if now about every little thing I want to do, I want to write a test for this function, I want to move the file from here to there, I'll confuse both my team lead and my product person, so I'm creating an information flood, and that doesn't help the big picture. I want product to hold the big picture. Don't clutter the mind with small things. If you clutter the mind with things that are too small, it means we have a problem in the process here.

Eyal David: [42:26] For sure. Yes, that someone else isn't holding it, or the team isn't independent enough. That's for sure. I think that came out very well.

Stas Wishnevetsky: [42:35] I think I also have something to share, I think that... earlier I touched on building that kind of guiding star, a North Star, I think it's a thing that can really give a significant boost to the trust between these two functions, between product and engineering, also because of the process required to build such a thing, and actually that's maybe, like, a topic for an episode of its own, but the process of building a North Star between engineering and product is such that it'll create inherent trust from the very process, or it'll fail and then, like, that trust will break, or that's also something that builds it. One more thing, I think it's shared wins. I think when you finish building a house on the way to building the neighborhood, when you finish building a house, to celebrate with each other the wins we've accumulated along the way, that floor that went wrong and then we managed to fix it, things like that. A big launch, working with customers, simply to encourage each other, like in a relationship. Really.

Eyal David: [43:36] If you go on a diet for the sake of solidarity, and you manage to encourage the other side too, then kind of encouraging each other.

Stas Wishnevetsky: [43:46] Another thing we touched on quite a lot here is open communication. And something else, it's from the world of, it's a bit sensitive. It doesn't suit me as a back-end engineer to say this, but high emotional IQ is something that's very necessary for business success in the environment we work in. A lot of our work is based on collaboration. It's not always the smartest person, or the one most successful at writing Kubernetes code, who wins business goals. Sometimes it's actually the collaboration between people. And then, in a world of collaboration, creating deep empathy between people, and the ability to recognize in the other side who's talking, when he talks about, I don't know, a certain place where there's very high technical debt and it simply, it creates an unpleasant development experience. Something that potentially, I don't know, could make people want to leave their workplace or just be unhappy. To see that too, to see that this too has a price, it's not a business KPI, it's not conversion, conversion, but it's another lagging metric, like velocity and quality, which are strategically important for achieving the goals.

Eyal David: [45:06] Which also cost a lot of money. Guys, I had such a great time, really, I think our digging, though maybe a bit long at times, brought up very interesting things. So each of you, basically, if people want to get in touch with you, want to follow you, so LinkedIn, what's the best way?

Stas Wishnevetsky: [45:23] Yes, LinkedIn is great. Medium, blogs I write. Ah, what, what, what, I didn't know? Great. I don't know if I passed the rule of six, right? We talked about it earlier over coffee.

Eyal David: [45:32] When do you become the blogger? How many blogs do you need to reach the critical mass of the blogger? So we'll hope that by the time this is published you'll already have six.

Asaf Shochet Avida: [45:40] So I'm also on LinkedIn, send a message, say hello. What, what, and you also have links to videos? Yes, I have a site, frogrammer.net, where you can find all the talks and another 13-13 blogs that passed the rule of six.

Eyal David: [45:58] Critical mass. Yes, nice. And I have one more question. If there's a product person who now wants to understand a bit more on the technical side,

Book recommendation: Peopleware

Asaf Shochet Avida: [46:05] maybe at the level of their company, maybe at a basic level altogether, what do you recommend? I want to recommend a book that isn't about understanding technical things. If you're a product person who comes... after all there are lots of kinds of product people, yes? If you come to steer product teams that are basically front-end, full-stack from that direction, it's worth learning a bit of HTML, understanding the business a bit. I want to recommend a book called Peopleware, which actually talks about the dynamics. The dynamics between teams, between people, it's aimed at software people, but not only, there aren't many code sections in it, it's a fairly old book, but very, very good. Enjoyable. Cool. OK,

Eyal David: [46:47] friends, so have a lovely day, and bye for now. Bye bye. Hi friends, thanks for listening. If you found this podcast valuable, you can subscribe and follow us, of course, for more episodes on Spotify, Apple Podcasts or any other app. Of course, if you didn't find us on some app, I'd be glad if you wrote to us. We'd really appreciate five stars on every platform, and for you to follow us so more listeners can discover us and find the podcast. For previous episodes, on every app or on the YouTube channel, we have links in the description. So until next time, yalla, be efficient, and bye bye.