Customers Are Not The Source Of Innovation | Marty Cagan | CEO Tales

Marty Cagan, Founder, Silicon Valley Product Group

Marty Cagan has worked with some of the biggest tech product companies in the world. He was involved in the early stages of Netscape and eBay, and has since formed SVPG, who work with tech product teams to help them make the most of their products. With SVPG, Marty has worked with teams at Google, Apple, Netflix, Airbnb, Disney, and Amazon – to name just a few household names.

In this talk, Marty hammers home the point that customers are not the source of innovation – it must come from inside your company. Prime and the iPhone would not exist if Amazon and Apple listened to their customers, he argues. Using examples from some of the biggest product companies in the world, Marty shows how using engineers in Product Discovery can lead to innovation in a way that a focus group never could.

 

Video, Slides, & Transcript Below

Video

 

Slides

 

Transcript

Marty Cagan: So, it’s a nice size group. Actually, we can do this, keep it informal and hopefully really interactive. We had talked before – you know product is a massive topic. There are so many different sorts of topics within the topic. And I kind of picked one that I am kind of interested in lately. I’m always sort of focusing in on different issues or problems I see. And so this is going to drill in on one. It will also let me talk about a few others but I’m going to save plenty of room afterwards for just open Q and A. Love the questions. Let me just ask though how many of you would call yourself either a product manager or a Product Owner? Okay, almost all of you. How many would call yourself a startup co-founder? Okay and how many would put yourself in the Design category interaction design, UX design? Okay, quite a bit and any engineers? Anybody else? Good good. All right well that’s my crowd for sure. I really basically just work with product teams which is product design engineering. And when they’re startups the product is usually a startup CEO or co-founder so that’s a group I like to talk with and spend my time with. So I don’t know how many of you know me but I have worked in this space for a very long time. It started 35 years ago actually as a developer for the first 10 years of my career at HP Labs actually.

Judy is in the audience. I don’t know how many of you know her but you should all know her. She should be a speaker for you. Judy and I go way back. You were at Microsoft early right after HP but I think we first met when I was at HP and you were too. HP Labs had a research lab here in Bristol. And so anyway Judy’s on the board of several companies you just finished up with the Guardian and it was really one of the people that have brought digital here in a serious way.

So, after about 10 years of engineering. I got very lucky – the internet started. I got a chance to work for Marc Andreessen. He was the co-founder of Netscape and Netscape was really the birth of the Internet a while ago now. But we just recently had the 20 year anniversary – it’s hard to believe. But the Internet changed everything really. It really did. But I was right at a great spot. I was the head of platform and tools. Marc Andreessen’s view was that the platform up until the internet was really Microsoft Windows, it was really the platform that everybody built on client-server. And then with the Internet that all changed. We had and we had to actually figure out what that really meant. We knew a change. We knew we were going from thousands of users of a big application to millions. And that was a huge change but we had to figure out how do people build the kinds of multimillion user applications which should run in the browser which should run on a device which should run in the server how many tiers all of these questions. And anyway we had all these different teams at Netscape and actually beyond as well in the sort of broader ecosystem like we’ve built things like SSL. We built javascript… Macromedia you remember them they built flash which was really an integral part of the early Internet. We sort of put these all together and I got to work with teams not just in Netscape but across the industry as some of my first trips to BT showing them how they could use the Internet. And of course many many startups Anyway after about six years we were acquired we actually lost the browser wars to Microsoft when we were acquired and then I ended up joining eBay because one of the developers in the developer program at Netscape was this amazing co-founder named Pierre Omidyar. And I just really liked this guy and he had already really got traction. You just had developers at eBay then. But I was brought on to build a product and design organizations there. And anyway it was great. And afterwards I just wanted to work with mostly startups – Silicon Valley Product Group is only four people – we just have all sort of been there done that for a while and we like working with companies and now the companies – you know early on it was Google and Amazon and Yahoo and a few years later Facebook and Twitter – now of course there are many many companies all over there they’re all over the world. There really isn’t much difference when I’m in London versus San Francisco anymore. There used to be a huge difference. Not anymore. I see very little. Some of the best teams in the world are in Shanghai or in Berlin or in London or in Sao Paulo. They’re just all over. So I want to be careful about that too because I’m gonna pick on…

So what I’ve learned is that I don’t see much difference anymore based on where I am in the world but I see a huge difference anywhere in the world including San Francisco between great teams and most teams. And this just drives me nuts. I continue to see it all over all go into a company. And even though even though you can often see a Google office through the window I was at the Guardian and now the Google office is literally through the window. But companies are often working 10 to 20 years behind the way good companies are working and so this really bothers me. And today I wanted to kind of pick on one of those topics. The real point I wanted to focus on here is that in many companies all over the world I find that the way they think of their engineers is the root of their lack of innovation. And so that’s what I wanted to focus on today. This is Bezos – for those that don’t know the CEO of Amazon. Amazon is probably the most consistently truly innovative company in the world at least in my opinion. There are some other great companies and some of great leaders but that that company is amazing. Every year he publishes a shareholder letter, he just published the one for this year. You should all read it. Last year’s one was epic and last year’s one had this line in it which I love this line. He always seems to repeat this refrain. Steve Jobs did too by the way. He would constantly in fact I remember him holding up his iPhone and saying look you can conduct 100 focus groups you will never get an iPhone. He was trying to say the same thing. And it’s true no customer asked for Prime. Did you see how many people are using prime. I mean it’s just amazing. Yeah. And the lifetime value of a Prime member versus non prime member it’s just – you can see where the money’s coming in. But this is really true that the customers are not the source of innovation. And yet I see so many companies that either they think it is or they the way they set up how they work is like it is. And it’s really not.

Now I want to be careful. This is not because customers are in a sense dumb or anything. It’s not like that. It’s that there’s two fundamental reasons. The first reason is that our customers don’t know what’s technically possible. This is really what’s different about tech products. If you were doing a new brand of toothpaste it probably doesn’t matter. You could probably do focus groups and decide like what flavor is going to be good or something. But for tech products it is not that way. It is all based on what’s just now possible and our customers can’t be expected to know that. And the second dynamic with tech products is that it’s really hard for our customers. I’ll go further it’s really hard for us as well to know what we want or what they want until after we show it to them. There’s this chicken and egg thing. In fact speaking of Apple of all the companies I’ve ever been in they use more prototypes than anyone I’ve ever seen. And it’s because they know this. They totally get this. They think they know what they want. They build a prototype and now they know all the reasons why that won’t work and then they iterate and they iterate. What Steve Jobs was great at was quickly zeroing in on why this prototype was bad. And his team will get back to work. But when eventually they came to him with a prototype that was good, it was a good chance they had a multibillion-dollar product coming.

All right. So this is sort of what’s underneath. Now what I wanted to talk about is the role of engineers. I’ve made this point in a lot of my writing and talks but this idea that if you’re just using your engineers to code you’re only getting about half their value. So many companies I meet, they just view their engineers as, they’re not necessarily literally in the basement. But they just as well could be. They are just… in fact, one of my favourite venture capitalist John Doerr likes to phrase it as we need teams of missionaries not teams of mercenaries. But that’s the way so many companies are treating their engineers – as mercenaries. They’re saying just shut up and build it and that’s the root of the issue. Now what I wanted to do was, first of all, I want to try to convince you that none of the great products out there were built that way. That’s the first thing I want to do. I don’t want you to take my word for it. I want you to see it and then I want to try to talk to you about what you need to do to get this kind of result out of your engineers. That’s really the heart of this. How do we do it?

So let’s first start I just have a set of examples I’d like to tell you about the back story on these. The advantage to knowing lots of teams you know a lot of back stories and the back stories are always fascinating but I will tell you they are consistently… You appreciate the role of the engineers. I mean Alexa is off to an amazing start. Most people would be thrilled but what they don’t know is that Alexa was not a grand strategy from Amazon at all. In fact it started it just a very humble beginnings with just a little Echo device. All they wanted was a voice-controlled speaker like a lot of people for a voice-controlled speaker. All they wanted and fine. But one of the developers on the team was sitting actually right near another team working on a smart version of the TV streaming device. And he just realized why can’t I just make a prototype that instead of just controlling the speaker controlled whatever I want to hook up to it. And he just hacked that together as a prototype and then showed it around and the team was like it was one of those defining moments for the team. They realized what he had come up with was way bigger than a voice-controlled speaker. In fact they realized what this really should be is the hub of your home. You may if you follow Alexa you now know down now that Amazon believes it also should be the hub of your work – your workplace. I mean they have huge ambitions for Alexa. It’s still just in the infant phase it’s just getting going. But no grand strategy no grand plan. Engineers playing creating a prototype realizing something is just now possible and solving a pretty great, I think a real need.

Another one. Most people will credit Apples and Googles and Amazons is like a great tech company but they don’t really think of older companies that way. Disney is kind of amazing. Disney is definitely an old company. They’ve been going Disney parks it’s been going more than 50 years. And I don’t know how many. I know there’s one outside of Paris or something but if you’ve ever been to a Disney park they are a special amusement park. They’re not a typical amusement park. But anyway and we could talk they have a whole division called the Imagineering division which is really where they do the discovery on their rides, their amusements. But separate from that , you need to understand and their business model. The parks are actually the core of their ecosystem. There’s toys there’s movies there’s games there’s all this whole thing but the park experience kind of gets kids hooked as kids. And it’s very powerful. And anyway the truth is they were a victim of their own success. About seven or eight years ago they started to see their numbers drop. Now the numbers were showing up pretty clearly in terms of how much money was being spent on a visit and how often people were coming back. It wasn’t really a big mystery as to why… it got too crowded. The parks were too crowded. People were waiting in line forever. It’s hot as hell in Florida where in the world is like this isn’t fun anymore and Disney was really becoming a lot less fun. And they knew that they certainly weren’t willing to give up on this. They did you know they could have raised prices more. But if you’ve seen the prices it’s already huge. Anyway they put a team together of some very impressive product design engineering. Put them together they said look it’s time we need to reinvent the experience and the charter was basically make it great again.

And not make the country great. I can never say that anymore. They had red hats. Don’t get me started. Anyway they wanted to make that experience like it was. And the team actually. I don’t want to oversimplify it, it was a major effort. They invested over a billion dollars into this by the way to really invest, they created a prototyping lab. So they’re not just prototyping your app on your phone which they did but they also prototyped lines, rides. It’s like when you wait in a line for a ride you see things they wanted it to be relevant to the kids age, gender, interest, what are your favorite characters. And so they simulated all this in a prototyping environment called the discovery lab and they were able to reinvent the experience they ended up creating something called a Magic Band. A simple RFID device that was actually mailed to you at home. You’d buy your tickets online you describe your family – mailed you the bands. If any of you have done it you’ve seen this but now when you go in there there’s no line there is no line you walk right through the turnstiles it recognizes your devices it welcomes you, when you want to have lunch, you want your kid to go buy some pizza, they don’t have to ever touch money at all goes through the device when they want to. They plan their rides in their day. It alerts them when to show up where and when they don’t. It’s just it got so much better and you know that’s if you go you should if you’re there you should check it out. But you can see how it’s the foundation for a whole future experiences as well it’s really a new platform for for entertainment. And yeah the customers again – customers couldn’t tell them I mean they customers could tell them why they didn’t like it so much anymore. They couldn’t tell them what to do. That’s up to Disney to go do.

Similarly Google Translate. This is like nobody talks about translate but it really is an amazing service. There is half a billion people that use google translate every month. You know if it wasn’t Google anybody else would consider that massive but. And you know Translate’s an interesting one. It has been there for over a decade now Translate’s been there and by the way to be honest the teams have been working hard on Google Translate for that entire period. But really up until last year most people would tell you Google Translate is kind of like… thankful it’s here. It’s better than nothing. But it’s not very good. It did save a lot of us that aren’t you know… I get an e-mail in Portuguese and I have no idea you know so I can go at least figure out what they’re saying what they’re asking so it’s better than nothing but not very good. And by the way there’s ways to quantify this to in language translation they have techniques to actually quantify how much better and after a decade of work it has gotten a little bit better but not enough for most us to perceive that difference. But last year they actually realized there was a new technology that could maybe help and they applied it here in Google Translate. I thought this was very interesting. They rebuilt the back end of Google Translate didn’t change a pixel of the user experience. You all know what it is it’s super simple you put whatever and there’s the Translate – you just pick your language. If it can’t detect it simple they didn’t change a pixel of that experience but they change the entire back end. And they wanted to see if people would notice. So I love this. And by the way they did in a big way. People were shocked. They were skeptical like how is this happening. There was a poet in Japan that actually was like this can’t be happening. He showed the original translations that he used to take months of work to get it to this stage. What’s going on? What they had done is applied machine learning technology to this problem. And they believe that if they really did a better job at this then the users would recognize it which they did and they made more progress literally quantitatively we could measure. But they made more progress in one year than the entire. I think it was 11 years beforehand. And that was purely by applying an enabling technology letting the engineers try out this new technology was one of the tests that Google did to help them decide that. I don’t know how many of you have heard this but for years they have made a big vocal statement about being a mobile-first company. They wanted to really tackle mobile which is not done. Of course there are still lots of work but recently they made a new announcement. Now they’re a machine learning first company. They are asking everyone of their product teams to go see if this technology can fundamentally improve how they do their jobs how they actually solve the problems they’re trying to solve. And this is just one of many examples. Actually there are some other great stuff that just rolled out actually on YouTube you might have noticed a few browser videos.

You know everybody knows the iPhone it’s 10 years old now. But what a lot of people don’t realize is the iPhone itself was three and a half year effort for the first iPhone 3 and a half years of work. And of course these are devices this is hard. But what’s amazing to me and we all really kind of know what Apple’s M.O. if you will it’s not really a secret but what is amazing to me is at the very time Apple was, I mean literally during the time Apple was discovering and the solution which was the first iPhone, the main competitors at the time – BlackBerry, Motorola, Nokia, Trio, those 4. They were the main competitors. And I actually know people at all four of those areas – literally these companies were conducting focus groups for their next device smartphones. If you remember well at the actual time the iPhone was being designed that the BlackBerry kind of was the leader and then the Trio was kind of like a super BlackBerry. If you remember the Trio did actually had a keyboard like a Blackberry but unlike a BlackBerry the trio actually had a touchscreen. And people don’t remember that. But it did. It was a crappy touchscreen. It was really bad you could barely dial a phone number but it had a touchscreen. Literally at these focus groups the main piece of feedback they got from people was “Well this touchscreen sucks”. Lose the touchscreen. That was the main feedback consistently those other companies got. And of course Apple knows enough not to even ask. So you don’t they don’t ask their customers do you like to touch them. No, they know that you know touchscreen. Yeah the palm Trio was terrible but you know what the technology wasn’t right didn’t it wasn’t ready. But now we think we can. And in fact not only did they know the customers not know what could be done with the touchscreen technology, but in truth, I think most of those competitors didn’t realize it either. Anyway that’s the story. It’s the engineers in applying technology that is just now possible to solve real customer needs. That’s where these come from.

I wanted to share one other example that wasn’t a big everybody knows consumer device because they don’t want you to think you have to be an Apple or a Google or an Amazon to do something like this. This company is called Workiva and I be surprised if anybody here had heard of them but they are one of the fastest growing companies in the U.S.. They went public after just a few years. They grew from nothing to something like 85 percent of the Fortune 1000 running their products and just completely disrupted their space. You wouldn’t have heard of them because they basically provide the automated software that helps finance accounting people handle all the reporting that they do every quarter and every year is when you’re a public company – it’s incredibly boring detail financial reporting and accounting. However these people the cofounders had actually done a company before that in engineering automation space and they had a friend actually whose company was going public. And the friend was showing them all the unbelievably tedious months and months of work that had to be done to prepare to go public. And they were looking at this saying this is just crazy. And the poor people because they would you know they were talking to these finance and accounting people they often weren’t getting home to their kids. I mean during the period of month end, quarter end, year end – many of you have heard this from the accounting people in your own companies – it’s just a thankless brutal job. And they realized this is crazy – we can totally reinvent this space, the software that’s there today is terrible which it was. And they just completely went in a bunch of six engineers got together. Now they really sat down and learned what they needed to learn from the accounting people. But they committed themselves to really making their lives better. They made some very early bets on cloud technology and rich experience technology and they rode. One of the things I love about this company is all over the walls are genuine letters from their customers telling them how genuinely grateful they are that they can see their kids at the end of the month and not just you know… So anyway you can absolutely do that. And this is how the great companies work. I’m happy to see there’s a little trend going on now we’re in enterprise software. It’s called consumerization of the enterprise. It’s applying consumer caliber products to enterprise. To me that’s long overdue. Because many of us that work we have great software at home and terrible software to use at work. That’s crazy. All right.

So I could honestly keep going. I know so many of the back stories of great technology in my book actually I wrote a bunch more. There are some great stories of great initial products. The original Netflix the original Google AdWords lots of them, but you’ll see that theme. It’s about unleashing the power of the technology and combining that with a real customer need.

If you believe or agree that you really need to get engineers to participate in not just building your products but also inventing your products then I wanted to talk about how we make that happen because it won’t happen on its own. It won’t happen on its own. And especially won’t happen if you treat them the old way where you or your CEO creates roadmaps and throws them over a wall to a bunch engineers and say build these features.

So there is this notion of table stakes. I only put this in here because I continue to meet companies that think they can actually be a true tech company yet outsource their engineers to India or something. So I don’t want to embarrass anybody here but if any of you are in that boat where you feel you literally don’t have engineers with you… To be clear I don’t care if you’re in India and you have engineers in India. But if you are here in London and all your engineers are contractors from Infosys or something in India or China you’ve got almost no chance, to be honest with you. First of all, you’re going to spend, waste way too much money and you probably are doing this because you think you’re going to save money which is a big myth in this. You’re not going to save money you’re going to waste money going to take a much bigger team it’s going to go way slower and you’re going to get no innovation. So table stakes is that you have a team. So if you’re located in Manchester you’ve got a team in Manchester with you. In fact, if you’re a product manager and you don’t have at least two engineers to work with on an ongoing basis, you’re not a product manager you’re someone else with some other job. So because we’re there to actually create products and the engineers will help us create those products so table stakes that you have a team of engineers.

We want to hire engineers that are passionate about our vision. That’s why the product vision is so important. This talk isn’t about product vision but I will just point out that that is our number one recruitment tool is the vision. That’s what good engineers that’s what good designers that’s with good product managers they want to join to work on a great vision. If you wonder why does Tesla share their vision with the world. The 10-year vision they just shared the second 10-year vision. This is their best recruiting tool so they don’t care if the world knows vision. Now the details of how we solve that – that’s the hard stuff and that’s not the stuff you’ll find on a Web site. But the vision is powerful. And anyway we want a team of engineers that are passionate about the vision that’s table stakes so without that you’re really not a contender. You just don’t have a chance. Any company that I work with, if they don’t have that I’m like call me when you actually hired a team because you’ve got nothing to do right now. All right.

So assuming you have that there are a set of things that I want to encourage. The first one is you have to provide your engineers with the full business context. Everything – they need the information. And to be clear really everything I’m going to say applies to the designers on the team too it’s just that the designers more often get access to this product than the engineers often do. But that engineers need to know they need to know the KPIs, they need to know the metrics that matter, they need to know the customer pain, they need to know the sales limitations, they need to know contractual obligations, they need this stuff. It’s amazing because a lot of product people think it’s their job. A lot of CEOs think they need to shield or shelter the engineers from this information. But I tell them this is the worst thing you can do. These are the people that are going to actually save you. So don’t shelter it. They can handle it. This is actually very motivating to good engineers. They’re very motivated by problems to solve hard problems to solve. And that’s what this is. So all the context. Now some of the context is pretty obvious. We talk about requirements. There are some things that are pretty obvious things like how performance constraints are scalability estimates but most things are not as obvious. I was just talking to somebody yesterday who is doing another one of those bike sharing systems. You’ve seen them all over the place. In fact in San Francisco it’s become such a problem because of course the cool thing is bikes you don’t need to park them anymore. They have GPS, isn’t that nice. Problem is people leave them anywhere and they do. So now they’re littering all over the place and people are complaining and they’re being impounded and it’s like you know what – product has to worry about this. We have to worry about compliance, about laws, about privacy. We’re right in the middle of a major privacy shift right now. Product has to worry about privacy constraints and policies. And we have to worry about legal issues, we have to worry about go to market limitations, our sales force, our marketing channel. Product Managers have all of these dimensions of the business they need to know so they can share these issues with the team. I’ll get more into that point in a bit. But the critical thing here is you have to share this context with your team. Now the truth is not all your engineers are going to care about all of it that’s fine but they need they need to know it. They need access to it at the very least from you.

Second, this is kind of amazing. I don’t really there’s a psychological thing that happens but I just call it magic actually but magic happens when the engineers see the actual users and customers face to face. It’s just you know it’s not the same over a video link. It’s not the same in a usability lab with a two-way glass stuff. It’s none of that is the same. They need to see it right there. Visceral that interaction. And even when by the way it gets really ugly, and a lot of times it does get ugly because the customer is mad. They might be mad at your product they might be mad at whatever they’re using. Maybe a competitors product but they’re not happy. Those are the really good ones to have engineers at because they will get very motivated. And so all and they’ve got a lot of people don’t want to include engineers of course. The most common argument is how can we take them away for an hour from their coding. Right. That’s crazy. We’re not trying to take all six of our engineers to all of our sessions but we want to take at least one to every session and again not all six are going to be crazy about doing this. They don’t need to be. But it’s normal for two or three of them to be very interested in doing this and so will rotate among them. And if you don’t have at least one engineer on your team that is into this you need a more senior serious engineer on the team.

Third, this whole topic of requirements could be a whole other you know hour, requirements are not talked about like they used to be talked about. The truth is most requirements are not really requirements. There is somebody thinks something is a requirement somebody in marketing says we must do this and of course they’re not just making this up it’s just they think we have to do this. We in product have to go figure out what is the real underlying constraint maybe what’s going on as they think we have to have this form because these other sites have it. But what’s really going on is if the users under 13 years old we are not allowed to ask certain things and there’s an underlying constraint we need to figure out because every time we get to those underlying constraints we give the engineers many more degrees of freedom to solve the problem. Done more you can. Well the less you can give them in terms of requirements the better mostly we try to focus on problems to solve. If you’ve heard of jobs to be done, it’s the same idea.

In general for every product team there’s two things we do. The term I use for it is discovery and delivery. Discovery is when we figure out what to build, like you might have heard of build the right product. That’s discovery. Figure out the solution. And really there’s four things we care about. The customer will buy it or would choose to use it. That’s value. The customer can figure out how to use it. That’s usability. We can actually build it. That’s feasibility and it’s viable for our business viability. This means it works for the legal constraints, it works within the financial constraints, we can afford, it works within the go to market constraints. So we’re looking for solutions that do those four things. That’s what discovery is. Lean Startup techniques. You mentioned Eric Ries was here the lean startup is a subset of discovery techniques. There are some great techniques in there. There are many different techniques that contribute to discovery. And we use them all. We have qualitative techniques, quantitative techniques. There’s always one technique. I mean there’s a book out on jobs to be done right now. So a lot of people are talking and it’s actually an old technique. It’s a good technique. It’s like. But if that’s all you’re using you’re in big trouble. Just like design thinking – design sprints great technique. One of my favorites but it’s not good for most work. But it’s great for other work. So you should all be skilled they’re also called discovery sprints. You should be skilled in that technique but it’s just one technique and you don’t even use it all that much. It’s more like we’ll do one discovery Sprint or design Sprint per quarter on average like that. So with any of these techniques you have to be careful – there is no silver bullet in product. We have many techniques and your job is to choose the right one for the job. Now the other side other work is delivery work which is to actually get this we figured out a product that hopefully we think we have evidence will sell and will work. Now we have to get it to market that’s delivery. Most companies are much better at delivery than they are at Discovery. Agile is all about delivery. If you have an agile coach they’re all about delivery. In fact most of the teams at least that I work with are doing continuous delivery. They’re quite good at this but discovery is the other half of the problem. I always frame it as discovery and delivery. The oldest way I’ve seen it framed was “Build the right product, build the product right”. But early Google and still in many parts of Google they phrase it as “Fake it before you make it” – fake it is discovery, make it as delivery. Facebook “Move fast (discovery) don’t break things (delivery). One of my favorites. Airbnb I haven’t mentioned them. They’re a great product team. They refer to it as “Build things that don’t scale (that’s discovery), and then build things that do scale (delivery)”. I like that framing because it really makes people understand that this is not… In fact there’s a backlash going on right now against Lean Startup. And it’s really bothers me because the Lean Startup techniques are great when used appropriately. The problem is most people don’t use them appropriately. I can’t tell you how many teams I meet that take four months to build an MVP. If you’re taking four months to build an MVP you are missing the whole point of this. That is what we call product as prototype. And just to level set you (I mean probably not fair to throw this at you just a side comment but) in discovery a competent team product team in discovery is testing on the order of 15 to 30 iterations per week. OK 15 to 30 per week not one per four months. OK. So what’s really going on when you have one for four months is you are using your engineers to do discovery which is a really expensive and slow and I would argue irresponsible way of working. So that’s a big topic. But that is the book that I guess you all get a copy of is 400 pages of it mostly talks about how to do that how to do 15 to 30 iterations per week in discovery. And by the way really good teams can do a lot more than that. It’s not hard to do that a lot of prototyping a lot of qualitative techniques not just quantitative but yeah that’s how we get good stuff done fast – try out lots of approaches.

So anyway discovery is the product manager, the designer, and the engineers. Now here’s the thing. Discovery is full time really for the product manager and designer. But all we need is about half an hour a day from your engineers now. And that’s of course because most of the day for engineers is doing delivery that’s their primary job is to build scalable fault-tolerant reliable software. And so that’s what they spend most of their day doing. But a little bit of time every day to go into figuring out what to build is easily the best investment you can make by the way. Most engineers already have been complaining that they are not included in this in fact I know I have heard countless times engineers complain to me if I had just been consulted for even five minutes we could have saved months of grief and course they didn’t. And I just want to make this real for you. If the first time you’re showing your engineers what you need them to build is at Sprint planning, you have screwed up on this. Sprint planning is way too late. That’s an example of the problem, not what I’m talking about. OK. So they need a little time thinking about it, making it better, assessing it.

The other thing here is that we want to make sure that we measure teams based on the business results. And of course the challenge is that most of you probably are given roadmaps from your executives or even from yourself and roadmaps are typically just lists of features and projects and that’s output. All I can tell you is that most of those things no matter how smart you are, you’re going to regret doing because they won’t actually work. The most common reason is that we’re excited but our customers are not. So they don’t actually use it or they don’t want to buy it or they try to use it and they can’t figure out how to use it and then they bail on it for whatever reason you’ll regret it. And so the question is you know that’s all waste. And we want to avoid that. So we want to get some evidence that it’s going to work before that. And so what we’re really measured on if we’re a good team is not on whether or not we ship these 25 features this month but whether or not we actually move the numbers we’re trying to move like retention rate or like lifetime value of a customer or engagement or whatever it is that we’re asked to focus on. That’s how we measure success and not… the whole OKR system if you’ve heard of that, that’s where it came from was to get to team stop worrying about roadmaps start worrying about business results.

And the last item here is really true. A lot of teams, a lot of engineers complained to me about their product managers. So many of them. That is the single biggest complaint I get. I mean many of you may have moved into product from engineering because you were frustrated with the product. I mean not that a really common motivation for moving in the product but it is. And this has been another hot button of mine lately. I have a theory about why so many teams feel like they have such… incompetent is a rough word but not capable Product Manager. And my theory is because most product managers I meet, the only training they’ve actually had is a certified scrum product owner class C SBO. And just to be clear you should have that certification, it’s super easy to get. But that’s like maybe 10 percent of the job of a product manager. That’s the administrative role and you know if your team is using Scrum or Kanban, there’s the administrative role that the product manager plays. That’s called the Product Owner responsibilities. But if that’s what you’re doing you’re an expensive backlog administrator. That is such a problem in our industry. I try to tell people you know that’s a small percentage of the job. I started actually going out on a limb because you really try to get people to understand just how big a difference this is the product owner responsibilities versus the overall product manager job. And I started advocating the point about a good product manager is truly the CEO of the product. This has been controversial for a long time and I went back and forth on it in truth. Of course it’s controversial because the product manager is not the boss of anybody. We need to be clear on that. They’re not the boss of anybody and when they start acting like the boss of the team then a lot of things go wrong. So it is not meant to imply that although in a startup where the CEO is the product manager then they are the boss of everybody. But that is the startup. But that doesn’t at a certain point you know that doesn’t scale. But they are like the CEO because a competent product manager has to understand all these elements of the business. They understand how the product is marketed, how it’s sold, how the onboarding process goes, how we pay for it the financials, how much it cost for us to run this product and serve it, how much it cost us to acquire users, how much value we get out of those customers, they understand the legal issues the compliance issues they understand GDPR stuff that if that’s going to impact this, they understand contracts with partners and literally what they’re on the hook for that. The only other role I know of in a company that’s like that is the CEO. Really that’s it. And so in a very real and meaningful sense the product manager needs to be the CEO of that product just not in the boss sense, they’re not an authoritarian role it’s a knowledge role and they’re bringing all these things to the team and helping them make a call. So that’s what I mean by a competent product manager. It takes some real work. I mean product manager is super hard job. I think it’s the hardest job on a team. So no I don’t apologize for that is a very hard job. I have this another pet peeve of mine as many of you have seen not associate product manager title and I’m not referring to like Google has an APM program which is an apprentice product manager. That’s awesome. But this notion of an associate product manager if it was up to me that would be gone. We wouldn’t have that notion because no team wants an associate product manager. They want a product manager somebody who knows this stuff not somebody that knows 10 percent of it. And so to me the table stakes for a product manager are pretty significant. It’s a lot of work but that’s key. And every great team I know the engineers have contributed in a big way. But they all have a strong product manager and most of them once they’ve tasted, had a chance to work with a great product manager they insist on having somebody like that going forward because they know now what they’re missing. Yeah.

Audience Member: I have a question, Marty, if I may. In your wonderful book, you feature 6 Product Managers from Adobe, Apple, Microsoft, and other companies. And the remarkable thing about all six of them is that they are women. And in a world where women aren’t very well represented, I think it’s amazing that your 6 exemplars are all women. Do you want to say anything about that?

Marty Cagan: I have lots of funny stories. I gave a talk actually in London at Mind The Product – I prepared this for that talk and I ended up including it in the book. There’s an article if you want called “Behind every great product”. And I knew what I wanted to write about. I wanted to write about great product managers but I actually and I and I know that’s my advantage, I know so many of them. I put a list together of great product managers but then I also wanted to pick stories because I wanted to tell the back story so I wanted them to be iconic products. I know a lot of great product managers of that were just not fortunate enough to work on an iconic product. And I couldn’t help but notice that even though women are not even close to 50 percent of tech product managers that they were more than 50 percent of my list. And I realize that I also wanted to highlight that I did end up. I got asked that so much… I did write up my theories about why. I didn’t put this in the book, but if you’re interested there is an article you can google titled “Why Women make the best product managers”. And I do believe there are real reasons why. It’s kind of complicated – I don’t want to not do it justice. But if you’re interested in why I’d encourage you to read that article that’s just my theories from a male perspective obviously about why women seem to be disproportionately strong in this. And I’ve got many more example you know a lot of them. I introduce a lot of great product people with Julie, I want them to know her. And so yeah there’s a lot. It’s a great career for women and by the way it is the proving ground for startup CEOs. It’s you know so it’s a great path to getting a lot more women leaders which I’d love to see for the same reasons I wrote why women make the best product.

OK good. Well just about questions anyway. There is the book and there is my e-mail. You know I touched on a bunch of topics and there sort of rambled a bit but are there any questions that anybody wanted to ask about?

Mark Littlewood: I want to say firstly thank you very much, Marty.