Here's a crazy exercise for you.
Try to picture a day in your own life three years ago.
In 2022, the big topics of the day were things like product -led growth versus sales -led growth and the debate around return to office versus remote first. AI felt like an optional side quest and the employment landscape felt like a buyer's market for job seekers.
Oh, how things have changed in such a short period of time.
But another difference was that this show had a different host and that former host is my guest today.
Michael Lutzen has spent the past three years shifting his focus into product leadership, and as a product transformation architect, he's been in the weeds through a pivotal time when the only constant has been change, both outside and within product teams. In today's episode, we'll be reflecting on the strategic and tactical bets he's made over the past several years, the ones that worked, the ones that didn't, and where the wind is blowing for product management as we move into the second half of 2025.
Let's jump in. Oh, by the way, we hold conversations like this every week, so if this sounds interesting to you, why not subscribe?
Okay, now let's jump in.
Welcome back to the Product Manager Podcast. I'm here today with Michael Lutchen, who some of you might remember.
Michael, thank you for joining us today.
Thanks, Hannah. Great to be here again.
Yeah. First of all, can you tell us a little bit about your background and how you got to where you are today?
Yes. So hey, everyone, I'm Michael, former host of this podcast. But more lately, I refer to myself as a product a transformation architect.
And my focus has been helping on growth stage companies, build product orgs that ship like startups, but scale like enterprises.
So personally, I've had 12 plus years of experience working on over 50 products from 10 person startups, global brands like Adidas.
And through this time, I've learned that companies that win aren't just ideal rich, but they're systems driven.
And so from my experience, great product systems to envision into repeatable execution.
And this insight comes from leading products across every imaginable context in org structure, each one teaching me new patterns about what actually works.
Most recently, I was the Director of Product at Float, where I transformed a product org from irregular releases to continuous cadences of delivery across all the teams, helping achieve significant ARR growth and the G2 number one position.
For that, I spent nine years at Crema, a fantastic leading digital product agency, leading their product management practice for the agency and for clients from elite consulting firms to early stage startups.
And then on a personal level, I'm a systems thinker at heart, whether I'm architecting product ops, framing a shot with my Fuji or building Lego with my kids, always exploring how pieces fit together to create something greater than the sum of their parts.
Very cool. And we've been talking a lot about systems thinking on the show recently.
So this slots right into our thematic little situation here.
So you were the founding host actually of the Product Manager Podcast. So thanks for laying the groundwork here for the show.
That was, I want to say 2022, not really a long time ago, but in product land, that's like decades now.
The discipline looked completely different.
So what have you found to be the biggest shifts from then to now?
Rewind and kind of compare what the discipline looked like then and what are you seeing out in the field?
Yeah, it's a really good question because I think in in our industry, we feel like this constant wave of change that we have to ride.
There's no like ever like one fixed process or structure or a way that we collaborate as product managers and with product teams to get great work done and out to our customers.
And so it's really hard to answer this question because honestly, I've been thinking about what's next right now as I answer the shift that I've seen.
So what is that shift like?
Well, when I first started hosting this podcast, that time there was kind of like two worlds of thinking that were competing.
There was either Either the feature factory type, you know, we've got a really defined process for better and for worse.
But then there was also like the pure agile scrum, almost worship to an extent, teams, you know, pick your poison.
Or if you're at the enterprise scale, it was safe.
And now I'm seeing that really having like kind of taken a backseat, like those processes are still there.
Waterfall is still there.
Scrum is still there.
Safe is still there for better and worse.
But what I see that the teams that are succeeding are doing is they're really looking at their their own product culture, their own ways of thinking, the people on the team.
And they're picking and choosing pieces from each of those processes without naming it as process and really creating kind of a systematic way of how they approach building great product and having fun doing it in a way that leads to that continuous discovery and delivery.
Okay, so I want to kind of pivot a little bit and talk about something that we don't usually talk about on the show, but I think is so compelling, which is a failure story.
You had mentioned before in a previous conversation that you had a transformation information initiative at Float, which failed the first time around.
What happened? What's the postmortem on this?
And what have you learned in the wake of that?
Yeah, so I started at Float after my, you know, nine years in agency space, like having the privilege of being able to work with so many different orgs.
And so I had seen it all in terms of the patterns of, you know, small orgs, large orgs, you know, orgs that were kind of getting over a growth stage hump.
And so I came into Float and I saw some of these patterns.
I had been talking to everyone up and down and across the org.
Everybody was aligned on these patterns of the pain points around the process and what was slowing down our ability to ship great work.
And so I came in there.
I got trusted by the CEO and basically two co -founders to give a presentation in person at the first all -company offsite a few months into the role.
I was like, we're moving to squads.
This is going to be great.
And the presentation was great.
Everyone loved it, including the two co -founders, everyone throughout that meetup was saying, this really resonates.
This is going to solve all our pain points.
And then over the next few months, it kind of dissipated and we started to go back to our old ways of working.
And so what I realized in retrospect was, even though I came in, I was like, here's the problem.
And everybody agreed with that problem.
And everybody agreed with the way to fix that problem.
The reality is that it wasn't the right time to make such a big big move to process improvement part of this was just due to how we had grown the org we were hiring for and we had specialized roles in engineering for example so if something happened or somebody was building a feature that needed a very specific skill set there was only one person that could do that and that would of course throw a wrench in any sort of kind of sustainable squads the other aspect i learned from this is that culture change it takes time it's not just one presentation.
Even if everybody's bought into it, it is that series of ongoing conversations, very much nuanced, things that you're working through on a one -to -one level or in a team setting.
And so, yeah, I'll never forget that.
And it's funny because chatting with the CEO later about this, we laugh about it today, about coming in, guns a -blazing, we're going to change.
And then that happened.
Yeah, I guess this is kind of like the systems thinking kind of thing is that you kind of have to take into account all the reasons why something might not work and then also evaluate things from the same perspective of like, oh, you know, what were the other context pieces that kind of inform how we might want to re -approach this in the future?
So I want to talk about the practical side of transformation.
You developed a framework for mapping org -wide pain points using Miro, tool that most of us are familiar with.
So how did you identify, what was the process for identifying the friction points beyond just product and what the process actually looks like from day to day?
Yeah, well, I think even before you get into the tools, just having curiosity and empathy.
So I remember when I started at Float and these same lessons apply to some of the clients that I worked with in my time at Crema, you hear a lot of pain and like challenges of like, oh, well, you know, it takes, and these are just broad examples over my career, but it like, it takes this long for, you know, designs to be ready so I can build them or maybe they're, you know, not aligned with what we want to build or, you know, there's no clear scope alignment or definition of done, you know, all the things that we all feel in our practice, the pain points every day and the things that we hear from our
team. And I think what's really easy to do is to have a knee jerk reaction where you take that and you weaponize that to try to force a solve for that one specific pain point if you're the leader of that person's team.
And so for me, like at Float, I was director of product overseeing the product manager's data, UX research, and further time design before it grew out into its own department.
And so naturally, my instinct is to protect my team.
But I had to set that aside in order to go about this exercise and not only meet one -on -one with people across my team, but a cross -section of the org from engineers to marketing to even customer success and sales.
What's working well?
What are you not getting?
What are the pain points that you're feeling and how we ship great product and talk about that product to our customers.
And it's just a conversation.
You don't go into it judging.
You don't go into it trying to point blame or fingers at one another.
And if you set that up and you just have that honest, curious conversation, you get so much great insight that you can then map to sticky notes on a mirror board and start to identify what those themes are.
Once you do that, and once I kind of have that, then I go and I map alongside that.
It doesn't matter when, in before or after those conversations?
What is the process that the company has agreed upon?
And you can pretty easily see, like, what are those discrepancies?
And then from there, I take those discrepancies and those themes that have those pain points across the org and basically map it to a new visual process.
And from there, that's what I use as the foundation to seek alignment with the folks I talked with, but also across the entire org and up and down the entire entire org on, these are the things we want to try.
These are the process change experiments we want to make.
And once you have that buy -in, because you're actually building it on top of the real -life pain points that everybody is feeling across the org, you rarely get any pushback from that.
That's awesome. And I was just going to kind of push on that point because I think the buy -in is often the hardest part.
Even if the proposed solution on the surface is going to create that source of relief for those pain points, change is difficult.
It's really difficult to kind of change people's habits and workflows.
And for example, like you'd mentioned before, that Float had a pretty specialized engineering culture.
And so moving towards more of a cross -functional product squad wasn't quite as well received or there was a little bit of tension there.
So how do you manage situations like that and kind of ease transitions when you're trying to transform things and make life easier?
Like, how do you kind of acquire that buy -in with more when there's tension to balance?
Yeah, it's a good question.
And it comes down to, no pun intended, the actual intent of float as a product, which is resource management, and having those discussions that lead to that.
Because it's really about clarity and respect.
Without having those clear lines of communication with partners across the org or respect in doing so, then what happens is, like, that's where you can have friction.
but if you really focus on collaborating on okay like let's say there's this really specialized individual that we want to have dedicated to a squad for example but they have to support like this really key piece of infrastructure well it's you can't answer that black and white so usually the options are well we can hire but hiring and onboarding that the quality that float does it takes some time so then what's the plan b in the interim well that's where capacity planning and resource management comes into play and aligning on those trade -offs and so this gets to kind of of two angles.
One, it's the person and the individual themselves.
Are they approaching this in a healthy way?
Like, are they being allocated to a squad, like halftime or full time or whatever that looks like?
How are they serving kind of those specialized needs of support or mentoring across the org that they have?
And are we okay with that trade -off?
And usually the answer is like, we don't want to like split that focus.
And so then it gets back into the product roadmap.
And this is where I really see the value of ops and product coming together because you can't answer like, well, how do we actually allocate this person effectively without the context of like, well, what are the bets that we're making or deferring based on our staffing approach to setting up these squads for success?
That's a really good point.
Okay. Tell me how the role of practical rituals kind of fits into that scenario.
Cause you'd come up with something called one team, one roadmap, and you'd kind of set up some async design sprints to kind of to facilitate some of this.
So how did that evolve?
And what did you find were like some of the most helpful takeaways from that time?
Yeah, one team one roadmap was really the culmination of all of my product transformation work at float from coming in with that failed squad implementation that later did transform into a successful lasting implementation once we did make that investment in the cultural investment, the hiring investments.
But one team one roadmap really came up about as float was scaling.
Now it's like, okay, well, there's all these product product squads.
There's also platform squads.
There's like marketing focused work going on over here.
And now product marketing is asking questions like what's coming up.
Sales is asking questions like how can I tell the narrative authentically of what's coming down the pipe or not?
How can I authentically involve product managers as spokespeople when we have like really key new client opportunities?
And then of course, the two co -founders are asking questions as well, like how do we make sure we're budgeting right and investing in the right way?
And so one team, one roadmap was really about today, you know, each squad has a roadmap.
Each platform team has a roadmap.
These are all like managed time separately and linear.
Let's bring this together in a really systematic way that is as lean as possible, but provides as much up -to -date context as possible without taking as much time as possible from the people that are involved in that.
And so there was really the systems piece of it first, which using some of the newer linear roadmap features.
We were able to create some great saved roadmap views of basically all the product and platform, et cetera, streams that were ongoing at a time.
This was really great because it meant that the product teams actually doing this really only just had to provide a status update in linear, a very lean one every now and then.
Those status updates would go out to a channel that I set up in Slack.
So anyone across the org, regardless of how close they were were to any sort of this product work could subscribe to that channel if they just wanted to be aware of what was happening.
And usually that channel would include like a Loom demo or even a link to like a test environment if they wanted to play around with it.
Then I also paired that with an ongoing monthly product huddle.
These were 60 -minute sessions that were focused on demos only.
Product managers across the product teams would share and celebrate their team and what they've been working on.
And then platform leads across the platform teams would be doing the similar work as well.
These were actually biweekly, I say monthly because that's how often people would have to attend these.
But I intentionally set them up as biweekly because we had Async team members across like 15 plus time zones.
And so to be respectful of time zones, we wanted to alternate ultimately how we presented this to make the best respect of everyone's time.
And so this radical transparency ultimately that was being shared through these focus product huddles, through the completely automated linear roadmap updates.
And then the, you know, every so often project status updates that would get piped into Slack with live demos.
It created this transparency that built trust, that created a culture of shared understanding so that we can make the decisions on how we move forward across, you know, all teams effectively.
Yeah, and I'm also really getting like this, it's a huge amount of empathy for people's different learning styles and ability to kind of integrate themselves into the strategy kind of at their own pace and be able to kind of, yeah, there's the multiple levels of being able to get buy -in from different stakeholders.
So I really appreciate this layered approach. That also like segues into like what you mentioned around design sprints as well.
So at Crema, like I had spent years leading design sprints with clients and new teams. And I think that today, like, you know, I don't believe you have to necessarily follow the like buy the book async design or design sprint process, but I do believe it's kind of like pick your own kind of tools that you cultivate what your own design sprint looks like for that alignment.
And so at Flow, to align on that strategic piece, I shifted that into async design sprints.
And so it was essentially like a fig jam board at the time of, you know, how do you take like a five -day sprint of exercises and then move it into an async format?
Well, you got to have more time because, you know, people in one hemisphere are going to sleep after contributing to that board. And then the other hemisphere is waking up, reviewing, and then kind of sharing sharing back what they thought asynchronously on that board. So they extended it to two weeks.
And what this leads to is actually you get like more participation because people have the time in the context of their own environments to safely share what's on their mind and add comments to that discussion.
And then you can always elevate it to a one -off sync discussion if you want to talk about anything that is a hot button topic that usually comes up in these strategy debates.
Yeah, it kind of sounds to me almost like a pen pal versus classroom dynamic.
like there's kind of there like a little bit more some degree of safety and being able to kind of put out thoughts without the sense of immediate judgment or media you know like overthinking what other people are going to think in the moment exactly yeah and being able to like shift back and forth between the two again ultimately out of respect of what's best for the team yeah yeah that's really cool i'm gonna change gears a little bit because we can't get through this conversation without mentioning everyone's favorite two -letter word which would be ai of of course.
So when you would have been hosting this show, I don't think anyone was really talking about AI in any certain terms. And now it's all anyone wants to talk about.
At the time that you would have been here, we would have been talking about AI as like really, actually, I even remember I was coming onto the team right around that time.
And I remember the conversations around AI were very loose.
It didn't really seem that the technology was ready yet to be useful.
And now Everyone is in a rush to adopt AI in every workflow and in their products.
So at Float, what was kind of the approach to AI integration?
And obviously, that's a huge thing you were navigating.
You've been really close to that project in the last little while.
How did you navigate that?
It's really interesting, because I think in the early days, when ChatGPT first came out, I was in awe and enamored by the product, much like everyone was.
And so I started experimenting with it and I started researching some of the capabilities and the opportunities that we had from a product perspective with it, just out of personal interest. And then I started to bring it back into, well, how do I apply this to the product at float?
And so I started like mapping out some ideas and ultimately that just led into a side passion project of mine, where I remember I put together this like big Notion doc white paper that had some of my own kind of beliefs of, it was the early days of time, but where is this modern LLM tech going?
Where is it going to be in three months, six months, one year, three years?
And how's that going to impact SaaS, particularly B2B SaaS that float serves?
So then bringing in some industry references, I was like, well, actually, how do you make bets that we need to invest in from a product perspective today, and make sure that we're timing those bets appropriately, but also not throwing everything away and just focusing things solely on AI, as was so the temptation at the time.
And then also a few sketches too, like mapping some of our data points in the API to, well, if we had this available to an LLM, like what are some of the things we could do with this?
And so it was really just from a place of curiosity that led to this doc that I then created and shared with the rest of the leadership team and got a lot of really great excitement and buy -in.
From that, we actually ended up consulting consulting with a generative AI consultancy out of Melbourne, a couple of great guys, Move 37.
And they really guided us on not just how to approach AI, but making sure that we approach it in a way that aligns with what we want to provide from a user -facing value perspective.
And so the earliest kind of separation they provided was the difference between structured data and unstructured data.
And at the time, we were also looking at improvements to make to the reporting product that float has.
But a lot of those improvements you could make just with structured data and some improvements to the database that we started working on later.
The unstructured data is really where generative AI, kind of that ambiguous stuff that we use every day with chat GPT or cloud comes from.
And that's where we were able to separate the experiments.
The core thing that came from that was focusing on the agent workflows.
They helped us create an agent playground that allowed us to play with some of the data to get some varying results so that we could see and figure out, well, how might we implement this in the product?
And so for me, what that meant is, as a product person, moving forward, I'm looking at not just user flows, but I'm also looking at agent flows.
So I started designing things where we would have like, yeah, the user flow, the user does X so they can do get Y result.
But then like almost under like quite actually literally from a visual underneath that, like, here's what the agent is doing in the background to help support the user in that result.
And this was different from a lot of the implementations that you see in the industry where it's a chat box, a glorified chat box.
And those are fine.
They're great, quick ways to interact with data as quickly as possible.
But it's also not the idea that user experience, I think, of where AI has the capability of going in terms of product integration that gets better with use over time.
but you don't necessarily have to use or know as a user that you're actually interacting with AI.
Okay, well, I'm going to change gears on you one more time.
Let's talk a little bit about the differences and how PMs need to operate now because we're looking at transformation on all levels, you know, culturally as an industry and in the actual role of product managers as well, who are now kind of moving from a very execution focused role to one that's very much more strategic.
So in your experience leading transformation, how do you advise product leaders to guide their PMs into adjusting their approach and kind of adopting some of these more kind of radical shifts in focus and skill sets?
So it's an interesting one because I'm actually going to lead with a hot take that I've held true to throughout my career and I continue to even more so.
A great product manager or product person, if you're wearing that hat, is holding both execution and strategy together at the same time.
And typically, I know that's a hot take because the way I've seen it is, and I think what your question alludes to, is there are people that say, well, if you're just doing execution, you're just a glorified project manager.
Or if you're just doing strategy, you're a mini CEO. I think both takes are toxic.
And I think what is ultimately good is where the PM has an increasingly unique ability to guide an org forward and is balancing both, well, how do we execute this in a way that brings together the expertise of everybody across the product team from development to design, QA and more in a way that strategically serves the needs of the business and the opportunities of the market and the customer and more.
And that's easier said than done.
Because during this, and I think where some of these arguments kind of that are more black and white thinking have had merit in the past is that they'll say, well, these two are just at odds with one another.
Like, you can't be strategic if you're thinking about how you're going to efficiently get this done.
But I disagree with that because I think when you, as I've shared through some of these other kind of stories, like when you lead with empathy and you lead with curiosity, it gets you to a place where you have all the context in front of you, kind of like if you're using a Miro board or a FigJam board, you got sticky notes with your team.
It's almost like a messy architectural desk and you can kind of move all the pieces around to see like what's the best, most effective way that we can strategically execute this.
It's going to guarantee us results, but it's also making an efficient use and a respectful use of the team's time and everybody that's coming together for that.
What this means for those who are more execution focused today is to like actually lead with with curiosity and think about from a strategic perspective, what are the things that you're hearing from your engineering counterparts in terms of tech debt concerns or new technical opportunities on the horizon or things that they're exploring?
What are you seeing from design in terms of new design stacks or ways of approaching how you do that?
And then of course, what are you as a product manager seeing in terms of what you're hearing from customers in the business?
You bring all that together, and I think you can have just a really great approach to execution and strategic moving the strategy forward at the same time.
I don't even think that's a very hot take.
I think that's a very good take, firstly.
Okay, well, let's end it off on something a little lighter, a little bit more personal.
Because you had mentioned to me that you've been doing some AI building projects with your son on the side, which I think is very cool.
Tell me a little bit, because we've kind of discussed through our newsletter and the like, which, you know, if you're listening and you're not subscribed, why don't you subscribe?
We did discuss a little bit about how parenting can really inform your approach as a product manager, as a product leader.
So how has your life or parenting informed your approach to leadership and transformation?
Yeah. You know, I try to like let both sides of my life influence one another.
I'd like to say my work -life balance is pretty good, but the reality is, is what I do is also my personal passion.
And so I try to bridge those gaps.
So like, you know, recently my son, he's a five and a half and one day he came home from school and he's like, Hey dad, can we build this ninja video game and put it on the PlayStation PlayStation 5.
And I'm like, okay, well, I could either say like, yeah, let's think about it, buddy.
Or like, yeah, let's figure it out.
And so at the time, like, you know, I haven't really done any game development.
But in my mind, I was like, I'm actually gonna take this as an opportunity to bridge some of that experimentation that I'm doing for work with him.
And I was like, you know, let's figure it out.
We'll use this new technology called AI on dad's computer, and we'll do that.
So what was interesting is then I started just kind of bringing in like the product development approach that I use without telling him that and so I was like hey why don't you start sketching out your ideas of who the character is going to be and like how the gameplay is going to be and all that ideation and discovery right and so he starts like massing like literally this pile of construction paper over a week or so with that and then we finally get time to sit down and I say why don't you sit down here and we talk about like what is the approach to the game and i was basically recording this using
a transcription tool on my mac took this interview dropped it into chat gpt asked it to create a game development doc and then asked it to bring that into something that an ai tool could handle and so from at the time what i had heard is that you know it's kind of like you want to tailor it for the mindset of a junior developer and so that's what i used to create kind of this level one concept of this this ninja game this is requirements I'm misgathering.
And so then I take it and I drop this into, I was using Bolt at the time as, you know, cleaned it up, the prompt up a little bit.
It created it. And now we're play testing.
Now we're doing QA on production.
And he's saying like, well, the sound doesn't work.
The controls are a little iffy.
Okay, cool. We're providing that feedback and we're iterating.
Now we got the loop going on.
And it eventually gets to the point where he's excited to share it with family and friends.
And then of course, later, now we're iterating with other ideas.
You know, How do we turn it into a 3D movie?
Cool, let's pull up Google's VO model and it just goes on and on.
So I was bringing that product thinking there, which if you think about product thinking at its core, it's really based on like the scientific hypothesis and kind of the scientific methodology and the way of approaching that.
And so like, yeah, I try to just bridge those two worlds in my day -to -day.
I think that that is a much more thorough example of bridging.
I think most people we've talked to are like, yeah, you know, sometimes I have to convince them to eat their broccoli.
In your case, your kid literally has a product development resume before he's able to read.
That's very impressive.
I guess so. I remember when I was his age, it was like, I was like, that would be so cool to work for Nintendo or something.
You know, I was like reading Nintendo Power back in the day to just date my age.
And now you don't need to do that.
Like you can just get on and start saying what he wants and go from there.
It's pretty cool. Well, thank you.
That's an absolutely incredible example and also a humbling example from parent to parent i'm gonna have to update my list of rainy day activities yes yes it's a good one thank you so much for making time to come back check in with us and yeah it's been so great to talk about what you've been up to working for people follow you online yes you can go to michaelluchin .com and there's links to all the various platforms I'm on. So yeah, I'd love to connect.
Don't hesitate to reach out.
Thank you so much, Michael.
Awesome. Thanks, Hannah.
Great to be back. Thanks for listening in.
For more great insights, how -to guides and tool reviews, subscribe to our newsletter at theproductmanager .com slash subscribe.
You can hear more conversations like this by subscribing to The Product Manager wherever you get your podcasts.
Thank you.
