S4E2: Why Lean and Agile Struggle in Chunky Corporates with Katie Tamblin

Welcome to Productly Speaking, the product management podcast where building products
is never a straight line, though the roadmap says otherwise. I'm your host, Karl Abbott.
In each episode, I talk with some of the most innovative minds in the industry. Together,
we share real stories, the breakthroughs, the missteps, and the lessons that usually
arrive, well, after the deadline. So whether you're a seasoned PM or just starting your
journey and wondering what really happens behind the backlog, let's give it a go.
Today's guest is a seasoned data and software advisor who provides consultancy and training
for business leaders and investors. With over two decades of experience leading teams in product
management, data science, technology, and marketing, she now focuses exclusively on consulting. She's
also the author of The Lean Agile Dilemma, a book that explores why lean agile practices can't be
applied in the same way to large, chunky corporate organizations as they can to lean startups.
I'm pleased to welcome to Productly Speaking, Katie Tamblyn.
Thank you so much for having me today.
Yeah, thank you for being here. So on this season of Productly Speaking, we've been focusing on why
products fail as a way of better understanding what not to do. And your book talks about something
that I think a lot of us who have worked at chunky corporates can resonate with. So first off,
would you tell us, what do you mean when you say chunky corporate?
It's a good place to start. So I typically define a chunky corporate as an organization that often is,
you know, well over 10 years old, has over 500 employees, has non-founder shareholders that are
invested in the business. So that might be private equity, it might be public, it might be, you know,
something else. But what that does is it shifts the organization's values to be much more heavily
focused on regular financial reporting, which then shifts the focus to be orientated towards
predictable performance, perhaps over innovation and risk taking and those sorts of things. So
those are the things that I think of that kind of define a chunky corporate. And yes,
I did come up with that as the opposite of a lean startup. While working at one, it became
a bit of a joke between us product folks that we were not a lean startup. In fact, we might be the
opposite. Well, and on the opposite, lean startup, let's talk about what that means.
So if we think about your typical lean startup, you know, they would be kind of on the other end
of the spectrum. So they're typically young, not always, but quite often they're young. They have
fewer than 500 employees, often fewer than 10 employees, fewer than 20 sometimes. They are often
seeking funding, so may have gotten some investment, maybe in the early rounds of investment,
but have not really truly scaled up to have serious investor input. And as a result of that,
they have none of the constraints that come with it. So they have more freedom. There's less oversight.
They're not working to a kind of monthly board report cadence that you would get with that sort
of investment. And quite often their reliance on process is lower, less people to manage,
less relationships to manage, less process required. Their defined timelines are almost non-existent
in a lot of cases or self-imposed, so easy to change, and they have less access to capital.
So those are the things that I think of that in the context of what we're talking about today would
be defining characteristics of a lean startup. And that's really the environment that lean and agile
have come out of. Yeah, absolutely. And I think it's interesting, you know, when I first started
drafting the book and I was sharing thoughts with colleagues and friends, one of the things that kept
coming up is it's almost like lean agile have become completely intermeshed, you know,
and they're not the same. They were not written together, but they've been fused together, I think,
in a lot of organizations. So the lean startup is an absolutely fantastic book and the principles that
are espoused around product development and lean product development are amazing for finding product
market fit and innovating in software development. Agile is a development methodology that was crafted
not necessarily to be used alongside lean principles, but often they are. And I find a lot of people I work
with in product and tech wouldn't even really know where the separating lines are between lean and
agile. So we just refer to them as an operating methodology that has gotten fused together.
Yeah, I think I find myself in that boat. Where would you put that line between lean and agile? Or
does it even matter anymore that they've been fused so closely?
For agile purists, I've worked with quite a few of those and they have fantastic perspective.
I think they would say if I can channel my agile purist friends, they would say that actually it
doesn't matter what software you're developing. You can apply agile anywhere, but lean comes in when
you're trying to find product market fit, when you're trying to innovate and fail very quickly
with what products and features you're putting out to the market, because you don't know what people
will buy yet, if that makes sense. So the line really should be in the what, do you know what
you're developing, which is kind of where lean comes in, and the how, where agile is the how you would
put out that software, regardless of what that software is. So I would put that line in there,
the what versus the how. But I think where they get kind of mixed in with one another is that the
whole reason you're trying to put out lots of software and get people using it as quickly as
possible is so that you can prove which features will get used the most. And I know we're going to
move on to replatforming in a few minutes, but I think when it comes to legacy big corporations,
you kind of can't get away from the fact that both lean and agile were designed for building
software for the first time that no one's using yet. And so with that, they take you away from
what chunky corporates often need to do, which is to manage an existing product stack, which is
harder to do in an agile way for a number of reasons. Let's talk about some of those reasons,
because your premise is basically that lean agile principles typically fell in chunky corporates,
because they weren't designed for that environment, that some of it maybe you can adapt,
but not all of it and not all at once. So let's talk about that.
Yeah. And this comes born of, gosh, painful experiences where, and I was, I was a product
manager who had read all the books and had built new products and I had had some product successes
under my belt. And I was so excited to take those into a new organization and continue to do that.
And what I discovered in coming into a job in a company that had 30 years worth of software
development that it was trying to manage is that we couldn't even get close to rolling out new
features because all of our resources were deployed, simply maintaining what was already
there. And you can track this, you know, I've seen this with a lot of startups, there becomes an
inflection point when you've been building software for a long time, you used to have, let's say,
a team of nine software developers that were just building new features. And if they've been
building new features for, let's say, five years, well, then those nine might all have to just
maintain the stack that's there. You know, as teams grow, so as you add to your software development
team, you bring on more engineers and more engineers, the longer that's been happening. And often, as we
say, chunky corporates, they're 20, 30 years old, you have 30 years worth of software, all you're doing
is maintenance. Eventually, there comes a point where the software is no longer fit for purpose and has
to be rebuilt. So this is where the concept of replatforming comes in. You are not releasing a new
product to a market and hoping people will buy it. You are taking away an existing product and
replacing it with new software. So you have to rebuild what's already there. Often that's referred
to as replatforming within organizations that are undergoing that. That kills the concept of an MVP.
It cannot be because why would a customer use a product that does less than what the existing
software can do today? So I like to use the analogy of a house. So let's say I live in a four bedroom
house. It has a kitchen, it has three bathrooms, and I'm very comfortable in that house. Now it's
old. It was built 100 years ago, and maybe the floors are creaky and the plumbing doesn't always
work great and the electrics are shot, but it's still a four bedroom house. To put onto me the concept
of MVP would be like saying to me, okay, go move into a tent in the garden while we rebuild your house,
which I'm probably not going to agree to, right? When you talk to software engineers about putting out an
MVP when they're trying to replace a platform that is as big and sophisticated as a four bedroom
house, their customers would simply not give up what they've got to go use something that does
less. You know, I'm not going to give up my house to go live in a tent. So an MVP would be something
like, okay, go live in a tent. Okay, now we've built your living room. Come and live in the living room.
And we're going to put a fake door that says kitchen. And we're going to see how many times
you push that door to see if you want a kitchen. So that's kind of like lean product development.
Let's just, we'll do some fake doors and some AB testing and see what you like.
None of that is necessary because you know, I know I want a four bedroom house with three
bathrooms, just with electrics and plumbing that works. So from the outset, replatforming is just a
completely different beast than building new software. And lean agile doesn't take that into
consideration that you can't have an MVP that's small because there's already an existing product
you're replacing. And the other one is existing data. So lean agile don't even consider existing
data sets that have been built up over decades of using software. That is often where the value
in a chunky corporate's product stack is. You know, I've generated 30 years worth of data by
having customers use my platform. I don't want to throw that out when I build a new one, but there's
not a lot of effort at understanding how to manage data in the context of lean agile. And the third thing
I think that really makes lean agile difficult to implement in a chunky corporate is simply the volume of
personal relationships. You know, agile was written to make the team smaller, you know, to get people
working in small tribal environments where everybody's talking and they're talking all the
time. And that's really effective. I totally agree with that. And lean was designed to work in a startup
where it's a small group of people. If you're in a lean startup, you maybe have 10 employees, maybe
less. That's about 45 interpersonal relationships amongst those 10 people, if that makes sense. You scale that
up to even just 100 employees. We're not even talking chunky corporate yet. We're talking somewhere
in between. Now we're thinking about maybe 5,000 interpersonal relationships between 100 people.
The communication is completely different. So scale that up to 500 employees. The effort that you have
to put into keeping that large a group aligned and communicating to where, you know, you're not having
mishaps or missteps or somebody heard this, but they thought that was happening. Or we heard this from
the customer, but it's passed through six different people before it gets to the engineer. You know,
that is the bit. It's managing not the tribe of a scrum team, but managing 100 scrum teams all trying
to deliver not just working software at the end of a sprint, but working software that fits together
and works with the data that's already in the business. That's just, there's a whole other set
of layers that you have to manage that I think lean agile in its purest forms simply didn't give
enough thought to, if that makes sense. Yeah. And like you said, lean agile is really
about developing like an MVP or something completely brand new. And you're talking about
being in a chunky corporate where you've probably got some flagship product that has been very
successful because obviously it's kept you going for as many years as it has. You're talking about
companies that are a lot older at that point. To change that is problematic. A couple of questions
for these larger companies when they try to create new products, because you've got this idea of like
capturing the entire stack. So say you have a platform, but then people run software on top of
that platform and they run software on top of that. And you start getting all these layers of software.
And so a company says, Oh, we want to go up the stack. So we want to go create new products.
Is that a place where lean agile can work in a chunky corporate because you are technically making like
a brand new product to fit on top of that stack to try to capture more of that? Or is that still a place
where too much of the chunky corporateness is already set in and you've got to adapt to it?
That's a great question. I think it can work. I have seen teams that work where they're truly given
an innovative and kind of a creative ring fence, but they have very discreet ways of plugging into
the existing product stack. So I have seen that work. I think it can. But I also think the more
common reality, this is born of my own scars when I first became a product manager and I had one product
go really well. And then I was all ideas, you know, I can do this. We're good at this. Let's do,
let's go after another one. Let's go after another one. And I put forward all of these proposals and
they all went through to leadership, to these like quarterly investment review decision-making
board groups or whatever within our leadership team. And to me, it was like a black hole. You know,
I was like a very small cog in a very big wheel, but I would send off these business cases and they
kind of never came back in the affirmative, but I never got any feedback as to why they weren't of
interest. And what I discovered when I finally got into the decision-making room is that the
proclivity of a large organization that is so focused on predictable performance to invest in
new products is simply way, way lower than I thought. And once I got into that cycle, I started
to see why. I mean, you know, a lean startup just focused on innovation because you're trying to find
product market fit. As you've already said, if you're a chunky corporate, you have product market fit,
you have a flagship product. So investors who want predictable performance are simply not very
tolerant of the margin dilution risk of trying out a new product. Oh, I'm going to go spend 5 million
on new software and hope that it generates more than 5 million in revenue. And I go into the book,
like all the places where this falls over in sales incentives, you know, why is a salesperson
want to go try to sell something new when I already have this existing product and my quota is built on
that. And, you know, there's kind of all these really nuanced layers in which this plays out.
But the short version is if a big investor backed organization wants to move into a new market,
they're probably going to acquire a company that has proven they know how to capture that market
because there's less margin dilution risk in doing that than there is in trying to build your own or
trying to compete with somebody who's already done it well is the reality that I've experienced more
often. Yeah, we've definitely seen a lot of that in the past couple of years where big companies have
acquired smaller companies. And I'd say that even more recently, we're getting to a point where
that's starting to be seen as risky to the point where they're just like, here's a couple million
dollars, go do something with that investment and show us that you can do it. And then maybe we'll
talk further. Yeah, absolutely. And you're right. They both present risk in different ways because
the risk of integrating an acquisition is very, doing that successfully is also very high for sure.
So another thing that you talked about is when you're trying to bring lean agile into a chunky
corporate, and even if you're not trying to bring lean agile into a chunky corporate,
you've got all these interpersonal relationships that still have to happen. And there's this
communication issue that once you get to a certain size, what would be your suggestions for keeping
people appraised of everything that's going on and trying to keep everyone on the same page? Because
that can be a challenge because there's so many teams, so many different regions.
Yeah, I think there's a lot of ways to do it. But I think especially for organizations that are at the
start of a replatforming journey, which so many organizations that I work with and have looked at
for evaluation purposes are in that place or some degree of it. The first thing is to align the aims
and be really discreet and really explicit with the whole business, not just tech, the whole business
as to what you're doing and why. Because where I've seen these things go wrong is in, I've seen
leadership teams throw around the words lean and agile at the start of one of these projects.
And then what that creates is attention when the product and tech people go in to try to deliver
it and deliver in lean, agile way. And they realize that those are incompatible. So the first step,
I'd say, is for business leaders not to use those words without a really deep understanding of what
they mean and the connotations that they have. Then the second would be to ensure that your subject
matter experts have dedicated time to the project. Because one of the biggest complaints I see
is the tech team went off and built a finance solution with no one in the finance team in the
day to day. And then what the finance team gets, they can't use or they don't know how to use or it
kills their productivity. I once watched a software release for a sales team get held for six months
because they couldn't pick a week where they were confident if the sales took a hit for the week
in the slower processing of sales because of the new software, they'd be willing to accept that.
You wait six months and the sales process has changed again. And it's because the sales team
were not embedded enough in the development to feel confident I could hit the ground running
using this tomorrow. I'd say that's one of the things. Make sure you invest in freeing up the
time. This can't be off the side of your desk. If you are properly changing the software that an
internal team would use, this often is even more for the internal software you're using within your
organization, not even the customer facing stuff. You've got to make sure that you have people that are
fully, fully embedded and know exactly what they need and that they're comfortable with it throughout
the process. And this is where it's like adapting Lean Agile, not throwing it out. Because what I
find happens is a lot of product and tech people, when they realize that tension, well, management said
they want us to run this Lean Agile, but there's no such thing as an MVP because the sales team aren't
going to switch to our CRM until it does everything their existing one does, blah, blah, blah. We'll just go
back and do it the waterfall way because that's the only other way we know is kind of what happens
without anybody saying that out loud. So it's about keeping that involvement of your stakeholders
in the way you would in a Lean Agile environment, but with the knowledge that you're not going to be
able to release an MVP in the way that you would previously. I think those are two. So keeping up
that communication and the intent of Agile communication across a wider team often means
changing up people's day jobs, frankly.
So you've talked about like management and leadership getting the idea that we want Lean and Agile,
but not necessarily understanding what they mean. What do you think is the reason behind that? Why
are these leaders drawn to those words? What are they trying to get out when they say that?
Yeah, that's a great question. I think a lot of it is that they're popular. And so people accept
that, you know, if they're popular, they must be right for everyone. I mean, gosh, I've seen Agile used
in procurement. If people want to have Agile procurement, they want to have, they want to do that
everywhere. It sounds cool. A business leader that I worked with a number of times, it just cracked
me up when he said, all I know about Lean and Agile is it basically means my tech team wants no fixed
budget and no defined timeline. And I thought, well, you get it, actually. You are one of the, you know,
I think a lot of what I see a lot of business leaders do is say, well, I want you to be Lean and I want you
to be Agile, but what they mean is I want you to respond to my changing needs on a day-to-day
basis. And when you tell them, you know, in Agile software development, you wouldn't actually have
deadlines, really. And you wouldn't actually agree on what you're going to build before it gets built,
really. Then business leaders and investors start to get really twitchy when you explain those
critical elements of Agile purism. Yeah. But also that kind of brings up a point that there is like
this illusion of agility that can exist in these Chucky corporates because, okay, you've been told
to go do Lean and Agile. You're in a big business. What does that illusion of agility look like when
that situation occurs? Yeah, I think the illusion of agility is if we start working in, you know,
two-week sprints and we're releasing software at the end of those two weeks, then we must be Agile.
And in some ways, there's elements of truth to that, of course. But if what you're releasing every
two weeks doesn't move the needle or is it relevant or is it used, then what's the point?
I still advocate, you know, releasing working software at the end of every sprint every two
weeks as much as possible. But the illusion of agility comes in when, as an example, if you have
these huge tech stacks that we have in mature businesses, what often happens is it's kind of
like playing whack-a-mole where you have this amazing idea that you want to change something.
We wanted to change our pricing model. And so we went into software that was built 20 years ago
to change the price and we changed the price everywhere we knew we needed to. But then when
we went to go live, we discovered that somewhere in a completely different part of the tech stack,
when we changed that price over here, the discount that was applied to it got doubled under certain
circumstances, right? Yeah. It was whack-a-mole. It was like you push something over here and something
pops out the other end that's a complete surprise. Thank goodness for thorough testing that we found
that before it went live. But if we had been truly agile, we probably would have released the software
and then tried to go back and fix it. And that would not have been an okay solution for our sales
team because they would have been digging out from some pretty hefty discounts. And if somebody found
that out and exploited it, we could find ourselves in a pretty deep revenue hole. So it's balance,
right? Like anything. It's knowing where you can be agile, where you should be agile,
and where you really shouldn't for the sake of securing and ensuring your predictable financial
performance. Yeah. And in your book, you talk about the challenges of replatforming,
which we've already kind of talked a little bit about what replatforming is. Can you share
a replatforming horror story and what you learned from it? Sure. I feel like most of my replatforming
horror stories start with data, but it's a real theme in the book. There isn't a lot written
it's not mentioned in the lean startup. It's not mentioned in agile principles,
but I think we forget how many little gremlins data can cause in software. The natural evolution
of most replatforming exercises I've worked on look like this. The business leaders decide they
need new software or usually tech comes to the business leaders and says, we need new software.
The software is going to fall over any day. Everything's out of date. We're losing security
update, you know, blah, blah, blah. We've got all of this, half of it's tech debt, half of it's
new things we want to do. We've got to change the underlying software. And business leaders
reluctantly agree. There's usually some finagling of the timeline and the budget. So going into the
replatforming project, the tech leaders are already nervous. They are not going to be able to rebuild
the software in the timeline and with the budget they've been given. So they're trying to cut corners
wherever possible. But at the end of the day, it's the tech team that leads it because it's
replatforming, right? You're rebuilding existing software and usually data scientists, data analysts,
and actual users don't get involved until way later. And what I have found is that software
engineers, they're simply not trained and don't have data front of mind. Because why would you?
The assumption almost always is we'll build the software and then we'll put the data in it.
But we underestimate as humans, all the ways in which the code is built on an assumption of what
data will look like and what format it will come through and how it will interact. And so my
replatforming horror stories, the big one was I went into an organization and when I joined the
organization, they were already three or four months into a replatforming exercise. They were
aiming to release an MVP in six months in December, six months from when I joined. We got within three
days of that and discovered three days before this is when the data were going to go in from the old
product. So data getting sucked out of the old product and put into the new. And when we looked,
we started to test the data in the new platform. Five percent of the data had come through and landed
where it was supposed to in the new platform. Five percent. And then this is a data heavy product.
So that basically delayed the entire release to customers of the new platform for 18 months.
Took 18 months to sort that out. And a lot of it had to be unpicked and rebuilt because they had
built code. You know, it was little things like they had built everything on UTC time zone,
but the data that came through were in all different time zones. So we had to go back and revise the data
model to take time zone into account. And then that fixed everywhere in the software that referenced
time. Little things like that, that you just would not see until you're looking at real data.
Yeah. And they waited until basically the 11th hour to ingest real data. Was there test data that
they had to develop off of? But the engineers made up the test data. Oh, okay. Yeah. They made up the
test data. Yeah. Cause that's a huge thing. Cause like you said, if you've got little differences,
like, Oh, our time zone is taken into account, but in one set and it's UTC in the other. Wow. Yeah.
That would cause some, some serious issues.
Yeah. And you know, it's funny. The other thing I've noticed is that very few QAs, quality analysts
and quality assurance folks, and very few engineers pay attention to what the data say. They're much more
likely to just tick a box if the data shows up. In my previous experience, until we had data analysts
and data scientists looking at data, they're the ones, and actual users can often perform this
function. When you see the data in the platform, you know, that doesn't look right. That can't be
right. A QA or a tester that's technology-based just wouldn't have that intuitive knowledge. And
again, that comes back to, if you're at a chunky corporate, those roles are so siloed because there's
no such thing as an MVP in a replatforming exercise. You may have only tech QAs looking at data in the
platform for the first 12 months of the software being used. Whereas in a lean startup,
you're only 10 people. So the people testing it are the people who know what data should be there,
what it should look like, and how it should work.
Yeah. And I think that that just speaks to the importance of communication in those environments,
because you're right. You've got people that this person knows this very specific thing about the
product. This person knows this very specific thing. And this other person knows this very
specific thing. They all work on different teams. And if you don't consult with everybody,
you end up in these awful spots where something goes wrong. And usually after that's happened,
whoever needs to be consulted with is found. Usually they're very upset about the fact that
they're just now being brought in because they could have saved everybody a lot of pain and headache
had they been brought in earlier. But also I think we tend to get into that position because we want
to get moving quick. And it takes time and effort to really bring everybody in. And then people have
different opinions. So getting everybody on the same page can be difficult. Often people aren't on the
same page. And so there's lots of conversations there. How do internal politics and potentially
even investor pressure distort product strategy in these types of situations?
That's a great question. In a lot of different ways. One of the biggest things I've seen is that
silos within organizations, and they can be functional, they can be regional, sometimes they're both,
they create conflicting agendas. And so when we talk about misalignment from business leaders'
goals down to product team goals, down to tech team goals, that sounds like, oh, you should be able to
figure that out. You know, you should be able to get aligned. But the reality is it's in the thousands
of tiny decisions that the engineers and the product owners have to make on a day-to-day basis where
these things start to drift. And internal politics can play a really big part because if I am an
influential member of the team, I might be able to get a feature kind of added over here just because I'm
really influential and I have the right relationships. If I'm a salesperson who's
incredibly successful and I'm about to close a multi-million pound or dollar deal, I might be
able to sneak a little bit into the product roadmap over here. And when you are replatforming,
your feature list is full. It's full of all the features that already exist and you need to rebuild.
I've actually seen companies completely scrap the replacement part of the replatforming because they
got so waylaid by, you know, not to throw salespeople under the bus, but customer-facing
colleagues who promise things to customers. Just to make this example more explicit, more colorful,
I was looking at a company based in Spain. We were looking to potentially acquire them. And they said,
right, we've just started this replatforming exercise because our existing software is old.
So we've built this new database and then the new software is going to run off the new database.
And so I asked to take a look at the product roadmap and I spoke with some of the product
colleagues and I started to see little things in the product roadmap that were red flags to me,
that they were doing things for new customers. They were putting new customers on the new software
first. They had no thought about how they were going to migrate the old customers from the legacy
software onto the new. And so I started to see new features, features that the old software didn't do
coming in before they had actually rebuilt what was there. And that just seemed a bit shaky to me.
Two years later, we came back and had another look at this company. They had two platforms now
and one had new customers, every customer since two years ago. And all the old customers were still
on the old one because of politics. The salespeople had the loudest voices, account managers had the
loudest voices, new customers won out over existing customers. And yeah, and that's just one of many
ways I would say it can influence it. Yeah, that's quite a situation because then you've got a real
mess on your hands. You've got your legacy platform for your legacy customers and your new platform for
your new customers. And that's easily two to three times the amount of work.
Yeah. And the other thing that was a huge red flag to me was they didn't have an aligned data model.
So the longer those two are running in parallel, they're generating different shapes of data.
It gets harder and harder to bring them together. So the longer that goes on, the harder it gets,
again, from a data perspective to get the data out of the old and ever get it into the new structure.
Yeah. And then trying to do analysis on the data that's there so that you can understand your
customer base or anything like that is that much more tricky because now you've got two different
data sets you've got to understand. And that doesn't mean that they're always going to be
comparable or sometimes you just end up in a world where you just cannot compare the data sets.
And it's so common. I find that so common. But it's natural, too, because it's like they put one
team of software developers on the new platform and a different team on the old platform. And then
therefore, the ones that are working on the new platform are always like, we could do this better.
Let's do it better. And let's do it like this. Without thinking about the impact that has on,
we still got to move those customers across. You still got to get the data across. So yes,
do it better, but not without a lot of thought as to how you're going to transition from old to new.
And then your migration story becomes extremely expensive. I've seen scenarios where a migration
has failed. You know, you can roll back, but customers tend to have to spend downtime and take
systems that they care about offline to be able to do this. Because typically, if you've got this type of
software, somebody's built something on top of it or depending on it. So it's not just your piece
that's going to have a domino effect. Yeah, you can really end up in a world where a migration
failure, like that's a whole day or hopefully not more than a day of somebody's life. You may have
just taken a huge chunk of somebody's work life out. You've not been able to migrate. And you can only
do that so many times before a customer is just tired of dealing with your company and your product
and your inability to help them move to what you tell them is the latest and greatest that they
need to move to. Absolutely. And then you start to kind of plant a seed of, well, if they're moving
within the same company onto a new product, that's a great time to go and look and see if there are
other products on the market. Like if you're making me move, and especially this is the other one that
gets me is the number of replatforming exercises and migrations that I've seen where the product team
or the organization isn't planning on bringing the data across. No, no, no, we're just going to,
we're not going to bring the data across. The customer will just enter their data again.
And you think, well, you're giving them a fantastic opportunity to go to another product. Because
if you don't bring their data across, you've just taken all the stickiness out of your product
because they're starting over. And I think people underestimate the value of bringing
customers' legacy data across sometimes. Yeah, well, I mean, that data, like you just said,
it's the sticky part of the product. It's the fact that you've put five years of your data into
that product that makes it sticky. You may love the product. It's great and everything else. But
without that data, you'd be a lot more able to move. And it's companies that can take a data set
from another company's product and then migrate that into theirs that have the ability to gain
your business. Because if you can move five years worth of data without a problem, then you've got
feature X and Y that I don't have today. Sign me up.
Exactly. And I think the pressure of that is only going to increase the more AI is used in
the development of new software. Because that's already happening. I work with a fair few tech
teams that are already using, at least for prototyping, if not for the real software itself.
So companies are getting faster and better at prototyping new feature development. But from my
own experience and the experience of a number of contacts of mine, what AI is not particularly adept at
yet, I'm sure it will happen with time, but is managing old data into new.
If you are managing a product stack that has a data component to it, hang on to that. Because as you
start to compete with software-based products that are popping up more and more new, then that may be
your most valuable element that you've got going for you in your product stack.
So what real-world lessons would you hope that product leaders take away from reading your book?
Data, if that wasn't obvious. Don't make data an afterthought, is one. I think the other one is,
the biggest thing is understand what you are and be glad about it and open up the conversation.
I've worked with a lot of product leaders who kind of, when challenged by business leaders to be more
lean or be more agile, turn inwards and maybe go quiet and they don't kind of open up a conversation
with a business leader and say, well, what does that mean to you? We're all making assumptions.
Does that mean that you want me to do it this way or do it that way? You want me to focus on this?
To really open up that conversation and challenge business leaders who are using those terms to make
sure that they mean what you think they mean. I think that's a big one. And work with those
business leaders to say, well, we cannot be agile and we cannot pursue lean development principles
because we are replatforming and we have a fixed set of features that we have to build first.
And get those business leaders aligned to that reality so that they can help you manage your
colleagues because that's really hard for people who are customer facing to say, look,
we're basically not going to develop any new features for two years while we rebuild the
existing software. That's a tough pill to swallow if you're customer facing. So the thing I would say
is make sure you get your stakeholders aligned around that and be upfront about it because hiding
it is not going to help. Trying to squeeze in little features on the side is not going to help.
And saying you can do it alongside an already overstuffed product roadmap is not going to end well
because you can't. Something has to give. So I think those are some of the key strategies I would
focus on. What advice would you have for product managers who are navigating lean startups?
I think with lean startups, follow the lean principles. They're very good.
There's a reason that book, you know, alongside the agile development methodology has been so
successful. It really works in that scenario. I think the advice I would have to product managers
in lean startups is be aware of the maturity curve of your business. What really made a lot of these
principles hit home for me was my husband, who was an entrepreneur, sold his business. And when he
took private equity investment, you know, from day before to day at two, I could see the values of his
business starting to change from innovation to execution. So for product managers, have open eyes and
see that coming and ask yourself, what do my business leaders want? Do they want innovation?
Do they want me to go searching for new markets and try to find product market fit? If so,
then lean principles, 100% new software. Or do they want predictable performance? Do they just want
the revenue growth that was predicted coming in regular to monthly board reports, etc? Because if
it's the latter, you might add some features, but not ones that you can't monetize, you know,
not ones that take you into a new market where you're trying to find new customers, you want to go
adjacent so that your product strategy fits what your business leaders really, really want. And that
is a different kind of layer and level to communication.
And then what about advice for PMs navigating large complex organizations?
I mean, gosh, if I could crack that, if there was a cure, I would be all over it. But I think the key
thing is alignment across the teams. So having the appropriate stakeholders. And, you know, there's
a ton of work around communication and management principles and managing stakeholders, understanding
who your influencers are in the different groups, identifying those influencers and keeping the
right folks in alignment and in communication. Because not everybody wants to know everything and
every milestone of your replatforming exercise and not everybody in the organization needs to.
But there will be a subset of people who are very curious about what's happening that are very
engaged and very interested in knowing the ins and outs and how it's going to work and what it's going
to do. And it's definitely worth keeping those folks very much on side and involved and structuring
communication so they have access to the information that they need when they need it, not when you
release it. That's the other thing that I feel like is always really tricky. I mean, you could tell me
something tomorrow, but if I don't need the information tomorrow, I need it three weeks from now,
that's no good to me because three weeks I will have forgotten. You know, so making it
accessible and having the right stakeholders available to engage as and when that engagement
is prescient and necessary, I think is really critical. Yeah, thank you for that. So where
can our listeners find your book and connect with you about these topics? The book's available from
major booksellers, so you can find it on Amazon or wherever you like to shop. And my website, you can
contact me through my website, which is just katytamblin.com. And I love hearing feedback. So I love
engaging with folks that have read the book or are interested or just want to talk more about it and find out
how this works in their organization. And if there's anything I can offer or insights that would be
helpful or if they just want to have a moan, that's always fine too, because I get that. So I love to
hear from anyone who's interested. So one final question to help our audience get to know you a
little bit better. If you had to give a TED talk tomorrow on something totally non-work related,
what would it be? It would be around balance. For me, I think I'm only as good professionally as I am
personally. And if I'm out of balance, that tends to deteriorate really quickly. So I think life and
keeping contentment and success, however you define it, for me personally, is very related to have I got
the right balance? You know, have I got enough time, enough energy, enough oil in my tank to focus
on my personal relationships, on my family, on the things that matter? And equally, have I got enough
time, structure, and ability to focus on the things that are challenging and interesting for me, which
for me is software development and managing data. And I know I have weird hobbies, but you know, it's
about finding the right balance across all of those things so that we don't get lost as people and we
don't lose sight. I've worked in organizations in very, very challenging circumstances. Re-platforming
is hard, very hard. And so you get a lot of stress, you get a lot of tension. When people start to miss
deadlines, you see some aspects of people that can surprise you. And I find that that can be really
hard. You know, nobody's bullying anybody or being rude or being stressed when you're hitting all your
deadlines and you're making all your numbers, right? But when you're not, people who are struggling
can often act out. And so I think balance is important for all of us to be the best people
we can be in all of our environments, work, home, whatever it might be. And when we get out of
balance, we're much more likely to have bad behaviors pop up. Yeah, no, that's a very interesting
topic. And yeah, I think we've all seen examples of exactly what you're talking about there, because
when things get tense and they get hard, people start to fall apart. It's a tough one.
Yeah. And I think one of the most interesting things is keeping it in perspective. Yes,
business is really important. Hitting deadlines is really important, but none of it's more important
than how you treat your colleagues and how you just treat the people around you. I've been shocked
in my career at how easy it is for some people to lose sight of that.
Yeah. Well, thank you so much for coming on the show.
Thank you for having me. It's been absolutely delightful speaking with you today.
Today's episode of Productly Speaking was brought to you by the letters P and M. If you enjoyed this
conversation, subscribe so you don't miss the next one. Share it with friends, coworkers, or anyone who
loves a good product story. Got feedback? We'd love to hear it. Visit www.productlyspeaking.com,
connect with us on LinkedIn, or email us at hello at productlyspeaking.com. Thanks for listening.
And remember, keep calm and build on, especially when the meeting invites keep multiplying.