Hello and welcome into another episode of Lessons in Product Management. On today's episode, I sat down with Paul Lono, Head of Technology and Innovation at XU Sustainable based in Berlin, Germany. Paul has been on the technology and engineering side as well as a product manager and leader as a founder and CEO of software startups. So Paul has great perspective on what it takes to collaborate well and work effectively with software engineers. On this episode, we talk about Paul's background.
in product engineering, the role of AI in learning platforms and what they're working on at XU Sustainable, how product managers can work better with engineers, how much technical knowledge should a PM have, PM anti-patterns and what drives engineers crazy. how to better manage your workload as a PM, and how you can better earn engineer's trust. I hope you enjoy it.
Hey Paul, welcome to the podcast. I'm very happy to be here. Thank you for the invitation, John. Yeah, absolutely. It was super fun to be on the podcast with you for Product & Cake and excited to now have you on Lessons in Product Management. Yeah, that is a very good one. So if you want to hear a little bit more about John's history, then make sure to tune in into the product and cake episode with him.
Absolutely. Go subscribe to that podcast as well. Leave it a good rating and review and let's all grow the community together, right? Yes, we can only learn and grow together. That's the beauty of our job. For sure. So Paul, for the listener who's hearing from you for the first time, maybe not a subscriber of Product and Cake just yet, tell the listener about yourself, a little bit about your background and what you've been up to lately. There's a lot of cool stuff that you're doing.
Yeah, definitely. So I'm looking back to 20 years in the product tech scene now. So I am located here in Berlin, Germany, and as a lot of startups are here, I somehow discovered how to develop websites back in the day. Yeah, and turned out a lot of people were in need of websites. So I founded an agency and we built all technical stuff for bigger companies. And we grew that to around 30 people. And we were like the tech people who come and do the stuff nobody understands.
Yeah, and that is still something that draws a line through my CV. So after 10 years of doing jobs for others, I was really missing this shared vision. So the idea we all have in common and we know why we are here and working all day and this one bigger thing. So I stepped out of the agency business and I founded my first product startup called Nepos, where we tried to build a computer, a tablet computer for elderly.
so basically we wanted to enable our parents and grandparents to also benefit from all the tech So we build our own... tablet computer based on open source components. We build our own infrastructure and operating system and communication in between all of that based on open source to really control and design the best user experience possible. And then unfortunately, we run into the issue of not having enough money to build the first 5,000 devices.
and that was very hard but we learned a lot so for me personally i switched over to the big corporate world and worked two years at ebay and built innovation teams there that was very insightful to see how the big corporates are doing and i really clearly discovered that stay moving very very slow and you need to be very very good in politics
So I stepped out and went back to the startup world where I am leading currently the product and tech team at XU Group. And we are building education platform for B2B customers. So that's super interesting. And your current title is Head of Innovation and Technology. What does that span? Does that encompass all of product and engineering? I guess, what's your focus there?
Yeah, and so my day-to-day job is leading the tech team to build this learning platform, right? So the requirements are pretty clear in the broader scope and the details. It becomes very... challenging obviously but in addition I'm always driven by technical innovation and by pushing the boundaries and make technology work for us so I'm super happy that I can always spend some time on innovative things and
try to think outside the box okay how can we apply new technology into our day-to-day business but also to improve our learning experience and obviously nowadays with ai everybody is telling us okay we will learn from ai agents in the future and nobody needs any platform anymore I doubt it, but nevertheless, we need to find a way on how to incorporate AI and also AI itself is one of the biggest learning content on our platform. So yeah, that flows all together.
I agree. And as somebody who has their own learning platform with path to product, I hope that's not the case. But I agree where integrating AI into the platform is absolutely necessary, whether it's augmenting or supplementing the learning. But to have it completely take over learning, I think that's
Just like saying that it can completely take over product management. I don't see that happening anytime soon. You know, one funny thing I'm always discovering is that people... from all profession Yeah, AI will take everything over beside my job. My job, you really need to be super smart and there's this edge you, hey, I will never do. But all other jobs, yeah, I did. I just wrote a product spec on open on JetGPT. That was super easy.
And this profession and this mastery of one specific topic, and therefore it needs... It needs humans that make use of AI. I agree. I think the future of AI isn't taking over any one thing necessarily. It may consolidate some... some things that are closely related or adjacent, but I think it's more of an efficiency tool than a replacement altogether. So I think we see that kind of similarly.
Awesome. So in your position, you've worked across engineering, you've been in engineering leadership, you've been in product management. And so one of the things I wanted to talk to you about is kind of that relationship between product managers and engineers. And in your experience, having lived on both sides of the coin, what are some of the things that product managers should keep in mind when working with their engineering counterpart? Yeah, that is an excellent topic that really drives me.
I really try to avoid the sentence we have in our podcasts much too often saying it depends because Yeah, every team is different, right? But there are some things that are similar. And for me...
The most important thing for a product manager is to create psychological safety, right? We are all most likely all read the studies from Google who... investigated what excellent teams the first good teams and it was a safe space where everybody is free to commit failure, to ask questions and to depend on other teammates. So working through that pyramid is super important and think about how can you be the one person everybody is.
motivated and interested in going to and will find a sparing partner. Similar to my AI story, I think a product person, whatever role, title you have, that tries to solve your problem. is not the very best, right? Because you want to have someone where you can say, I have this and that. problem or challenge and then you get a dedicated knowledgeable answer that brings you on new ideas because
Yeah, you want to be the best in your profession, right? And you learned so much and you did so much and you know very well the technical setup. You don't want to have someone jumping in from the side and say, oh, I think I just put it in ChatGPT and now I know how to write an architecture and look, you should have these and that module connectors, then it should be easy. No, no, explain me the why and the bigger picture and give me the room where I can ask more questions.
Yeah, I love that. I was going to go in that direction of asking what psychological safety means because everyone's different. Have you seen the definition of psychological safety differ based on the personality or the mindset of the engineer that you're working with? That is a good question because in the end everybody is slightly different and as product people.
need to understand that and to talk to them and find the right words and give the right responses and room for people, it will be slightly different from every person. But having the basics like dependability.
the ground layer so you know you work with great people the people know what they are doing they are reliable they do what they say they don't have any any hidden side agendas um that is very common i mean how you how you do that in the team how you facilitate that that is maybe different but creating that need of okay we can relay on each other i think that is that is always the same requirement.
I think that makes sense. And you said something that deeply resonated with me and in my experience, and that's always being clear about the why. Why are we trying to do this? What are we trying to solve and why? And then giving the team space to figure out how we do that. I've also wondered too, and I think a lot of PMs wonder,
how technically competent do I need to be? And I'm curious if that plays into the psychological safety for engineers to know that they have a competent product manager, not just on the business and UX side, but... Can they understand enough of what I'm saying to make suitable trade-offs in terms of scope or complexity and how that... how that might intertwine or contradict the business or customer requirements. That is a thin line, I would say.
I met a lot of product people who said, hey, I took a coding class and now just give me access to your GitHub repo and then I... I will find out what to do and today it is even more possible, right? Because you can throw it into cursor and then it will do more or less.
a lot of things but I think the real benefit you as a product person can do is finding the structure your team wants to work right and that also connects to what you said like how do you give the room to people especially in this remote world and
I saw it also a lot of times. They said, yeah, I give you room. Just come back when you are ready. Then they get some requirements from the outside and then suddenly they stand on your doorstep and say, hey, you need to hurry up. Our deadline is suddenly appearing. And that is not really the room. And that is also far away from structure.
But what you as a product manager can do is building that structure, talk to the people, find out how they want to work. And I think that is a very valuable question that is not asked so often, especially in smaller teams.
writer work writer how to work with me manual and creating the structure and take time to think about and then you can you you need to find out what technical knowledge you have and how much is it benefiting to that structure and that is also very very different but one thing in common be the one who is the first one at the day clicking on the product, on the production system, on the QX system or QA system and so on and so forth.
and know what is going on. Nothing worse than a product manager who pretends to add the coding skills and then never clicks. are never locked in. And we as engineers, we see it very clearly everywhere, right? What is happening on the platform? No, for sure. And I've actually gotten that feedback too, where engineering counterparts
When I just started a new job, they're like, how are you the PM and you don't know the product? And I'm like, I've been here for like two weeks. But like the expectation to your point is that the product manager deeply understands the product. So I think that should definitely be top of mind for.
Product managers, you know, onboarding is, you know, deeply understand the product, the customers and the business, but to be an effective partner as early as possible, truly understand the product as much as you can. And I have to say, and I am also suffering from it, it is so easy to lose your product. in your day to day work, right? Because you are so into it and you know every aspect.
but it is already two weeks ago that you locked in the last time because there's so much things to do on the site and that is an issue i would say Maybe even in the whole company, you should use your product. Everybody in the company should know how it looks like. And you as a product manager, you can really do something about it. And the first one is use it yourself.
Yep, completely agree. So we've covered a couple of things that you should and shouldn't do. I'm curious because I like learning from other people's failures. Are there anti-patterns that you've seen from product managers? of things that they've done that have like driven engineers nuts and things that the listeners should probably avoid. Yeah, I think one major thing is being stressed and overworked.
i saw a lot of product managers who runs around who have a schedule from eight to nine in the evening they are sitting late at night and you see in the ticket system new ticket created close to midnight That puts a lot of pressure to everyone in the engineering team. Worst thing is the engineers are also pressured from that behavior and that way of working.
Or they disconnect completely and they say, oh my gosh, this product function is totally crazy. I don't want to change anything. I do my stuff and I don't care much. So it is so important to be that person you want to work with. create a room where people have time and mental capacity to really dive deep into the tasks, because this is what we need to do.
Again, even more with AI, when we can have prototypes in just a minute, we need to tackle the hard things, right? And the complicated stuff. And therefore it needs mental space. So it's not just creating the clarity of what needs to get done and why, but also creating the culture. that gives space to do deep work versus feeling like you have to, you know, run around all the time and always have like be busy, right?
Yeah, and there's this false conception in a lot of people to say, if my schedule is completely booked, I am important and I am doing hard work because I have no break. But then you give bad answers and you give stress. You write stressed messages in between and the engineer can't understand and is maybe too shy to ask because you look so busy. And this is not helping.
Yeah, I've seen that before when I worked in one particular job where that was my schedule. The cost of coordination was so high across so many parts of the organization where I felt like that's all I had time for. My answers were short. They weren't very well thought through.
And I felt like I was doing a disservice to my engineering counterparts because I... I was hardly ever around for them to talk about trade-offs and where maybe the acceptance criteria wasn't very clear or there were some pieces that I didn't understand that we needed to talk through. And it created delays because the team didn't want to move forward with a certain direction because they weren't confident and they wanted my opinion on it.
And so, yeah, I agree with you. Like you have to be able to carve out space for your team and not get so caught up in the whirlwind of the day to day. Yeah, there's one interesting concept or exercise you can do that is splitting your tasks into offense tasks and defense tasks.
are all the stuff where you are responding, where you get the ball and you throw it immediately away again, right? Answering chat messages as you described, all the nitty-gritty stuff, and it is so easy to fill your full day with it. that are really the brain work that puts your team forward, that change significant things in the structure, for example.
or creates a new roadmap or product vision or engineering strategy, whatever. But that is something where others can relay on and that pushes your team forward. And if you find yourself only in the defense, Then there's an issue, even though you are super busy and maybe it feels great. I don't want to. I did it the same in a lot of projects because it's great. It's fast. A lot of things happen. But the deep. Important product work may suffer.
I love that, the offense versus defensive work that needs to get done. On a similar note, one of the things I learned that I had to do was actually block the time on my calendar. And I like I like now I'm going to actually take that the offense and defense for like differences. But being able to make sure that I had
periods of time throughout the day to where even if for, you know, one 30 minute window, one of the engineers needs my time. If I'm in a meeting, I know the next 30 minute window I'll be available. So I'm like, Hey, you know, the max delay here's 30 minutes. trying to keep those stakeholder conversations to under 30 minutes.
getting really crisp and clear and not just kind of shooting the breeze. Cause that, that happens a lot in, in these stakeholder meetings as you talk about things that don't matter. And it's very, it's a time suck and a time waste. So one thing that's worked for me is just time boxing my calendar. And if my day fills up with some of the defensive and offensive tasks, they need to get done.
you know, my stakeholders can wait 24 hours, right? But a lot of times my engineering partners that waiting 24 hours would be a very costly delay. I really like what you said, and I think that is a very good behavior to not rush in a quick, not thought through product answer, but instead answering, hey, I will come back to you in 30 minutes or whenever.
but then i as an engineer i know okay i have this time spent now to do debug or to take a short break or whatever but i'm not sitting there waiting Thinking, oh, usually he's responding immediately and now he didn't. What's going on? So, yeah, communicate that clearly. And one more thing in addition. select the offense task. really push that forward and then i would highly recommend to pick only one
That is so difficult for me because I'm looking at the list and I think, okay, damn it, all of that stuff is so important. And I really, I have two time windows. I can push in four things and I will really change the thing here. And in the end there are thousands of questions and things that appear and in the end I did nothing.
But if I choose one task and I said, okay, this has to be done, then maybe it is done after two hours and I can pick the next one. But this pressure of, okay, my to-do list is so long, it's massively reduced and the probability of... doing good work on that one task is much, much higher. I love that. It becomes like your roadmap where every day you have to prioritize what is the one thing that we have to get done today. And it just becomes another prioritization exercise. I love that.
Yeah, don't be shy to just choose one, even though it feels strange. But in the end, you are much faster if you solve one thing at a day. It's kind of like engineering task, right? Where you're like, hey, this is the important thing I'm going to commit to today. But if it gets done a lot faster than I expected, then there's the backlog that I can go pull from, right? That's true.
All right. So we went over some, some anti-patterns. Are there kind of final thoughts of like things that you've seen work really well where, you know, Product managers have done X, Y, or Z, and it's really paid dividends in working with their engineering counterpart. Yeah, that is again on the topic of psychological safety.
Because I think you should be the sparing partner for ideas and for implementations. And you are the one who is most likely also clicking through the product and find all the bugs and said, hey, you misunderstood this. And this feature was thought differently. It's grinding. But if we ship something, we should always ship it together and the product person should be the one who is.
totally behind it the worst thing you can do is saying yeah right this feature is not working correctly i said that in the beginning but the engineer overruled me so don't know their fault yeah then then you lose the trust immediately right but saying hey no that was a conscious decision and we did that because of this and that and it is on the roadmap or on the backlog and we we measure that we have that in mind but look this feature is shipped as our product tech team and we are all
behind it and we delivered it together. That is a really strong behavior I want to see in every product person. I think that's so important because from a PM career standpoint, I've been in those conversations with my product leadership early in my career where I've had those conversations of, oh, well, you know, the engineers thought it'd be better to do it this way. And they're like, well, is it? How do you know? And it's like, you can't answer those questions. And so when you...
When you learn to be that sparring partner and ask good questions and drill down into why... why is this engineer making this recommendation and being able to talk through those trade-offs, then you're absolutely correct. You've made a team decision. and a defensible decision that you can now speak to in those stakeholder conversations, in your one-on-ones with your product director or VP.
And yeah, it adds to your credibility across the board. So I love that recommendation that I think that would pay dividends for the listeners to put into practice. Yeah, I agree to that. a training thing you will not listen to that episode and then you have all of that just right away you will do a lot of mistakes but that is okay just build this personal product development values and try to stick to them as good as possible.
Absolutely. And to your point, it may not come second nature, but maybe hearing this advice in the episode will come to you over lunch or something that you can go back to the engineering partner that you have and then ask those questions and get to a better. better position. So that's a good point. It doesn't happen overnight. Right.
Well, Paul, this has been an absolute pleasure. We've already mentioned product and cake. And again, listener, I encourage you to go subscribe, rate and review the podcast and take a listen to the episodes there. Great content, great guests that they have on. Paul, where else can the listeners follow you and learn from you? So first of all, if you are capable to understand German, you can find me now on Amazon and buy my debut novel. my debut roman so it is about an engineer who finally gets the
gets the dream position in one of the biggest tech corporations. And if you read it carefully with your product perspective, you see a lot of best practices. ways of working and cool software stuff and then she finds out that something super super evil is behind all of that shiny facade and starting to fight against it then it becomes more fantasy but All in all, you can find me on Amazon now. That is very new to me. So sorry for that self-plug here.
And beside that on LinkedIn, I think the best thing is on LinkedIn. We share all our episodes there. I post from time to time stuff. So let us connect on LinkedIn. That sounds great. And if you don't know German, go download Duolingo, take some lessons and then start reading Paul's book anyway. Let me know. Then I give you the book for free. If you learn German to read that book, that's a massive invest.
Thanks for joining, man. And no problem on the self plug. That's what the end is for. So thanks for sharing the book. And I know we have a sizable German audience. So if you are listening and you can read German, don't delay. Go find the link in the show notes. You'll get the book. I know you'll enjoy it.
yeah thank you very much for the conversation it was very insightful for me as the same as all your other episodes john keep up the good work here thanks paul and thanks for you who are listening out there and we'll see you next week for another lessons in product management