Transcript: Billy Kovalsky | Sisense | How Do You Build Products for Developers?

Eyal David: [00:01] Hi everyone, this is Eyal. You've reached Product Builder, where you can listen to the most interesting product conversations. My journey started 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 gives me great feedback that the podcast brings you value, and it would make me very happy. So let's go, we're starting. Hi Billy, how's it going? Hi, all good, how are you? Excellent. So great to have you here. Great to be here. A pleasure. So Billy joins us from Sisense, he's VP Product, leading Embedded Analytics.

What Sisense does and what Embedded Analytics is

Billy Kovalsky: [00:47] Right. Tell us in a few words, what do you do at Sisense? So at Sisense I basically lead the product. Sisense, as you said, works in Embedded Analytics. It started out in the BI space, back then, so it was a bit... the easiest comparison is Tableau, but about eight or nine years ago the company shifted its direction a little, and today this world of Embedded Analytics, the easiest way to explain it, is that it gives tools to other companies that need to embed either analytics or data-based products in their own product, and they don't want to build all of it. So the simplest example is probably a dashboard. If at the company you work for you now want to show customers a dashboard with a lot of data, connected to a lot of sources, you don't want to build that, you don't want to invest in all the processes, so you use Sisense to connect to all the data. We know how to connect the data, take care of the performance, and also help you embed it in a way that looks like part of your product, but with very little development on your side. So who's the customer profile, really? Well, that's a good question, because we move a bit between profiles, basically the product organizations inside companies that need to embed this thing. Right now we mostly target people who are more in the data world, BI, analysts, data developers, or product managers of data products, and today we're also trying to reach other people inside those teams, which is the developers who do the embedding, and go in through them, or have them be the first entry point into the system, because they got a task to embed something in their product, and instead of racking their brains, just like when a developer gets a task to send an email, he won't build it himself. He brings in SendGrid. Yes, he'll bring in SendGrid, so we want to do the same thing in the analytics world, so we're starting to look toward developers. That's probably also an easier sale than to product people,

Eyal David: [02:39] at least from the tools I know, there are a few that are entrenched in the market, at least the ones I know. You also basically help,

Billy Kovalsky: [02:48] the point is also that the dashboard is very versatile and I can bend it and build it exactly to my needs? Yes, it's even more than that. People at the company always get mad at me that I go straight to dashboards, but a dashboard is the simplest example, and it's only the tip of the iceberg of what you can do, because you really want to do Embedded Analytics inside your product flow. It can be a single chart that floats up when you hover over something, it can be a data-based notification that pops up for the user, and the content in it can be a visual chart, it can be text that explains what's happening with the data plus some call to action, it can be an email, so it can be lots and lots of things, and today, in the AI world, it can already start to be an actual conversation. Meaning, as a user or as an end user of the companies we work with, I can start asking questions about my data and get answers, both visual and textual. So a dashboard is just very easy to explain, because there are dashboards everywhere, but Embedded Analytics is basically anywhere there's data and some product flow. Cool, and is the model fully SaaS, or how does it work for you? Somewhere in the middle. We work with fairly large companies, mid-level to enterprise, it's a fairly long selection process, so everything is very cloud-based, but it's not really classic SaaS yet. And from what point can you deliver value?

Eyal David: [04:04] What I mean is, I need to hook up all kinds of hardware for the data to start flowing, right? What's the bare minimum needed to actually start answering?

The first wow moment and the product team structure

Billy Kovalsky: [04:12] When you get into the product you don't even have to connect data, because you get samples right away, so you can very quickly see what the product can do. You get, let's call it, an initial wow moment. I call it initial because in my opinion it's not a real wow moment when you haven't put in your own data, and then the friction depends on what data you want to bring in. If you upload a CSV, you play with it very quickly and get data, but usually it's more complex processes, because you want to bring in your Snowflake and connect your Salesforce and there's some implementation process. That's exactly what we're working on, both to simplify that and to aggregate the data faster, to basically take the user from the huge amount of data they have to very quickly seeing something visual they can get excited about. Lovely, so we got the big picture. What does your day-to-day look like? I guess like all of ours, you start in chaos and it continues in chaos. And then you slowly ramp up. Slowly, and you plan tomorrow's chaos. So what does the team look like, what does your day-to-day look like? There are seven product managers on the team, spread around the world, three UX designers, in different areas. I mean, the product managers are split by different domains. We have people who are more at the data core and come from the BI world and that's what they manage, a product manager responsible for the platform, a bit more on the infrastructure, we have product managers who are responsible for the developer tools, and a product manager who's responsible for our AI products. Oh, is that new? It's relatively new. I mean, there was always a team responsible for AI, but the evolution of an AI product manager is relatively new, and we're right in the middle of discussions about what this will look like, how much responsibility there is for the AI infrastructure that she'll provide for all the other products to consume, and how many features are end-to-end, so AI-oriented that she takes responsibility from the start through the release, including all the growth of that feature.

Eyal David: [06:10] The whole end-to-end. OK, let's put a pin in that, we'll come back to it, I just want to complete the picture. When you say, and this stuck in my head, you say they're spread around the world, can you tell us a bit?

Billy Kovalsky: [06:19] Yes, we have people in Israel, in Ukraine, near London, in Oregon and in New York. And how does that work? Are the teams, the development teams, based in Israel? The development teams are split too, we have development teams in Israel, Ukraine and the US. Product managers don't fully sit with the development teams, we try to make it so, but it's a very global company, a lot of the work is online. And is that something you ran into before at previous companies? Do you recommend it? In the end. I ran into it, not to that extent, Sisense is the most distributed place I've been. At Sisense too I'm a big believer in trying to have everyone together as much as possible. Ideally I prefer that the product manager, developers, designer, analyst, everyone in the product trio, sit in the same place and speak the same language, but that's not always possible. So we do try to co-locate where we can, but a lot of things happen over Zoom. Wow, so you must do lots of get-togethers during the year, right? Team meetups, offsites, that kind of thing. Yes, in years without wars. Without, yes, two of our sites are at war, so we travel less. What a world. And in AI, is that something you're investing in, and what does it look like? We have a pretty strong AI team, in terms of data scientists, in terms of product, and there are also existing AI products. I don't want to call them legacy, because it would be strange to call an AI product legacy, but there are existing AI products that we're already replacing with smarter things. AI is an inherent part of the product, both for those who create the assets at those companies, so whoever creates those dashboards, those flows, also uses AI for that, and for end users, to give them better access to data, plus insights, better data summaries, calls to action. So this is very developed in the company and now it just got a boost, because obviously there are now APIs and new tools you can use to iterate and improve it. Wow, at your place it sounds lovely, the initial experience of creating the dashboard and moving everything to prompts sounds like a serious game changer. I've even experienced it myself, suddenly opening a chat and saying, OK, I want to see a breakdown of my sales by country and by gender, and it gives it to you, and you say OK, what should I do, and then it starts giving you insights and recommendations, and that wow moment where you very quickly get, both visually and textually, everything based on your data, literally in seconds, is amazing. So that's the experience I hope to bring to our customers. Gorgeous. I really had tough experiences from that event, which I'd describe myself as terrible.

Eyal David: [08:59] OK, so from your vantage point, you've really been through a lot of companies. Let's talk about that for a moment, and we'll touch on it when we talk about your bio, but basically, like me, you come from a front-end background, you were at Wix, at Yotpo, and I'm probably rushing here, you were also somewhere else at some point, and then Sisense, right? So you've seen a lot of product managers and ways of managing product. First of all, how do you actually work at Sisense? What drives the team, is there a methodology you believe in?

Outbound product managers and impact-driven work

Billy Kovalsky: [09:29] We're really trying now to introduce or update our working methodologies. I believe that the thing I think doesn't exist is inbound product managers. I believe only in outbound product managers, so I really try to push them outside, to be very connected to customers and to be very, very impact-driven. That's what's driving us now. Because of the company's distribution, each team gets a bit of its own flavor, but the essence is the same essence. Meaning, the reasons for the things we build need to come from customer pains. Because it's a company that serves huge customers, sometimes it also comes a lot from customer requests, but those are always weighed against impact, what we can do and where our opportunities are. And then doing the discovery work of how we take something from that and scope it down enough to ship something that will actually deliver impact and start seeing it. But it means taking a company that's used to working with huge customers, with fairly long releases, where it takes time to ship a version of something.

Eyal David: [10:42] Yes, getting us to a state where we look much more at impact and customers and release much smaller, much faster. There was probably also some moment in time when all this became possible. You said there's a platform and someone in charge of the platform, so there are these puzzle pieces and someone else responsible for them, there are already several moving parts that know how to move together, and there's infrastructure.

Billy Kovalsky: [11:01] So the company can probably also deliver that way. I think it's still taking shape. We're getting to the state you describe, but we're moving there, really to create a state of infrastructure in the platform that everyone can consume, that they could consume, and also a working method where whoever builds something writes the API first so we can connect things easily, things that wouldn't have happened this way a year or two ago at the company.

Eyal David: [11:22] Nice. So today, when you write a PRD, does it already contain the API? I don't know if you write PRDs, I'm asking. No, we do write PRDs, I

Billy Kovalsky: [11:28] don't think the PRD will usually contain the API definition yet. People still raise an eyebrow at me when I sometimes say I want to see the API definition. Where do you start, what's the connection between an API and product, that's a process people go through, but the definition in any case is API first of all, first of all, and things connect on top of it. And we really try to detach the product and UX flow from the infrastructure itself, which we can consume in several ways.

Eyal David: [11:54] Cool. And tell me, what are the product skills you identify, that you look for most?

What Billy looks for in PMs: essentials vs. trivia, empathy and soft skills

Billy Kovalsky: [12:00] I think the most important thing for a product manager, before anything else, is the ability to tell the essential from the trivial. I also believe it's innate. Meaning, you can't learn it. We're all Jewish, Billy, it should be in our blood, no?

Eyal David: [12:15] Telling the essential from the trivial is related to our Jewishness? To money. To money. Maybe that's why we succeed and there's such a good high-tech scene here and so many talented product managers. Maybe.

Billy Kovalsky: [12:26] But I think you have to have the core of it, and it can be improved. I compare it to something, and there's criticism of the comparison too, right? But I see it like drawing. I need to have the ability to sketch something, and then I can develop it. That's how I look at it, and I'm always looking for that core of essential versus trivial. A person's ability to pull out the important things and really identify what's relevant. The second thing I look for is empathy. Meaning, a person's ability to put themselves in the shoes of their users, their customers, never to treat them as those annoying users. You always have to put yourself there and understand that they're always right, and you cause them either pleasure or suffering, and we aim for pleasure. And the third thing, which is much harder to identify, is whether you have the soft skills this job needs. So yes, the ability to persuade people, but pleasantly, to lead people without leading them, I'm sure you've talked about that here in other episodes. Of course. But those soft skills are very hard to define. I try hard to identify them in interviews or in conversations, and it's hard to identify them in interviews, but sometimes when they're missing it grates even in the interview itself, and then it's a red flag. And how do you guide the people in your department today to find impact? I push them to talk more with customers, and I push them more to use the product themselves. And I push them more to look at data. And where data is missing, to try to add as much visibility as possible into what we do.

Eyal David: [14:01] For example, I'm assuming, for example, they know which customers are currently in a shaky position, they know when a contract is about to end, like, do you call them? So they call them, sales goes along with me.

Billy Kovalsky: [14:13] Yes, so we have stakeholders I try hard to work with, partly so they aggregate this for us. Obviously sales gives us a snapshot of two things. The current prospects, and what's urgent right now that they need for sales. That's a bit dangerous, because it's usually colored by one or two prospects they need on the table right now. Sometimes it colors the others for you. Better than that is to understand what your lost deals are and what they have in common. If some common need comes up from lost deals, then you obviously understand there's an opportunity to make an impact here. If you're still there, but yes. Yes, if you're still there. So that's the sales world. In the customer-facing world, whether it's success or support, I also always ask them to aggregate. It's also very hard; many times these teams were asked to connect their requests to impact. And they always say, OK, let's connect it to numerical impact, money or something, and that's very hard, so with these teams I work a lot on trust. I say, listen, there are ten things you want, you give me the priority, I trust your priority, but take into account that, I don't know, the first three or four can get in. Now you have to agree among yourselves what the important thing is so I can push it forward, and they hit the mark very well because they know it, they're there day to day, they work with our users, with our customers, they feel the pain. And even their mistake is probably not a big mistake, because instead of getting the top-priority feature, it's somewhere in the middle, and it's still a feature that will do the job.

Eyal David: [15:42] Totally, and in the end they probably need to sell it when the need comes up, so if they believe in it strongly, it's easy for them. They need that ammunition. Yes, so that was a good example of how you overcame a challenge you had. What other challenges do you have in the role?

Billy Kovalsky: [15:56] I think there are a lot of challenges in mentoring people, especially when people are spread around the world: how to create working processes that are identical, or similar, across everyone, without doing enforcement. I come from an understanding that... for example, if one person wants to do a PRD in Confluence, another in Docs, and a third is comfortable with a presentation, I'm fine with that, as long as the basics are kept. So that's something I'm starting to focus on now, basically creating what I call How We Do Product in Sisense. It could be a document, it could be a presentation, I don't know what the final output will be, but it needs to contain the principles we want to have in every product creation process, what we can compromise on and what we can't compromise on. Cool, good luck with that. Share it with us when you can, maybe you'll have a template you can share. Now that I've talked about it, it also gives me a deadline. I've said it out loud and I'm being recorded, so I really have to work on it, it's not just fluff I'm throwing out. You're right, you have a bit of grace until the episode goes live, but you're totally right. Let's talk a bit about your bio and give some context.

Eyal David: [17:10] So as we said, you came from development, I'm just throwing us there, so really from development to product. I understand you were at Yotpo, right? Want to tell us a bit about that, or would you rather jump to Wix and tell us a bit about your time there? No, I can start there, I think it's an interesting story, or I think within my bio I like telling it.

From development to product at Yotpo: the guerrilla team and Yotpo Ads

Billy Kovalsky: [17:31] So I started at Yotpo as something like the tenth employee, in a real Wild West period, a small startup where everyone does everything, and I joined as a front-end developer and at some point I built the front-end team, and after about two and a half years the company realized it wanted to open another product line. To do that, they asked me to set up a kind of guerrilla team, you can call it innovation, you can call it Labs or POC, to basically check all kinds of ideas for what the next product line could be. That was a super exciting period for me because it was very project-based; very quickly you get some whim. You need to show very, very fast whether it's worth getting into or not, and usually it's not worth getting into, and then you have the not-so-simple task of saying no to whoever dreamed it up, which is usually the CEO. But when it hits, it's nice. We did several such tests in a kind of team where I did everything, and the last test hit and we set up another product line in the company, a product line for creating ads. We called it Yotpo Ads, and it could basically create ads from the content customers wrote, the content users wrote. Wait, one second, one second. First of all, at that point in time, I'm trying to understand, from that point Yotpo operates inside Shopify, isn't that so? Where did Yotpo actually operate, how did it work? Yotpo always operated as some kind of add-on for e-commerce platforms. It always supported many platforms, at the time and today a lot of platforms, there's no process of narrowing platforms. Shopify was the strongest most of the time, and it was also kind of the early days of apps on Shopify, so mainly Shopify, but also Magento, BigCommerce is another platform. The reason I'm asking is, so these ads basically created an ad campaign on Facebook or something like that? Exactly. OK. So that's the connection: someone writes a review of a product, you have a store, you sell something. They write you a review, even with their photo with the product, and you start having content. Now, the customers at that time were mostly relatively small stores. SMB, those mom-and-pop shops, a small team, they don't have huge marketing teams that can support them. And what we built for them was the ability to say, OK, this is the ad budget I want to spend. And I now want to start a Facebook campaign. We knew how to bring all the content needed, because we used content their buyers created in the form of reviews for the ads, we know their product catalog, we know how to install a pixel for them to measure conversion, and this connected for us with great timing, when Facebook released their Marketing API and we were right in the beta. So it all came together into a product where you, as a store owner with no technical knowledge, have a working Facebook campaign in a few clicks

Eyal David: [20:19] and it's also self-optimizing, because it keeps testing itself. Gorgeous. So the POC team, or whatever we call it, managed to prove to Yotpo's CEO that there's an opportunity here, technically, market-wise, in every way, people are willing to pay, the effort is probably not big because look, we managed to make it work. At this stage you don't have, you're not coming with a product background, you're coming two years into your career, of course, but from a development angle. So was the goal more to prove technological feasibility, or had you already really built the case too? How was it? What needed to be proven

Billy Kovalsky: [20:51] was that it can work, and once we proved it can work, they told us OK, go productize it. And on a personal level, I was almost a team that did everything, I did code there, and we also did support for it, and we also did some design where needed. It was a startup within a startup that was itself a small startup. But on a personal level, in that process I realized that what I really love is product management. And coding, for me, is a means to an end. Then when they asked us to make it an official product I said OK, let's go, I want to join the product team, in quotation marks, because it was one person. I joined him, and the people who worked with me were simply absorbed into the company, and we started building the company around product lines, we suddenly split it into teams aligned to different product lines and started building

Eyal David: [21:39] relatively orderly product work, including the new product. Wow, that's really nice of them. First, cool that you managed to prove it, but it's very nice of them that they gave up the front-end developer, who at the time was a very expensive commodity, their most senior one, and you basically didn't write code at that stage, right? Yes, but look, in parentheses, now I can already say it, yes, I'm a better product manager than I am a coder, so it wasn't such a big loss. OK, but there's a learning curve, and in that time they basically need to give up the person when he was a star in his field. True. So that's very nice of them, cool, so.

Wix App Market and reviving the developer ecosystem

Billy Kovalsky: [22:11] How long were you at Yotpo from that moment? Six years in total. Wow, wow. Of which two years and a bit in development and almost four years in product management. Wow, and then you moved to Wix, to App Market. Right, so after, throughout that whole period at Yotpo I pretty much focused on relatively technical product management. That's also what I love, and after that I was itching to see how it's done somewhere else. That's how I got to Wix. Wix, I assume most people know, is split into "companies", autonomous units that each work on some product. And I got to App Market there. What fascinated me there is that it's really a marketplace that on one side faces Wix users and on the other side faces developers, the whole developer portal, their whole ability to start developing, manage it, manage versions, all the market listing, their tests, basically all the development processes they do with Wix. That really, really fascinated me, and I was there a bit over five years.

Eyal David: [23:08] And did you arrive when there was already something there, or was it being set up? How was it? So the Wix App Market is very, very old, but it

Billy Kovalsky: [23:14] was in a kind of dormant state, because it used to run on old technology. A lot of things built at Wix, say what's today Wix Stores, started as an app on the App Market that was built internally by all kinds of small teams. To this day, Wix is built so that many of its verticals and its companies are built as apps, that's still the infrastructure. But back then all the apps were based on iframes, and that worked for its time, and then gradually it focused more on what's done inside Wix and less on third-party apps, and there wasn't the technology that could bring these things in, while Shopify, as we said earlier, ran ahead and put a huge emphasis on the ecosystem. Then Wix realized it wanted to revive the App Market, and that's roughly when I came in. There wasn't really a REST API, the first REST endpoint was probably released externally around then, there were no webhooks, there were no normal tools for developers, and based on the new technology the platform provided we started doing the work to attract developers, to support them in their development process, and also to basically be the voice of the developer inside the company, to understand what their needs are and what they need to do

Eyal David: [24:24] to revive this App Market in a new way. So basically the outcome of this is that, first, you unified, I assume, this Wild West you described where anyone can write whatever they want, so basically things went through, you had your finger more on the trigger

Billy Kovalsky: [24:39] you probably also communicated more to developers what you expect to receive, and as a result, on the quality of the thing. It wasn't, it's worse than that, because a few years earlier developers could get in based on that same iframe technology, there was a review and also guidance on how they want it to look, but the technology gradually stagnated and simply fewer and fewer apps were let into the system. But then we did give them all the tools for how to develop, plus the guidance, and in the end we were the gatekeeper, so every app that gets in goes through review. Today it's already a review that's partly automated, and always at the last stage there's some manual review that checks it looks right, that it does what it promises to do, that there's no security issue as far as we can see, that it doesn't hurt the site's performance, lots and lots of checks

Eyal David: [25:29] to see that it's really fit for users to use. Cool. You mentioned that you really love building products for developers.

Building products for developers: error messages and documentation

Billy Kovalsky: [25:37] Right. Can you expand on that a bit? Yes, I really love this persona of the developer as a user, and I think a lot of people neglect it or neglect its experience. At Yotpo there was a whole ecosystem of developers who built more complex things inside the stores themselves, and who connected to software in our ecosystem, the same at Wix, the same at Sisense. What's interesting about this persona, I think, is that it really has zero patience. Very forgiving, but very forgiving, meaning if something works and there were X issues, it's no big deal. Wow, forgiving. Yes, and if something doesn't work, no. I'm saying as long as it works. Right. But within that, I think we take advantage of this type of user twice, in what we do day to day. Once, we can really take advantage of it because we know there's friction there we can work on. The example I use a lot is the error messages APIs can send. They're sometimes truly a disgrace. A person has no idea what could happen. And instead of sending something informative, something you'd never do in a UI. Right. I mean, in a UI we'd never show "internal server error", while in an API it's totally fine to send that to someone and they'll be fine. And the second sin we commit is saying OK, we're developers. As someone who was a developer for longer, I'm a developer, so I know how to serve developers, and that's dangerous. Because the range of "developer", under that word "developer" there are so many types of developers, levels, needs to get something done, that we sin by saying OK, I think I know what he needs

Eyal David: [27:17] without actually checking what he needs, and we wouldn't do that with users. I agree with you, and I think there's another thing: documentation needs to be tight. Sometimes they release documentation that really

Billy Kovalsky: [27:28] relies heavily on the developer to understand and manage, and it doesn't work that way. Yes, in that context I tried to do something, but I didn't succeed, it's still something I want to succeed at. Many companies adopted Amazon's model of doing the PR first. First write the PR, how it'll look in the marketing world. Did you start from the documentation? I started: write the developer documentation for what this feature is supposed to do, including the API definitions, what the parameters are, and then we'll build it. I think it's still applicable, I mean I think it's a right way to build for developers. No, I didn't get the process to a state where it actually works.

Eyal David: [28:05] Interesting, it probably kicks in from a certain point, like you probably need to bake the story first and then bringing it down to earth can probably happen. That's actually a really interesting approach. I really liked it. So today at Sisense, that's the direction you're heading, right, toward developers. How does your mindset actually change, or are you basically leading around developers?

Billy Kovalsky: [28:26] First of all, developers need to see value much faster, the whole process. The sale, if it exists at all, or the time to wow is different, and they need to see the value for themselves. One of the things Sisense does is improve dev velocity, because instead of a developer having to write this whole thing from scratch, they can use us. When you explain that to someone responsible for a budget, which could be someone on the product management side or a VP R&D or a CFO, you say I'm cutting your development time, they understand that, they translate it into numbers. When it's a developer, they need to understand how this becomes more pleasant for them. How, like you said, they get better documentation, how they get better tools, how it sits in their IDE, they don't necessarily want to go into the product. How it connects to Git, how they manage versions, quality of life, in short, quality of life, they want to work more easily and in an orderly way. They're not necessarily looking to work faster. The mindset isn't "cut my dev velocity", it's "make it more pleasant for me, save me

Eyal David: [29:29] work so I can really focus on my code." And today at Sisense, that's the old side, but you have a lot of technical product managers, what does that look like?

Why every PM needs to be technical, and how to learn

Billy Kovalsky: [29:43] Yes, I think the product managers at Sisense today are almost all technical to a degree. In general, my approach is that I think every product manager needs to understand the technical side of where they are, they need to be technical to some degree. Back then, we talked about this a bit before, we used to look at three types of product managers, as a rough generalization: a product manager who's very UX-oriented, a product manager who's very data-oriented, and a technical product manager. Usually those were the ones who had been developers or had studied computer science. Today I think everyone needs to know everything. You really have no justification, as a product manager who isn't junior, for not understanding a bit of user experience. I don't need you to know how to design, but you need to know how to work with the designer. You need to understand data, because if you're not data-oriented then what are you doing. So you need to understand the technical infrastructure. You need to know what an API is, you need to know what a webhook is, you need to understand a bit how things work behind the scenes.

Eyal David: [30:44] You need to understand that there are synchronous and asynchronous processes, not much beyond that. And maybe let's stop for a moment and say why it adds, what flavor it adds, suddenly being more effective at work.

Billy Kovalsky: [30:54] Beyond the more correct dialogue you have with the developers, the way you help them solve problems is much better. My approach is almost radical in the product management world, I told you earlier, that I believe only in outbound. For me, a product manager needs to know the market, bring the opportunity, put it on the table, or some pain, and they don't even have to be part of the solution. But if they come in as a facilitator of the solution, they need to understand what's being proposed to them, they need to understand trade-offs with development, and that's significant. Now, the products we use are technical, even if there's some non-technical layer on top of them, and understanding that communication makes what you do day to day much, much more efficient, it makes the way you solve all kinds of issues much, much more efficient. It's even critical. I still really see product managers who don't have that flavor, and you really see the differences in efficiency and in what they can achieve in what timeframe, it's just very noticeable.

Eyal David: [32:02] So everyone on your team is like that right now, it's also something you look for. When we talked about what you look for, maybe it's a checkbox that's ticked by default, but it's there.

Billy Kovalsky: [32:10] As of today, almost yes, everyone is technical to some degree, obviously not to the same degree, but everyone will understand the technical side behind the scenes and won't flinch when I say a word like database. But I also believe it's something you can learn, meaning you don't have to come in as a developer and then become a product manager to really have the basic technical understanding. In the world I lived in, a lot at Wix, product managers came to me, juniors or seniors, saying: what, I'm afraid of this technical thing, because I never dealt with it. And after a few months, a few iterations, they got into it and understood it and had the same dialogue with the developer about what they need, whether it's an internal developer, not a developer as a user.

Eyal David: [32:55] Yes, it's totally learnable. I think if you even want to give advice to someone entering the field who wants to get into this, and maybe isn't yet working in a tech company, do you have any advice on how to start touching and feeling the technical side?

Billy Kovalsky: [33:13] Like, as a product manager, how to feel the technical side? They haven't worked in such a role yet, they want to, like, one way could be to start messing with HTML, JavaScript, CSS, play with it a bit, another option maybe connect it to some database, play with it a bit, and that will probably give such a good understanding of the basics of the basics that when you sit in a room and they show you some complex design, at least you'll have the jargon or the basic terminology. You could probably also do a consulting hour with one of the developers on the side, right? No, I think that's what I was going to say. I think the other side is much, much easier: sit with the developers, ask them what they do. Have them explain the infrastructure to you, and explain what the process of information moving from start to finish looks like. Just draw it on some whiteboard, and you'll probably learn a huge, huge amount about your product's infrastructure and in general. If you have the time, the opportunity, the ability to sit down, then yes, learning to code a bit with all kinds of online tools can be very, very effective, but it demands a lot. It demands a lot, and once you don't use it, there's not much you can do with it. On the other hand, today you can go to ChatGPT or some other engine and tell it, I want to write, write me a script that does x, y, z and explain it to me. And then you can understand what it wrote and why it wrote it, or even take a piece of your code and ask it to try to explain it,

Eyal David: [34:36] and learn a bit, since in the end most code is written in English. Yes, totally. I'm just thinking, all these companies where everyone signed an NDA and everyone works with GPT on their code, I don't know how that works, I'm very curious about the legal aspect. So tell me, let's dive in for a second. OK, we talked about the basics. Where do you think this world of developer products is going, where is its future heading?

The future of developer products and AI

Billy Kovalsky: [35:03] I think first of all there's connectivity to the world the developer lives in. That's not new anymore; it needs to meet the developer where it's comfortable for them, in their development environment, in their IDE, connected to the tools they work with, whether it's Git or any other tool. Connectivity to Slack definitely helps, because Slack, granted, not every company uses Slack, but a lot of development teams, even inside companies that don't use Slack, use Slack or Discord. So first of all connect it to their ecosystem. Two, I think there too we're already seeing the connection, or suddenly the first sparks of AI in this world as well: how to take and simplify a developer's work by using an LLM or prompts, how to save them that work, and also a new layer that you need to deal with and make accessible to developers. I think those are two essential things. And as in products in general, definitely in B2B, I like having an advisory board, some group you can turn to and get feedback very, very fast. With developers it's even easier. They're available for it, they'll agree to give you feedback. They won't agree to meet a salesperson, but they will agree to hear someone

Eyal David: [36:22] from the team and sit with them at some round table and give feedback. Yes, the customer advisors, like users of the customers, not the more senior people, more as your customers. So OK, don't move the cheese, leave people where they're used to consuming and living, and that's a cool slam. Let's talk about AI. How do you imagine integrating it? You gave an example around dashboards and we talked about more complex systems; how do you imagine it in developer products?

Billy Kovalsky: [36:50] I'll take it from the examples we're working on, because that's easiest for me. Today, when a developer is inside Sisense, at some point they need to get to where they're embedding what was built and they need to get code and make their modifications there, whether it's customizing colors or behavior. So what do they do? They take what was built for them, go to the documentation and start a kind of back and forth of how to customize it. Today we're already starting to show them tools where they can just say, OK, I want this thing but change the colors to orange, and they get new code, a new snippet, and can start working with it. And I think that's where both we and the world need to start heading. I mean developers, definitely at the kickstart level of what they need: how you approach a new product and your Hello World experience with that product, meaning what happens from 0 until you have some initial experience, today can be very prompt-driven. And also the rest of the way: you got an initial experience and you want to start adapting it to you. Instead of tweaking the code, you can tweak prompts that show you where in the code you need to change things to adapt it. So it also gives you a view for the two relevant stakeholders, which are the developers who really touch it. But there's always another stakeholder that I always called the prospect. It can be the product manager, it can be someone senior on the development team who isn't necessarily in the day to day and coding, but wants to understand what your system can do. This layer can very quickly show them the power and what you can do without them having to get into a development environment. A bit like what we talked about earlier, basically again, if I'm not that technical and I want to understand, then suddenly there'll be this magic, it'll be lovely.

Eyal David: [38:34] What I was thinking when you talked about it, and I think you're very right, but broadly, as a persona, are developers more permissive, more into delegation? OK, I now have some, I have my code that I built and I'm protective of it.

Billy Kovalsky: [38:48] And then suddenly I tell the AI, yes, please turn all the instances in the CSS orange. I'm worried it'll just do something. You drew it differently from how I'd have aimed it, but exactly because of that, because I think developers won't let something touch their code.

Eyal David: [39:03] Because they want to touch the code. You don't, you don't trust AI to write your code from scratch or change your code from scratch. Because in the end something breaks and you're up at night. I have an answer to that too: probably the next step here is just, there's the diff principle, right, like GitHub knows how to display it, so that would probably solve it and remove that fear. But I'm just curious, at the user level, whether they're more permissive, like that. Probably not.

Billy Kovalsky: [39:23] They're not permissive and they need more guidance. That's why we try to get to a state where we show them where they should change it, where they should do the tweaking, we give an example, but they're the ones who touch the code.

Eyal David: [39:38] Where do you think this hat of the AI product manager you mentioned earlier is going, how do you see it, where is it heading? So I try to look at history, and I think a very, very similar process will happen.

The rise of the AI PM

Billy Kovalsky: [39:52] As we said earlier, back then in teams it was common to have product managers where one of them was a technical product manager. I was one, I assume you were one somewhere in one of your hats, and there were lots of them. And the other product managers who needed something would go to them for help to access the platform, or because their product had some integration. Today I don't think that's the situation. Maybe it's because of the companies I worked at, but I really feel today that product managers are all much more technical, it's become much less scary to talk about APIs, integrations and infrastructure. And I think a very similar process will happen with AI. Today we already have, as I said, one product manager who's AI-flavored, and that's the right thing for now, and I assume it's happening at other companies. There's one product manager who's more AI-flavored, both in infrastructure and in AI features, and she advises the other product managers. I think we'll move forward exactly like technical product managers. Everyone will need to know how to bring AI into their systems, how to integrate it into their day to day, how to be a bit of an AI product manager. The difference is that I think in development it took 10 years, and in AI, like everything in AI, it'll probably take two years. So we need to start bringing these things into our system now. The advantage is that it's much easier, because it's much clearer how to use AI. How it does it is much more complex, but you don't need to know how it does it to know how to use it.

Eyal David: [41:19] Yes, I strongly agree. So is that the process you're running? I mean, the AI product manager basically does for you, like, how does it work?

Billy Kovalsky: [41:28] First of all, she originally comes from data science, so she understands very, very well how the systems work. And again, there are things that are really her bread and butter, very AI-driven products that she's currently leading, but she's also starting to provide infrastructure to other product managers and accompany them. Where do I think this will go? I think at least some of them, a year or two from now, when they need to do something AI, won't need her anymore, and then we'll need her only for things that are really... infrastructural, deep. Either infrastructural, or where AI is really the core. Deep, totally.

Eyal David: [41:59] Wow, that's so interesting. Sounds good, so we're getting close to the end of the episode. I'll ask you,

Billy Kovalsky: [42:06] what do you wish Billy in 10 years? Wow, good question. I'd be very happy to work on exciting products. I think I wish that for today's Billy and for Billy in 10 years, so to keep working on exciting products, that's what I wish myself. And I'd be happy to help more people in places where I got stuck 5-6 years ago. I always enjoy meeting someone who's either at a crossroads or can't find themselves and helping them, so I hope I can do that more. And I wish us, besides quiet, that this terrible period passes, I also wish each of us, and myself, in this context, more time, that work becomes more automated, and that we'll find more time to do our own things and integrate life better, and I think that's where we're heading. More work-life, yes. I'm a big believer in work-life mix, not balance. I think work is very intertwined with our lives, and we have the privilege of enjoying our work, so it spills into everywhere and our lives spill into work. So I want that to continue, meaning that it'll be very, very fluid when you work and when you don't, with flexibility, and doing more of your own things and bringing them into work, and work coming into life, in a healthy way.

Eyal David: [43:28] Yes, that mostly happens when the kids grow up. Organically, I hope, and healthily. Great. And how do people get in touch with you?

Billy Kovalsky: [43:36] I think LinkedIn is the most convenient. I'm very available on LinkedIn, I'm always happy to reply and connect. There are a few forums I'm in, more closed communities, and I'm happy there too, but whoever wants to get in touch with me, LinkedIn is the place. LinkedIn, so we'll put a link. Excellent.

Eyal David: [43:53] Billy, thank you very much, it was really fun. Thank you. Bye everyone, see you next time. Hi everyone, 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. And if you couldn't find us on some app, I'd be happy 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. You can also find the previous episodes on any app or on the YouTube channel. And we have links in the description, so until next time, yalla, be efficient, and bye bye.