To kick off our product communication series, I had the pleasure to talk to Enzo Avigo about his time as a PM at Intercom and the challenges he faced when it comes to communicating effectively between Design and Product. Enzo is also co-founder and CEO at June.so, which is an amazing analytics tool that we love here at Spoke.
The goal of this series is to provide value to all product folks out there. We all experience difficulties when it comes to communication and we should all be sharing and learning together.
Enzo’s insights underscore the importance of leveraging team strengths, open communication, and the balance between methodical processes and intuitive actions.
Jack:
How about with product and design? Because there can also be some challenges there in terms of interaction. Tell me a story or experience that you’ve had there where it didn’t work so well.
Enzo:
The one I can think of is one that happened at Intercom with Davey, who is one of the great designers I worked with that now left also for another venture. We were working on a project called 'Permissions' where basically, you know, as Intercom was growing up and so on, a lot more users wanted different ways to access the product, right? And usually it's the IT team that requires that because they don't want to give the full access to everyone, right? People should have different permissions basically. And so that project, I remember I was driving it and I had lots of thoughts on how we could design it, copy, blah, blah, blah.
It turned out that at some point I was kind of bypassed by the designer, which is not what you want to happen when you're a product person. But it was actually the best thing that could happen because then the project was done in like, I think less than two weeks. And it was even called out by one of the founders at the All Hands saying that it was such a success, such a nice way to move project forward and so on.
The thing is I was going through the traditional artefacts of product development, like the double diamond: you expand, you explore, you have discussion, you zoom in, blah, blah, blah. Then you explore a few possibilities of solution and then you scope things down and then you build it. Turned out that Davey jumped on a quick design and because of the components and his understanding of this problem that he worked on for many, many years, basically, he was able to just scope perfectly on the first shot, a solution that would entirely solve the problem that required almost no development because basically it would rely on existing screens and existing setup we already had. You would just put some sort of shield on top of what we had, which was basically mostly front -end work, to be honest. And the solution was super elegant, like very intuitive and very aligned with the rest of the patterns of the product and other settings that he had developed. And turned out that, you know, I was trying to do too well, I guess again. And I mean, this time the learning is I was trying to do too well. And turns out that sometimes if you can streamline this product development and you just had the right person with the right understanding and you can speed things up, it works really well. Right. So that time I felt a bit bad because I was bypassed. But afterward I built so much trust into Davey because I was like, dude, like if you're able to do that every time we need to build something you know, take my job, right? And I remember he told me like, dude, if I was not a designer, I would be a PM. And I told him like, look, if I was not a PM, I would be a designer. So we got on the way after that.
Jack:
Nice! That's a cool story. I guess it's about choosing the right tools for the job, right? Sometimes you need to go super deep, go broad, do the double diamond, explore everything that you can possibly explore. And sometimes it's just about getting something out and being super pragmatic. And also, I guess, you know, you should, if you've been there for a while, know your users pretty well and understand the problem pretty intrinsically without doing user research or usability testing on every single thing.
How would you have approached the communication differently there? What would you have done differently with Davey in that instance? Well, it was kind of building up to him, bypassing you.
Enzo:
I guess we should have had a chat about why he was trying to speed in that very specific situation. And I guess back then I was maybe a bit protective of, I was also, I just newly joined, I was kind of protective to be respected and stuff like that. Maybe I should have shown more vulnerability and be more open, and just assume good intent, right? Just assume that he wanted to do the best for the team because he's a great designer and he's always done some great job at Intercom. And maybe on his end, he should, I don't know, maybe on his end, he's a Dutch guy, he's a very direct guy, right? I'm a Latino, right? I'm a Southern Europe guy, you know? Maybe on his end, he should probably have had also one step toward me and understand that I'm a slightly more emotional person than him, you know?
Jack:
Nice. So aligning on kind of the project and what you wanted to do first and then your different approaches to solving it maybe would have helped.
Enzo:
100%.
.webp)
.webp)
