S4E3: Beyond Dogfooding: Balancing Complexity and Market Insight with Jake Bowen-Bate

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 product manager with nearly two decades of experience across
startups, agencies, and global corporations. He is also a certified scrum product owner
with substantial experience working on agile projects. He moonlights as a novelist, Army
Reserve Officer, a dog dad to a rescue terrier, and an occasional amateur chef. I'm pleased
to welcome to Productly Speaking, Jake Bowen Bates.
Thank you very much, Karl. Great to be here. And thank you for the introduction. Nice summary
of my life and achievements.
Yeah, it is good to have you here. So we have talked about a number of different topics that
we wanted to talk about on today's podcast. And one of those was like navigating product
complexity in fast moving environments, which you've had some experience with. What are some
of the biggest challenges you've faced when building products in high growth or high pressure
environments?
I think one of the big things and I've actually written a little blog post about this and I
talked about it a bit is this idea I have of, you'll be very familiar with the expression
and it's used across our industry about, you know, we're building the plane while it's in
flight. And what I add to that is I think we're often learning to fly the plane at the same
time in the kind of companies we're working in.
And so you have this sort of three-way challenge of you're simultaneously trying to build it,
you're trying to fly it, but you're also working out what's the best way to operate this? Who
should we have? What are the roles? What are the responsibilities of those roles? How are we
measuring ourselves? Who should we be hiring? What kind of mechanisms should we be following?
And these three things I think are often an intention to a certain extent. And it might be that you
briefly have the right way of doing things and you have the right team and you have the right
structures and that gets you through a certain period of complexity, but then something changes
and now you need to change your operating system, you need to change your roles or how you're doing
things. And then probably the other one, and again, I think this will be very familiar to anyone who's
worked in a tech startup. So I almost hesitate to say it because it's so obvious is that feeling of
capacity and demand never being in sync. Maybe this is the case in all organizations, but I think it's
particularly in tech startups where you're trying to grow and you're always chasing the next
opportunity and always trying to build more things more quickly, but never having the resources to
do it. And that puts a lot of pressure on people. And I think it's often a little bit overlooked.
You know, we talk about how exciting this is working in tech startups and fast moving environments,
but actually just spending years feeling like there's too much work to do and not enough people
to do it, I think can be a struggle as well.
Well, and also in a tech startup, you've got, like you talked about, there's a frenzy going on
and it's build, build, build, because we've got to build this, we've got to build that. But in addition
to not having enough time to build the things, there's like not enough time to think about why
do we have to build these things? Asking the questions that you would like to ask, like how
many people are truly going to buy the product if we build this feature?
Definitely. Yeah. And I think that that can be one of the struggles because you have to decide
how much data do we want? How much validation do we want? And there's no perfect answer. You know,
you can validate to the nth degree and discuss and debate and then never build anything or you can
throw yourselves into building things and half of it turns out not to be useful or not to hit the
objectives you want. And somewhere in the middle, there's a happy medium, but it's never obvious at the
time when you're in the middle of it. Yeah, that's a tough dichotomy. And having worked in large
companies, you get a version of this. The key difference is in a large company, you typically have
enough money to keep going. Whereas in a startup, you can get in that scenario where money is
literally the thing that's going to derail the whole project. If you don't make enough,
if you don't sell this one customer, if you don't have that coming in, well, you know, there's a point
where you do literally run out of money. Yeah, exactly. So it's always got that little edge of
fear behind everything you're doing as well. Yeah. So you wrote an article called Why You Should
Sometimes Feed Your Dog Pedigree. Tell me about that. This came from, obviously, it's a little bit,
you know, trying to be a slightly humorous title, but it came from this idea that,
you know, we as product managers, and I'm sure most people listening to this will be familiar
with the term dog fooding. But just in case they're not, the idea is that we should probably
be trying to use where we can our own products that we're building. And sometimes it's very
difficult to do that. If you're building products that are for an entirely different market,
then of course, you're not going to be using them. But if you're building something that's
for product managers or for tech companies, or it's just a general enterprise product, then of course,
you would want to use it day to day. Why wouldn't you? And there's lots of advantages to that,
because you get really familiar with it, and you're testing it constantly. And you'll spot
bugs the minute that they hit production, and you'll understand all the user experience issues.
And I think all of that has a lot of truth to it. But what occurred to me from an experience that
I'd had after moving on from a previous role, where we dog fooded our own product very extensively,
and then I went elsewhere and started using our biggest competitor, and not just a peer competitor,
but the big enterprise grade dominant monopoly in that market. And I suddenly realized a lot
of things that I had probably just missed when I was dog fooding the product that I was building,
that by not using the monopoly in the market, and the most popular product that was out there,
the pedigree charm equivalent, that maybe I just wasn't quite understanding what some of our
audience or prospects wanted. And when they spoke to me about features,
it was very easy for me to dismiss those as nice to haves. They're not very important. We don't
really need them. When actually, I pretty quickly realized once I started using them that I got a
very strong emotional attachment to them. And you would have had to pry them from my cold dead fingers
if you'd wanted to, to get me off that product and onto someone else. It was a bit sobering. And
I certainly don't mean it as a criticism of the previous company, I think more a criticism of myself
as a product manager that I just felt like I'd been missing so much for the last couple of years.
So that's what the article came out of, really. Yeah, that we can get into a spot where we get
kind of blinded by our own tunnel vision, so to say, of where we see the way to use our product.
And we're on that road of this is how people want to use our product. That opinion is because of the
people you're talking to, which may be limited in scope. You get a blinkered view of the market,
I think. And in a way, ironically, you get you can get a blinkered view of your own product as well,
because what I suspect is the case, you start to overlook some of its flaws. And when you're
using something every day, you very quickly become inured to how many times a day am I having to
refresh this product or do a hard reset. And you probably forget that actually you're doing that
a little bit more often than most people would tolerate. And alongside dog feeding, there's another
really valuable question that product managers should be asking ourselves, which is, how would I
feel if I was forced to use my product for 24 hours against my will? And if you're dog feeding
every day, you can't get that experience. And I sometimes think it would be, it would be good to
be able to get that experience of I'm taken away from my favorite thing. And I'm forced to use this
product that I build 24 hours. What would that feel like? And that could be a really interesting
question. And yeah, we just lose sight of that if we're dog feeding it every day.
Which I guess if it's possible to use the big behemoth enterprise product that dominates
your market space, if you can get your hands on that and you can use it for a day,
that might give you some of that perspective. Yeah, I think that would give you really
interesting insights. And it would be fascinating to understand more about, you know, what attracts
people to that product? What are the emotions that people who do use it having? And it's a really
difficult balance. And I certainly don't think and when I wrote the article, I'm not suggesting
that people should just stop dog feeding their products, and everybody should be using their
competitor products. I think that's crazy, really. And you'd lose a lot as well. There's no perfect
answer to this. I think some of it is being a bit more deliberate in what you want and what
the outcomes you want. And it's going to vary at different times and maybe even vary for different
teams. So do I want to get really close to my own product? Do I want to have a really deep
understanding of the UX and be really close to the bugs? And is that what's going to benefit me
in the kind of stage of development I'm in? Then yeah, of course, do as much dog feeding as you can.
On the other hand, if I really want to understand the market and I'm trying to introduce a highly
competitive product that's barely known up against a behemoth, then maybe spending a little bit more
time using their products and understanding their current user base would benefit me more
than dog feeding my own. Well, and sometimes these products that are dominant in the market,
they're expensive, they're going to be hard to get your hands on. You might need your company's help
to get your hands on these products. And I think that in your article, you talked about
using a competitor's product internally may raise some eyebrows. I mean, it's not every day that
you get the approval to spend money and let alone spend money on your competitor's product. How can
leaders kind of help foster a culture where that kind of exploration is encouraged rather than
discouraged? I think one of the ways is something that I'm really keen on for leaders in general,
which is trying to set outcomes that they want rather than telling people how to do things.
And I think being really clear about the outcomes they want, setting parameters, but then giving
people a lot of freedom as to how they achieve those outcomes. And I think it applies as much as
anything here. If leaders are clear that the outcomes they want are really good understanding of the
market, improved research, better competitor analysis, then it should be easy for me as a
product manager to say, the best way for me to achieve the outcome is to spend X thousand pounds
with a competitor. And it might sound crazy, but that's how I'm going to get there. And I think for
leaders that do that rather than focus on what are you doing and how are you doing it, but what are
you achieving and are you achieving the outcomes they've set is the biggest thing. And also for them to
model curiosity themselves and talk about learnings and so on. I do think it's one thing we do well at
Amicus, which is where I currently work. There's a lot of talking about learnings,
what we're reading, what competitors are doing, people constantly keeping an eye on the market,
posting things they've seen on LinkedIn. And I think that spirit of openness and we're in a
competitive market, but that doesn't mean that we dislike or dismiss or disapprove of our competitors.
We're interested in them and intrigued by them as curious people. I think that's important from a
cultural point of view as well. Yeah, I think that's a good balance to have where it's less about
trying to fight the enemy competitor and more about they've got people that we want to serve.
What are they doing differently and how is that playing out? I think it's interesting. You also
mentioned, oh, it's easy when you're dogfooding your own product and you hear feedback that doesn't
really quite jive with what you've gotten before to dismiss features as, oh, that's a nice to have.
And yet you've talked about how some of those nice to have, once you got your hands on them and got to
use them, that kind of became, there became an emotional attachment to that. And it now became like a central
part to how you used that type of software. How can product teams better identify and respect those
emotional anchors? I think acknowledging and identifying the emotions is a big part of it.
And one thing that we've been trying, and I don't know if it's necessarily something you want to do
all the time in every circumstance, but it's actually being very explicit about the emotions
and the feelings we want to provoke. And as product managers, we'll probably be quite familiar with
formulating what we're building in terms of, I want this feature so that I can do this,
or I want to do this, so I need this feature. But I wonder if we sometimes should go another level and
say, you know, the user wants X feature so they can do Y, but so that they can feel Z. And if we
identify the feeling we want to provoke in them, then it's much easier to say what they do is
unimportant. That is a nice to have, but the feeling isn't a nice to have. The feeling is actually
essential to the feeling that we want our users to have. And therefore, we're going to build this
in inverted commas, nice to have feature, because that's something that we've identified
as critical. So I think that's one thing that really helps. And it's another area we've been
working on a little bit, and I've been prompted into it by my current manager, Elaine, who talks a
lot to Amicus about how we want the product to feel when we're setting out a vision, particularly
three, four, five years down the line, where we don't necessarily know what it's going to do,
but we know what we want it to feel like. And we know what the kind of emotions we want to provoke.
And I think a lot of our sort of user stories, we could start set out in terms of not just things
that we want to enable people to do, but how we want them to feel. So I think that's something
I'm going to focus on a lot with things we're building over the next year or two.
So tell me a little bit more about that, about how you've already, you know, you're talking about
looking at that long term strategy and really talking about how a product makes somebody feel.
What does that kind of look like in practice when you're defining that?
There's a couple of different things we've done with it. So initially, I'd set out a vision that
was a little bit of a feature list, which of course is something that's easy to do. And we've all got
wish lists of features. It feels very difficult, particularly a company our size and tech startups
where things move so quickly, it's very hard to commit to features down the line, we want to be
able to adapt to a changing market, we want to be able to reprioritize quickly. So of course,
we've got features we want to build in the next six months. But when you start to look two,
three, four, five years down the line, that feature list becomes a little bit less useful.
So we very consciously adapted it. And the research that I did when then talking internally to
stakeholders, getting inputs from teams, inputs from the product managers that I oversee from
executive team, I asked them, we want to grow, we have an ambition to get to a certain growth over
the next five years. To get there, how will Amicus have to feel to use and really trying to get them
to think not what features will we have, but what would it have to feel like for us to be that
successful? And what would our clients have to feel every time they're using it? Where we want
to take that then is to build something that I've been calling a concept car, rather than a product
vision, something that kind of evokes feelings in people that the concept car or the fashion parade,
where what you see is not what you're going to get, it's not what's going to go into production,
but it's something that's intended to kind of challenge and provoke and give a sense of the feeling
that it will have rather than necessarily worry too much about the specific features.
It is a bit of an experiment to be candid. This is the first time that we've done something like
this, but I think it creates a much more useful framework to give a sense of direction for product
managers, the individual product managers that are then working on areas of the product for them to
have a sense of where we're going and what they should be focusing on and what's going to be
important for us as a company and as a product down the line without having just listed a load of
features or dictated exactly what we want to build. I can see how in a scenario like that, it would be
just really easy to put a blanket statement out there like, well, the software should make people feel
good, it should make them feel like we've saved them time, we've saved them money, we've improved their
life in some way. I mean, the tech industry has been saying some form of that for ever since I've been
alive. I don't want you to have to reveal any company secrets or anything. But what does that
actually start to look like? I mean, to what level of depth are you taking that?
Some of the statements will be more broad. So it should feel quick and easy to use. I should feel
reassured that I'm compliant, but there are some bigger picture statements like that. But also
going down into individual pages and looking at particular areas of the product and saying maybe
this page should feel quick to navigate, it should feel as if it's barely present in my workflow,
it should feel as if I hardly even notice that Amicus is there day to day. Things like that,
that I think can then be quite revealing about the direction we want to take things and the kind of
product that we're trying to build rather than as you say, big grand statements like we should just
be making people feel happy and feel better off or whatever. So in taking that type of approach,
have you gotten good feedback from customers that have interacted with this?
So we have shared the early vision prototype with a quite select number of customers where we're
conscious of striking that balance between wanting to show things to customers where it is a bit of a
long term vision and it's not necessarily very helpful for them. But some are more strategic
customers where we are very keen to kind of build a long term relationship with them and get them on
board for a longer term journey. We've shared some of this vision stuff and had really positive
feedback and they've interacted with it and given us feedback on it. And a lot of the ideas of what
we want to do with the products have come from them as well. And I think they've found it really
exciting. I think by and large, clients like to see the vision of where something's going,
particularly enterprise B2B software, where they are candidly spending an awful lot of money on it.
They want to know what it's going to look like in a few years time.
No, that's really exciting to hear. And it's neat to see that you've got a connection that
you're able to make with those customers and those clients and to actually start getting some of that
feedback out of there because you've talked about this is what the product should feel like. In
addition to we'd like to empower you in all of these higher level achievements, getting down into
that granular level of this part should feel like this, this part should feel like that. What do you
think about that? And then getting feedback that way. That's a really interesting way to do it
because a lot of times we do just say, well, if it does this feature or that feature, tell me what
features you need. And sometimes we miss. I think you're really starting to get into the science of
how to get what somebody actually wants, even if they can't state it. Because you could never have
told the world you need an iPhone. But then Steve Jobs gets up on the stage and says, here is an
iPhone. And everyone went, yeah, that's what we wanted. Yeah. And it's such a product management
cliche, but it's the faster horses thing, isn't it? That if you go back 150 years or something and
ask people what they want for transport, it's faster horses, not cars. But the reality is it's
cars that are going to change the personal transportation industry over the century or so
after that. And I think that's where sometimes if you go and ask people what they want, they'll give
you a list of features, but asking them what they need, how they need to feel, what kind of emotions
are important to them. Those sort of things generate much more interesting product insights.
To get to that point, I think company culture plays a huge role in being able to have that type
of conversation. How do you see company culture playing into the success or failure of a product?
It's a really interesting one because I do think company culture is vital at a given time and setting
probably some of the things that I've talked about in terms of curiosity, setting outcomes rather than
digging into the details of how things are done, freeing people up to pursue things that they're
interested in, to go and ask questions, giving people space to trial things and giving people space to
fail, I think are all really, really important for success. I think maybe to take a cynical view, there's
perhaps an argument also that sometimes company culture doesn't have as much impact as we think it does.
And so much of success or failure with products can come down to luck, to timing, to external
circumstance and to individual people. And I was saying a little bit like how when we look at
somebody who's been very successful individually, we might say, well, it's because of their morning
routine and they drink kale juice and they get up at 5am. But the reality is there are lots of people
who are doing that and are not being successful. So maybe there are other elements to it. And we
could look at companies that famously have cultures that have generated amazing products like Google,
but the same culture that's given them those really successful products like Gmail and Android
have also given them Google Wave and Google Plus and things that have been less successful.
And perhaps that's part of it. And it does come back to that having the ability to fail or the
willingness to fail. I think it can cut both ways. And sometimes we can perhaps put too much emphasis
on it. But a lot of those essentials of giving people flexibility and trust and freedom to
experiment are always going to be valuable.
Yeah. And you mentioned Google Wave. That's a product I haven't heard of in a long time. But Google
Wave is basically everywhere now because it's how you work on collaborative documents,
whether they're Google documents, Microsoft documents, any number of products out there
that allow for simultaneous collaboration. And that technology that lets you be in the document
at the same time working on it together is pretty much the same stuff that they were doing with
Wave. And I remember seeing that and wondering, why would you use this at first? And then it was
like, oh, wow, this is wild when people can co-collaborate.
Yeah. And now it's amazing, isn't it? The idea of not being able to co-collaborate on a document. And
occasionally I work with clients where we're not able to share documents because of their internal
systems or whatever. And I think, gosh, it's like back in the 90s having to send individual
documents around.
It's just has changed how we do things. And I mean, it's part of what's helped remote work be
plausible, reliable option for so many people is that, well, you can actually work with people
in different places on the same document. That is just pretty amazing.
Yeah. So have you seen examples where internal misalignments in a company have led to product
breakdowns?
I definitely have. I'm conscious of probably not wanting to talk too much about specifics
because I don't want to critique individuals or things that are too current. But I think
some of the patterns that I've seen without going into specifics, probably the biggest is
teams not having a shared understanding of what's being built or why it's being built.
It can seem crazy that you can have a small team of five or six people and actually they
don't all have the same understanding even of what they're building maybe over the next
couple of months, let alone over the next six to 12 months. And I think it's really easy
to underestimate. And I think this is particularly a challenge for product managers where they
understand something really deeply and they assume that everybody they're working with
has the same understanding of them and they believe that they've communicated it clearly.
And it would be shocking to them if they actually spoke to some of them and said,
do you understand what we're building and why we're building it? The different answers
that they might get from the team. And I think when that happens, people, especially
high-performing, enthusiastic people who want to do a good job, they often then go off in
slightly different directions. And if the product manager isn't constantly bringing people back
together, making sure everybody's got that shared understanding, it's very easy for things
to start to fall apart and sometimes in ways that aren't immediately visible. And it's only
too late, two, three months down the line when you realize that a miscommunication much
earlier in the product has created some kind of horrible hidden debt that is now going to need
to be dealt with. And I think the other one probably is when decision-making kind of stalls
and it's another, it's the key role of product managers really is to be great decision-making
engines. And if that starts to stall and people are waiting for information or no one feels empowered
to make a call, you get this sort of debate, iteration, lack of forward momentum. And especially
in startups where exactly as you alluded to, time is money and money is time and there's
not a lot of either. They're both precious resources. Keeping those decisions made and
clearly communicated and a bit of momentum I think is essential. And when that starts to
go wrong, that's when you can get breakdowns in products.
Yeah, I think your point about having like a five to six person team that can still be out
of alignment, even though they've been listening to the same structure about the product,
they've been listening to the same stories is an interesting one because it really does
speak to how we as individuals perceive things differently. And like you can say the same message
to a group of five people and they each hear a slightly different version of that message.
And everyone has their own heuristics, their own mental models for things, their own different
experience. And exactly as you say, they can sit through the same 30 minute presentation
about something and they'll all go away with a very slightly different impression of it.
And this constant just rechecking, bringing people back together, I think is a process that
never ends. It's probably the most important job almost of a product manager.
Yeah. And it's one that we don't always spend a lot of time on because there's always a hundred
other things that we need to do too.
Definitely. And I think that's why it has a tendency to slip because it's easy to focus on
everything else, the stakeholder management, speaking to clients, writing documentation,
whatever else it might be that there is so many other things. And it can be easy to just
assume that, you know, the team seems to be working effectively. They seem happy, they seem
productive, they're working, getting through tickets, stuff's looking good, very easy to
leave it a little bit too long before checking in with them, or even just not wanting to patronize
people. And there's plenty of times where I haven't wanted to go back and retell the team
something that I think I've already communicated because I don't want to bore them or waste their time.
And then afterwards I think, I really wish I'd actually just had that meeting and told them
what we're doing and what the plan is. Cause I realized later that people didn't fully understand
it or I hadn't properly communicated it before.
Yeah. You have that thought in your mind that you've already done it and that it's just going
to annoy people. It's going to make them upset with you. And yet that's kind of a key part is not
annoying and upsetting people, but to keep reminding them of the why and the what. And then when you have
like multiple PMs working on different parts of a product, there's now a cross PM communication
piece that has to happen as well, because everybody's got to be generally aligned because
you may be a specialist in your area of the product and I'm a specialist in my area of the product.
We have to at least be aligned on the product itself.
Absolutely. The complexity just grows with every level and then everybody else as well that needs
to be kept in the loop that needs to be informed, you know, how are you getting to market? How's the
marketing going to work? What are the clients expecting? You might've spoken to the sales team
three months ago and they no longer are selling exactly the thing that you were building or you're
no longer building the thing that they're selling. So the communication need never ends.
That misalignment can happen between product and sales quite easily. And yet product and sales
absolutely need each other because sales is how you get the money in the door and it's how you get
the customers and product is what you're actually selling. So those two disciplines are a lot
more tightly connected than we would probably like to think.
Oh yeah. Yeah, absolutely.
So what advice would you give to product managers trying to navigate complex organizational structures?
Personal relationships are a product manager's best friend, I think. And it's one of the things I
enjoy about product management is even in this very, you know, we work in tech companies often
remotely. There's a lot of tech involved. There's a lot of asynchronous communication, but having
really good relationships with people across the company in all sorts of different roles, exactly as you
allude to, sales is so critical to the success of product, but so is marketing. So it's having
good relationships with executive stakeholders, with really junior people in the support team,
whatever it is, not to mention, of course, your engineers and your designers and so on.
And taking the time to build those relationships and get to know people and get trusted by them and
build trust so that they know that you're someone that they can come to and that ultimately when you
need a favor or you need some help, that they're there for you. I think that's really important.
And building your own almost personal brand as somebody who can be trusted, who gets things
done. That's something I would advise any product manager, especially in complicated org structures.
And then the other one, and I think we were just alluding to this really, but just over-communicate
the extent to which every piece of communication just is never quite enough. I was thinking about it
as like throwing rocks underwater. They just, they don't go anywhere. You think they will,
but they just sort of go a little way and sink to the bottom. And that's like every time you try
and communicate. So just do more communicating, different ways of communicating, understanding
that people receive information in different ways. Some people would love to be brought onto
a 60 minute call and have you talk to them for an hour. Some people want to read a quick summary.
Some people want a weekly email. Some people love JIRA tickets and Notion documents. And so you have
to kind of be quite multimodal in your communication as well and really take responsibility for that and
responsibility for making sure that people have heard your message and you're communicating with
them. I think it's a bit of a stretch to say people love JIRA tickets, but I get what you're
saying. I'm sure there are some people that do, but yeah. If you love JIRA tickets, please reach out.
I'd be interested in talking to you. I'll find the one person that does and let them get in touch with
you. Yeah. You also talked about how important it is to build your brand, your personal brand,
but to do that internal to the company. Can you tell us a little bit about how somebody might go about
doing that? At least for me, I think a big part of it is being seen as somebody who can be trusted.
So really early on, making sure that you do what you say and that when people come to you for help
or to ask for something that they know you're somebody that can be relied on. I think building
a bit of a presence and it's part of the communication, which was the second thing that
you should be the person that's out there a lot of the time asking questions and talking about your
product and responding when people have queries and helping people to understand how your product
works and why you're making the decisions you are. So that is inevitably going to build a brand.
And if you're doing it in a helpful, constructive way with integrity so that people can trust you,
then you're inevitably, I think, going to end up with quite a positive internal brand. And I think
that's a sign of a good product manager.
So what's one lesson you wish every product manager learned earlier in their career?
I think the single most useful thing that product managers can do, especially when product
managers, as you know, come from all sorts of different backgrounds, a lot of former engineers,
some former designers, people who've got MBAs and have come straight into product management.
But the thing that really unites them, regardless of what their soft or hard skills are, is being
able to make a decision and clearly communicate it. And the third part that's really essential is
explain why they've made it. And if you can do those three things, you're at least halfway there to being a good,
successful product manager. And also to understand, and this is probably the lesson that comes in,
is the decision doesn't have to be perfect. If the decision is made, communicated and explained,
it can be a pretty mediocre decision because it's still better than a decision that hasn't been made,
communicated or explained. And I think if product managers learn that, they can get such a long way
and probably save themselves quite a lot of heartache and, you know, sleepless nights.
Yeah, perfect is the enemy of the good. And boy, we love perfect.
Yeah, exactly.
If you're the type of person that likes product management, wants to be a product manager,
you're probably also the type of person who's seeking perfection.
Definitely, definitely. And that will come with a lot of anxiety and sleeplessness and,
well, a lot of hair loss in my case, although I don't blame product management for that necessarily.
So are there any books or resources that you'd recommend for product managers who are facing
tough product challenges?
Probably the two. And I think they're both classic. So a lot of product managers will
absolutely be familiar with them. But I am a huge Marty Kagan fan. And I've read his more recent book.
But I think going back to Inspired is just a classic. And it is really great for understanding
what effective product managers do and how effective product teams operate. And I think
when you're a little bit stuck or not quite sure why things are going wrong, it's something I kind of
refer back to as a bit of a vibe and just open this up and refresh myself on ways of working.
And the other one, and again, a real classic is Crossing the Chasm by Jeffrey Moore. And I like it
because I think it's often billed as a book for marketers. And it is sort of a book about
marketing. But really, it's about driving adoption. And particularly that awkward phase
where you sort of you have got product market fit, you've got a good product, but you're just not
quite seeing the adoption that you'd expect. And I think it's got some really useful models for
product managers. So both of those, I think, for people who haven't read them, well worth
picking up a copy. Yeah, thank you for that. So where can our listeners follow your work or
connect with you? I have a website, jakebowenbate.co.uk with a hyphen between Bowen and Bate.
It's a bit of a split website because it covers both some of my professional writing and has some
links to my substack and some blogs that I write and also my novel writing. So I do also write novels
that are kind of loosely inspired by my work as a product manager. And some people who are interested
in tech might find particularly the first one interesting, but it is fundamentally a novel.
Both of those are there on my website. And also people are always welcome to add me on LinkedIn
and always really happy to have conversations on LinkedIn as well.
Yeah, absolutely. Thank you for that. And one final question here, just to let our audience get
to know you a little bit better personally. If you had to give a TED Talk tomorrow on something
totally non-work related, what would it be?
Oh, wow. That's an interesting question. I would probably give a talk about cooking.
And I think I'm certainly no great cook, but it's something that's really inspired me.
And I think one of the things I enjoy about it is that it feels quite different to product
management in that there are kind of right or wrong answers in cooking. And you get an output
that's very clear that you can take all the responsibility for. You stand there for a few
hours, you cook, you have something that either works or it doesn't, and you eat it. And a lot of that
uncertainty, the frustration, the trying to balance multiple stakeholders and get work done through
influence. None of that is there when I'm in front of the stove making some pasta or something. So
there's a real joy in cooking for me. And I'm not sure anyone would listen to my TED Talk about
cooking, but I would certainly give one.
I'm sure you'd have some takers that would be interested in listening to that.
Well, thank you very much.
Well, thank you so much for coming on the podcast.
You're welcome. Thank you for having me. Great to catch up. And I hope people have found it
interesting and useful. But yeah, thank you very much for talking to me.
Thanks for listening. And remember, keep calm and build on, especially when the
meeting invites keep multiplying.