S1E4: Driving Success in Your Startup

It takes a really deep market understanding and product manager maturity to, for example,
tell a senior vice president not to close that really big deal because it's not a good fit.
If you do that one time in your career, you should get a little metal on your shirt.
That's a moment where it's like you've demonstrated that you have the maturity to think that way.
Hi, I'm Karl. And I'm Danielle. And this is Productly Speaking.
We're product managers by trade, and here we explore the world of product management.
It's people and their stories. We promise to keep it entertaining,
and maybe you'll learn something. Shall we give this a go? Let's do it.
On today's episode, we're going to talk about some of the core tenets of product management.
How do you prioritize what to do with all the different inputs coming in? What do hiring managers
look for in product managers? And how does one even break into product management anyway?
There are many ways to do it, and we'll hear one of those stories today.
Our guest today is a specialty coffee connoisseur and even roasts his own beans.
But that's not why we've invited him. He started his career in medical device engineering,
moved into project and program management at Red Hat, and then became a product manager
at Service Trade. He then became the director of product management at Service Trade,
and ultimately decided to move out of product management, and now leads the Solutions
Architect team at Service Trade. Throughout his career, he's always been a customer advocate,
and his journey into and out of product management is an exciting story that we wanted to tell.
We are pleased to welcome to Productly Speaking, Adam Strong.
Hey. Hey, Karl. Hey, everyone. I'm really, really happy to be here.
Karl, I think it's really appropriate to start with a thank you for this whole journey. I don't
know if you remember 14 years ago now when I was interviewing at Red Hat. Yeah. Folks who aren't
familiar, I started at Red Hat as a technical support engineer. They liked my customer service
skills. They liked my attitude, all that stuff. But they wanted to make sure that I had the
technical chops to be able to support that enterprise tier customer base. And so the
managers brought in Karl to test me and ask me really tough questions. Yeah. Well, I was one of
them. I was much younger back then. We all were. I passed your test. Thank you for passing me there
because none of this stuff would have happened. It is funny to think about it like that because
yeah, that was colloquially known as the Karl, at least in our circles. Did I do the thing where
I would basically talk about one of our products for like five minutes and I'd say like the key
points two or three different times and then turn around and give you a test on it? Yeah, that and
also off the wall questions that some of which you'd have to be a long time Linux user and know
that history. You had a couple like engineering ones where you just wanted to see like, how would
I say in a high pressure situation? I have no idea. I'd have to look, which, you know, it turns out
to be really important for that type of job and many jobs too. And you're not expected to have all
the answers all the time. Being able to stop and say, I don't know, is a skill that you can take
with you anywhere. I know that I had more answers in my career at that point than I do now as a
product manager. It was pretty black and white. I mean, you either knew the tech or you didn't.
And product management, as you're quite well aware, there's a lot of gray area that you have
to figure your way through. Yeah, there's some good frameworks. There's some good methodologies,
but it is a lot of sitting comfortably with ambiguity and charting a ship's course through
real thick fog and just hoping that everyone on the ship trusts that we're heading in the
right direction and doesn't mutiny. So you started in technical support, as you mentioned,
how did you go from technical support all the way into product management?
Yeah. Great question is that these trajectories are never really straightforward. Like I have no
idea what I would tell a college student like how to get here because my path is just, it's so
personal. It's so random. Kind of the theme throughout my career is being invited into
really ambiguous situations where even the problem itself isn't well defined. And so
in technical support, I was a fine support engineer. The feedback I got was, you're fine.
But where I excelled was a kind of meta layer of how do we as an organization offer support
and streamline that and scale it. Red Hat at the time was in this explosive growth phase where
we added 10 times as many employees during the length that you and I were there. And so
I didn't last very long in the front lines before they pulled me into project and program management.
The letters P and M have followed me relentlessly throughout my career.
I developed this specialty in knowledge sharing, which was a trend at the time and something we
really needed to do. You solve a problem once, how do you reuse that knowledge across an organization
that is maybe many hundreds of people. This is important because I ended up working with
software engineers, technical writers, SEO optimization people, support staff from front
line people to management, the VPs in these kind of continuous improvement loops of how do we
deliver better and better support. But there was also this product that we were building at the
time, actually several. There's the knowledge base and the customer portal for customer interaction.
But then there was this also this really cool search and pre-chat GPT, all that stuff,
AI analytics driven recommendation engines. As you're typing in your question to create
your support case, it's saying, oh, we've actually seen the answer to that already. Why don't you
just read this? And that's what you need to do to fix it. So I became a program manager over that
continuous improvement loop. And despite not having a product manager title, I was really doing
a lot of those types of things, talking to end users internally, talking to engineers saying,
here's the not to overuse the phrase low hanging fruit, but like when we leave this room, do X,
Y, and Z and it will be better based on this metric, this metric, this metric. And I owned
that process basically until we had the tech stack really well defined. And the thing that
we were missing out on was the internal user adoption, the support engineers following the
workflow, if you will, of what was required. So the improvement strategies at the tail end
of this whole program were really repetitive. It just needed to do the steps that we talked about
and it's going to work out. They didn't do the steps and so it didn't work out in this case.
It's just we got to do that. That ran its course and had this fork in the road in my career.
I had one manager who I really looked up to, who was heading in a product management path
of, Hey, be my product manager over this recommendation engine type thing. Follow me,
we're going to do all these cool things. I think you'd have a lot of fun doing this. And then
another manager who I really looked up to who said, Hey, the knowledge and content is really
the meat of this thing. Follow me, we're going to take on the documentation team and do people
management and people leading and take your career in that direction. So I had kind of this fork of
which one I would choose. If you think I chose the first one, you'd be incorrect. I actually chose
the second people manager one and spent several years doing that and actually working more with
people and growing careers and all the stuff that comes with that and not this product management
thing. Should I have taken the first path? Ultimately, I decided that I would be more
happy doing that than this other one. Captain Picard says, you don't want to unravel your
tapestry. I would not change any of the choices that I've made because I like where I am now,
even though the path here was very indirect. Going down the people manager route probably
really prepared you quite well for product management where you have to really be able
to empathize with people and you have to really get in and understand the problems that people
are having. And just the amount of one-on-one time that you end up having as a people manager,
you start to learn how to have those conversations a little bit better, just be able to suss those
answers out a little more. My ability to sit through incredibly stressful, high stakes
conversations that are just ridiculously uncomfortable. My threshold is really high
and that's not a pat myself on the back thing. I've just been training for years. That's not
only having difficult conversations about what other people need to be doing. It's also taking
accountability for your own decisions, your own prioritization, let's say missteps, or talking
with difficult or angry customers. The higher up you get in your product management career,
the bigger and more enterprise your customers are going to be. Getting called to the carpet
to do what I like to call the congressional hearing meeting where it's you, whole bunch
of cameras on you, and a room of C-level executives from your most important customer base pounding
their fist in the table, letting their constituents know how important they are, not folding and
melting in that situation is incredibly important and that time and people management really
prepared me for gracefully handling that kind of stress. A friend of mine who still works at
Service Trade, he had been courting me to join the company for a long time. Eventually he won.
You can look up Service Trade now and see who we are and what we do, but I want to paint a picture
of where we were at the time. A 30 person startup that was in an industry, commercial service
contractors, yuck. Why would you ever want to be in there? You were always really supportive of my
decision to leave Red Hat and join Service Trade, Karl, but there were some who were like, okay,
going to do that. That's sort of a step down for you. Good luck. It's easy to say now how incorrect
that viewpoint was. At the time, we were really small, scrappy, unproven. The investor community
kind of looked at it as like, I don't know. It was not an obvious safe place to jump. It was an
incredibly risky decision to leave and go there. Well, I think startup is a risk. What is it like
80, 90% of startups fail? You're always taking the risk that that startup is going to fail,
but that's also where there's so much learning to be had at a startup and it's just a lot of fun
to get in there and like, oh, we don't have X, we don't have Y, we don't have Z,
we've got to build it all. I love that. I really do love getting in there and just building from
scratch. It is a very specific type of product management and you have to be aware of those
phases. The minimum viable products, classical MVP, fail fast, all that stuff requires a very
different mindset from inheriting something that is larger, more mature, has big code base,
has all sorts of technical debt. When I was in my director role looking at people who were going
to hire, I had to kind of weigh this like the right product manager has to be paired with the
right product in its phase and those skills. There are different types of PMs who fit different
types of problems and kind of sorting that out and just being really honest and open about what kind
of opportunity this is and what kind of opportunity this is not helps both the product manager and
the whole team and company feel really good about a fit. So my first step into product management was
really kind of terrifying in the sense that I'm like employee 30 or, you know, I think officially
I was 34 when I joined. But it came at a time in surface trades life cycle that was this really
big milestone moment. I came in to manage our second product and when a company goes from being
a single product company to a multi-product company, that is just an absolute transformation.
The days before looked nothing like the days after. And I was really kind of the face of that change
service trade. But what that meant was I was a startup within a startup because they didn't have
cross-functional integration infrastructure. You know, it's just me, this guy. I like to tell people
that all the sales, I was the guy doing the demo. So I would make the sales. When we won the customer,
I was the one doing the implementation. Let's take your data. Let's put it in the app. Let's
structure it. Get all the users in a room. I'm going to lead a training, going to get you live
and up and running and hit the button and now you're live. Great. And so when the customers
went live, I did all the support and I wrote all the documentation. And my whole career of doing
all sorts of random stuff was really important. I had to lean on everything that I had ever done
because I was really kind of a company of one and that lasted for arguably a little too long.
I have more gray hair than maybe I should. Yeah. I found that when I was in that scenario,
I was constantly going back to my boss like, hey, we do need to eventually hire for these roles.
We need to bring people in. This is not going to be sustainable long-term. And we did eventually
get support moved out and we're working on documentation and things like that. But yeah,
it's wild how you get in a startup like that as a product manager and you really do get to do
everything. Yeah, it's fun. It's unlike anything else. I think if that sort of thing is exciting
to you, you got to try it once. It's a blast. It really is. Every day is different and every day
is like, oh yeah, we don't have that. Oh yeah, we don't have that. Oh yeah, we don't have that.
And everybody's coming to you with a hundred different problems and they're not going away.
And it's like, I know that, I know that hold on, working as fast as I can. I'm one person over here,
but you then eventually get it. And when you start to see it come together, that's what makes it so
much fun. Yeah. Having that level of exposure to every part of the organization, I think is really
formative. You have to keep it all in your head. You know, when you talk about how do you prioritize
the next sprint? And that's like, well, all these inputs are kind of diffusing their way into my
brain. And then brain does stuff and priorities just kind of seem obvious like this, this is the
next thing to do. And of course I made some mistakes. I prioritize some stuff that I thought was
beautiful, really useful feature. And that hits the market and the user base and one guy cares and
the whole rest of the market does not. And it's like, ah, I think we're going to pull this.
You've got one fan who's writing, you're going, this is amazing. It was the best thing ever. And
then nobody else is interested. And you spend all that time building it.
During my interview at Surface Trade, the VP who was doing the phone screen said like,
how do you feel about talking with customers? I think my answer was, you know, something
the effect of if this role does not include talking to customers, I have a lot of concerns.
And he laughed and he's like, okay, yep, next question. So it's really important to talk with
customers, but I see, I see a lot of product managers set up these user meetings with the
friendlies that people are really easy to talk to. And you know, we really like what you're doing
because it's easy and you get good feedback and everybody's happy and everybody feels like they're
helping each other out. But in my experience, you get really weak feedback that way. I think
the users that you need to talk to customers, not just end users are the ones who are a little bit
ticked off at you. They're annoyed by you. They've got something to say, but they're not just
nitpicking. Like they're actually rooting for you. Like what you're doing for them with this product,
they are really invested in. They want it to be successful, but they are not happy. I think those
are the ones that you have to talk to first. In my opinion, they're your champions. Your product is
going to live or die by their hands. If they didn't care about it at all, they wouldn't be
talking to you. Exactly. You know, with all the different things I was doing, and of course,
the service trade got bigger, more people started joining my team and specializing in the pre-sales
thing. So I trained a solution architect to talk about my product. I trained implementation
engineers and support and all that stuff. And I don't do any of the video training anymore,
the documentation, it's all done by specialists who are all really, really good at it. But in
doing that, I found it really important to talk with a lot of different personas, talking to
people who haven't bought yet, who are in the process of making that decision. My perspective
is more business to business. In watching somebody go through that evaluation and that buying
decision process, you get to really understand what's important and what's not. And typically,
that perspective is just so different than any of the other things that come up in your other
meetings. If you're successful with it, you'll get a really good sense of who sales should sell to
and who sales should not sell to. It takes a really deep market understanding and product
manager maturity to, for example, tell a senior vice president not to close that really big deal
because it's not a good fit. If you do that one time in your career, you should get a little
metal on your shirt. That's a moment where it's like you've demonstrated that you have the
maturity to think that way. Yeah, you're absolutely not lying about that because the salespeople,
they see dollars and if there is any way they can spin a story to get those dollars,
they're going to do it. So what were some of the things you were looking for to
really show you that, yeah, this is not a customer we need to be going after even though there is a
high price tag associated with it? Understanding the market, not just the one individual or the
one individual company, understanding the total addressable market, the TAM in that sense,
what your ideal customer profile looks like and just being really deliberate about, yeah,
we could spend the time to bring this customer on board. We could spend the time customizing
and configuring and adding these features that are really important for this deal,
or we could spend the time to find multiple customers that fit this ICP who are not going
to be as expensive to onboard and support and who are going to look at the value that we're
providing and it's just a no-brainer. That's what I want this thing to do. I'm going to buy this
thing. I'm going to use this thing for 10 years and never look back. Not every dollar of annual
reoccurring revenue is the same. You have to be really choosy about who your customers are going
to be, especially early on. So regarding the ICP, did you get a lot of say in figuring out
who the ICP would be or did the founders of the company already have their mind on an ICP? Tell
me about how that came together. Being the second product and now we've got this whole platform with
lots of other products, I had a huge say in who the ICP for my particular product was. My product
was a key part of the core one and so it existed to open up that TAM, that addressable market.
We needed to make sure that this wasn't just some fringe product that's an objection handler. That's
a really common pattern that you can fall into is like, oh, this thing, like when they say this,
just throw this other thing in there so that they're happy and buy. You can't let something
that important just be this casual call it an add-on that will help close a deal. It has to
be valuable in its own right. And so in focusing on who the ICP for my product was, we could look
at the ICP for the company as a whole and say, what are our value edges? What are the things that we
do that no one else does that this thing and only this thing drives? And it was this turning point
in my career where we would get customers coming to the company because they saw my product,
got interested in my product and then saw the whole portfolio and said, oh, the rest of this
also makes sense. There was that kind of harmony of the whole portfolio and that really came from
being really choosy and thoughtful about who should use this thing and who should not.
That's really cool. And that's really neat to see when somebody comes in and sees your part of the
product and then recognizes what else the company offers and go, yeah, I want some of this other
stuff as well. You talk about coming in as basically the second product, and now you're
transitioning from a singular product company into a multi-product company. At first, it's just you.
What did you do over time to really align the team that you built out and the team that was already
there around the idea that this is our second product and to bring it into the culture of the
company? There was this idea, the main product shares the name of the company, and then there's
this other one. Really, it was just being present in all the company functions in the office and
just familiarizing people, easy to do in a smaller company, but just familiarizing people that this
thing exists. Do the good work and think about those strategic things and the value of the product
will eventually speak for itself. I think when we closed some of those deals that my product
brought into the pipeline, then the value of what I was doing in the company was self-evident.
I was working and the company was making money off of what I was doing. Then any question or doubt or
fear or anything like that started to turn into, oh, we've got this opportunity. At that point,
we were looking at ourselves in a different way. One day I went to work and we were truly a
multi-product company that had internalized that. I was like, when did that happen? I don't know what
day that was, but it did happen that way. Now I'm just like, I'm the company's DNA. There's
no separation between my efforts and my work and that of the entire organization.
Yeah, those things happen. I think it's slow. You've got to take baby steps. Every day you come in
and you take baby steps and eventually you've actually reached this big goal. It is one of
those moments where you just wake up and you're like, wow, this is really what it is now. That's
really cool. One of the things you had to deal with was all these different inputs. You've got
customer input, sales input, you've got market research that your marketing team is hopefully
helping you uncover to figure out what are you not hearing from everybody else. How do you
handle the difficulty of prioritizing all of that and figuring out what to actually make use of?
I think it's a little bit of a cliche to cite Apple or Datorams and less but better,
but I think it's really important to make sure that the number of things that my product does
is really quite small, but clear and obvious and useful. Before we started talking, I was on a
prospect call, somebody asking about, it turns out the product that I brought into existence.
And they said, well, does it do this feature? That was something that I get asked a lot,
especially when I was in product management, like, does it do this thing? And my answer
comfortably and casually was, no, it doesn't do that. And it's not in the plans to make it
do that. Let's talk about why that's important to you, what that looks like in your workflow,
all that other stuff. See if the way that the product works obviates that need, or if that's
really a deal breaker. Being really comfortable about if that is the most important thing for you,
then this isn't the product for you. And that's cool. We can part ways and be friends. I think
my time doing some of those sales demos and turning away leads that weren't fits like trained me for
that. But the other piece was doing the onboarding and the training and the support. When you,
in a very real sense, own the customer loyalty over a longer period of time, you're going to be
very careful and deliberate about what you add to the product and make sure that it is actually
something that you want to deal with for all of eternity. That forces you to be much more thoughtful
about what you take on and what you don't. Hopefully what you do end up prioritizing isn't
just support reactivity, but as part of this broader, I want to be able to tell prospects,
the answer is yes, because it's a very important thing. And I also want to be able to show support
that this is worth the effort to maintain and cultivate and all that. I don't have a formula.
It's sort of like stuff goes into brain, diffuses around for a little while, and then comes out as
roadmaps, I think, with a style and the fast paced nature of what we do at Service Trade,
having like a gigantic roadmap where three years down the road, I can tell you what feature is
going to be in Sprint 842. Like, no, that does not happen. And there are some methodologies.
I was calling it Now Next Not Yet. I only actually recently found out that some thought leader whose
name is escaping me has a Now Next Later. Yeah.
Janna Bastow claims to be the inventor of that. I'm not sure if she is the inventor of it,
but she definitely has had a lot to say about Now Next Later and pushes that quite heavily.
Again, like I only recently found that, but you can go into my notes years ago and have a
Now Next Not Yet because I like alliteration. I think that sort of thing is like calculus. Like,
it's there and multiple people are going to invent it on their own because it solves a problem.
Well, it makes a lot of sense not to tie things to very specific dates and to tie that, yeah,
we're going to deliver this feature so you can stake your business on this ambiguous world
four months from now. There's just so many things that could happen. Your engineering team could go,
yeah, we thought we could do it X way, but no, we can't. And it's going to take us five times
as long to do it the right way. Yeah, there's so many different things or the market could shift,
somebody could move on. You had like the one person who knew how to do that and they've left
the company. And now you're stuck having to try to hire somebody else that knows how to do that
skill. And there's just so many things that can throw a roadmap off. You got to be director of
product management during your time at Service Trade. And I imagine as part of that role,
you had to hire product managers. What did you look for in the product managers you hired?
The fit for the situation, not just the situation now, but where that thing is going.
The product that I managed from basically like its embryonic state to fully formed,
there's a whole other saga that's probably an entire episode about re-platforming. Talk about
making a decision that's going to affect a lot of people's lives and dollars, like the idea that
we need to do this again. That's definitely a story for another time. So I had people who
were really good about thinking about those downstream effects on the team, who had deep
subject matter expertise in the third party platforms. The hire that I'd want to reference
the most here is the one who backfilled me. I wanted somebody who had a calm but strong
personality, who wasn't going to be intimidated by my tenure with the product and who's going
to take it in a direction. I told this individual, the day that you tell me, know about a feature
that I want in the product that I'm giving to you is the day that you've earned that seat.
When you were comfortable telling me, know about the product that I created,
like you have arrived. And that has happened and it's wonderful. But we had this team that
had just recovered from all this chaos. So I was looking for somebody who had much more of a deeper
understanding of methodologies and all this other stuff to kind of build in what I like to call
quiet and mature consistency. I was out there doing hand-to-hand combat for years. We got out
of that phase and now we've got a thing that's stable and that's really delightful in the
marketplace. I wanted to find somebody who could really inherit that and take that in its own
direction. Somebody who had very different skills from me, very different temperament,
interests, all that. But again, if you've got a product that is much older, has a lot of technical
debt, you need somebody who's going to be slow and deliberate in thinking about, yes, that sounds
like a very good answer and how we would solve this problem. However, context, context, context,
context. Those personalities and temperaments and experiences, they have to fit what the product
needs. Really interesting to think about some of those different qualities that you're looking
for to hire those folks and especially hiring your own backfill. That's a responsibility right
there and that's one of those you don't want to get wrong. Right. My goal there was actually a
little self undermining. I wanted this person's presence and stewardship of the product to not
make me look like a clown per se, but like, man, are we glad that this person is here? They're
just doing great with it. Everything's perfect. There are no problems. You don't want six months
of, I wish Adam was still here. Yeah, no. My marker of success is that nobody missed me or cared when
I moved into solution architects. That's not exactly the case, but the contributions that I
have on the product team now are much more of that senior stakeholder type thing, where I have
perspective and context and they can bounce things off of me and I can say, oh yeah, we tried that
and it hit a wall and don't try that again type thing. So what led you out of product management
towards solutions architect? I had navigated the team through this era of chaos and hired up
and built this team and things were getting stable. Again, not the roadmap three years out is
well defined, but the strategy is really well defined. We know who we are. We know what we're
doing. We've got the technology. We've got some things we still need to do with the product team
needed. Just execute on that. And my personality and my skillset and kind of what I enjoy is
paratroop me behind enemy lines and I'll hand to hand combat my way through some kind of solution
to a problem that is at this point still ill defined. So as we were growing our solution
architect skills and capabilities, our CEO was like, I see you when you're on stage and giving
presentations and you just have the audience just really paying attention to some real dry,
not sexy stuff. And to make that exciting and entertaining fill the room that we're talking
about. Vendor invoices. Yeah. But like why people would attend my stuff. Put a dollar
in front of that field. It's awesome. One of the things that I do really well is taking in all those
random inputs and turning that into a story. And I'm more technical than most product managers,
but I also am much more of a storyteller than most product managers. And given all the different
things that I had done reporting to the CTO and VP of product and VP of marketing and just kind
of name it, I've been there. I have this kind of unique interest, but also skillset of being able
to sit in front of our biggest potential customers and talk to them about their business, about their
KPIs, about their vision for where they want their business to go. And then say, here's how you can
use this technology to amplify that and really bring in the C-suite and executive level buyer
persona in on that journey, but then get right to the details with the procurement person or the,
you know, whoever it is and say, here's how this software is going to do the thing that your
management wants when they want to take their company this way. This is a really fun opportunity.
There's a lot of new stuff that we're trying. There's a lot of inventing. There's a lot of
those things that really excite me in a day job. No one day is like the last. And that's what brought
me to product management. I like building things, whether that's a piece of software or a workflow
methodology, like in Red Hat, or just that story and solution for a particular customer. That's
what gets me up in the morning. Very cool. Is that tea you're drinking? Because it is. You're a coffee
guy. I am a coffee guy and I have fresh roasted Kenyan coffee. Had that this morning, but-
That sounds delicious.
Oh, very good. This time of day, I cut back on the amount of caffeine I have because it will now keep
me up where it used to not. Yeah, I've got that too. I only have one cup of light roasted coffee
a day and I'm done. If I have a second one, I'm up till 12, one, so forth.
And I'm naturally a night owl and you don't want me up at three in the morning playing drums.
Not that I play drums, but like if with enough caffeine, I will just start, you know?
You'll start pretending that you're a drum player. That's right.
All right. So one final question to close us out here. If you could go anywhere for a day,
where would you go?
I could pick a lot of places on Earth or times or that sort of thing. I think if there was an easy
bucket list item, it would be space, actually. I would love to see the pale blue dot from
that perspective. And while I'm at it, let's go across the, what does the Orion Nebula look like
from inside the Orion Nebula? It's a little bit far-fetched with such an open-ended hypothetical.
Why not, right? Well, you got to have a moonshot answer, right?
That's right. Well, thank you so much for coming on the show. We're glad to have had you on.
Yeah, absolutely. Anytime. I really appreciate it.
So Karl, what are your takeaways?
Yeah. So a couple of things that I took away from this episode. One of my favorite comments
that Adam made is that product management is a lot of sitting comfortable with ambiguity
and charting a ship's course through real thick fog and just hoping that everyone on the ship
trusts that we're headed in the right direction and doesn't end up mutating.
I mean, that really sums up product management. That's what it feels like a lot of the time.
That's probably the best-dated what product management actually feels like I've heard today.
So I was very happy to get that. And then startups require a very specific type of
product manager and different types of PMs are better suited to different types of problems or
different types of stages of a company's life cycle. And we've talked about that before and
it was nice to hear that again and to just get a little bit more detail around that.
Also, feedback from happy customers is weak. I liked this one a lot because we really do like
to go talk to the customers that are happy with us. Positive reinforcement. It makes our day
feel better. And honestly, as a PM, it really does feel like you're on this ship that you're
navigating through thick fog. And it's nice to get positive reinforcement from time to time,
but it's talking to your unhappy customers where you're going to get the real feedback
that's really going to drive you forward. Because these are people that care enough to share
what they think about the product with you, but they're not happy about it.
And that's the people you really, really need to be talking to.
Yeah, definitely.
So Danielle, what did you take away from this?
I agree with everything you've called out. And the ones I would add to this as well would be
that you're not expected to have all of the answers. It's a transferable skill to say,
I don't know. I think it's so valuable a skill. It can really apply to all parts of life. But
even if you don't stay in product management, like Adam has moved on from this line of work,
it just works everywhere. And it means you're creating human interactions with people and
you're empathizing and you're having real relationships with folks. And I think that's
such a strong skill to bring to product management and to so many other career choices as well.
And I guess my other couple of call outs from the episode are kind of similar in that they're not
very specific to product. I really liked Adam's call out that it takes training to increase your
threshold and ability to have difficult conversations. And being a people manager
has helped him get his threshold really high for difficult conversations, but also just
being good at managing time, being good at managing people are skills that help you get
to those difficult conversations and make them productive chats. And then leaning into the
harmony of a portfolio when you're adding products to a company's portfolio, just the harmony between
each one comes from being choosy about the person that you're solving with your products. I think
that was really key for me. Let us know what your takeaways were. What comments made you think?
What new thoughts did you have listening to our podcast today?
Drop us a line at hello at productlyspeaking.com or join the chat on Matrix at hashtag productly
speaking colon matrix.org. Also follow our page on LinkedIn to get the latest updates.
We'd love to hear from you. This has been productly speaking.
Thank you for tuning in. If you like what you heard, subscribe. Make sure you don't miss any
episodes. Also share our podcast with your friends and anyone you think might enjoy listening to an
American and a Brit natter on about product management. I don't think you can call it
nattering. I guess actually we did stay on topic and it's not technically nattering. Exactly. Well,
what did you guys think? Leave us some feedback. Make sure to visit us at www.productlyspeaking.com.
Send us an email at hello at productlyspeaking.com or join the chat on Matrix at hashtag
productlyspeaking colon matrix.org. Thank you all again and until next time cheerio.