Navigating the Challenge of Product Market Fit

One of the startups I worked for, one of my peers in product management once said to me
that if you release something and everybody likes it, you waited too long.
I've heard that too.
I like that.
Minimally viable product.
Do we dare admit to ourselves what that actually means?
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.
For today's episode, we are back at it on one of our favorite topics, product market fit.
Having explored why Zizzazoo seeds aren't selling in the veil of the boat in season 0,
we're now interested in digging a little deeper and getting perspective
other than our own in order to do so.
I'd like to introduce our guest today.
His product management career has been a rich one, starting at Promenet and moving
into the system storage group at Sun Microsystems.
He was at Sun during the time that Oracle bought Sun,
and he continued at Oracle for just over seven years.
After Oracle, he moved on to Red Hat, where he is a product manager for Red Hat Enterprise Linux,
covering in-place upgrades, conversions, and live patching.
His breadth of experience on industry-leading products makes him a valuable asset to Red Hat
and brings a unique perspective on product market fit to the table.
We are pleased to welcome to productly speaking, Bob Hanlon.
Hey, pleasure to be here.
Nice to see you guys, meet you guys, as the case may be.
Yeah, so Bob, tell us a little bit about yourself
and about what we're going to be talking about on product market fit today.
So I've been in product management for about 20 years now and different roles.
I've done some technical marketing, some product marketing as well.
And today, that topic that you mentioned is a really interesting one,
because I had a very specific experience with that when I was working at Oracle.
We had a machine that was very fast against the workload,
the kind of 10x fast that makes you want to go after a market.
But we came to figure out that it didn't quite fit for other reasons.
And I found that an interesting life lesson.
So the example I'm talking about is I worked on a product called CFS Storage Appliance,
which came out of this brilliant file system technology out of Sun called CFS.
And it was really fast and it kept a lot of things in cash.
And the market we tried to enter was VMware.
And VMware was dominated by EMC and NetApp.
If you don't know that market, those are the companies in that market.
We said we could go take that out because we were somewhat similar to the way the NetApp
product worked and we had a product that was really fast against the workload.
It turns out, though, that operational integration matters.
So while we could blow someone away by actually installing the product
and making it go fast behind VMware,
you couldn't right click and build a clone VM the way you could with the NetApp box.
And so we would get through the CTO, CIO level of discussion and really get close.
And then the operations people would say, I can't work with that.
It doesn't work the same way as my NetApp.
And I thought, well, this is a fascinating reality.
And so it took us a while to learn that.
We were hearing that a little bit from our customers.
But then the last bit was I actually started to get on airplanes and go from city to city,
going to VMware user groups.
And cleverly, we would pay for the parking at the event.
So you had to come talk to me in order to get validated.
Right.
And so one after the next, I thought it was a little cheesy until I actually lived it.
They at least have to say hello.
I get some conversation started.
So we're talking to these people one after the next and saying,
this is really good for what you do every day.
You should at least buy one of these to go faster on that part of your workload that
you need this for, et cetera, et cetera.
And what we started to learn was that people thought that what they had was good enough.
Actually, I've looked at one a few times.
I had the same thing years ago when I was working on gigabit ethernet switch.
It was the same basic idea.
Like your Cisco switches have head of line blocking.
You're going to have all these performance problems if you use the Cisco stuff instead of ours.
And finally, I'm talking to someone who's working for Global Crossing.
And I said to them, well, how can you use those Cisco switches?
They've got head of line blocking, yada, yada, yada.
I've got thousands of them.
I've never had a problem.
It's a very startupy kind of thing too.
You know you're better and you're faster and you're cheaper, but you don't really know
why it is that you can't penetrate a market space until you really dig in and find out
what that individual end user has to do every day and whether or not the difference you're
making matters to them.
That's an interesting point because I can definitely see that having been at a startup
before where you definitely know you have these key differentiators that ought to be
selling you into a market.
And yet sometimes you do have trouble actually closing sales in that market or the sales
process takes a long time or you kind of get into these, well, we don't have X, we don't
have Y.
So how do you go about kind of digging down into that end user perspective, especially
if you're a product manager and between you and the end user as a sales team or a couple
of sales teams?
I think the first thing you do is it's basic blocking and tackling stuff.
You have to get the requirements.
What's the difference between what this is and what you need to be?
And we did a lot of that.
And then there's a second step, which is a technical step in a sense.
Can you recreate that capability in the thing you have and can you do it fast enough in
a way that impacts this market?
I think that's where this idea died for us was we got the requirements.
We actually had people who understood the requirements and we brought them back.
But on some technical details inside the system, we couldn't recreate a little function that
allowed the system administrator to do what they wanted to do.
And I guess the ultimate sort of failure, I guess, was we were working with a large
customer in the Midwest and we gave them the system.
And this person who ended up going to work for VMware, just a total VMware expert, ran
our product behind what they were doing and his jaw dropped.
It was 10 times faster and yada, yada, yada.
They didn't buy.
Same reason.
My goodness.
Couldn't get it in there operationally.
That's big.
10 times faster is big.
That's usually the metric.
I mean, that is money there because time is money.
And if you can go 10 times faster with the same equipment, that's valuable.
And yet still not closing the deal.
Right.
I gave the whole speech of why we were better at this workload.
And we had a new GM, Israeli guy, which is interesting because they tend to be
very brass tacks.
They've all been in the military.
They all kind of know each other.
It's a cultural thing, I think.
No BS kind of person.
Right.
And I give my whole speech to a bunch of field people about how this is the
solution for this problem.
He pulls me aside.
He says, Bob, do you believe what you just said?
And I said, yes, because, and I gave basically the same reasons that were in
the presentation.
He goes, yeah, but do you really believe that we can go get that market?
And I said, I have to be honest.
I was asked to go take that hill and I'm trying to take it.
Interesting product management problem.
Right.
It is, it is.
We think that we're in the business of trying to figure out what to build, but
sometimes we're in the business of trying to figure out what not to build.
Right.
Yeah.
Well, and that gets to a point that we like to talk about.
Danielle and I have had a lot of conversations about this where realistically,
you've really got to understand the problem before you start going to build.
And it almost seems like there was a lot of the problem that was understood.
I mean, you made an application that's able to do things 10 times faster than
the incumbent, which is amazing.
And that in and of itself should absolutely like land you a market, but
not understanding the jobs to be done on top of that application and that this
has to be just as easy to do as the competitor product to be able to unseat
the competitor, not understanding that aspect of the problem seems to be where
that that fell down.
An interesting history bit there too, prior to the product that I was working
on, which started at Sun and then moved over to Oracle after the acquisition.
I think Sun had tried to launch either nine or 10, the space is called NAS,
Network Attached Storage, NAS products, because Sun looked at the technology.
They basically invented NFS, which is the file system technology in that space.
Right.
And they kept building them and they were always wrong because it isn't just
that. It's that plus the way people use it.
And that's the hard part.
And startups are particularly vulnerable to this because they conceptualize the
10x faster part.
Right.
But they don't necessarily understand that they're coming into a market space
where they're chasing the tail of an entrenched competitor that they have to
now unseat.
In order to unseat that person, you have to be able to provide the right
operational fit with your product too.
So it can be a bit of a nightmare.
Yeah, especially as you're fairly resource constrained in a startup,
typically.
So you've got to be very careful about where you put those scant resources.
A hundred percent.
And if you find yourself playing catch up in that interface sort of operational
level, you're probably not going to catch up.
You better be redirecting them to some different place.
And those same systems were very, very successful in certain specific
workloads where the companies had the resources to worry about just getting
this thing to fit.
Because it was so much faster.
If they could just get it to fit, it was worth their time to wriggle it in.
That wasn't the case with some VMware administrator who was right clicking and
trying to make new virtual machines every day.
They couldn't afford the extra work because that wasn't the key operational
part of the job.
And you get all the way back to, yeah, sure.
Do you ever see performance problems in those things?
Yeah, I do.
But not often enough that I am lying awake at night worrying about it.
So that is a very cute trick you just did, but I don't really need it.
So it kind of played out like that.
Yeah, right.
Like breaking down that barrier to entry almost.
And it doesn't always lie in usability.
Sometimes people are really, even if a system is hard to use, they've gotten
their own systems around it and they've spent maybe 20 years doing this job.
And so it's easy to them.
So even if your product is like two clicks to deploy or something, it could be
perceived to be difficult.
And not for nothing, but sometimes they're certified on the product they have too.
So now you're asking them to change their careers.
When we went from Sun to Oracle, Larry Ellison decided he really liked this
product.
So he made Oracle standardized on it.
We mentioned network appliance.
Network appliance was what they had standardized on prior to buying Sun.
And now he goes into his data centers and he tells his admins, you got to get
rid of those and put these in.
Half of them quit.
Wow.
They were trained, certified data engineers.
They weren't going to deal with this.
The half that stayed for the most part came to really appreciate the product.
And they ended up with like an exabyte worth of it running in Oracle data
centers, exabytes a lot.
It's amazing what a lip that is.
It's not always a better mousetrap.
It has to be better in some way that changes the life of the people that have
to use it every day.
It's not even good enough sometimes to just be better for the business, let's
say.
These days with AI simplifying a lot of folks' process, imagine the
translation space, for example.
We're now asking Google to translate.
We don't need translators.
It's not about just changing your career.
It's potentially the product you're trying to insert into this company.
The end user will lose their job completely.
So they're not always incentivized to help or give positive feedback.
We recently saw examples of Duolingo getting rid of a lot of contractors due
to AI.
And we've also seen Google this year get rid of a lot of people due to AI
because now it takes less people to do the job that they were doing before.
The markets then, but the users aren't.
It comes up as a marketing thing a lot, too.
Don't ever make it your pitch that you're going to save money by costing the
person their job.
And it's a very easy pitch to fall into.
Again, working for Oracle.
And I remember watching the head of the sales team get up and talk about how
Oracle Cloud would cut 30% of the cost versus doing it in your own data center.
But in that room, they were admitting that 30% they were saving was headcount.
And so working with a very large customer, they were telling their story.
And they said they ran the evaluation themselves.
And they found out that using public cloud to solve their problem was actually
more expensive.
And the reason it was more expensive, because when they did their analysis,
they didn't cut out their own jobs.
Yeah, minor detail there.
Minor detail.
It's a weird way to...
It's a weird pitch, like to your point, Danielle, right?
It's a weird pitch to go into someone and say, buy this product so that your company
can save money by not needing you anymore.
It's tough.
What sort of data or feedback would you be looking for to identify whether that's
the problem or to understand whether the product is where the problem lies?
We've developed a discipline not to say that bit about how you're going to save money
by taking out your own job.
So we ended up focusing more on capability.
It takes a while to see it.
We were very convinced about that one workload case I was talking about.
And it took us a year.
I kept going out on the road, getting more and more feedback, going to the engineering
teams who said they could actually make the changes needed.
But then the changes never came.
And I remember one of the more interesting moments in my product management life,
because I'd never done this exact thing before, was I went into my boss's office
and I sat down and I said, this isn't going to work.
We are wasting our time on this.
We have given it our best shot.
There are barriers here we can't overcome.
Let's go figure out something else to go after.
And this is me spending...
I had to actually...
I wasn't risking my own job, but I was defeating the sunk cost fallacy, if you know what I'm
talking about when I say that.
It didn't matter how much time and effort I put into trying to win, to take that hill,
like I had told the GM prior, it wasn't going to work.
And it took a long time to see it.
But once I saw it, just went and told my boss, then she went and told the VP,
and then we stopped worrying about that one.
Wow.
Yeah, that's a pretty bold statement to have to go in and tell the boss that, hey,
look, I know we've been working on this for a year, but it's just not going to work.
It's an evolution.
You have to learn to be confident that that's important.
I remember when I first started out in product management, the dumb product management that
we've all done when we were young product managers is just go look at the competitor's website and
write down all their features and then try to sort that into some sort of list.
And you give it to your team and say, here, go do this.
It's understandable form of product management, but it's not a good form of product management.
I don't know, Karl, if you were there, but we all sat in a room at Red Hat in,
I think, January of 2020.
We were all retaking Mastering Product Marketing.
I don't know that you were there.
I think I was there, actually.
It was December of 2019, I think, in Boston.
Yes.
Yes, that one.
And it was all get on the road, primary research, go live in the soup, right?
And guess what, it never happened.
I had mentioned earlier to you, I think, that we're looking at Red Hat now to try to figure out how
to open up into some different spaces that we haven't historically been as strong in
because we're so good at the very top end of the market, let's say.
And that's a primary research task because it's not a customer we're talking to
as much as we talk to the ones we know, right?
That muscle maybe went away for a lot of product managers just getting out and traveling and
visiting on speculative basis, let's say, just getting in the soup a little bit and
listening to people talk.
But it's invaluable stuff.
It's exactly what we told ourselves we were going to do back in 19 that we never got to do it.
Here we are now.
It's, oh, wait, we can do that.
We can actually do that now again.
I don't know if anyone remembers how anymore, but we can actually do that again.
So let's go do that.
When you're grabbing people like that, how do you tell the say do gap?
Grabbing people as they're walking into an event because you sponsor the car park
is such a cool way to get people's attention and to start those conversations.
Sometimes there's a lot to sitting down with folks at their computers and watching them
do the task that they're doing to learn.
Well, in that example, so first off, it's still kind of like direct mail where you get a three
to four percent response.
Even if you pay for their parking and you ask them one question, you get a handful of
responses and conversation.
The say do was very important there.
In fact, one of the things I did during that research is I took a class in VMware
system administration, and this is how things I've seen this a few times with software
and Daniel, I'm guessing you probably have to VMware decided not to do their Windows
based client anymore in favor of a web client.
They both work, but the click pattern was different to like you had to relearn your
right clicking and your left clicking and where things were.
This cause an absolute uproar in that community that you would never occur to you that that
would be a huge problem.
Just it's a different sequence of clicks, but give it give it an hour.
You'll you'll you'll figure it out.
Oh, no, I know my clicks.
Please go away.
And and I think I saw from one of the other you worked for Intuit.
I remember going the saddest person I ever saw was my accountant the year that he went
from his lightning fast text based look like the old saber system that they'd use for
airline reservations.
They made them use a GUI.
They were pulling their hair out because they you know, and that's a do right.
That's that I've seen these dues and that's probably the part we couldn't fix was to do
right.
You can't get the do right.
Then you can't get that first lip accomplished and people just see that as more work that
I'm willing to do.
So but it's also an interesting point.
You know, you bring up going from a CLI to a GUI and people that love their CLI Eric
Madeline interface based tools.
They really love them and they really do cling to them.
It is possible and this is probably a controversial take in the CLI community because I like my
CLI tools as well.
But it is possible to make good graphical user interface versions of tools that wouldn't
traditionally be CLI based tools.
It is hard.
It is very hard, but it is a doable thing.
And I find that even after you've done it, convincing the CLI people that the GUI tool
is just as good, if not a little bit better is still a very challenging thing because
they're so used to doing it.
A hundred percent true.
In fact, if you decide for yourself that the GUI tool is better, your peers will mock you.
I lived it.
I was working in technical marketing when it first got acquired into Lucent and we used
to go and do trade shows and everybody would have their own way of getting their machines
up for the show.
And I would just bare metal everything and I would rebuild it, including the system.
I would write the system files and everything in the GUI, right?
And I was always done first and they would always laugh at me and I was always done first.
And I thought, this is a really interesting thing.
Why is it exactly?
It's all this thing.
It's barriers to entry, right?
It's a classic problem.
Just building a piece of tech that's better than the last piece of tech is not sufficient.
Does it loop background to, I know we've already mentioned, you're trying to convince people who
are trained in something to use a different something and maybe they don't want to retrain.
Maybe they've had years of experience.
Maybe you're putting them out of work.
But does it loop background to pride or motivation?
Like many of us in a privileged position in tech kind of don't have to worry about the
wages coming in and a lot of the reason we show up to work is because we're proud of what we're
doing. We're the most masterful being a CLI person, like being able to code it right there
in the command line.
I can be really proud of myself.
If it's just a button click, anyone can do it.
Absolutely.
That is a huge, huge, huge factor in this.
In fact, I saw it first with Solaris administrators working
VSUN and then Forsun and then moving in as Linux started to catch on.
I believe that one of the most important reasons that Linux grew to the prominence it grew to is
that it was good enough at what it did, but it worked the same way as Unix.
So those command line jockey types could migrate to the new system and it felt familiar
at the command line and the command line was in fact to your point where their power lived.
Incredible thing to watch really, but I always felt that. I always felt like
as I was trying to, like I said, put up these machines myself and I would maybe use the GUI tool
that it was insulting to a command line person or a command line jockey that you would actually
be able to do something properly with the GUI. It just didn't make any sense to them at all.
And having used both command line interface and GUI and loving tools that live natively in both,
that blows my mind to be honest. I have a hard time understanding that perspective,
even though I know it's very much out there.
Yeah. When I first, before I was in storage, I was in networking in
Cisco was dominating and they had an operating system called iOS.
There was the same thing. It was a command, you build a command script and when you fire up
your router, it runs this command script. And they did an actually brilliant thing that I haven't
seen others do. Maybe they have, but I haven't seen other examples of it.
When you used, if you use the Cisco GUI, it wrote out an iOS file. It was the format didn't change
if you use the GUI. So the command line jockey could open up that script that the tool created
and it would be in the form of Cisco commands that they knew. And every time I, if I had,
I wish I had a dollar for every time I went to people who build interfaces and said,
do that. Have it spit out. In the case of a Linux operating system, let's say have that
thing spit out a shell script instead of having it spit out some binary format in a database that
is different from what they're used to. And if you don't have the new thing in your tool yet,
let it open up a command window. Just bridge the gap. But I think that's where they fall short.
We have some of that now actually. We are building a growing capability into a user interface, part
of which is to go after this maybe more midsize market, the less command line hero type person.
One of the things that is going to become a problem at some point is that I think we're
still in the mode where the thing can arrive in the GUI after it exists as a function,
after some bit of lag. Well, that means that your users who standardize on your GUI can't
use the new thing that you have to get out of that. At some point, you have to get to eventually get
to a point where you can deliver both in the same day so that you're not servicing one community
with better functionality than the other. But I think it's very common. I think the GUI always
comes as a follow on. And that's another reason that maybe affects adoption a little bit.
Yeah. At my last job, we very much started with a CLI-based installation tool. And then we rolled
out the GUI. And there was a lot of who moved my cheese in that move. Even though the GUI actually
made a better configuration experience and a better overall driving experience, people still
wanted to edit their 20 text files and put values in. Right. Always. That will persist,
I think. We have this thing now. As a product management problem, we have to keep two backlogs
because of it, right? You have to have a backlog for the creation of the function.
Then you have to have a backlog for the integration of it into the management tools. And unless you
have enough resources to not do that, then that's just the way it has to be. We had an engineering
manager who was saying, let's make a unified backlog. How do we prioritize things if we can't
do that? And I was like, well, I understand what you're saying. But the only way to do that when
the resources are a little unbalanced is to say, the feature has to wait until all the tools have
time to integrate it. That's never a thing. Well, I mean, it would be ideal if everything was ready
to go when it came launch time and it wasn't just, it works over here, but not in this other tool.
If you get big enough and boring enough, companies start to be able to do that.
But it's really a late stage thing when you're still solving original problems. And that's why
it's an interesting thing when it comes to Red Hat. We're big, but we're not that big.
I've worked for other big companies that are solving problems at the scale of Red Hat,
and they have like 100,000 people working for them. And Red Hat has nowhere near that many.
So I mean, a lot of that has to do with upstream and open source and the way we develop software,
but we don't have enough people to just do all the things all the time. Like maybe you do if
you're building a proprietary software and you have to figure out what that means. Actually,
coming back to product management too, you have to figure out which things are actually important
to do and when they're important to do them and whether you can get by without having to do them
all right away. Yeah. Well, that's a fascinating point because it doesn't matter how small you are
or how big you are. You never have enough people to do all the things that you've identified on
your plate. So prioritization is just absolutely key because Red Hat's roughly 20,000 people.
At a startup, you've got 200 or less. Right. You don't have enough people there and you don't
have enough people at Red Hat. Exactly. And it's fascinating. I remember one of the startups I
worked for, one of my peers in product management once said to me that if you release something
and everybody likes it, you waited too long. I like that. Minimally viable product. Do we dare
admit to ourselves what that actually means? Yes. Minimally viable is pretty minimal.
We used to have this. The other thing is, and Karl's familiar with this, we used to have this
thing at Red Hat. We try to use it vanishingly a few times now. We call it tech preview.
What tech preview was, we're going to put it out there, but we didn't really finish it.
So we're going to let you experiment with something that we're telling you doesn't
quite work right yet. And you know how many people actually would experiment with something
that didn't quite work right yet? Almost zero. That was the worst part, but it's the same idea.
I feel like sometimes minimally viable product is a way of saying,
we didn't get as far as we needed to, but we're going to release it anyways.
It's similar to putting things behind Labsflags and B2C type products. Danielle, I know you have
a little bit of experience with functionality going behind Labs. Do you see similar usage
patterns on that? It depends on your audience. I think in one of my B2C experiences that Labsflag
folks just weren't excited about finding it, and so they didn't turn it on.
And then in another of my B2C experiences, you've got early adopters to new tech,
and so they're really excited to play with Labsflags. And they're kind of your QAs.
They want to break it, and they want to give you feedback, and they want to build the product with
you. So I really think it just depends on the kind of humans that you're going after or what
that market looks like and how much time they have for this sort of stuff.
Yeah. And in B2B, you tend to not find people with a lot of time to play with your newest
crazy invention. They just need something that works and move on with the rest of their day.
We always think that brand is more important in business to consumer, but brand is proven out to
be way, way more important in B2B. And it's because of the complexity that they have to
deal with in a lot of these enterprise data centers, as an example. Again, we keep going
to the same space that Karl and I are familiar with. They are incredibly risk-averse. So you're
asking them, it doesn't matter if it works on their one system in that kind of environment.
It has to work in the environment. It has to scale properly and all that other stuff.
And if they can't call you for support because you called it something pre-production-y,
experimental, they can't do the experiment they need to do.
And so I think that's probably the other reason. It's a market thing.
I think even product managers can sometimes fall into that trap, though. You want the thing to get
out there because you've worked hard on it for a long time. And yeah, sure, the three or four things
that you really thought needed to be there before you hit the go button aren't there yet.
But it's been a really long time. Management's upset. You don't want your engineers to feel
unmotivated. So you just kind of put it out. We had some really strong voices inside Red Hat.
And I think they were right. We really shouldn't do that. Just finish it first and then put it out.
Yeah. And especially, like you said, the larger you get. And while Red Hat's not as large as some
organizations, it's certainly a lot bigger than a lot of companies that are out there. And it's
certainly got a lot of resources to it to be able to do things like that, to be able to afford to
finish a feature before actually releasing it to market. Right. That's a huge one. A lot of times
with these small companies, you have a clock ticking at all times because of your fundraising.
Yeah. You don't have time to do it because you don't have runway. And if you don't sell enough
or raise enough new funding, there's not going to be the runway or the time to do it. So you
just have to scrap the idea and go for the core idea. Without knowing what the core idea is yet.
You don't know what your market is until you get there sometimes, which is fascinating.
I was thinking about this in anticipation of talking to you guys about how often startups
don't really know what the product's for. They know what it is. They have a sense of where it
might fit, but they don't really know who and what it's for until they actually get it out there
sometimes. It's a fascinating thing. It's not really a product manager. It's not a product
management problem. It's a, can I make this thing sound interesting enough to get someone
to invest in it problem? And then they build the thing. And it's only after you build it,
you figure out these things. We've been talking about this all the time,
but it doesn't quite do this or that. And that's a problem.
In a similar vein, how do you find those markets for your thing? It's kind of the same question
as if you're a market leader like Red Hat is, how would you find new markets to go into that
you may just be able to walk right into if you knew they were there? And it's kind of the same
idea from a startup. Well, okay, you've got your thing. How do you actually go find that market?
We live through it every day now. We're working in a mature technology and a mature market, right?
That can make you bucket loads of money for a really long time, but it doesn't necessarily
guarantee down the road growth. So you have to start finding these new markets. And you're
exactly right about that. They always tell you, you can't find the new market by listening to
the customers you already have, because by definition, you already have them. But boy,
it's really hard to get around that one. You're talking to customers all the time,
and you feel like that gives you the sense you need of what you're doing right and wrong and
where you need to go next. You have to figure out how to have a conversation about your thing with
that customer who doesn't care about your thing yet. But they might, to your point, they might if
they knew what it was. Again, we're living that now as we've identified certain growth opportunities,
but one of them is taking the same product with the same capabilities and going after.
A customer segment we feel like we're applicable to, but we don't really know how to talk to yet.
You have to go figure out what the entry cost is for that. It's fascinating.
That's a good point to bring up that there's always an entry cost into a market. You're not
just going to walk into a market unless you get really, really lucky. Most of the time,
you're going to have to pay to play. 100%.
That cost could be in time as well as resources, or it could be in quality, right? We've already
talked about releasing the MVP that's not quite good enough. That's a quality cost,
resourcing cost of how many humans do I have to throw at this problem to make it worth doing,
and then time. I think sometimes when you're breaking into a new market,
people don't give it enough time. Something Intuit used to say is if they were opening
a new office, that it would be a seven-year clock before they then decided to close that
office in that region, which seven years is a lot of time, but you're just not going to get
traction in a market unless you dedicate that much to it. But startups don't have that same privilege.
That's very true.
It's a huge product problem because a lot of times when you start... Even a healthy company,
if they sort of see a flattening of one of their market spaces or something,
a lot of times they start looking then. If you start looking at that moment,
you don't have seven years to figure it out.
How do you know when a flat is a good flat versus a bad flat?
Flat isn't allowed because tech is always priced for growth.
So I find that the weirdest part. You could have this gigantic business,
but if it's not growing at the prior pace, you're failing. I'm sure that's a fail.
That's the venture and market culture that we've got around being publicly traded or being venture
backed. Either of those will put you in that scenario because investors always want that
group. It still grew. Yes, it was only 5%. It wasn't the 11% you expected, but it grew 5%.
And it's throwing off cash in large buckets, but ignore all that. It's not growing the way
that the investors saw it. The biggest thing when you really dig to the bottom of that is the
companies themselves are overvalued. They're valued against the growth. Everyone's trying
to figure out if you're Apple. It's kind of not very realistic that there's a lot of Apples out
there. It can be frustrating in a really healthy business that the expectation comes from without
and you're not even putting the expectation on yourself. You know that what you're doing is the
right thing. You know that actually the way it's cycling right now is fine and healthy based on
what you do. Because no one knows your business the way you do, right? But they're comparing it
to things that aren't quite the same and saying, well, you're not doing what this one's doing over
here, so therefore you're not as successful as you could be. Interesting. But then that's a product
problem. That's a strategy. People with much larger paychecks than me get to go figure that out.
Yeah, except when you're a startup and then you get to do strategy and product and everything
all at one time. Strategy to startup is simple. If we could just capture 1% of this $12 billion
market, that's- Would be set. And then what is it like 80, 90% of startups fail or something like
that? It's some ungodly high number. One in 10 or one in 20, depending on the moment. There are
times when that changes, I guess, when tech gets hot or something and I wouldn't feel horrible
pitching an AI product to VCs right now. There's a lot of people doing just that.
And they're probably getting funded. They are. There's a lot of series A and series B AI companies
out there right now. Why not place a few bets, right? I wonder how that actually, I don't know
how that would boil down to product. I feel like I've been at startups where I could sense that
there was something going on that was really amazing and then ones that were just people who
are good at talking, let's say. And I've flipped through both. I've seen both be successful,
which is interesting. I've actually seen good products fail and I've seen mediocre products
achieve a good outcome, let's say. So it's a complicated thing and it's not always a product
thing. We as product people, we can only control what we control. I was around when the tech bubble
collapsed after the sort of Netscape boom and then about 2000, 2001, everything fell apart.
What really happened was everybody bought all new stuff for Y2K and they didn't buy anything
for the next two years. And the whole tech thing went into a depression, right? While tech was
collapsing and all these startups that were lavishly funded and it had all this money to
burn were failing left and right. And they were pulling the employees and the most common reason
the employees felt their companies were failing was bad management. It was clearly market dynamic.
It was clearly the tech bubble collapsing. It was poor choices and poorly spent money
and all these other things. Talk about classic perception versus reality thing. Well, this is
what we live. We can always overcome perception with product, I guess, is the way to do it.
We can work together and build great products, but in order for them to succeed,
you got to have all those other gears too. Well, Danielle, did you want to close us out
with a closing question? You are going to wake up tomorrow anywhere in the world.
What would you choose to do with your day and where would you wake up?
I don't know. I would wake up in my office getting ready to talk to
Karl and Danielle because that's really fun. I really like to talk.
That's the right answer.
I'm speechless. I don't have anything else to say to that. That was great.
I would not be going down to buy coffee beans from a roaster because I didn't want to have to put
halfs and halfs in my coffee. That I would not be doing.
It's all about the instant coffee. You're on my team.
A few instant coffee funds.
It goes somewhere in the middle, but yeah.
I will say one thing on the instant coffee thing. I have seen specialty
roasters start to have their coffees as instant coffee, which is an interesting
baddest interesting scenario.
My excuse for having instant coffee in the house is because it's good to make coffee flavored cake.
I arrived in Australia on business. I arrived in Sydney and it went straight to the office.
All they had in the break room was freeze dried instant coffee, let's say. I thought,
these people must not care very much about coffee. They didn't even have brewed coffee in here.
The only reason they had that there was that it was beneath them to drink coffee
that had originated in the office.
You had to leave the building to get a proper cup of coffee, and they all did.
And so I guess the existence of the instant coffee can be deceiving on that side. It can be
that brewed coffee is beneath them.
Yeah, that's fun.
So Karl, what will you take away?
Yeah, I really liked where Bob talked about where does your power live.
You know, that whole concept of you're coming in with a product.
And yet it may actually be displacing the very people that need to use it, or it may be making
them relearn something that they've spent their entire career becoming the expert in.
So that was pretty important because a lot of times we don't necessarily think about
the displacement factor of bringing a better product to a client and about how that may
actually impact the people that are using it.
Also, another thing that really stuck to me that Bob talked about was what is the entry
cost to a market, that there is always going to be an entry cost to a market.
You've got to plan on that when you want to go look at a new market.
You can't just go turn pivot and say, hey, new market, here's exactly what I have.
Each market is going to talk a different way.
And you're going to have to spend time researching that and understanding how those people talk and
going to their conferences, starting to talk to those people to see if what you're saying resonates
or if you need to change what you're saying to try to resonate, or if you don't have any
chance at all in that market.
And that's an important thing.
And those are costs that you have to bear to be able to do that.
Danielle, what did you take away from today's session?
Yeah, I agree with both of the things that you picked up on and talked about there.
I really liked them as well.
I think the ones that stood out for me were that consideration for the
operational integration of your product into an environment.
That's why we're here building products is to go after problems.
And so it's likely that your target market already has some form of solution and you're
trying to displace that.
And so understanding that operational piece of how does this fit in and then recognizing
that you can't overcome perception with product.
You've got this perception that a product is not always going to fix it, even if that
product is 10 times faster than the thing that you're dealing with right now.
If it's perceived to be not cool or perceived to be gooey, it's too easy.
I want to stick around on my command line.
That's a really hard thing and it can't be done with just product alone.
So that's what stood out for me.
How about you guys?
Let us know what your takeaways were.
What comments really made you think?
What new thoughts did you have listening to the podcast today?
Drop us a line at hello at productlyspeaking.com or join the chat on Matrix at
hashtag productlyspeaking colon matrix dot 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 productlyspeaking.com, send us an email at hello at productlyspeaking.com
or join the chat on Matrix at hashtag productlyspeaking colon matrix dot org.
Thank you all again and until next time, cheerio.