Interview Transcript (Anonymized & Translated from Italian)
Giuseppe Silletti: I’m collecting stories from developers and also from people in leadership about the relationship between the engineering side and the product/business team, with the goal of creating free educational content. Can you choose one of these three topics and tell me about the last time something like that happened?
Three options provided: 1) Times when you identified a UX/technical problem that product didn’t notice, 2) Times when product asked for something that seemed wrong technically or for users, 3) Times when you wanted to influence product direction but didn’t know how to approach it
Senior Engineer: I choose the third one. But more than influencing the product direction but not knowing how to approach it, my habit and I think it makes a lot of sense for a product engineer figure is to challenge many decisions.
Something that distinguishes, in my opinion, being a feature factory versus being something that does product is above all challenging - not taking for granted the ideas that come from product, especially if product is an entity disconnected from the development team, from the engineering team.
The more it’s disconnected, the more you need to challenge. So for me, influencing is not influencing in the sense of “I want it to go in one direction rather than another at all costs,” also because that’s not a constructive approach in my opinion.
It’s more about trying to understand why they’re proposing a certain direction, trying to question that direction. Trying to understand if it’s really the right path, if there are different alternatives - I’m not saying better.
Then I’m all for a very iterative and incremental approach to development, so for me challenging sometimes also means following the direction, but trying to propose solutions to make that direction smaller, that evolution sometimes.
And so when you find yourself doing this type of scope reduction of what a person has in mind, or what’s a solution that maybe someone else has thought of, you find yourself having to challenge that solution a bit to say “ok but do you need all of it? Let’s pretend you need all of it - are there things more important than others? And if there are more important things, are you sure those less important ones are really needed?”
For me, going deep into a proposed direction is a bit of a basis for putting your face as a dev in the product choice.
What I don’t believe is that you can give a direction in the sense of eliminating the product figure - I don’t think that’s very forward-thinking. It’s also a bit, if we want, closed-minded. I come from companies where I’ve worked - I don’t think it’s right towards those who do product for a living, to think of eliminating them.
What I think is a bit the product engineer figure is to challenge on one side, and the other part is to make very clear the consequences of choices.
Any technical choice in one direction or another has consequences on the product. Often this thing is silenced. It’s underestimated, more than silenced.
A technical choice can close options to product, can open others. So in my opinion a difficult part of our work as software engineers is precisely being able to make other departments aware of what happens given our choice.
In this, I don’t know if you know Extreme Programming - in Extreme Programming this is one of the concepts that’s well expressed, the separation of roles.
It’s not that everyone should do everything, so it’s not that the dev should do product in the strict sense, but it’s very important that they can make business - they don’t even call it product in Extreme Programming, there’s the concept of business - understand what the consequences of choices are, whatever they may be.
Both choices that product makes, and technical choices that we make that fall back on the product.
Giuseppe Silletti: Can you remember an episode where what you’re talking about had positive results in terms of collaboration, or maybe where something happened that could have not happened if you had applied this approach you talked about?
Senior Engineer: This happened a week ago. With the person doing product - by the way, they’re new, just entered the company, so it’s also their first experience. At first we trusted a bit. Then talking, some questions come out and one of the questions that emerges: “ok but the user who uses that software, what’s the first action they do once they understand there’s one of those things?”
“They go to this other page, they do this.” “How do they go to that other page?” “This page here, well that’s kind of the home page, but they don’t use it, they go over there.”
“Wait, everybody stop. We have to do a giant project, I’m not saying we won’t do this thing, maybe we won’t, but let’s start with the things that give us more value.”
So this is a bit of an extreme example, in the sense that a product person who’s probably a bit more savvy wouldn’t have fallen into a trap like that, but it’s something that happens in a normal, large, structured company.
Giuseppe Silletti: What exactly did you do in that moment?
Senior Engineer: By asking questions - my way of challenging is above all asking questions. When you ask questions and the answer isn’t convincing or is weak, let’s say, you try to deepen that answer.
From there a discussion is born. Usually from that you can find a minimum common denominator between the two parts.
Giuseppe Silletti: If we take a step back, what made you notice this problem?
Senior Engineer: It was a UX thing, precisely. The thing that made it come out was “ok, but if we have to replicate what’s there, let’s try to understand where to start, let’s understand what are the actions a user does who uses that system.” That was a bit the question - what does the user do when they enter?
The approach instead had been: replicate page by page, one at a time. Two completely different approaches, if you think about it.
Giuseppe Silletti: Yes, for me it’s your incremental way of working. So after this discussion what happened?
Senior Engineer: They went back to talk with the people who had given them some indication of how the system worked, went to ask the user who actually uses the system for more detailed information on what they did, what they didn’t do.
In the end the decision was: we don’t start from that page, we start from the one the user uses. So in this case it was basically a change of direction, a change of direction in a project that hasn’t started yet, so it’s very embryonic, so it’s fine, very legitimate, it’s normal.
Giuseppe Silletti: Do you say this because you think it would have gone differently if the project had already started?
Senior Engineer: Not so much if it had already started - let’s say the luck was having very early feedback on this thing. The risk was developing it and then realizing at the end that it wasn’t the thing that brought value to that, and maybe leaving behind things that you discovered instead gave more value.
It’s really a question of priorities - being able to do the things that bring value first. Sometimes it’s also less fun on the dev side, but it should instead be a mantra on the product side, and then since we’re devs and we’re also in the product universe, it’s right that we also bring out these things.
Giuseppe Silletti: Can you tell me about a time when maybe you didn’t agree with a product vision and your feedback wasn’t listened to?
Senior Engineer: Right now I can’t think of a specific episode, honestly.
Giuseppe Silletti: That’s a positive thing.
Senior Engineer: That it’s completely ignored, it’s difficult.
Giuseppe Silletti: Has it happened to you to manage the implementation of a new feature end-to-end, from understanding the problem to releasing the solution?
Senior Engineer: Yes, absolutely. So did you work instead of the PM or with the PM?
In some companies where I’ve worked the PM didn’t even exist. So you did the discovery part, but it was a discovery, let’s say, you didn’t really go to the end user, you proposed more improvements on the product part.
And so there you tried to do that minimum of A/B testing or discovery, but now with code already inserted. You took feedback from how the user actually behaved for a solution.
Giuseppe Silletti: Did this happen to you in a situation where there was a product team? Or only in consulting?
Senior Engineer: No, what I was referring to before wasn’t a product team, but not because I was in consulting - it’s a product company.
But when we develop a feature it’s always end-to-end. Maybe something already pre-filtered arrives on the table from a PM, from a PO, call it what you want.
The fact that there’s something pre-filtered doesn’t mean that when you work on it, you don’t go and dissect it. Usually what comes out of planning done with a PM or PO - regardless that we usually also involve users - what comes out isn’t so much a list of things to do as a list of discussions to have.
Sometimes I need to talk with whoever will use it, now I don’t know. For goodness sake, it’s not that… but let’s say, for things that have a certain relevance, usually yes.
Giuseppe Silletti: In your experience, in this planning, this phase of discovery, what role did designers have, UX designers, UI?
Senior Engineer: Sometimes designers arrive with a proposal of what they have in their head, which then becomes a pretext for having discussions on those things, for challenging some things they thought of.
But other times there isn’t even this phase - we do a brainstorming together first, let’s call it, a kick-off, and after the design part takes the feedback to try to design something.
It’s not that… In few companies has it happened to me that what arrived from a designer was what we really wanted to end up in the code. Usually it was the starting point, it was a rough draft, but then you had to discover what the designer really had in mind.
Giuseppe Silletti: Since you said that wireframes arrived from design that maybe weren’t final, and I imagine there was an investment of time, energy, from the company, an expense that can last weeks. This will change a bit with AI, since now making prototypes takes very little time. What do you think about this?
Senior Engineer: For probably simple things there could be help from AI, but I don’t know, I’m one of those who’s still quite cautious with it and the result of AI I think is always something to validate, so it can be a starting point but it’s never an endpoint.
I experience this with code, but I think in the design part it’s the same - AI can give you a boost at the beginning but then it’s something you have to validate and so you have to work on it, refine it and so on. Sometimes maybe it means doing it with prompts, but maybe you lose as much time in prompts as doing it by hand.