Product Management Demystified

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Hannah Clayton-Langton (00:04):
Hello world, welcome to the Tech
Overflow podcast, the podcastwhere we explain technical
concepts to non-technical people.
I'm Hannah.
I've spent three years workingat a tech company.
I didn't really understand whatmost of the people were doing,
so I teamed up with my friend,hugh to take me on a technical
journey, and I want to bring youall along with me.

Hugh Williams (00:21):
My name is Hugh Williams.
I'm a former engineering vicepresident at Google and at eBay,
and I began my career in theUnited States working in
engineering at Microsoft.
Hannah's recruited me to helpdemystify how technology works,
and today we're going to betalking about product management
.

Okay, so let's start right at the very
beginning.
What is product Like?
What's an example of a techproduct?

So, hannah, I can think of a few different types
of examples.
So Instagram's a product,obviously.
You can get that for asmartphone, you can access that
on the web, but I'd say it's asingle product in any case.
Second example Microsoft Word.
I hope we'll get a chance tocome back and talk about Word a
little bit later on, butMicrosoft Word's a product.

(01:05):
I'd argue that Microsoft Officeis a suite of products.
And then, last of all, lots ofus use Workday at work to do all
the people management stuff.
I'd say that's an example of anenterprise product, one that
you'd often use in the workplace.

Okay, if you have any product management
contacts at Workday, I'd likeyou to put me in touch with them
, because I have some feedback.
All of those are familiar to me.

I've never met somebody who loves Workday.

And are some products more complicated
than others?
Like thinking of the examplesthat you've just given?

Yeah, for sure.
I mean, let's maybe just pickon two of the examples, right?
So Instagram has somecomplexity, for sure, but I
would say, relative to microsoftword, it's a much less complex
product and perhaps the way toillustrate it is just a you know
, talk for 30 seconds aboutmicrosoft word.
If you just think about all ofthe things that are in microsoft
word, right, so you can importand export lots of different

(01:57):
file formats, you can be workingin microsoft excel and you can
actually cut and paste intomicrosoft word, you can imagine
how hard that is to build.
Think about printing, right,you have to work with all sorts
of different printing devicesand then there's all the
elements around the actual, youknow, typing itself.
So think of all the elementsaround, sort of styling,

(02:17):
headings, fonts, colors, tables,all those kinds of things.
So it's a very, very complexproduct.

So everything I'm interacting with
basically drives the complexityof the product, because I want
to change my font size, how it'saligned on the page.
I might want to interact withhardware or upload a photo, or I
don't know if Clippy is still athing, but Copilot's probably
the new Clippy, I would say.
Fair enough, clippy was verymuch a feature of the 90s.
So what is product managementthen?

(02:45):
What does that mean?
What are product managersworking on it?

So there's not like a one-to-one mapping
between a product and a productmanager, but product management
itself is really theintersection of three things is

(03:11):
the way I like to think of it.
So it's the intersection of thecustomer, the intersection of
the business and theintersection of technology.
So imagine there's this Venndiagram.
It's got three circles, thosecircles overlap and there's this
beautiful sweet spot in themiddle and the product manager
is somebody who sits at thatintersection.
So they're somebody withempathy and understanding of the

(03:32):
customer.
You know what customers want.
They're somebody who reallydeeply understands the business
and how the business works andcan talk to the commercial team,
the finance folks, themarketing team, the legal folks.
All of those folks understandthat context and how the
business itself works.
And, importantly, they'resomebody who really understands
technology and how technologycan be used to solve problems

(03:55):
for the customer and thebusiness.

Okay, I have like a million follow-up
questions.
So how technical do productmanagers need to be?
Do they need to understandcoding, for example?

So, how technical do product managers need to be?
Do they need to understandcoding, for example?
I think so.
Yes, you know that's probablynot a global opinion.
That probably belies my USexperience, but if you go into
Google, where I used to work, oryou walk into Microsoft, where
I used to work, or you walk intoAmazon, you will find that 95%
plus of the product managers andthere's probably hundreds or
maybe thousands of those folksin those companies you'll find
95% plus of the product managersand there's probably hundreds
or maybe thousands of thosefolks in those companies.

(04:26):
You'll find 95% plus have atechnical background, so they've
got a computer science degreeor something that looks like a
computer science degree.

Okay, because in my experience there's
a real mix of folks that workin product in the tech company
that I work for.
So is that sort of a preferencething, Like each company might
have their own preference on theskillset of their product
manager?
I think so.

And I think you know, being honest, if you look
in the UK, you look incontinental Europe, you look in
Australia, where I'm based, youwill find that the majority of
product managers don't have atechnical background, and I
think personally that's quiteproblematic.
Now, I'm not saying that thatshould be the case in every
single business, but I think oneof the really important parts
of product management is thatyou understand what's possible

(05:10):
with technology.
So you're somebody who's tryingto figure out what the team
should build and you have tounderstand what's possible with
technology to be able to answerthat question right, because
you're going to turn to yoursoftware engineers, the folks
that we talked about in our lastepisode.
You're going to turn to thosefolks and say, hey, we should
build the following thing, andthe only way you can have a

(05:31):
conversation that really is apowerful, meaningful
conversation where you're on apage, as they say, is if you
understand technology, becauseyou've got to be able to
advocate how technology cansolve the problem and the
engineers have got to understandthat and then go and figure out
how to actually build that.
So I think technology, a deepunderstanding of technology, is
absolutely core to being asuccessful product manager in

(05:52):
most companies.

Okay, that makes sense.
And then you've alluded to therelationship between the
engineering teams and theproduct teams, which is
something I'm really interestedin, and it sounds like you're
saying something like theproduct managers are figuring
out the what and maybe even thewhy, and then it's the
engineer's job to figure out howthey do something and then
maybe when they do it.
Is that a fair assessment?

I think it's a fabulous framework, hannah,
really really great.
And so maybe pulling that alittle bit apart, right?
So I think the place to startwith anything in technology is
to ask why are we doing this?
Why are we doing this?
Are we trying to grow the topline, get more revenue?
Are we trying to increase theengagement of our users?
Do we want more users?
Do we want our users to churnless?
Do we need our users to comeback more frequently?

(06:37):
Do we want to sell more stuff?
Whatever it is?
So you're going to have a why,and once you understand that why
, then you can start to thinkabout what can we do to actually
solve that problem?
And because product managers,technical product managers,
typically work on hardware andsoftware, it's going to be about
using technology to solve thatproblem.
So then they're going to thinkabout the business context, the

(06:59):
customer context, and they'regoing to conceive technical
solutions that might addressthose needs.
So it's very much the why andthe what, department and, as you
say, engineering, how, how arewe actually going to build this?
And then it's really importantthat the engineers own the when,
because they're the peopledoing the building.
That's not true in everycompany you will find in some
companies that they do what'scalled date-driven development,

(07:20):
where somebody tells theengineers when it has to be done
by, and that usually has lotsand lots of bad side effects.

What's the alternative to date-driven
development Proper?

estimation.
So if you think about maybe ananalogy right, so let's think
about building a house You'regoing to get the best house if
you let the builder provide youwith the timeline right.
So the builder really thinksthrough sort of what are the
steps in building the house,when do all the trades come in,
what are all the crafts andactually building the house, and
then they tell you when thehouse can be, can be done.

(07:49):
If you say to the builder, look, I don't care what you do, I
just need it in six months,you're probably not going to get
the house that you're you'redreaming about, right?
So well-run tech companiescertainly let the developers own
the estimation.
Part of a product manager's jobis to pressure test that right.
It's to say to the engineersagain, because they're technical
people, part of their job is topressure test that and say,
hang on a minute, I feel likeyou're not really understanding

(08:13):
what we need.
Can't we cut that corner?
Can't we do that a little bitsimpler?
Really, do we need to reallychange that system over there
now?
Can we defer that to a latermilestone?
So a good product manager willput a lot of pressure into the
how and the when, but ultimately, the engineers should be
accountable for the how and thewhen.

Okay, because I was going to ask you
about the relationship betweenproduct and engineering and if
there's like a necessary tension.
But it sounds like you'veanswered that question and, yes,
there sort of should be.
They should be pressing on eachother in terms of you know
what's really needed when it'sreally needed.

Yeah, definitely.
And I think from theengineering side, you know you
should be persuaded, you know,like you should be persuaded by
the product manager, that what'sbeing asked to be built is
worth building and then, whenyou're persuaded, you know,
really commit to figuring outhow to build it and when to
build it by.
So I think there should be areally healthy tension on both
sides.
I mean it's really sad when anengineering team just sort of
sighs and thinks that this isthe dumbest idea they've ever

(09:06):
heard and just sort of goes onyou know what we call a death
march, just building somethingthat they don't want to build.
I mean that's really really sad.
So it's really important thatthere's a lot of tension,
healthy tension, betweenengineers and the product
managers.

Yeah, makes sense.
A couple more follow-upquestions, things I've heard
working in a tech company thatI'd like us to talk about here.
So ratios that's something Ihear about a lot, and I
understand that to mean theratio between one product
manager and how many engineersthey're sort of marshalling.
Is there an industry standard?

I don't know that there's a sort of a widely
agreed industry standard, but Iwould say most of the companies
I've worked in you know Google,microsoft, ebay, these kinds of
places we always thought one to10 was about the right ratio for
a large team.
So you need about one productmanager for 10 engineers and
typically when you get deep downin dark parts of the
infrastructure you know thereally back end pieces typically

(09:56):
there'll be less productmanagers.
And typically as you get closerand closer to the customer, so
when you start moving pixelsaround the screen, building user
interfaces, then typicallyyou'll get a few more product
managers.
But I'd say on average one to10 is about the right number.

I like that distinction between the
deep dark infrastructure techand the more customer facing
stuff.
And what is a product managersort of doing day to day?
What activities does thatinvolve in practical terms?

We used to say in the US that product management
is kind of a soup to nuts sortof role.
So you know, start with a soup,finish with the nuts at the end
of the meal, so it's very muchsort of an end-to-end role.
And so at the very, verybeginning it's about, you know,
exploratory sort of userresearch.
So it's about trying to figureout what sorts of solutions
might work to solve this problemthat we're trying to solve.

(10:43):
So lots of talking to users,watching users, listening to
users, and then there's probablysort of a brainstorming element
coming up with possiblesolutions.
And then there's sort of asketching element, if it's
visual, so you know, drawing upwith pencil and paper what
screens might look like, howflows might work, and then you
sort of get into the realtechnical details and start to
write down documentation thatyou're actually ultimately going

(11:04):
to end up giving theengineering team.
And then lots of work with theengineering team while it's
being built, lots of work withthe engineering team while it's
being tested and all the bugsare being fixed.
And then probably back to thestart, because that's probably
just version one and you'llyou'll listen to the data that
you're getting from version oneand you'll go back to the start,
but it's very much like aboutthe whole product life cycle

(11:26):
that makes sense, except for thebit where you said you eat nuts
at the end of the meal, becausethat's not something I've ever
done, but that's not a techquestion.

So you mentioned user interfaces.
How does that interact withwhat we call ux?
So user experience because Ialways understood the user
experience seems to be the folksthinking about how the customer
so on a commerce website theymight be the shopper like how
they're interacting with thescreen and what's going to make
them add more items to basket ormake sure they get through

(11:54):
checkout.
But that sounds a lot like whatyou just described as product.

Yeah, great point .
There's a lot of tensionbetween product management and
user experience in mostcompanies, particularly as you
get sort of closer to the pixelsand you know what users see on
the screen.
And I would say that if I wasvoicing a user experience person
I would say look, my job is toreally design a user interface.
So come up with the look andthe feel of it, test that with

(12:19):
the customer and reallyunderstand is this something
that's going to work for them?
And then there's a whole bunchof graphic design right, really,
and really understand.
Is this something that's goingto work for them?
And then there's a whole bunchof graphic design right, really
getting the pixels right, thecolors, the fonts, should the
corners be rounded, whatever itis, and really manifesting a
beautiful experience.
But if I was talking about itfrom the product management side
, I'd say most product managersprobably want to get a pencil
and paper out, draw what thescreen should look like and give

(12:41):
it to a graphic designer andhave it done properly, and they
get a little bit frustrated withthe UX as sort of doing product
management and the productmanagement folks get a little
bit frustrated with the userexperience folks.
But in reality.
I think when you're a leadertrying to build teams, you know
you put the right userexperience people with the right
product management people andso you know if the product

(13:02):
management person is reallyreally fabulous at user
experience design, then you knowthey probably don't need
somebody who really wants to dothat whole user experience piece
on the user experience side.
And obviously vice versa isalso true.

Okay.
So at these edges of UX andproduct, where UX applies, and
then product and engineering,you end up with these sort of
regions of overlap whichbasically sound like they're
healthy and result in challengeand debate, which is ultimately
pretty productive.

Yeah, you know, my old boss at eBay, mark Kudges
, used to say to me you know,software engineering would be
really easy if it wasn't for allthe people involved, and I
think that's kind of true.
So you've got to get people towork together really, really
well and be a team and go besuccessful together.
If you have sort of frictionand people that spend too much
time talking about where theboundaries are, then you end up

(13:50):
with a suboptimal experience.

Okay, and something I've always heard
discussed when it comes toproduct management is the words
agile and waterfall, and myunderstanding and you'll correct
me imminently is that agileproduct management is less
constrained by date.
So you mentioned a littlemoment ago date driven

(14:13):
development work.
So I understood that agile wasmuch more like we build as we go
, we see what we need next, wedon't think too far ahead, and
that waterfall is like we have asort of long-term plan of the
things that we're going to buildand we're not going to deviate
from the plan because it's theplan and it's what we've agreed
that we need.
Is that fair and could you talkabout the sort of the pros and

(14:33):
cons of each?
Yeah?

yeah, great theme , hannah.
Waterfall was actually inventedin the early 1970s, and the
idea is to simply do steps oneby one, and I guess that's why
it's called a waterfall.
So then let's talk a little bitabout Agile.
So Agile is quite different and, if you like, in the early
2000s, when it was invented, itwas really a reaction to the
rigidity of waterfall andperhaps a reaction to the fact

(14:56):
that waterfall isn't a greatmethodology if you're building
online web accessible product.
So, instead of really longphases, what Agile does is
breaks down projects into whatare called sprints, and sprints,
if you like, are typically oneto four weeks, and each one of
these sprints is a little bitlike a complete project in the

(15:20):
waterfall sense.
But what makes it very, verydifferent is that the software
is delivered incrementally.
So that means that we beginwith the things that we think
are most important.
We might not even have a reallyclear idea exactly how the
features are going to turn out,so we start to build them, we
give them to the customer, weget some reactions from the

(15:42):
customer and then we use thatfeedback to continually improve
and refine the features, and sothe product kind of gets built
from the most important thingsdown to the least important
things, and we may not exactlyhave a sense for how those
features are going to look andfeel, and so we're reacting a
lot more to the data that'scoming back from the customer.

A lot more to the data that's coming
back from the customer.
In a world of modern technology, agile sounds more fun, a bit
sexier, but can that be a bit ofa nightmare if you're sort of
figuring things out on the flyBecause you kind of need a plan
that's more than one month out,or I assume that it's sensible
to plan more than one month out,but if you're sort of getting
into the work and seeing howlong it takes you, that sounds

(16:25):
like it could be quitefrustrating for some other
people in the business.

Yeah, and I think , look, there's a lot of art in
this right.
So as an engineering leader,that's sort of the essence of
what's difficult in the jobworking with the product
management team is you've got toreally think about sort of
what's going to happen over thisyear.
You've probably got to breakthat down into quarters.
You've got to have a prettyhigh fidelity idea of what's
going to happen in this quarter,because you're promising it to
the customers, you're promisingit to the business, but then the

(16:50):
details of exactly whichfeatures you work on, in which
order and how you sequence that,that can be a little bit more
flexible, but overall you betterget it roughly right.
So you've kind of got to pullup and say this is what I
believe we're going to do, maybeto a 90% fidelity over the next
three months.
But then you've got theflexibility day to day to be

(17:10):
doing things in the right order,listening to the customer,
looking at the data, workingthings through, and you've got
that sort of ability to kind ofTetris it, if you like, to sort
of put the pieces together in away that makes sense, that's
more agile than you know,something that's pre-planned and
inflexible.

Okay, I like the Tetris analogy.
That makes a lot of sense to meand, as we mentioned in our
last episode, that there's sortof books of excellent code.
I assume there's like a wholehost of resources.
Maybe we can link them in theshow notes around sort of
product management principlesthat people, if they were
interested or they work inproduct management, could go and
educate themselves around.

Absolutely.
Yeah, look, I will make sure.
In our show notes we have a fewgreat books that people can
read and some links to somefantastic resources.
There's also courses you cantake.
So a lot of the popularplatforms like Coursera have
short courses on productmanagement, and then some of the
major universities Harvard,columbia, university of
California, berkeley they haveactual large product management

(18:08):
programs, so masters of productmanagement, so you can actually
go and study it as a disciplinethese days.

Hugh, you spent a big part of your
career in product management.
You sort of spent a lot of yourcareer in engineering as well,
so I don't know whether youidentify as a product guy or an
engineering guy, but I waswondering if you could share
some examples of like goodproduct management in action, so
like that could be what a goodproduct manager is doing, or
like any products that thelisteners might, you know, be

(18:35):
really familiar with.
Like, do you have any funinsights about how they were
developed?

Yeah sure, first thing I'd say is I always seem
to get engineering titleswherever I work, and I think
that might be, you know, myqualifications in background,
but in my head I'm a productmanager.
I just don't see the point ofbuilding technology for
technology's sake, like itdoesn't interest me.
It maybe interested me when Iwas a lot younger, but I'm
really, really interested insolving business and customer
problems, and so productmanagement is sort of the way my

(19:01):
brain works.
It just happens I'm qualifiedas an engineer.

Okay, so it sounds like whoever's worked
as the product personinterfacing with you as the
engineering person probably hada bit of a nightmare time
working with you.
That healthy tension wasprobably very much in action,
yeah.

Yeah, definitely a healthy tension Leads me to a
good story, actually.
So probably my only reallysignificant claim to fame is I'm
one of the co-inventors ofInfinite Scroll.
And, of course, infinite scrollis this idea that you can
scroll forever, right?
So if you've used Instagram,tiktok, facebook, whatever it is
, or any of the popular imagesearch products, then you're
used to just scrolling forever.
You don't see pages, right?

(19:36):
Whereas in lots of other thingsMicrosoft, word, web search,
these kinds of things you'reused to seeing pages.
So I'm lucky enough to be oneof the co-inventors of that and,
you know, I think that's animportant landmark product
invention.
I'll tell you quickly thebackstory.
So I worked with julie faragoas the product manager.
So I was I was what microsoft'sknown as a dev lead, and so I

(19:57):
ran the image search team atmicrosoft.
I started that team with julieand we were up against google.
So this is 2005.
Google probably has aseven-year head start.
They've probably got 20 peopleworking on image search.
It's probably available in 100countries.
They've got over a billionimages in their index, so you

(20:18):
can search a billion images.
It's really really fast and theresults are really really good.
But what I would say is theiruser experience wasn't great.
If you go back to thatexperience in your head and I'm
sure some of our listeners areold enough to remember it it was
a paginated experience.
So what that means is there was20 thumbnails per page, little
thumbnails of images, and thenat the bottom there was a
control.

(20:39):
You remember that control thathad the G and lots and lots of
Os, and you press next, next,next, and you went and just
looked at pages and we did awhole bunch of deep diving into
how users use image search andwe happened to have a lot of
data at the time and what wefound is that the majority of
users pressed the next buttonand went to the next page and in

(21:01):
fact in web search that's quiterare.
So 75% of queries in web searchdon't go beyond page one.
But back in the old days withthis image search, to hit that
75% threshold you had to go topage seven, right?
So people love looking at lotsof images.
So one day where we're deep inthis data having this
conversation, there's a guy,nick craswell, who was a
researcher, julie and I sittingaround a table having this

(21:24):
conversation and we got talkingabout this data.
Nick actually found a user whotyped in the query butterfly and
went to page 77 before theypressed on a picture of a
butterfly and I assume that'sbecause people are scanning
image results super quickly soyou can fit.

Yeah, a picture's worth a thousand words
, right?

Is that old saying so, anyway, we're sitting
around this table, we'relooking at this data and
somebody says why are there only20 images per page, like, why
did Google and its predecessorsdo that?
So you know, excite, altavista,infosql, those really old
search engines they all did 20images per page.
And somebody said you know, whydon't we have 40 images per
page?

(22:02):
And then somebody said, whydon't we have 80 images per page
?
And then that conversation wenta little bit longer.
And then somebody said whydon't we just not have pages?
We could have an infinitescroll.
And so that was the moment thatinfinite scroll was invented.
It was technically quite hardto build.
That's probably a story foranother episode, but you know a
really great moment, and I thinkthat illustrates kind of the
healthy tension, if you like.

(22:23):
So we're all sitting around thetable looking at the data and
having an argument, and Julie'sjob was really to bring us
together, make us be data-driven, make us dig into the user,
make us think about the business.
At this point Microsoft wantedto make a splash and wanted us
to get in front as quickly aspossible, and so she brought
that context and then made usall look at the data, but

(22:43):
together we collaborativelycreated the answer.
So you can sort of see thehealthy working together there
and the overlapping in the roles.

That's an example of great product
management, because infinitescroll is very much a big part
of modern technology.
I was thinking more about somebad examples of product
management that the listenersmight recognize, and maybe bad
is unfair, because I think someof this stuff just times out.
But I was having a think aboutthis and came up with a few
ideas, so I'd love yourprofessional thoughts on this.
So one of the ones that I foundthat just really made me smile

(23:16):
was something called I didn'tknow of it at the time but
Microsoft Zune, which was like acompetitor to the iPod from
Microsoft.
That just like never wentanywhere, and I assume that will
be because Apple has a supersexy, smooth user interfaces and
they just sort of got therefirst and won the hearts and
minds.

Yeah, I think that's right.
I mean, I was actually atMicrosoft when the Zune was
built and released and sadly, Ithink yeah, the majority of
users were Microsoft employees.
Did you have one?
I did not, Though.
When I was at Microsoft, youused to have to hide your iPhone
when Steve Ballmer was around.
He used to get pretty upsetwhen people used iPhones.

So Microsoft Zoom didn't even
really make it to the mainstream.
Another one I was thinkingabout was the Google chat
function.
Gchat, I think it was called.
I was on the Google graveyardwebsite and I think it might be
officially retired.
I couldn't exactly get ananswer.
But like, google chat used to belike a little pop-up instant
messaging service within theGoogle suite, and I'm a big fan

(24:15):
of the Google suite, like I useGmail, I love docs, I love
sheets, but I am a Slack diehard, so I think most listeners will
be familiar with Slack, butmaybe not.
It's like an instant messaging,basically an instant messaging
service, but you can also sharedocuments.
It's really good communicationtool, especially in the sort of
modern working environment.
But Google Chat was just likeit was integrated into Google,

(24:38):
it had every chance ofsucceeding and there was just
something about the way itworked.
It felt sort of super oldschool that it was just blown
out the water by Slack.
So is that fair to say thatthat's bad product management?
That they just they couldn'tland that element of the product
with users?

Yeah, look, I think there was some bad product
management.
Perhaps, though, it's more anissue at the top of the company,
if you like.
So Google ended up with a very,very fragmented messaging
strategy.
They had multiple competingproducts, so at some level they
ended up competing withthemselves.
So they had things like GoogleChat, Google Talk, hangouts,

(25:18):
allo, duo some products thatyou've probably even forgotten
that are certainly in the Googlegraveyard.
So I think they were confusing.
So there's an overall sort ofvice president level senior
level product management problemthere, I think at Google.
But Google Chat itself wasactually pretty popular.
It was in Gmail and it wasreally quite successful during
its heyday in the mid to late2000s.
But really what happened to itwas other mobile messaging apps

(25:41):
came along.
So things like WhatsApp,imessage in the Apple ecosystem
and Facebook Messenger camealong, and they just offered
more features to customers thatoffered them a better experience
.
So things like they were betteron mobile, and I'm sure most
listeners use WhatsApp, imessageand Facebook Messenger on their
phones.
They had group messaging, whichI know just about everybody

(26:04):
uses, particularly on WhatsApp,and they also had multimedia
sharing.
So, if you like, theexpectations moved up a lot from
what Google Chat was actuallydelivering.
So you could argue that therewas some product management
issues, particularly withinGoogle Chat, so it wasn't really
being aware enough of itscompetitors and it wasn't moving

(26:24):
fast enough.
But I think the overall issuewas that Google was frankly
confusing as a product companywhen it came to messaging.

And then I was thinking about Skype,
because it, famously, wasfinally deprecated recently, but
back in, I would say like 2008,.
Game changer for us to be ableto speak to each other.
And I was thinking like, isthis bad product management?
Is it just timing, like didthey not keep up with the times
or did the market just changearound it enough that it was

(26:52):
time to call it a day?

Yeah, I think a few things happened there.
I mean, it was an independentcompany ended up being bought by
eBay PayPal.
I think the thesis was thatSkype could be something that
buyers and sellers could use tocommunicate with each other on
eBay.
But it was a terrible fitreally.
It was a terrible idea, aterrible business idea.
It sort of languished at eBaywas a terrible idea, a terrible

(27:16):
business idea.
It sort of languished at eBayand then eventually it ended up
at Microsoft and became part ofthe team that built Teams in the
end.
So I think there's a bunch ofbusiness missteps there and a
real cast of characters involvedand a lot of changes went on
and I think the world passed itby during all those changes.
So you had things like Zoomappear in the end that were
better quality sound, betterpictures.

(27:38):
I mean, you and I are usingGoogle Meet to communicate today
and I think you know all aroundthat has a better feature set
than Skype did towards the end.
So I think you know combinationof sort of business missteps
and product execution kind ofled them to lose their lead and
it just shows you right.
You've got to really keep aneye on your competitor and
that's an important part ofproduct management is really,

(27:58):
you know, knowing and lovingyour competitors, and you know
you've got to keep moving,otherwise people will come and
take your crown.

Okay, so an eye on the competitors is
clearly super important in theproduct space.
Is that something like ifyou're a product manager for
Amazon, are you all over eBayand Alibaba to keep yourself up
to date with this sort of newfeature set?

I think the best product managers absolutely do
that, hannah.
And to tell you a quick storytoo, I was lucky enough at the
end of my executive career inthe US to run Google Maps, so I
looked after the product andengineering teams for Google
Maps and I can tell you that Iquite often used to drive to
work using Apple Maps.

But you were doing that just to know
they hadn't changed their gameor come up with anything, yeah,
and I had a lot of respect forthem.

I knew they were trying really, really hard.
They had a catastrophic launchin 2012 and this is more like
2015 when I was using it.
So they'd really got off theirknees and kept on going and they
were beginning to do somepretty useful things.
I'll give you a couple ofexamples.
Actually, they were the firstones to have a parking feature.
So when you parked your car,they'd put a pin on the map that
showed where you parked yourcar Fantastic feature.

(29:03):
So I remember going into Googleand saying you know, hey,
apple's got this awesome feature.
One of the product managerssaid oh yeah, we've got that
kind of que and got on with thatand ultimately Google released
that, I think probably six orseven months later than Apple,
but I thought it was a greatfeature.

Okay, I'm loving these insider stories
here.
Have you got one more you cangive us before the end of the
episode?

I've got a great one and I hope you'll enjoy this
one.
I was speaking to my friend,Jim Walsh, who I worked with at
Microsoft.
He was my first boss atMicrosoft Great guy, Jim and we
were talking about theWordPerfect Microsoft Word
battle and for those listenerswho've never heard of
WordPerfect, it was the dominantword processing software of the
late 80s and early 90s.

The Skype of its time, the.

Skype of its time and, in fact, if you go back to
the mid to late 1980s, I'd sayMicrosoft Word's share of the
market was probably three orfour percent.
You know, WordPerfect was thisgiant gorilla and there was
another thing called WordStar.
So they were the two bigdominant word processing pieces
of software and, of course, fastforward to today.
It's Microsoft Word in everyenterprise, right With a little

(30:09):
bit of Google Docs thrown in.
But going back to the story, sohow did Microsoft Word beat
WordPerfect?
Well, I'll stick to the productmanagement side.
I think there's probably amarketing story and a
positioning story and a fewother things that contribute to
this, but a couple of quickthings.
So one thing that happened atMicrosoft is they understood

(30:30):
that WordPerfect was incrediblypopular in the legal domain and
that that was a really popularplace, that WordPerfect was
incredibly popular in the legaldomain and that that was a
really popular place, thatWordPerfect was used.
So I know that Jim told me this.
One of the senior folks who wasworking on Microsoft Word went
to a bunch of legal companiesand watched how legal
secretaries and attorneys workedwithin US companies.

(30:53):
So how did they actuallyinteract with each other and
what was the process and somegreat product management there,
right?
So really digging into whatusers do, and he understood that
there was lots of reviewing ofdrafts of legal documents, right
?
So the legal secretaries backin the day they were paid about
$70,000 each and a typicalsecretary was getting paid

(31:13):
$30,000.
So you got paid a real premiumto be a legal secretary because
you had to be good atWordPerfect.
They would draft the documentswith this WordPerfect word
processing tool and then theywould print things out, take
them to the attorney and theattorney would read things,
They'd underline things and it'dkind of go back to the legal
secretaries for editing.
And the folks working on Wordrealized that this was a little

(31:35):
bit cumbersome and so that's howtrack changes got invented in
Word, yeah, so they really builta process where the attorneys
could actually look at thedocument, make edits to the
document in real time, actuallyby touching the keys on the
keyboard rather than sending itback to the legal secretaries.
And all of a sudden, Wordbecame popular in legal

(31:56):
departments, despite thesecretaries not really wanting
it to be popular because theywere getting paid a premium to
use WordPerfect.
But you know, the attorneysjust found it easier when they
got their emails, which were allMicrosoft-based, and they all
understood how to use MicrosoftWord.
They just found it easier tostart typing things in and all
of a sudden, you know, Wordstarted to take over from word
perfect.
So there's one one story for you.

(32:16):
Another story is a really bigmisstep by word perfect that the
word folks capitalized on.
So if you sort of fast forwardinto the mid 1990s, word perfect
was trying to launch a windowsversion.
So this is a sort of you know,it's all the old microsoft dos
days.
So you know you didn't have the, the windows that we're all
used to today, and WordPerfectwas trying to get into that

(32:37):
space, and so they were going torelease this thing called
WordPerfect 7 for Windows, andit was a disastrous release.
So when they released it it wasbuggy and it crashed.
But most interestingly, it dida terrible job of opening and
displaying documents that werewritten with the previous
version of WordPerfect, whichwas WordPerfect 6.
So if you opened a WordPerfect6 document it might crash the

(33:00):
actual software or it justwouldn't look very good.
The Word guys saw this and theysaid we're going to do a better
job, and so the version ofMicrosoft Word that came out did
a fabulous job of importingWordPerfect 6, and the
WordPerfect 6 documents lookedperfect and the users just
flocked to Microsoft Word andthat was kind of pretty much the

(33:20):
end of WordPerfect.
So again some really goodproduct management and in this
case some really deep, darktechnical details, but a really
good story of again getting thetiming right and really
delivering a feature that thecustomers cared about at a
moment of weakness for yourcompetitor.

So that feels like the perfect place to
end this episode, because it's aperfect illustration of product
management as this criticalbridging role Eye on the
customer, eye on the businessand market eye on the technology
and you end up with an awesomeproduct that cuts through and
gives customers what they need.

Yeah, great way to wrap up the episode, Hannah.

Okay, well, thanks so much for tuning
in everyone.
This has been the Tech OverflowPodcast.

I'm Hannah and I'm Hugh, and you can find us at
our website, which istechoverflowpodcastcom.
You can find us on LinkedIn,tech Overflow Podcast, and we're
also available on Instagram andX, and we would love you to
share this episode and tell yourfriends about our show and
we'll link anything that we'vementioned throughout this
episode into the show notes.

Thanks so much.
See you, Hugh.
Thanks, Hannah.
Bye.

All Episodes

Episode Transcript

Popular Podcasts

Stuff You Should Know

Dateline NBC

On Purpose with Jay Shetty

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Product Management Demystified

Episode Transcript

Popular Podcasts

.css-r6mb8g{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:1;overflow:hidden;}Stuff You Should Know

Dateline NBC

On Purpose with Jay Shetty

All Episodes

Product Management Demystified

Stuff You Should Know