Hannah Clayton-Langton: 0:04

Hello world, welcome to the Tech Overflow podcast, the podcast where we explain technical concepts to non-technical people. I'm Hannah. I've spent three years working at a tech company. I didn't really understand what most 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 you all along with me.

Hugh Williams: 0:21

My name is Hugh Williams. I'm a former engineering vice president at Google and at eBay, and I began my career in the United States working in engineering at Microsoft. Hannah's recruited me to help demystify how technology works, and today we're going to be talking about product management.

Hannah Clayton-Langton: 0:38

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

Hugh Williams: 0:45

So, hannah, I can think of a few different types of examples. So Instagram's a product, obviously. You can get that for a smartphone, you can access that on the web, but I'd say it's a single product in any case. Second example Microsoft Word. I hope we'll get a chance to come back and talk about Word a little bit later on, but Microsoft Word's a product. I'd argue that Microsoft Office is a suite of products. And then, last of all, lots of us use Workday at work to do all the people management stuff. I'd say that's an example of an enterprise product, one that you'd often use in the workplace.

Hannah Clayton-Langton: 1:20

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

Hugh Williams: 1:27

I've never met somebody who loves Workday.

Hannah Clayton-Langton: 1:28

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

Hugh Williams: 1:33

Yeah, for sure. I mean, let's maybe just pick on two of the examples, right? So Instagram has some complexity, for sure, but I would say, relative to microsoft word, it's a much less complex product and perhaps the way to illustrate it is just a you know, talk for 30 seconds about microsoft word. If you just think about all of the things that are in microsoft word, right, so you can import and export lots of different file formats, you can be working in microsoft excel and you can actually cut and paste into microsoft word, you can imagine how hard that is to build. Think about printing, right, you have to work with all sorts of different printing devices and then there's all the elements around the actual, you know, typing itself. So think of all the elements around, sort of styling, headings, fonts, colors, tables, all those kinds of things. So it's a very, very complex product.

Hannah Clayton-Langton: 2:24

So everything I'm interacting with basically drives the complexity of the product, because I want to change my font size, how it's aligned on the page. I might want to interact with hardware or upload a photo, or I don't know if Clippy is still a thing, but Copilot's probably the new Clippy, I would say. Fair enough, clippy was very much a feature of the 90s. So what is product management then? What does that mean? What are product managers working on it?

Hugh Williams: 2:47

So there's not like a one-to-one mapping between a product and a product manager, but product management itself is really the intersection of three things is the way I like to think of it. So it's the intersection of the customer, the intersection of the business and the intersection of technology. So imagine there's this Venn diagram. It's got three circles, those circles overlap and there's this beautiful sweet spot in the middle and the product manager is somebody who sits at that intersection. So they're somebody with empathy and understanding of the customer. You know what customers want. They're somebody who really deeply understands the business and how the business works and can talk to the commercial team, the finance folks, the marketing team, the legal folks. All of those folks understand that context and how the business itself works. And, importantly, they're somebody who really understands technology and how technology can be used to solve problems for the customer and the business.

Hannah Clayton-Langton: 3:58

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

Hugh Williams: 4:05

So, how technical do product managers need to be? Do they need to understand coding, for example? I think so. Yes, you know that's probably not a global opinion. That probably belies my US experience, but if you go into Google, where I used to work, or you walk into Microsoft, where I used to work, or you walk into Amazon, you will find that 95% plus of the product managers and there's probably hundreds or maybe thousands of those folks in those companies you'll find 95% plus of the product managers and there's probably hundreds or maybe thousands of those folks in those companies. You'll find 95% plus have a technical background, so they've got a computer science degree or something that looks like a computer science degree.

Hannah Clayton-Langton: 4:34

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

Hugh Williams: 4:47

And I think you know, being honest, if you look in the UK, you look in continental Europe, you look in Australia, where I'm based, you will find that the majority of product managers don't have a technical background, and I think personally that's quite problematic.

Hugh Williams: 5:01

Now, I'm not saying that that should be the case in every single business, but I think one of the really important parts of product management is that you understand what's possible with technology. So you're somebody who's trying to figure out what the team should build and you have to understand what's possible with technology to be able to answer that question right, because you're going to turn to your software engineers, the folks that we talked about in our last episode. You're going to turn to those folks and say, hey, we should build the following thing, and the only way you can have a conversation that really is a powerful, meaningful conversation where you're on a page, as they say, is if you understand technology, because you've got to be able to advocate how technology can solve the problem and the engineers have got to understand that and then go and figure out how to actually build that. So I think technology, a deep understanding of technology, is absolutely core to being a successful product manager in most companies.

Hannah Clayton-Langton: 5:53

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

Hugh Williams: 6:15

I think it's a fabulous framework, hannah, really really great. And so maybe pulling that a little bit apart, right? So I think the place to start with anything in technology is to ask why are we doing this? Why are we doing this? Are we trying to grow the top line, get more revenue? Are we trying to increase the engagement of our users? Do we want more users? Do we want our users to churn less? Do we need our users to come back more frequently? Do we want to sell more stuff? Whatever it is?

Hugh Williams: 6:41

So you're going to have a why, and once you understand that why, then you can start to think about what can we do to actually solve that problem? And because product managers, technical product managers, typically work on hardware and software, it's going to be about using technology to solve that problem. So then they're going to think about the business context, the customer context, and they're going to conceive technical solutions that might address those needs. So it's very much the why and the what, department and, as you say, engineering, how, how are we actually going to build this? And then it's really important that the engineers own the when, because they're the people doing the building. That's not true in every company you will find in some companies that they do what's called date-driven development, where somebody tells the engineers when it has to be done by, and that usually has lots and lots of bad side effects.

Hannah Clayton-Langton: 7:26

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

Hugh Williams: 7:28

estimation. So if you think about maybe an analogy right, so let's think about building a house You're going to get the best house if you let the builder provide you with the timeline right. So the builder really thinks through sort of what are the steps in building the house, when do all the trades come in, what are all the crafts and actually building the house, and then they tell you when the house can be, can be done. 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're dreaming about, right? So well-run tech companies certainly let the developers own the estimation.

Hugh Williams: 8:01

Part of a product manager's job is to pressure test that right. It's to say to the engineers again, because they're technical people, part of their job is to pressure test that and say, hang on a minute, I feel like you're not really understanding what we need. Can't we cut that corner? Can't we do that a little bit simpler? Really, do we need to really change that system over there now? Can we defer that to a later milestone? So a good product manager will put a lot of pressure into the how and the when, but ultimately, the engineers should be accountable for the how and the when.

Hannah Clayton-Langton: 8:30

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

Hugh Williams: 8:44

Yeah, definitely. And I think from the engineering side, you know you should be persuaded, you know, like you should be persuaded by the product manager, that what's being asked to be built is worth building and then, when you're persuaded, you know, really commit to figuring out how to build it and when to build it by. So I think there should be a really healthy tension on both sides. I mean it's really sad when an engineering team just sort of sighs and thinks that this is the dumbest idea they've ever heard and just sort of goes on you know what we call a death march, just building something that they don't want to build. I mean that's really really sad. So it's really important that there's a lot of tension, healthy tension, between engineers and the product managers.

Hannah Clayton-Langton: 9:17

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

Hugh Williams: 9:34

I don't know that there's a sort of a widely agreed industry standard, but I would say most of the companies I've worked in you know Google, microsoft, ebay, these kinds of places we always thought one to 10 was about the right ratio for a large team. So you need about one product manager for 10 engineers and typically when you get deep down in dark parts of the infrastructure you know the really back end pieces typically there'll be less product managers. And typically as you get closer and closer to the customer, so when you start moving pixels around the screen, building user interfaces, then typically you'll get a few more product managers. But I'd say on average one to 10 is about the right number.

Hannah Clayton-Langton: 10:09

I like that distinction between the deep dark infrastructure tech and the more customer facing stuff. And what is a product manager sort of doing day to day? What activities does that involve in practical terms?

Hugh Williams: 10:21

We used to say in the US that product management is kind of a soup to nuts sort of role.

Hugh Williams: 10:26

So you know, start with a soup, finish with the nuts at the end of the meal, so it's very much sort of an end-to-end role.

Hugh Williams: 10:30

And so at the very, very beginning it's about, you know, exploratory sort of user research.

Hugh Williams: 10:36

So it's about trying to figure out what sorts of solutions might work to solve this problem that we're trying to solve.

Hugh Williams: 10:43

So lots of talking to users, watching users, listening to users, and then there's probably sort of a brainstorming element coming up with possible solutions. And then there's sort of a sketching element, if it's visual, so you know, drawing up with pencil and paper what screens might look like, how flows might work, and then you sort of get into the real technical details and start to write down documentation that you're actually ultimately going to end up giving the engineering team. And then lots of work with the engineering team while it's being built, lots of work with the engineering team while it's being tested and all the bugs are being fixed. And then probably back to the start, because that's probably just version one and you'll you'll listen to the data that you're getting from version one and you'll go back to the start, but it's very much like about the whole product life cycle that makes sense, except for the bit where you said you eat nuts at the end of the meal, because that's not something I've ever done, but that's not a tech question.

Hannah Clayton-Langton: 11:34

So you mentioned user interfaces. How does that interact with what we call ux? So user experience because I always understood the user experience seems to be the folks thinking about how the customer so on a commerce website they might be the shopper like how they're interacting with the screen and what's going to make them add more items to basket or make sure they get through checkout. But that sounds a lot like what you just described as product.

Hugh Williams: 11:58

Yeah, great point. There's a lot of tension between product management and user experience in most companies, particularly as you get sort of closer to the pixels and you know what users see on the screen. And I would say that if I was voicing a user experience person I would say look, my job is to really design a user interface. So come up with the look and the feel of it, test that with the customer and really understand is this something that's going to work for them? And then there's a whole bunch of graphic design right, really, and really understand. Is this something that's going to work for them? And then there's a whole bunch of graphic design right, really getting the pixels right, the colors, the fonts, should the corners be rounded, whatever it is, and really manifesting a beautiful experience.

Hugh Williams: 12:36

But if I was talking about it from the product management side, I'd say most product managers probably want to get a pencil and paper out, draw what the screen should look like and give it to a graphic designer and have it done properly, and they get a little bit frustrated with the UX as sort of doing product management and the product management folks get a little bit frustrated with the user experience folks. But in reality. I think when you're a leader trying to build teams, you know you put the right user experience people with the right product management people and so you know if the product management person is really really fabulous at user experience design, then you know they probably don't need somebody who really wants to do that whole user experience piece on the user experience side. And obviously vice versa is also true.

Hannah Clayton-Langton: 13:14

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

Hugh Williams: 13:30

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 all the people involved, and I think that's kind of true. So you've got to get people to work together really, really well and be a team and go be successful together. If you have sort of friction and people that spend too much time talking about where the boundaries are, then you end up with a suboptimal experience.

Hannah Clayton-Langton: 13:52

Okay, and something I've always heard discussed when it comes to product management is the words agile and waterfall, and my understanding and you'll correct me imminently is that agile product management is less constrained by date. So you mentioned a little moment ago date driven development work. So I understood that agile was much more like we build as we go, we see what we need next, we don't think too far ahead, and that waterfall is like we have a sort of long-term plan of the things that we're going to build and we're not going to deviate from the plan because it's the plan and it's what we've agreed that we need. Is that fair and could you talk about the sort of the pros and cons of each? Yeah?

Hugh Williams: 14:34

yeah, great theme, hannah. Waterfall was actually invented in the early 1970s, and the idea is to simply do steps one by one, and I guess that's why it's called a waterfall. So then let's talk a little bit about Agile. So Agile is quite different and, if you like, in the early 2000s, when it was invented, it was really a reaction to the rigidity of waterfall and perhaps a reaction to the fact that waterfall isn't a great methodology if you're building online web accessible product. So, instead of really long phases, what Agile does is breaks down projects into what are called sprints, and sprints, if you like, are typically one to four weeks, and each one of these sprints is a little bit like a complete project in the waterfall sense.

Hugh Williams: 15:21

But what makes it very, very different is that the software is delivered incrementally. So that means that we begin with the things that we think are most important. We might not even have a really clear idea exactly how the features are going to turn out, so we start to build them, we give them to the customer, we get some reactions from the customer and then we use that feedback to continually improve and refine the features, and so the product kind of gets built from the most important things down to the least important things, and we may not exactly have a sense for how those features are going to look and feel, and so we're reacting a lot more to the data that's coming back from the customer.

Hannah Clayton-Langton: 16:04

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 of a nightmare if you're sort of figuring things out on the fly Because 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 how long it takes you, that sounds like it could be quite frustrating for some other people in the business.

Hugh Williams: 16:27

Yeah, and I think, look, there's a lot of art in this right.

Hugh Williams: 16:30

So as an engineering leader, that's sort of the essence of what's difficult in the job working with the product management team is you've got to really think about sort of what's going to happen over this year.

Hugh Williams: 16:40

You've probably got to break that down into quarters. You've got to have a pretty high fidelity idea of what's going to happen in this quarter, because you're promising it to the customers, you're promising it to the business, but then the details of exactly which features you work on, in which order and how you sequence that, that can be a little bit more flexible, but overall you better get it roughly right. So you've kind of got to pull up and say this is what I believe we're going to do, maybe to a 90% fidelity over the next three months. But then you've got the flexibility day to day to be doing things in the right order, listening to the customer, looking at the data, working things through, and you've got that sort of ability to kind of Tetris it, if you like, to sort of put the pieces together in a way that makes sense, that's more agile than you know, something that's pre-planned and inflexible.

Hannah Clayton-Langton: 17:28

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

Hugh Williams: 17:47

Absolutely. Yeah, look, I will make sure. In our show notes we have a few great books that people can read and some links to some fantastic resources. There's also courses you can take. So a lot of the popular platforms like Coursera have short courses on product management, and then some of the major universities Harvard, columbia, university of California, berkeley they have actual large product management programs, so masters of product management, so you can actually go and study it as a discipline these days.

Hannah Clayton-Langton: 18:14

Hugh, you spent a big part of your career in product management. You sort of spent a lot of your career in engineering as well, so I don't know whether you identify as a product guy or an engineering guy, but I was wondering if you could share some examples of like good product management in action, so like that could be what a good product manager is doing, or like any products that the listeners might, you know, be really familiar with. Like, do you have any fun insights about how they were developed?

Hugh Williams: 18:38

Yeah sure, first thing I'd say is I always seem to get engineering titles wherever I work, and I think that might be, you know, my qualifications in background, but in my head I'm a product manager. I just don't see the point of building technology for technology's sake, like it doesn't interest me. It maybe interested me when I was a lot younger, but I'm really, really interested in solving business and customer problems, and so product management is sort of the way my brain works. It just happens I'm qualified as an engineer.

Hannah Clayton-Langton: 19:09

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

Hugh Williams: 19:15

Yeah, definitely a healthy tension Leads me to a good story, actually. So probably my only really significant claim to fame is I'm one of the co-inventors of Infinite Scroll. And, of course, infinite scroll is this idea that you can scroll forever, right? So if you've used Instagram, tiktok, facebook, whatever it is, or any of the popular image search products, then you're used to just scrolling forever. You don't see pages, right? Whereas in lots of other things Microsoft, word, web search, these kinds of things you're used to seeing pages. So I'm lucky enough to be one of the co-inventors of that and, you know, I think that's an important landmark product invention.

Hugh Williams: 19:50

I'll tell you quickly the backstory. So I worked with julie farago as the product manager. So I was I was what microsoft's known as a dev lead, and so I ran the image search team at microsoft. I started that team with julie and we were up against google. So this is 2005. Google probably has a seven-year head start. They've probably got 20 people working on image search. It's probably available in 100 countries. They've got over a billion images in their index, so you can search a billion images. It's really really fast and the results are really really good. But what I would say is their user experience wasn't great. If you go back to that experience in your head and I'm sure some of our listeners are old enough to remember it it was a paginated experience. So what that means is there was 20 thumbnails per page, little thumbnails of images, and then at the bottom there was a control.

Hugh Williams: 20:39

You remember that control that had 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 a whole bunch of deep diving into how users use image search and we happened to have a lot of data at the time and what we found is that the majority of users pressed the next button and went to the next page and in fact in web search that's quite rare.

Hugh Williams: 21:03

So 75% of queries in web search don't go beyond page one. But back in the old days with this image search, to hit that 75% threshold you had to go to page seven, right? So people love looking at lots of images. So one day where we're deep in this data having this conversation, there's a guy, nick craswell, who was a researcher, julie and I sitting around a table having this conversation and we got talking about this data. Nick actually found a user who typed in the query butterfly and went to page 77 before they pressed on a picture of a butterfly and I assume that's because people are scanning image results super quickly so you can fit.

Hannah Clayton-Langton: 21:40

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

Hugh Williams: 21:42

Is that old saying so, anyway, we're sitting around this table, we're looking at this data and somebody says why are there only 20 images per page, like, why did Google and its predecessors do that? So you know, excite, altavista, infosql, those really old search engines they all did 20 images per page. And somebody said you know, why don't we have 40 images per page? And then somebody said, why don't we have 80 images per page? And then that conversation went a little bit longer. And then somebody said why don't we just not have pages? We could have an infinite scroll.

Hugh Williams: 22:15

And so that was the moment that infinite scroll was invented. It was technically quite hard to build. That's probably a story for another episode, but you know a really great moment, and I think that illustrates kind of the healthy tension, if you like. So we're all sitting around the table looking at the data and having an argument, and Julie's job 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 wanted to make a splash and wanted us to get in front as quickly as possible, and so she brought that context and then made us all look at the data, but together we collaboratively created the answer. So you can sort of see the healthy working together there and the overlapping in the roles.

Hannah Clayton-Langton: 22:55

That's an example of great product management, because infinite scroll is very much a big part of modern technology. I was thinking more about some bad examples of product management that the listeners might recognize, and maybe bad is unfair, because I think some of this stuff just times out. But I was having a think about this and came up with a few ideas, so I'd love your professional thoughts on this. So one of the ones that I found that just really made me smile was something called I didn't know of it at the time but Microsoft Zune, which was like a competitor to the iPod from Microsoft. That just like never went anywhere, and I assume that will be because Apple has a super sexy, smooth user interfaces and they just sort of got there first and won the hearts and minds.

Hugh Williams: 23:33

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

Hannah Clayton-Langton: 23:53

So Microsoft Zoom didn't even really make it to the mainstream. Another one I was thinking about was the Google chat function. Gchat, I think it was called. I was on the Google graveyard website and I think it might be officially retired. I couldn't exactly get an answer.

Hannah Clayton-Langton: 24:09

But like, google chat used to be like a little pop-up instant messaging service within the Google suite, and I'm a big fan of the Google suite, like I use Gmail, I love docs, I love sheets, but I am a Slack diehard, so I think most listeners will be familiar with Slack, but maybe not. It's like an instant messaging, basically an instant messaging service, but you can also share documents. It's really good communication tool, especially in the sort of modern working environment. But Google Chat was just like it was integrated into Google, it had every chance of succeeding and there was just something about the way it worked. It felt sort of super old school that it was just blown out the water by Slack. So is that fair to say that that's bad product management? That they just they couldn't land that element of the product with users?

Hugh Williams: 24:52

Yeah, look, I think there was some bad product management. Perhaps, though, it's more an issue at the top of the company, if you like. So Google ended up with a very, very fragmented messaging strategy. They had multiple competing products, so at some level they ended up competing with themselves. So they had things like Google Chat, Google Talk, hangouts, allo, duo some products that you've probably even forgotten that are certainly in the Google graveyard. So I think they were confusing. So there's an overall sort of vice president level senior level product management problem there, I think at Google.

Hugh Williams: 25:28

But Google Chat itself was actually pretty popular. It was in Gmail and it was really quite successful during its heyday in the mid to late 2000s. But really what happened to it was other mobile messaging apps came along. So things like WhatsApp, imessage in the Apple ecosystem and Facebook Messenger came along, and they just offered more features to customers that offered them a better experience. So things like they were better on mobile, and I'm sure most listeners use WhatsApp, imessage and Facebook Messenger on their phones. They had group messaging, which I know just about everybody uses, particularly on WhatsApp, and they also had multimedia sharing. So, if you like, the expectations moved up a lot from what Google Chat was actually delivering. So you could argue that there was some product management issues, particularly within Google Chat, so it wasn't really being aware enough of its competitors and it wasn't moving fast enough. But I think the overall issue was that Google was frankly confusing as a product company when it came to messaging.

Hannah Clayton-Langton: 26:31

And then I was thinking about Skype, because it, famously, was finally deprecated recently, but back in, I would say like 2008,. Game changer for us to be able to speak to each other. And I was thinking like, is this bad product management? Is it just timing, like did they not keep up with the times or did the market just change around it enough that it was time to call it a day?

Hugh Williams: 26:54

Yeah, I think a few things happened there. I mean, it was an independent company ended up being bought by eBay PayPal. I think the thesis was that Skype could be something that buyers and sellers could use to communicate with each other on eBay. But it was a terrible fit really. It was a terrible idea, a terrible business idea. It sort of languished at eBay was a terrible idea, a terrible business idea. It sort of languished at eBay and then eventually it ended up at Microsoft and became part of the team that built Teams in the end.

Hugh Williams: 27:23

So I think there's a bunch of business missteps there and a real cast of characters involved and a lot of changes went on and I think the world passed it by during all those changes. So you had things like Zoom appear in the end that were better quality sound, better pictures. I mean, you and I are using Google Meet to communicate today and I think you know all around that has a better feature set than Skype did towards the end. So I think you know combination of sort of business missteps and product execution kind of led them to lose their lead and it just shows you right. You've got to really keep an eye on your competitor and that's an important part of product management is really, you know, knowing and loving your competitors, and you know you've got to keep moving, otherwise people will come and take your crown.

Hannah Clayton-Langton: 28:05

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

Hugh Williams: 28:20

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

Hannah Clayton-Langton: 28:35

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

Hugh Williams: 28:42

I knew they were trying really, really hard. They had a catastrophic launch in 2012 and this is more like 2015 when I was using it. So they'd really got off their knees and kept on going and they were beginning to do some pretty useful things. I'll give you a couple of examples. Actually, they were the first ones to have a parking feature. So when you parked your car, they'd put a pin on the map that showed where you parked your car Fantastic feature. So I remember going into Google and saying you know, hey, apple's got this awesome feature. One of the product managers said oh yeah, we've got that kind of que and got on with that and ultimately Google released that, I think probably six or seven months later than Apple, but I thought it was a great feature.

Hannah Clayton-Langton: 29:20

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

Hugh Williams: 29:25

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 at Microsoft Great guy, Jim and we were talking about the WordPerfect Microsoft Word battle and for those listeners who've never heard of WordPerfect, it was the dominant word processing software of the late 80s and early 90s.

Hannah Clayton-Langton: 29:46

The Skype of its time, the.

Hugh Williams: 29:47

Skype of its time and, in fact, if you go back to the mid to late 1980s, I'd say Microsoft Word's share of the market was probably three or four percent. You know, WordPerfect was this giant gorilla and there was another thing called WordStar. So they were the two big dominant word processing pieces of software and, of course, fast forward to today. It's Microsoft Word in every enterprise, right With a little bit of Google Docs thrown in. But going back to the story, so how did Microsoft Word beat WordPerfect? Well, I'll stick to the product management side. I think there's probably a marketing story and a positioning story and a few other things that contribute to this, but a couple of quick things. So one thing that happened at Microsoft is they understood that WordPerfect was incredibly popular in the legal domain and that that was a really popular place, that WordPerfect was incredibly popular in the legal domain and that that was a really popular place, that WordPerfect was used. So I know that Jim told me this. One of the senior folks who was working on Microsoft Word went to a bunch of legal companies and watched how legal secretaries and attorneys worked within US companies. So how did they actually interact with each other and what was the process and some great product management there, right? So really digging into what users do, and he understood that there was lots of reviewing of drafts of legal documents, right? So the legal secretaries back in the day they were paid about $70,000 each and a typical secretary was getting paid $30,000. So you got paid a real premium to be a legal secretary because you had to be good at WordPerfect. They would draft the documents with this WordPerfect word processing tool and then they would print things out, take them to the attorney and the attorney would read things, They'd underline things and it'd kind of go back to the legal secretaries for editing. And the folks working on Word realized that this was a little bit cumbersome and so that's how track changes got invented in Word, yeah, so they really built a process where the attorneys could actually look at the document, make edits to the document in real time, actually by touching the keys on the keyboard rather than sending it back to the legal secretaries. And all of a sudden, Word became popular in legal departments, despite the secretaries not really wanting it to be popular because they were getting paid a premium to use WordPerfect. But you know, the attorneys just found it easier when they got their emails, which were all Microsoft-based, and they all understood how to use Microsoft Word. They just found it easier to start typing things in and all of a sudden, you know, Word started to take over from word perfect.

Hugh Williams: 32:15

So there's one one story for you. Another story is a really big misstep by word perfect that the word folks capitalized on. So if you sort of fast forward into the mid 1990s, word perfect was trying to launch a windows version. 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 WordPerfect was trying to get into that space, and so they were going to release this thing called WordPerfect 7 for Windows, and it was a disastrous release.

Hugh Williams: 32:44

So when they released it it was buggy and it crashed. But most interestingly, it did a terrible job of opening and displaying documents that were written with the previous version of WordPerfect, which was WordPerfect 6. So if you opened a WordPerfect 6 document it might crash the actual software or it just wouldn't look very good. The Word guys saw this and they said we're going to do a better job, and so the version of Microsoft Word that came out did a fabulous job of importing WordPerfect 6, and the WordPerfect 6 documents looked perfect and the users just flocked to Microsoft Word and that was kind of pretty much the end of WordPerfect. So again some really good product management and in this case some really deep, dark technical details, but a really good story of again getting the timing right and really delivering a feature that the customers cared about at a moment of weakness for your competitor.

Hannah Clayton-Langton: 33:35

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

Hugh Williams: 33:51

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

Hannah Clayton-Langton: 33:53

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

Hugh Williams: 33:58

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

Hannah Clayton-Langton: 34:19

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