Partial Interview Transcript (Anonymized & Translated from Italian)
Giuseppe Silletti: I wanted to ask you, how are product decisions generally made in the company?
CTO: That’s a good question. How? It depends, it depends. So, at the company there’s a product function, there’s a product team, which in theory is responsible for product decisions, but that doesn’t always happen. Because in some cases, now less than in the past, certain decisions are imposed directly by the co-founders.
Giuseppe Silletti: Ok, so let’s say you’re in founder mode.
CTO: Yeah, let’s call it founder mode, yes. But in my experience, it’s quite inevitable, especially in early-stage companies. And honestly, look, maybe this is a bit unpopular, but if you have two or three people, the co-founders of a company, who have invested a huge part of their personal wealth, personal time, personal life in an idea they believe in tremendously and you don’t have the same, you as a person who maybe has less skin in the game because you don’t have equity, you’re not, I mean, you’re also less, how can I say, inside the project, it’s understandable that when you’re small, the decision ultimately comes down to the founder’s gut feeling, because they founded a company to solve a problem and it’s understandable that type of vision, willingness, prevails, pardon the term. So I honestly don’t find it that strange that there are these dynamics in the early stage. Then, when you know, it’s no longer like that because you grow and maybe product-market fit is reached, it can be acceptable that product decisions are made by a person who doesn’t work with the tools or typical mindset of a product manager, but gets there in a different way.
Giuseppe Silletti: Ok, do you have product managers?
CTO: Yes, I told you there’s a product function, yes, there’s a function, there are four product people.
Giuseppe Silletti: Ok, from what you’ve seen, are developers involved in some way in deciding what gets developed in the end and not just how?
CTO: This is another… So, less than I would like. I mean, for me, now also here, let’s give things names because we like to give names today. Now the product engineer is all the rage, but for me, it’s not a role that exists now, I mean since I started working, also here, it depends on the size of the company, but when you’re early stage, or in tech startups, for me it’s fundamental that the engineer is not an executor, a translator of requirements who just writes code, but actively participates in being a first-person user and helps propose product solutions. So, you should talk to the guys on the tech team. So, from my point of view, too little, way too little. But it’s really something that… I’ll tell you, sometimes I struggle too, I mean there’s a lack of willingness in software engineers to be more than just a software engineer. To extremize it, for me, if I have to, the product team shouldn’t even exist, the software engineer can do the product manager’s job perfectly well in this company dimension, right? Because for me, the fact of talking, look, last week I went to install POS systems in a beauty center here in Verona, the POS is our product, because for me talking with the people who use it, it’s not that someone else has to do it, it’s very nice if we who then maybe also fix and implement solutions do it. So, sorry, I’m getting emotional here. So, yes, they’re involved, but then there are those who maybe would like to be involved even less, maybe, and also expect from past work experiences, from how they’re used to working, that the ticket with requirements ready comes from someone else, but we don’t work like that. We try to discuss together, we do refinement together and we also try to meet, I don’t know if we’re talking about merchants, we meet with account management or sales and we try to unite business functions rather than divide them, but it’s very, very, very difficult, very difficult.
Giuseppe Silletti: Ok, from what you said it seems to me that there’s more resistance from developers than from the product team to have developers contribute to the product side. Did I understand correctly?
CTO: In my opinion yes, that’s right. From my point of view yes.
Giuseppe Silletti: Ok.
CTO: In fact, if I understood correctly what you’re trying to bring and the idea you want to develop, for me, this is a problem that needs to be seen globally, organizationally. And there need to be two conditions, certainly, technical leadership that believes in this way of seeing things, boom, without this you can’t do it, but it’s also necessary, one, a company culture that accepts and encourages seeing the software engineer as a resource that can contribute to product decisions, and two, engineers who want to do it. Both conditions are needed.
Giuseppe Silletti: If you’ve had the experience, maybe it’s not your case, of conflicts between product and tech?
CTO: No, sure, yes, there have been clashes, if we want to use that word, but so, from my experience, the difficulties have always been more between business and product and tech. But between product and tech more or less, I don’t know, it’s more an issue maybe when, if we want, when product also decides how to implement things, thinks they know better than those who then have to implement, then there can be issues, but I must say that in recent years, if I look at the experience, at least in the last 4-5 years, there’s never really been, I wouldn’t speak of conflict between product and tech. Maybe I’ve been lucky, maybe we’ve managed to create environments with good collaboration, but I wouldn’t say there are conflicts between product and tech.
Giuseppe Silletti: At the level of not being aligned between product and tech, have you had experiences with that?
CTO: Little. Also here it seems like the previous discussion, little, because maybe some years ago, 7-8 years ago, but I was much younger and more inexperienced, now I’d say that in the last 4-5 years no, I don’t have examples. We’re hyper, I mean, every week we always start from OKRs, we always start from the goals we need to reach. With the tech team every two weeks I start from how the business is doing, what are the numbers we need to reach. In terms of revenue, deployed, certain business KPIs, we’re doing this, so it’s really by force of, we habitually continue to remark by speaking the language of business, I don’t know how to say it. So this in my opinion has helped a lot, in fact, if anything I’d say there’s more misalignment maybe between business and tech and product, but between us no, I don’t think so.
Giuseppe Silletti: So speaking specifically about the developer role, have you ever seen, have you ever had experience with a developer who maybe challenged something coming from business, like a requirement or a direction being taken? If so, how did it go?
CTO: Now we’re doing a process, we have a platform migration activity, these are always very painful things, there’s a past and so it’s always very painful to do an app migration. Specifically we’re moving from a no-code solution, we developed with no-code tools an app, but now, since we have thousands of users on this platform it has limits, there are no logs, it’s difficult to debug, reports arrive, maintenance is difficult because you can’t even have a test environment, you can’t write tests, in short it has problems maintaining a no-code platform. It worked well in the first two years of the company’s life, because we went live quickly, there wasn’t AI so it was more difficult to do something scrappy and so we have this migration process. In tech we’re going faster than business, so we’d be ready for, how did we approach this problem? We said we’re not doing mega releases and this was honestly my imposition, because the only thing the Big Bang Deploy ensures is the Big Bang. So are we making a new app? No, we do it piece by piece, we make slices, we release a functionality as soon as we have it and iteratively. So the first thing we did is login, the first credential management, login in front, so the new entry point is new, and then meanwhile we redirect to the old platform, right? And now we’d also be ready to show some rewritten functionalities to some of the new merchants, let me write, of existing merchants. The problem is that we were supposed to arrive at this point having already migrated all merchants, but it’s not yet like that. So, talking, a guy on the team said, but excuse me, why do we have to wait to finish that part of migrating credentials to everyone? We can already show the new functionalities to those who have already set up credentials with this subset of users. Sure, there are two platforms, some can use this app, some that app. It’s a bit more difficult to manage from a point of view… So a release plan for an important platform was challenged. And we’ll do it like that. So, let’s say, in general it can happen and I dare say, but you should always hear the other sides, obviously, because this is my point of view. I believe there’s this type of environment where we also try to challenge certain concrete decisions with business. But then, also for me it’s very important to agree with business. I’ll give you another example. Always on this. We’re talking, as I told you, about thousands of merchants to migrate. I mean, also for us, for example, when we talked about this migration problem, we said, I mean, for us it can be done all together, but it doesn’t seem like a choice to us, because if from one day to the next everyone asks customer service, support, everything has changed. So, we suggest having a gradual, incremental approach. You tell us what’s better to do, what type of batch, what type of cut to give to the migration, and we’ll do it as best for you. So, let’s say, we always try to reason with business and in certain issues the decision must be made by business. Like this one. I don’t know what’s better. Do we go by Province, do we go by Merchants who use the platform more and then those who use it less, the opposite, I don’t know. We talk about it and then we decide together. I don’t know if I explained myself.
Giuseppe Silletti: Makes sense, makes sense. While from the point of view of maybe, I don’t know, a new feature, maybe these ideas can also come from tech, so bottom-up.
CTO: Yes, yes, yes. But unfortunately, I must say this happens few times that they then get implemented, I’ll say it. Ok.
Giuseppe Silletti: And in your opinion why?
CTO: Eh, for two reasons. One because we’re perhaps not good at explaining, demonstrating the impact that these functionalities could have, but two, also because when we manage to do it, something else is still considered to have more impact. So certainly, yes, here unfortunately I don’t have great, we struggle with this, I struggle, honestly. Which is also a problem because guys who suggest things and then it never happens that bottom-up suggested things get implemented, then people stop suggesting things.
Giuseppe Silletti: Ok, how would you see it? How could this logic work?
CTO: So, for me it works that we as, from a team point of view, we must and therefore I must create the space so that in the team these initiatives can emerge. For example, during roadmap activities, we do brainstorming to see if the team has ideas about what could be nice to build as product features. But clearly maybe these ideas are very qualitative, so the quantification part is more something that I should, me and product, I mean the leaders of the tech team, of the product team should do. To understand that an idea then also needs to be quantified in terms of business KPIs. We do this thing and we think the conversion rate will increase by X because ABC, or this thing because we could increase revenue by Y because ABC. Every idea should be quantified, in my opinion. And so how to improve? I imagine, already in the ideal way, I would do this process. A brainstorming where there’s space for these ideas to emerge, they’re voted on, discussed, etc., etc. But then those, let’s say, that we like most should then also be quantified. And then discussed with the other things coming from other teams, clearly. Ok.
Giuseppe Silletti: Ok, here I imagine anyway having developers who are also willing to think beyond tech. Yes, regarding this last thing, what are the characteristics that a developer should have to be able to contribute to the product? Should you hire one? What would you look for in this person?
CTO: For me two things. One, curiosity. Two, ownership or agency, depends on what you call it. So being curious and agency in the sense, not the agents we have now, because the agents now don’t do anything unless you tell them to do it. So they actually have little agency. So you could say, they try. Actually, no, I decide to do something, but without curiosity, no, I’d say these two things.
Giuseppe Silletti: Ok, is it always important to have the leadership, the company culture that allows developers to contribute in this way, or as much as possible maybe developers who are more product-minded, let’s say, can have influence, despite leadership not pushing in that direction. I don’t know, maybe a developer can, as you said, can demonstrate, let’s say, can have an idea for an initiative, maybe find metrics talking with product managers and then take it forward in this way. So well defined, also trying to sell it to business, sell it. Is it possible in your opinion or could there be some resistance?
CTO: In my opinion it’s very difficult. I think from my experience a totally bottom-up approach is very difficult.
Giuseppe Silletti: Ok, let’s say let’s pretend we’re in a company where this type of attitude is not encouraged, right? In your opinion, having this type of mindset is still useful for daily work, so thinking also about the business side, or at that point is it no longer that important?
CTO: In my opinion it’s important, but I don’t think it’s universal, I mean maybe for me it is, or in a scale, for me it’s very important. And I think it’s really a value and a characteristic that makes people better professionals. But I don’t know if it applies to everyone, you know? If it can apply to everyone. I wouldn’t extend it to a universal general rule.