Build better products faster by learning the basics of product management with Enzo Avigo from Junedotso
Summary
If you want to know how to build better software products faster and haven’t learned product management or hired a product manager yet, this episode with Enzo Avigo is for you. We debunk some myths and give you an overview of how product management increases the speed and accuracy of the solutions you develop, and how to get started. We’ll also touch on why SCRUM might become outdated fairly soon. Intrigued? Give it a listen!
Episode
Victor: [00:09] Welcome to Product Stories, where we explore how founders build successful software products. This is a podcast about product management, development, remote work and anything else non-technical as well that technical founders need to know to launch and scale software products.
Today’s guest is Enzo Avigo. In his previous life, he was a product manager at N26, Zalando and Intercom.
Today, he’s the founder of Junedotso and he’s just completed Y-Combinator and raised the Seed round. He will share his expert knowledge of product management and how SAS founders can build better products faster by learning the basics of product management, and what the state of effective software development is? Hint, it’s not necessarily Scrum.
Enzo, welcome to the show.
Enzo: [00:50] Hey, Victor. Thanks so much for having me.
Victor: [00:53] Yes, it’s a pleasure. Why don’t you give people a little background on yourself and what you’ve been doing, your previous company and how you’ve gotten into product management?
Enzo: [01:05] Yes, so actually, it’s a funny story, something I heard like pretty many times that most of the people that get into product management were in that, like it came to it from very different paths and journeys. And that was my case.
So I came—I actually started my career in finance, in trading finance. And after, I think, a year and a half, I decided that I wanted to switch. And there are a couple of components that I wanted to keep; I wanted to keep the numbers in my job, in my day-to-day job and I wanted to keep the very fast-paced environment of the trading floor. But I wanted to merge that into an environment or an industry that I was more passionate about.
And so at the time, I was reading a lot about tech and you know, all this kind of like founders biography, and I thought, okay, and I want to move into tech, but I want to kind of apply this kind of like, things I was looking for, I was looking for back then.
And another thing I was also looking for is to kind of keep a very generalist role. I think there are literally two types of people; the people that like to be very experts on one thing and the people that want to be more versatile and I was the latter. I was the second one.
So I kind of like looked around me, what kind of jobs could do that in the tech world. And actually, I had a friend that told me about product management. I bought a couple of books, met a few other people that were doing this job, asked a few questions, and decided to take the leap of faith and started to do this job in a startup in Berlin, and that was almost seven years ago.
Victor: [02:45] That’s awesome. I think back then I even know the head of product of N26 back then. Possibly, he was a good friend of mine. I don’t know when exactly he was there. So that is super interesting, because for those who don’t know, you didn’t go too far from finance and N26 is the German unicorn challenger bank that’s very big locally in town. So it’s a very exciting place to work at.
But then you moved on to the other German unicorn, Zalando and then to Intercom. It’s also very interesting. Why leave the big unicorn, glaringly, you know, sparkling startup world?
Enzo: [03:30] Yes, I mean, that’s a different topic. I think the kind of the career in the past and the steps that you take to get somewhere, you know. I think what I do—the easiest way to picture that is, do you think you can outgrow like—there are literally two types of setups, either the people outgrow the company and they think they need to move on, to grow faster, or the company outgrows you, in which case, it’s very likely that you’re not going to get the responsibilities you want to get and they need to start recruiting outside for this kind of responsibilities.
And I think in my case, I was kind of like, believing that there was a bigger opportunity for me elsewhere. And N26 was growing very fast and it was very, very successful. But the number of jobs you would have in the product family back then, was fairly limited. So it kind of became, you know, kind of like an option. And then I kind of like, you know, coincidence happened and I met some recruiter who was offering like a very, very tempting offer. And I just assumed like, “You know what, I’m maybe going to lose a bit of stars on my resume, but at this point of my career, it doesn’t matter, I should probably optimize for my learnings.”
So that was the thing actually. Actually, all along my short career, I would say I was always optimizing for learnings, more than you know, prestige and so on, and I never really regretted that.
Victor: [05:02] That’s very interesting. I love that. And now you have then moved on to found June. What is June?
Enzo: [05:10] Yes, so funny enough, I kind of knew that I wanted to start a business when I started doing product management. And this is what I told you, when I said I wanted to become a generalist. I wanted to do many things, because I knew that later on, when I would start my own business, I would need a lot of different skills to make it happen.
The thing that I didn’t know is that actually, I was going to face some problems along my journey and that I would then start a company to basically fix or try to fix this problems, right?
So June is basically an answer, a solution to the main problems I’ve had when I was working for N26 and Zalando and Intercom, which is to basically an easy way to turn data into some insights. And then they will, of course, use this insight to make some ongoing decisions.
So June is simply like, kind of like a very lightweight, very easy to use product matrix for founders and early stage companies or non-technical people that wants to self-serve these many questions they have.
Victor: [06:15] That is very exciting. And one question that I have is because I know, we’ve talked before, that you’ve both went through Y-Combinator and raised funding. So there’s obviously—there’s two tracks, either you bootstrap, a lot of people are in the lifestyle business niche or you go the fundraising route, which also N26. Sorry, N26—with Y-Combinator is obviously also a path that you take when you want to do that. How did you make that decision quickly?
Enzo: [06:50] Yes, that’s a good one. I think it depends—at the end of the day, it depends a lot on the type of business you want to build. I think it depends also a little bit on the space, you know, what are the competitors? What are the players out there?
In our case, I think my co-founder and I, we were quite aligned that we wanted to build a worldwide business and we were also quite aligned that it was a fairly competitive space.
And so in our opinion, the best way to compete in such environments was to raise money to accelerate, hence the seed round, and hence, the reason why you were a VC back company. This doesn’t mean that we don’t fight for our ownership, right, you can be the VC-backed and you can still own a decent portion of your company. It depends how much you want to raise and what kind of valuation you can kind of aim for, right?
So we kind of really respect the people who are going the other path of, you know, being like, self-funded. We just think it’s a very different journey. It probably takes a little bit more time and it probably the growth is like a little bit more steady. And sometimes slower, not necessarily. So we decided to take this path.
Victor: [08:06] Awesome.
Enzo: [08:06] I think what we’ve seen, is also something we’ve seen and we’ve experienced in all the companies we work for. So maybe there is a bit of a reproduction schema in this.
Victor: [08:16] Absolutely. But now let’s dive into product management. For those who don’t know, because we have a lot of listeners who are very non-technical founders, who’ve kind of fallen into building a SAS from the industry that they’ve been working in and are very new to this entire process. What is product management?
Enzo: [08:39] Good one. So there are many, many definitions. I think the easiest one I can think of is a cross-functional position to where you’re basically—it’s a role. Usually, it’s a role that can be also, like just some kind of science or art, whatever you call it. And it’s usually a place where you are the crossing of many, many jobs in your company, including development, design and business, that’s the traditional way of picturing it. And what ultimately you’re doing is you’re the voice of the users. So you’re supposed to represent the voice of the users for all these disciplines.
And ultimately, what you’re meant to do is to solve the most urgent problems for these users. Of course, the problems which are in line with what your company is doing. I think that’s the easiest way to picture it, and there are many, many other ways to put that together. But I think if you always remember these things, which is that you’re kind of like—you’re not manager as such, but you’re someone who gathers people around the table to make decisions in the interest of the users, I think you should probably do a good job.
Victor: [09:55] Awesome. And so, as an example, in a bigger company like the ones you used to work at, of course, there’s a product manager for even bigger feature sets, you have an entire product team, not the product manager. So what would be the day-to-day within a big company that you were doing?
Enzo: Yes, no, it’s a good question. So it depends a lot on the company, of course. I can speak for where I’ve been. And this being said, there are also some trends right now in the market, right? So there are many, many companies that start to, you know, structure this role in a similar way.
So like, if you’re like in a software company, and that company has kind of adopted, you know, the Agile workflows, which is the big dogma for the last 20 years, then most likely, your job as a PM will look into a lot of—it will break down into a lot of rituals during the week, where you’re either in the driver’s seat or just in the collaborator seats, where you’re going to be expected to drive things that are on the roadmap, where you’re expecting to translate the eye level strategy of the company into some items that, you know, development teams memberships.
Ultimately, you’re also expected to be the head around the data, you’re expected to like, either collect the data yourself or be the intermediary with like, whatever data department there is to actually justify whatever prioritization or decisions you want to make. You also are going to be some kind of like sparring partner for the designers. So that you make sure that they understand the—to make sure that the designers understand precisely what needs to be done. But it’s kind of the main problem that needs to be tackled.
And most of the time, the PM is also responsible of the timeline, making sure that whenever a project goes into development, design and production, it doesn’t explode that. So you’re kind of like the gatekeeper for the timeline. So what that means is that you have like tons of meetings all around the week, where you need to gather all these people I just mentioned, and you need to make sure that everything moved through some kind of like big funnel of processes, where you’re either sometimes the driver or again, just the attendee. Again, I think something which is really interesting about the title of Product Manager, is that you never really manage, you’re not a manager as such, you’re like more kind of a leader, if anything in a team.
Victor: [12:33] What about that prioritization in things like that? So, in the end, what the product manager does is based on the entire input, right? From stakeholders and users, helps everybody or makes them himself, decisions to build a better product faster? Is that what it is?
Enzo: [12:58] Yes, totally. Yes, that’s a good summary.
Victor: [13:03] And how does a product manager make decisions? What does a product manager take into account? How does he gather user feedback and things like that?
Enzo: [13:17] Yes, I think definitely, there are three main pillars into the—three main inputs or category of inputs for product teams and product manager to make decisions. One of which is definitely customer feedback. It’s the one that you can never trade off, like, there is no way you build a successful company without listening to your customers.
At the same time, the nature of the feedback you’re going to get from customers is pretty narrow, people are going to usually comment on things you’ve always already like shipped. They’re going to give you some comments on a feature you pushed or they’re going to give you a comment on a new product you could be launching, which is in the realm of the same, you know, kind of space that you’re building in, right? So you want to rely on this feedback a lot. But also there are some limits.
The second source of input is traditionally data. There are things that people will not tell you or about things that people are not aware, they’re thinking, and this is where you need to observe people’s behavior to understand kind of like, what are they trying to do ultimately, without telling you. It also works at scale, right? Like asking 10,000 users if you have 10,000 users, what they think about something is not doable, right? Data is scalable, whether it’s like analytics or surveys, whatever, you can scale the volume of input that you get. So that’s usually the second pillar.
The third pillar is traditionally the strategy. You usually have a vision or strategy as a company or your team or your group has a strategy. And this is really, really important because intimately, the users is not always right. There is this very famous quote from Ford, “If you ask people what they want, they will tell you more horses.” That’s the same with strategy, right? You just want to, you know where you want to drive or commit to your company, what’s kind of division. And if you have something that you think is like a great achievement for the division, but no one has asked for it, maybe it’s a good idea, right?
So these are the traditional pillars and there are many, many more, but I think it’s a good start.
Victor: [15:18] I recently read this somewhere on LinkedIn or Facebook, I really unfortunately, don’t remember who said it. So I can’t quote that person directly. But this entire quote from Ford, “If I were to ask people and listen to them, they would say they want faster horses.” it says that a product manager should ask that question because when people say they want faster horses, you go one level above and you try to understand the problem that’s behind why are people saying they want faster horses? And then if you do that on the meta layer, then you might actually get to, “Aha! We could build a car that solves their problem way better.”
Enzo: [16:06] Exactly. That’s a good one. That’s a very good one. Actually, it’s, I think, it’s called Thinking in First Principles. That’s how Elon Musk things. That’s Peter Teal’s [Inaudible] methodologies. And it’s actually one of the very, very strong methodologies that Intercom, the latest company I worked for, is using. Like, every time you have a question or a problem, they urge you to think into first principle or they urge you to think the root of the problem. And so yes, it’s something we can talk about, maybe later on, but methodologies around how to frame problems and you know, your development cycles. I think this has a lot to do with how you ask the questions and what kind of source of input you’re using. So it’s extremely relevant, I think.
Victor: [17:00] Oh, yes, absolutely. How does that—at what point? Because I assume there should be a set process. Like, at what point are you asking questions? At what point, are you asking questions? At what stages does that ideation or well, coming up with the right roadmap items and then getting towards actually implementation? How is that moving? And maybe how does that differ from a small early stage company?
Enzo: [17:28] Yes. So let me start with the first question, which is, when do you talk to your users or when do you ask questions? I think this is the only process that you do all along the way of the process, the product development process. Like whether you’re like in discovery phase, you can ask a lot of questions, right? But you ask them in a very specific way, which is extremely broad and you don’t want people to be biased. Or when it’s like the later phase where you want to narrow a problem, you may just ask a survey, like out of the three problems here, which one is the top one for you? You just want to narrow, you know, a top priority.
And then when you go in the scoping phase, where you want to understand precisely which features should be part of your solution or which pieces should be part of your solution, you also may do some kind of [Inaudible] design and put that into the end of the users, right? And then when you when you live with the solution or just before you go live, you may also put that solution, final solution into the hands of the users to do more some kind of usability testing and you ask them, whether they really understand the thing that you’ve crafted for them.
And then when it’s live, you can also do some satisfaction, like, “Okay, now that it’s live, you told us you wanted it like that. Are you actually happy with this thing that you’re using on an ongoing basis?” And so actually talking to your customers is that one thing that you do all along the path. That’s probably the only one that you do all along the way?
And, yes, and to answer the second question, which is, what’s the difference between a later stage company and an early stage?
In theory, the more latest that you are, the more resources you have and the better you should do these discussions all along the way. So in theory, you should be talking to customers all the time if you’re large. If you’re small then, well, you’re going to do it, but you’re probably not going to be able to do usability testing every single time you ship a new feature, right? So it’s your call as an early stage startup to decide which conversation you want to prioritize.
Victor: [19:30] Wait, you probably run a lot more on assumptions, right? You don’t have that many customers, you probably don’t have that many leads even or contacts. You can’t ask about a lot of features, so you’re more writing these assumptions. So would you say the vision is just way stronger in an early stage company or way more important?
Enzo: [19:50] I think it’s always important, but I think you’re right. I think trusting your gut feeling when you get started is a must have. Like, if you just expect your two users to be constantly giving you feedback and write about your product, when you get started, I think it’s wrong. And also, I think it takes a lot of time to take off the ground a product, which is appealing or exciting enough in the first month or even sometime the first years. But if you exclusively rely on people, yes, I think it’s less likely that they will tell you how to build something fancy, right?
This is why when you get started, there’s so many people saying like, you should solve one of your problem. Because actually, if you solve one of your problems, it’s not that—it’s kind of like you will be at you should be able to listen to yourself every time you have questions, since you’re one of the users. So it’s going to save you some time on running interviews, you can just look at yourself in the mirror and ask yourself
Victor: [20:50] Mm-hmm. 100%. Now, let’s move on a bit on to software development itself. And obviously, in smaller companies, the product manager is also used as the Scrum master, as the project manager, as a lot of other things. But I think it’s a vital part of that discussion, especially since we were speaking about methodologies in general. We touched on Scrum already. And we already mentioned kind of in the intro, that Scrum isn’t necessarily the best for everyone. There’s better ways we found out over the past years.
What’s your favorite? What do you like here? And why? And when?
Enzo: [21:45] Yes, we touched on this one also, just before we started the call, but I think this one is interesting. I think in my opinion, I think people are always looking for x, they’re always looking for shortcuts, right? It’s just in the human nature, we’re lazy, we’re always trying to find something easier to do.
And I think what happened with Scrum is just like, we came up with one methodology that kind of worked out for a lot of people. And we went very deep on this on like, many, many ways on how to run it many, many different ways on how to do planning points, T-Shirt sizing, many, many ways to distribute the roles, whether it’s the PM or proper Scrum Master.
Like, we went very, very far, I think, and I think it worked. And there are many companies for which it worked. And so it’s pretty cool. But my feeling is that when you blindly follow some rules like that, you tend to forget a little bit the first principles, which is why was Scrum put in place in the first place, right? And in the first place, it was put into place so that there was going to be an efficient way of building things, ultimately, for people so that they can solve some problems. And I think Scrum is probably the best way we had so far. But my feeling is that we will refer to https://www.scrum.org/Scrum like, you know, we are referring to waterfall today, in a couple of years.
I think Scrum it will be outdated sometime soon.
Victor: [23:17] Yes.
Enzo: [23:17] I definitely think less than 10 years, I don’t think Scrum will stick around for too long. So yes, so that’s my thinking. Agile seems to be quite sticky though. Agile is a very variable dogma. If you look at the Agile Manifesto online, it literally says like, I think it has 10 bullet points, something like that. And it’s funny how people can read and interpret these points over time. I think that’s quite thoughtful, that may stick around a little bit.
?Victor: [23:49] So going back to the roots a little bit because Scrum was supposed to kind of follow agile and be agile. But what other trends have you seen emerge
Enzo: [24:03] So the one thing that I was really surprised was—so N26 and Zalando were fully Scrum, like, classic playbook, you know, planning poker, velocity stuff, estimated everything
One thing that I’ve seen a lot is they seem to be like—a lot of like the new school of product where people are moving away from the estimation, it seems that estimation is the beginning of a lot of problems because if you want us to make things then you have to create some culture around estimating things. And then if things are not properly estimated, it put some extra pressure or you miss some targets then you need to report or catch up yet, etc, etc
So I’ve seen that—what Intercom started to do. I mean, they’ve always been like that. And obviously Basecamp is one of these precursors in this domain is stuck doing estimation. That doesn’t work, you’re never going to be right. And instead try to kind of give yourself some timeframe where you think you can push a significant piece of value for the users
So Basecamp does the six week cycles, which is also adapted by Intercom. And I think there will be more and more companies following this path. I’m not sure if the six week cycle is the best format necessarily, but what Basecamp is saying is that six weeks is like not too long, not too short, just enough so that you can anticipate and plan some projects you want to push. And you’re kind of like, pretty sure that within this month and a half, you’re going to be able to fit a minimal version of, you know, quite ambitious project you have
And so then kind of like estimation doesn’t really matter. Because you know, that in six weeks, you can make magic happen, right? And this kind of like, it’s still very short, you know, deadline, which means that you still have to scope things out a lot if you want to make them work, but it’s not like, too strict.
So that’s one thing really, really important. I’ve seen a lot of discussion around estimation. And I think there may be other stuff, but I would just pretty pause on this one and ask you, like, any ration, what you think about this one
Victor: [26:25] Oh, 100%. Yeah, the Basecamp one is called Shape Up. Right? And so I’m doing six weeks cycles. I’m supposed to push something of value during this these six weeks
When I think about the scrum sprint, the idea of the two weeks was always I should be pushing something of value during these two weeks. That was also the mantra. So within the six weeks, what do I do differently than let’s say during a two week Scrum sprint? How does my thinking differ, my actions
Enzo: [27:03] Yeah, it’s kind of like the reality if you work with one week sprints or two week Sprint’s is probably that you’re not going to be able to push what you can push in six weeks, right
So the only difference is, do you set a goal on a weekly or like, bi-weekly basis? Or do you set a goal and kind of like some targets, and yeah, some things you want to push overall, with a six weeks timeline? And so what it does is just it tells you like, I’m not going to set like, one fraction of the feature as my goal. But rather, I’m going to set the full feature as my goal, right, in six weeks
And what that means is that, as soon as you know that you have six weeks to make it happen, you’re going to be a lot more smart about how you can rearrange this work within the six weeks to make it the more efficient
So like the one and two week cycle is like, “We have six weeks, let’s get with the most every piece. And let’s go through as fast as we can. Because next week, we have the second piece we need to start, so we need to finish the first piece on time
Six weeks is like we have six weeks, we have like five engineers, this is like, you know, 50 days of engineering time, how do we assemble the piece to get this thing out? And can we actually make less than six weeks? Like we said six weeks, but actually, maybe we can do four like, is there a way to cut this down? And so you start to think in a very rich way and usually you find much better submissions. That’s my experience at least. And you also put less pressure on people to just achieve, you know, which kind of targets
Victor: [28:46] Yeah, I guess the key is not to think problems, solutions, tickets. “Oh, how many of those fit into a sprint,” as it is with with Scrum, but problem; six weeks, how can I solve that? The feature kind of is the end product of this thinking. I mean, within Basecamp Shape Up, you’re even divided into phases, right? Where you have the shaping up phase first, you say, “Hey, here’s just my problem definition, guys, what can we do
And then you only have the implementation phase, at which point you already know, what can we even do in these four or five weeks that are left? So that definitely is a very fascinating mindset shift. But it just makes sense
Enzo: [29:36] It just makes so much sense. Like, I’ll give you an example. When I started at Intercom, we had this beautiful roadmap for one quarter so we plan to week—two cycles. And I had this like three items on my roadmap for the next cycle, they were prioritized aligned with my you know, head of product and so on. And we were like, “Okay, let’s do them. Like, that’s clear. We should do them
And one of them, which was initially estimated in my roadmap for two weeks, turned out to be a one day task. So there was this one thing, I thought we could do a solution in the product and someone came up with a video and say, “Oh, can’t we just add ask customer success to do a video, and we put the video here and people can take the video,” and you know, it solved the problem, like, you know, it’s just solved the problem. And we ended up doing that.
And that was kind of like really troublesome for me at the time, because I didn’t plan enough items in the roadmap to move forward, you know, to move to another one. But actually what happened that day and the team knew it, but I didn’t know it was that we had used our resources as a company in a much more efficient way. And we would have progressed much faster along our roadmap, and that was the best decision to do
So yeah, thinking first principle, leaving some doors open to, you know, what’s the best way to solve the problem? And what’s the timeline to solve the problem is usually quite powerful, surprisingly powerful
Victor: [31:04] 100%. How big is your team at June right now
Enzo: [31:10] So we are a team of three right now
Victor: [31:12] Nice
Enzo: [31:14] We’re still a baby company. And we are doubling that count in the coming three months
Victor: [31:20] Awesome. That’s very good. How does your software development process look like? Within this small early stage company, how do you run your product team at that stage
Enzo: [31:35] It’s so interesting, because I was—it’s very interesting now that we have had this conversation about how others do and how we do it. I think one of the thing we’ve had [Inaudible], my co founder and I, when we started was we also wanted to build a very opinionated approach to product development, because we’re really passionate about this space. And so we thought, “Okay, how can we do it differently
I think the one thing that we do pretty aligned with Intercom is the six weeks cycle, together with a work weekly planning. It’s not because you have a six week cycle that you don’t reflect every week, whether you’re on track and where you’re going next week, right
So this this we’ve completely kept it. We’ve also adapted OKRs, which is very common in large companies. I think the main difference for us is that with maps or OKRs at a cycle frequence. So we have cycle OKRs, and we only have one because in the startup, if you start to have like 10 OKRs, you just lose track of what you should be going after
So that’s kind of like the eye-level metrics and kind of the goals. And then when it comes into product development, I think we’re extremely lean, we tend to remove a lot of tools if we can
So we are doing really quick spec, product spec, usually in the Notion Doc or in a Google Doc. And then we open to many, many conversation from the team. So we tend to challenge the assumption and what we’re going after
The prioritization is usually done asynchronously. We tend to talk about, like lots of problems, we have very shared understanding about what other customers problems because we have like lots of channels in Slack where they share feedback with us. And so kind of like, we tend to skip a little bit the prioritization exercise, just because customers are so noisy with us and so loud with us that people tend to know exactly what is the next priority
So usually, it’s not like what should we do next. And we are not really convinced it’s like, “Okay, there are like three urgent things, which one is the most urgent?” So we do this prioritization exercise on the fly and asynchronously during the planning exercise
Then what happens is we do a very short design exploration, usually less than a week for any things we want to push. I tend to align on the spec with our designers. And then our designer will share again, in Slack all the expressions that he has done. This is something that actually Intercom was doing really well, which was that every time you do an exploration at Intercom, a design expression, you share it with the entire company and the entire company can comment on your design, even if they’re not in your team, even if they’re not perfect people, like a salesperson that is new, can comment on the design of a very senior product designer within the company and this is amazing because as soon as you open for feedback, you get very very rich feedbacks and very rich ideas. You also [Inaudible] sometimes into [Inaudible]
So we kept that, we just love it. So the designer will share it on Slack and we have actual emojis and we can vote with emojis on our favorite design. Either like three option, we can just vote with the emojis, so without open endless debates like you know, if there is more emojis on one version, we just go for it. And of course, we can open thread on Slack if you have any comments
And then when this is done, it goes into a scoping decision, which is usually driven by the engineers.
Victor: [35:19] That is very interesting. My first reaction when I heard you say, this was like, “Why would you do that?” You know, too many cooks, you know, everybody has an opinion on design and they’re likely unqualified, but then again, you sometimes use applications and you wonder, you know, this is so stupid, how could they make this UX mistake? Like, I don’t know what this is about
And that happens because someone was looking at a very isolated feature, was applying their best knowledge to it, but just they had no idea about the context that a user would be in coming directly from signup, for example, or just not thinking about it. And here, somebody can really, from various perspectives, get feedback. So I really like that
Enzo: [36:06] It’s really nice. It’s really nice. It’s one of the really cool thing that’s Intercom was doing. I love it
Victor: [36:10] That’s awesome. And now, for just a few minutes, because we’re we’re slowly running out of time, because it’s such an interesting conversation, but are you guys remote first
Enzo: [36:26] Yes, we are. We are. It was the first time we kind of like, when did your full remote setup, we used to be working in companies with our office. Of course, with the COVID crisis, we moved to a remote setup. But it was kind of a remote-friendly setup, right? Until like, you know, the world would go back to normal
With June, we’ve decided to embrace the remote first setup. And I think what we’ve found out is that you need to be extremely—you need to invest a lot in your process, because, you know, you need to, like, human nature needs some kind of like personal bonds and so on. And it’s easy to feel disconnected from people when you don’t see them every week, right? So, we are trying to invest a lot into that
The other thing is, we are looking into some retreat format in the coming weeks. So that basically, you know, the team has like, an opportunity to meet in-person. I think over time, the most inspiring company, in my opinion, right now regarding remote is, is Dropbox, they have something they call the studios, which is basically that they have places around the world where people can gather on a voluntary basis
So let’s say you’re in New York, you work from home and you really, really want to see your colleagues from Dropbox. Then once a week, Dropbox has this amazing studio that they rent and you can go there and there is like, you know—it’s not compulsory, you can just go there if you miss your personal connections. And I like it, I think this kind of hybrid model where you can be remote when you want or you can meet people in-person when you actually want on a voluntary basis. I think that’s really, really strong
So as we scale, most likely, this is the format we’re going to lean for
Victor: [38:18] I love it. That makes a lot of sense, actually. Now, to wrap this up, if people want to learn more about product management, the thinking behind the mindset, the methodologies. What should they learn first? And do you have any resources on hand that would help
Enzo: [38:40] Yeah, so I think I started with Intercom to be frank. So I would say going with the first ebook, that Intercom published on product management, which is called Intercom on Product Management, I think that’s really really good basis. I think it’s really approachable. It’s really short, very digestible and it’s good basics, because it’s like first principle. So I would really, really advocate to do that. And it was written by the founders of Intercom who are amazing people. So this is kind of my Bible update to start then
Then there are many books which are great. I think one of them—one of which I really loved was called Product Leadership by Mr. Erickson—forgot his name. The dude who created, you know, Product Management—Product Management Conference. I also forgot the name of this one. The most famous one on—its not product, it’s called—Yeah, it’s extremely famous. It’s extremely famous
So basically, this book is really important. Product leadership is really important to read early on, to understand that your role as a product manager is not to manage. And this is one of the first thing you need to understand. And this is one of the most classic mistakes you do when you get started, which is you try—you think you’re the like mini-CEO of the company, and usually, it doesn’t work really, really well. So that one is really important
They are, I think, what Basecamp did is amazing. I think Shepherd is a good book and I think it’s the best they’ve written. Actually, they wrote a few ones before that. And they wrote one very early on called Getting Real. Getting Real is, I think magnificent adaptation of the Agile Manifesto, into building software, it’s quite old. But it’s extremely relevant. And honestly, I don’t think they they’ve written any better book since Getting Real
And then if you—I think one less book, I would recommend, if for any reason, you’re joining a company with very strict with Agile and Scrum, and you need to catch up with these things really quickly, then there is a handbook called Agile Product Management with Scrum. It’s written by our friend, Roman Pichler. And it’s just like a very good summary of what is a backlog? What is a sprint? How you do all this stuff when you have no clue how they work. And it’s kind of like a cheat sheet like, you can read that and two weeks, you’re up to speed with the way that many, many companies work out there
Victor: [41:33] That’s very helpful. And one last question. A lot of people, a lot of CEOs of growing software companies, they decide that they don’t want to learn it themselves. They also don’t have the time to do that. The more folks have been fundraising, sales marketing, strategy and they want to hire a product manager, but without really knowing or without being a product manager
What are the biggest mistakes? Or what should somebody watch out for when hiring a product manager? Because I’ve seen myself, we sometimes recruit product managers for our clients. Unlike developers, there’s a lot of applicants. The problem is you need to understand who’s the right fit
Enzo: [42:24] It’s a hard one, because I think in our situation, since I’m like a founder with a product management background, we will probably delay this recruitment, just because we have these skills in-house
Victor: [42:38] Of coursse
Enzo: [42:39] So for me, this question is especially hard, how do you recruit the first PM is hard. But when you have already some of these skills in-house, it’s especially hard because you need to justify that
I think I can just reflect on my first experience. So maybe your friend actually was head of product [Inaudible] is actually the person who recruited me. And so reflecting on that on why I was given a shot. So I didn’t start as a PM, I started as an Associate PM, right? Or something like that. But nevertheless, you need to be given a chance at some point, right
I think for me, I think what they were looking for is someone with a strong enough background in one of the three input [Inaudible]. So strategy, data, or customers, like being able to talk to the users. Either you have some kind of background in research a little bit or you’ve done some surveys, you know how this work, maybe you have a bit of a design or research background or a bit of marketing background and you really are passionate about tech. You may be a very strong person to run the digital [Inaudible] reviews and be very customer-centric. Or in my case, I was kind of like pretty good with data. And so they were kind of confident that I could you know, justify probably some of the decisions or the ideas that I had with data
And actually, I’m going to drop the last one, which is strategy. I think when you’re an early stage recruit team person in a large—in a company, I don’t think people care too much about your vision or your strategy. I think it’s way too early for you. So yeah, we don’t recruit. I wouldn’t say like, being a visionary or very, very strong service skills is important for an early stage recruitment, an earlier recruitment in a startup. It’s a very hard role to recruit for. I don’t know how they do it
Victor: [44:31] And that’s super interesting, because it shows precisely what the thinking out there is because one thing that you did not mention, rightfully so is being able to write technical documentation and managed developers and run sprints, which is what actually most founders want when they’re looking for a product manager and funnily enough, what most applicants pitch when they apply for a product management role
Which is very funny because you you are looking for, in theory, you know, you need someone to help make better product decisions. But in the end, it boils down to hiring a project manager, which is a mistake somewhat
Well, thank you so much for joining us today. How can we learn more about June and learn more about you
Enzo: [45:35] Thanks for having me, Victor. I really, really appreciate the time and the conversation was good fun
The best place to learn about me is probably Twitter. I try to be quite active. So you just take my first name, Enzo, E-N-Z-O and you put it in the other way around. So it’s like 0ZNE, and you replace the O with a zero. Because—
Victor: [45:56] We’re definitely going to write that out in the show notes
Enzo: [45:58] The other one was taken. That’s the best way to learn from me. And actually, yeah, if you follow me on Twitter, you’re going to see the journey of June. So yeah, you can just follow my [Inaudible] or my Twitter, whatever. Or if you want to have a look without following me, which is totally fine, the website is https://june.so/. So it’s, yeah, analytics, good analytics for startups
Victor: [46:22] Amazing. Thank you so much. It was a pleasure to have you
Enzo: [46:27] Thanks, Victor. We’ll talk soon
