“With today’s methods, we can build the wrong product faster than ever.” Steve Johnson | Product Management

Join us for Steve Johnson’s Product Management Surgery – April 14th 2016

Steve Johnson was once described by my most cynical (and perhaps consequently most competent) product manager friend as the only product management guru worth listening to. He shares a wealth of experience, in this talk where he questions the notion that Lean Methods work, not least because most people haven’t read the book…

Join Steve online – bring your gnarliest product management problems for a one hour, AMA Product Management Surgery, 14th April, 17:00 BST, 12:00 EST.

You can also view his Business of Software Conference USA talk, with transcript and notes below.

Define, Design, Deliver, Refine.

Join the Product Management AMA with Steve - 14th April, 1700 BST, 1200 EST

Transcript, Slides, Hangout, Notes and Video of Steve Johnson’s talk, ‘Have we Leaned too Far?’ 

http://businessofsoftware.wistia.com/medias/9qqswjx7fe?embedType=async&videoFoam=true&videoWidth=800

Recording of post event Hangout and Notes: Five Lessons From Steve Johnson Hangout (Link)

Steve Johnson Transcript

Well, hello all. Friday is pizza night at my house. I was actually at a conference recently filled with marketing people and I was starting to tell this story. And I said it was actually pizza and Star Trek night. And, I tried to explain further that its pizza and Star Trek TNG night… Nobody got it. [Laughter] Okay. Next Generation. Anyway.

My wife makes pizza from scratch. Every Friday night, we make pizza and we watch Star Trek TNG. And last year, a couple of years ago, we refinished our kitchen. As the designer came in and started working with our kitchen, talking about the challenges we had using the kitchen, I pointed out that we use this Kitchen Aid mixer all the time. He said you know what? They make a shelf specifically for Kitchen Aid’s. And we’re like cool. Totally? Wow. So, he designed the cabinets and he put them all in. He put in the Kitchen Aid shelf and he said you’ve got to come watch this. It’s a demo, right? It takes this shelf and he pulls it out. It’s so cool. It locks at counter height. So, you put the Kitchen Aid on the shelf, you pull out the shelf and it locks at counter height. Sweet. We’re like this is cool. He says you try it and I say okay; I’ll try it.

You pull it out, lock it in place and it’s really cool. Then, he’s like, Susan, you try it as well. So, she pulls it out, locks it in place and looks at it a second and says where’s the power? And I went oh! Good one. I realized I’m hoping now that I have an Agile developer. [Laughter]

Now the old school would have been you didn’t ask for power; screw you. The new rule is hey, you know what? We couldn’t anticipate all of our requirements months in advance. As we realize these requirements, we need to adjust accordingly. And he said hallelujah, the electrician’s coming on Friday, so I’ll have him put in power now that we better understand our requirements. The thing is this guy had never done a Kitchen Aid shelf before; he saw it in a magazine. I had never done one before; my wife had never done one before. And guess what? Your developers are doing things they’ve never done before.

Tom Kelly was the lead engineer on the Lunar Lander back in the Apollo program and he said of course we were over budget. Budgets and schedules are based on similar work. Some of the work that we do is completely dissimilar; we’ve never done anything like this before. Yet the whole company is like can you show me a Gantt chart? What day of the minute? What day and minute is this thing going to be available? And we’ll talk about that a little bit more.

A lot of the companies that I work with are adopting or adapting or trying to adapt The Lean Startup method in big companies – which is brilliant. Yet what I found, maybe you’ve had this experience as well, most of us only read the first third of a business book. [Laughter]

So they got MVP; they got Pivot and they’re like I’m there. Okay, Lean it is. And with today’s method, golly, we can build the wrong product faster than ever. And, as you’ve already seen this week, this is what happens. Right? This feels like every enterprise product I’ve ever encountered.

I actually just started using a SaaS product a while back.

One of the customers, one of my customers, said now you have the opportunity to file your statements of work and your MSAs through our system. And it costs us nothing for you to use our system, that system, but it costs you ten percent of your revenues. No, sorry, two percent of your revenues. I’m like wow this is a great sale cycle for somebody, right? The SaaS vendor said to my customer it won’t cost you a cent. My customer said I’m on board and hey Steve, you have to pay for this service. And I’m like well I really do want the money, so okay. But it was clearly created by people who had never actually used it. It’s like sixteen screens to get to upload a pdf. It’s like… you’ve seen Facebook now, right? You’ve seen Yo, right? But anyway, I think a lot of products feel this way because you don’t have a way of prioritizing. You don’t have a way of saying what’s in and what’s out. Everything sounds like a good idea. And so somebody says hey I talked to a guy which to a sales person is a statistically relevant market research product, right? [Laughter]

You know… I talked to a guy. So, sure enough, we had a bley. You know I talked to a guy. The marketing VP goes to the conference across the hall here and comes back and says whoa have you heard of the cloud? It’s apparently a big thing; we out to get us a cloud. And boom, another feature on the thing. And before you know it, you’ve got all this stuff. And what’s really funny about this particular knife is it is intentionally a gag. So for their one-hundredth anniversary they decided as a promotional tchotchke to put every single blade they’d ever made on a knife. And the thing came out and I’m like, I totally have to buy one of these. Turns out, it’s very expensive. So, I had a hard time getting it through procurement in my home. [Laughter] And then I thought, but – and I won’t be able to travel with it. So I would end up with a picture of the knife I bought. Well, I’ve got the picture, so why bother? Well, of course, the other funny thing is you couldn’t actually use it as a weapon. I mean – not a knife. You could use it as a brick. But anyway, I find it terribly amusing and a really good illumination of how a lot of software feels to other people.

A couple of years ago, four years ago, here at this conference, Eric Reis said “The biggest waste of all product development is building something that absolutely no one wants.” And this is why I think we may have leaned too far. I think we may have embraced a lot of the principles of agile or the principles of Lean Start-up a little too far because it seems to me we’ve all been talking about well – the conversations I find myself in – start with product. It’s – let’s build a product and then wander the county looking for people dumb enough to buy it. And it feels like there is something backwards there. So I was going through our basement and I found my daughter’s stuff. She moved out a while back and we’re delighted. [Laughter]

But she uses our house as her storage unit. And I found this thing and first of all – I was really struck by it. Do you remember these at all? I mean, this is a CD wallet and it has all of her favourite CDs in it. And it caused—I paused a little bit at some of the choices. She’s got some Billy Holliday; which, you know, you’ve got to kind of respect that. I mean, well done. She’s got some Benny Goodman. She’s got some Matchbox 20; I can kind of get there. What bothers me is not only is there one, but she owns a soundtrack from Scream 3. Very twisted. But I was looking at this thing and I was remembering the days when I travelled with a CD wallet. If you think about it yourself, back in those days, if you can remember – you go to the airport, you’re on a long flight, you know, you’re going cross country and you have to commit yourself to a cd. You’ve got your little Discman and you’ve got your headphones ready, but now you’re getting ready to get on the airplane and once you got the airplane, of course, you cannot move your arms. So, you commit. So, you’re like, hmm: what do I want to listen to for three hours? Is it the Beatles White album? Do I go with Dark Side of the Moon? You know, what do I choose? That happened to a lot of us and my real point is innovation begins with this kind of observation. Isn’t this where the iPod came from? So many people I know are like… wow Steve Jobs was one with Gaia and this idea came fully formed from his head, but no. We all had this problem and they solved it completely, not just a little bit of it, but the whole thing. We’ll talk about that some more too.

The other thing I hear a lot of is you’ve got to listen to your customers. I completely disagree.

You have to observe them. Customers — the things customers say tend to be too finite to respond to.

We — for example do you remember Netbooks? Everybody was like – Apple has got to come out with a Netbook. There is – people are screaming for netbooks. No. Netbooks suck. They always sucked. They were just bad choices. And if – and Apple came out and said you know what? We think a Netbook is a bad idea. And surely everybody went oh no! Netbooks is a go, yeah. Anybody still got a netbook?

Apple comes out with an iPad and suddenly an entire category of product disappears because the other vendors were listening to what people were saying: what I really want is a small windows computer that doesn’t work well. Or, maybe they were saying was: I want to get a computer for my dad, but he’s cheap. Can we get a three-hundred and fifty dollar computer that won’t work? And then I can spend the weekend helping him. [Laughter]

Observation is the key. Here’s another one. Back in the day, X-ray machines consumed film. X-ray film. Just like today’s laser printers, the vendors made their money on the film. My wife and I bought a laser printer, a colour laser printer, recently and I tend to be prepared; after all, it’s a whole mile to Staples. I need to go ahead and make sure I’ve got some in inventory rather than go over to Staples, but anyway. So, we bought the printer and the next time we were in the area we went to Staples and we bought—we thought—well, you know we’d better just get another set of toner. So the printer was $350 and the toner was $400. [Laughter]

Brilliant. Anyway. That’s how—the same thing is how x-ray machines used to work. And so we’d have these x-ray machines and the hospitals—I mean the vendors—made all their money on the sales of the film and suddenly film sales started plummeting. A product manager—well done—a product manager went to the customers and said what’s going on? How are you using our product? Why are you not—in effect, why are you not buying our film? Turns out, a film manufacturer had found a real problem in the x-ray machine situation. And what was happening was—they produced the film, the doctor would get the x-ray, hold it up and—okay! Here’s your heart! [Laughter]

And people were like dude that took you way too long. [Laughter] And the manufacturer started losing consumable sales to the firm that watermarked the film “this side up”. Suddenly, the doctors were like boom, look, there’s a watermark—boom. I’m in place. Here’s your heart, here’s your lungs, here’s whatever that thing is, right? [Laughter] But you’re—it’s disturbing when you hear your doctor say things like oops or what is that, right? [Laughter] And so, in this particular case the product manager asked some questions, but I suspect he also observed it. Why do you prefer this film over that? They probably wouldn’t say I look stupid in front of my colleagues and patients because it takes me a while to orient, but as soon as you saw the film you could probably go, big duh, good answer. Well done.

So we’re in complete agreement. We come up with a set of priorities and everyone on the team thinks we’re in synch because they’re all purple, right? But we… really struggle… to align. Usually because we’re talking about what the customer said or the salesperson said or what the executive said instead of focusing on what have we observed.

So we’ve talked a lot this week about ideas. And ideas are wonderful, wonderful things and frankly there’s more ideas than any of us can implement. What we need is a way to turn ideas into businesses. How do we take our idea and do something with it, so that we end up producing excellent results? And it seems to me that what happens in that little cloud is a mystery to everyone in your company. And the part that I find appalling, in the large companies I work in, is the number of people who think what happens in that cloud is factory work.

I find it galling the number of times I hear people say you know what—let’s outsource—we’re a software company—let’s outsource our core competence to another company. I don’t consider development factory work. Do you? Frankly, I consider sales factory work. It should be. But what happens in that cloud is a miracle. Something that never before existed has come to exist. And what I’ve seen in my career has been kind of funny—fascinating—as we move through that cloud there’s a lot of confusion that happens.

Once upon a time, we had an idea—we built a thing—we started shipping it and the VP of something said wait—that’s not what I thought we were getting. So somebody says you know I just read a book. We ought to have a business requirements document. Good idea. So the next time through we said okay—this time, we got this idea, we’re going to write it down as a business requirements document and then we’re going to ship. So we do that the second time through and the second time through the VP of marketing says hang on. I see that it’s there, but it’s not what I was expecting. And somebody goes, oh, you know, good call. I just read a book and what we totally need is a marketing requirements document, right? So everybody thinks that’s a great idea, so the next–so we go through this thing again—and this time we’re going to write a BRD—a business requirements document—and a MRD—a marketing requirements document—and that will solve all our problems. And we start shipping and somebody else is unhappy. So the VP of support says I see that it’s working but it’s not working the way I expected it to work. And somebody says you know I just read a book. We need a feature specification document. [Laughter] So this time through we have our BRD, we’ve got our MRD, we’ve got our FSD and suddenly we’re spending more time writing documents about code than we are writing code. Does anybody remember those days? And let’s hope that’s in the past for most of us, right?

Instead of building documents about documents about documents, the Agile community has correctly said let’s have some conversations instead of documents.

Let’s have more discussions, right? And let’s embrace, one of the other ideas from the Lean Startup, let’s embrace the Minimum Viable Product. My friend Saed Khan writes it this way: Minimum Viable Product is a set of product functionality that is best described as—it’s the least we could do.

Like this. Last year, in the heat of the Virginia summer our air conditioner died. The guy came out and talked to us about something called R22 and how we needed to have R24-or three-or nine. You know, whatever it was, and he said good news–it comes with a smart thermostat. So, he puts this thing in and—wait—let me put it this way. If you’ve ever seen these before, they’re always accompanied by a sign that says don’t ever touch this or a two or three page instructional manual. And I found it, actually, pretty straight forward. All you do is press the schedule button, then those changes—and you press sixteen or seventeen other buttons, right? It’s very straight forward, right? That sentiment was not common in my house. So the following year for Father’s Day—Father’s Day—I got this as my gift. Anybody have a Nest? Sweet. You totally need one; and in my house actually, it turns out, we need two. We have two zones. I don’t know why, but the good news is—that means I can have my temperature where I am and she can have her temperature where she is, but the way this thing works is really amazing. That is—if you are cold—turn the entire thing to the right. Anybody confused yet? [Laughter] If you are warm—turn the entire thing to the left. That’s it. It suggests that maybe we don’t know what exact temperature we want it to be at various times throughout the day. Instead it says if you’re cold, turn it. If you’re hot, turn it—and, after a while it goes, you’re pretty consistent. Seems like you get kind of warm around four o’clock and crank it up. Steve: And I—I don’t know if this is everybody—I do seem to know a good number of people, I’m not saying anybody in my house necessarily, but there a good number of people I know who do not understand analogue. They seem to think of digital. So my son, when he is warm, sets it—sets the old one to fifty. [Laughter] And then my wife gets cold and she sets it to ninety. I’m like—dude, pick a temperature—right? But, with a Nest they just go—turn, turn, turn. It works out.

But that’s not all they did and I think, back to this example, they said boom! Here’s a thermostat. Nest said we’re going to build a lovely thermostat and surround it with services. So this is one of the few things I’ve taken a picture of when I unboxed something because it was so cool. It was kind of like getting an iPhone. Wait—iPhone, thermostat—it doesn’t quite feel like the same thing, but anyway. It came with—the thermostat, of course—it came with instructions that were in colour. The first, I love this, the first instruction was take a picture of the wiring you’re getting ready to dissemble in case you screw it up. Amazing and sure enough I did. I mean it was like—wait, where was that yellow wire again? Not plugged into the y thing, you know? Whatever.

I was also kind of amused that they’re suggesting I might not have a screwdriver. [Laughter] So, screwdriver in there. Interesting; I think if you’re doing this kind of install, you probably already have a screwdriver. But they also—if you say, gosh, I’m not really a handy kind of guy—you know? I just don’t bend the rod, in the toilet, to make it stop leaking; I actually call Mr. Plumber to come out. You don’t want to do this install, I guess, but it took me about ten minutes. I’m not great—you know, super handy—but I’m a little handy. But the thing is—I love the most—about this product—is it came with a bezel, a plastic piece, exactly this size—so I didn’t have to paint a wall. Nice. They really understood the entire user experience and just to make sure I love it every single month they send me an email reminding me how much power I’m not using. You used less power this month than last month—well done—and I’m like—yeah. [Laughter] Look at me, I kind of love the earth, you know?

So, we’ve got this idea, and we want it to be successful, and we have to go through this middle thing of breaking it all down into the parts. Maybe into breaking it down into the jobs to be done, as we heard about the other day, maybe into themes or goals or epics—as you’ve maybe heard before. It’s breaking the big idea down into the parts that starts getting to be the really exciting and frustrating work. But it can be simplified I think—and this is the takeaway for this week is to take all of the stuff that we’ve been talking about and take some action on it. It says we’ve got this idea. Let’s first define where we are and where we’re trying to go; then break it down into how we’re going to design, what we’re going to deliver and how we’re going to refine it over time.

Before we build a product—you heard someone yesterday talking about target markets—the most common target… the most common market segmentation I see is: we’re going after customers.

Sometimes they segment into male and female customers or large companies and small companies. Let’s define not only what market we’re in, but what business we’re going to serve before we get into designing our product. And yet so much of what I’ve been hearing about over the last many years that I’ve been doing this is an obsession around the product. The product is great, don’t get me wrong, but we’ve have to look beyond the product to the rest of it. What business are we in? What market are we going to serve? Not only what product are we going to build, but how are we going to promote it in a meaningful way? How are we going to sell it? How are we going to support it? And how has selling changed in the last five years? Pretty substantially.

For those of you in a marketing role, we are now providing much more sales enablement than we were before because our customers don’t want to hear—our customers don’t want to hear generic information from our sales people. They already have that, right? The difference between a sales person and your customer is the customer has actually read the stuff on your website. [Laughter] So how are we going to promote it? How are we going to sell it? How are we going to support it?

Impressive, listening—a moment ago to—it’s pretty wonderful when you’ve got people scattered around all the time zones; you can support people all the time. And, as somebody said the other day, what a great experience it is when somebody calls in for support. Marketing is spending millions of dollars trying to get people to contact us while service seems to be, or support seems to be saying, could you stop talking to us please? We want to get you off the phone as quickly as possible. There’s something disconnected here.

Finally, on the refine phase, let’s revisit the business goals and the market goals as part of our retrospective. I work with teams of product managers and development teams and hallelujah that we’re finally doing retrospectives. I love that phrase too. It used to be we called it a post-mortem—which, of course, meant someone died. But, in the retrospectives I’ve been involved in we only look at the process. How could we Scrum better? What did we do right? What do we do wrong? What could we do better in the process? I suggest we want to suggest we want to extend that that view to looking at did we achieve our business goals and what are we going to do about it? Did we achieve our market goals and what’re we going to do about it? And perhaps we say, you know what, we’re starting to be able to segment our customers based on the good and bad. Here’s one. Does anybody have a bad customer? In fact, I’m tempted to throw out a couple of names because I think we share the same bad customer in many cases. Bad customers don’t seem so obvious at the time, but after a while you start realizing, you know, they’re being very demanding or they’re being very self-centred. Customers who say, you know, I don’t really care about the rest of your customers—I want what I want are not good customers. Customers who hold your feet to fire and say I have to win—in order that I win, you have to lose.

My dentist is pretty interesting; he fires patients.

Have you ever heard of this? And I’m like wait—are you doing a set up here? He was telling me about it. We were talking about business stuff and I thought: I’ll floss—I swear—I will. And actually, I always like him to feel satisfaction of a job accomplished, so I typically eat a bag of Oreos. [Laughter] On the way, you know? So my teeth are all gummed up and black and stuff and it’s like whoa! Before—after, you know? It’s just—it’s pretty delightful. But, anyway.

So I live outside Washington D.C., in Virginia, but above the sweet tea line. Okay, so some of you know what that is. The Mason-Dixon Line has effectively moved south substantially, so the South begins south of Virginia now. Anyway, so I live not too far from the sweet tea line—and, anyway. In D.C., it takes you an hour to an hour-and-a-half to get anywhere. We don’t talk miles. So people will say hey, listen, I’m at so-and-so; can you come visit? And I’m like hmm, this time of day, check google maps . . . yeah, I can’t make that. It’s like a three-hour drive to go across the street because it’s rush hour. But, anyway, dentists sell hours on the schedule, right? And, if you don’t cancel and don’t show they can’t resell that inventory. So, you know, do it one time? That’s cool; I get it. Do it twice? That’s bad. Do it three? You’re cancelled. I wonder how many companies have the nerve to do that. It says let’s take a retrospective look at the customers we have—and maybe that will help us hone up our target market—as we realize that there are some people in the generic market segment we chose who are not good customers.

I love Agile; I love Scrum. I love Extreme Programming.

It seems that many people have taken Lean Startup and Agile development methods as permission to not plan. Does that sound familiar? It’s like—you know what? Let’s put everything on a Post-It note or an index card. We need more specificity than that. So this is a tool that I use and you’re welcome to, it’s included in the slides, to say what the steps are? What are the artefacts? What are the meetings? What are the things that we need to get from here to there? To get from goals to success? And, I named my company Under Ten because that’s my goal for you—to be working on under ten things. Under ten steps; under ten artefacts. Under ten projects; under ten priorities. And, the real answer should be three, right? But I didn’t think anybody would buy under three. I think they’re like, oh yeah, get real, right? You know, but under ten.

And what I do with companies typically is I sit down and I do an assessment. I say what are the top ten most critical things—out of the thirty-five or forty-five or fifty-five things on your plate—let’s master those ten or fewer. So when I first start working with companies, we’ll go through a chart like this and they’ll write in the artefacts they’re using at these steps. Just to get pernickety with them I only give them five little bullets to work with and they’re like ugh you’re killing me here. And in my illustration, I only gave them three. But, you know, maybe we—oh, you know, here’s one.

A lot of company’s still have a business case. And I say well, what’s in a business case? This is always just fun, in a medium to large size company, to say—what’s in whatever the artefact is? Because nobody knows. So we’ll say what do you guys put in a business case? Or a business plan? And, then they go, okay. We put the market information, the product information, we put the financial forecast and we put this and they start ticking off stuff. And then they start having a fight with themselves. No, no, no—that’s not in that—that’s in this other artefact. And I wonder do we need anything more than a business canvas? Thank you, Alex, for that. Brilliant. Do we need a business canvas, maybe a portfolio roadmap, and some maybe some business goals or a financial forecast for a few years? Isn’t that—in a staple—all you need for a business plan? How—the question for—again—larger companies is not how many artefacts do we need, but how many can we get rid of? I stopped writing business cases a few years ago when I realized that executives cannot read; they want a roadmap because it’s pictorial. They’re like oh, I see, you know? And this being an internal confidential document…you want me to distribute it how? The joke I always had was if you wanted customers to see the document you needed to label it company confidential—do not distribute—which would guarantee customer’s would have it that very day. It was kind of a clue to the sales people that this was really important.

So we look at—what are the artefacts that we need to articulate our market goals? Our business goals? What are the things that we can leverage in our corporate infrastructure? And so forth. So this is a tool that a lot of company’s use—that a lot of companies I work with use—to help them identify how do we get from here to there without having this big paper tiger? Without having a thousand documents and a lot of confusion?

One of the documents that a friend of mine recommends that I like a lot he calls a Product Journal. I think this is one of the things that we struggle with, particularly in the world of Agile, is we don’t remember why decisions were made or if they were made. So, my friend advocates that a product manager, in this case, keep a journal of every decision that was made or things that you think about related to the product. So, three or four months down the road when people are questioning the decision you can go back and figure out what happened. And, it was like, well because the VP of Sales came by and said this is my idea, so therefore it is the most important. You’ve got that written down at least. As opposed to, oh yeah, God spoke to me in a dream and that’s how it ended up being in the product.

I’ve spent most of my career working with teams around product management. I spent fifteen years doing training, training product managers and skills of business, and many of those product managers said I apply this stuff now to my CEO job. But so many people I talked to said can you come back and help? And a training business is really difficult because no I can’t come back and help. I’ve got a gig next week and next week and next week. So when I started Under Ten consulting a couple of years ago my goal was to work with a smaller number of customers and stay with them for a long time. Instead of swooping in and swooping out, and doing what the industry calls showing up and throwing up, we do a lot of hands on application. How do you make this work for your product? What I’ve encountered in this is product managers, and others in the organization, have and need different types of expertise.

One of the questions I get a lot is when should I hire a product manager?

Correct answer is right before your first failure. [Laughter] Generally the correct answer is right before . . . at the kick-off . . . of your second product. Because the first product was the CEO’s brainchild, right? That all came from wow—I have a vision–but after that first pass the CEO is now the head of a business not the head of a product. But, none the less, people ask me what am I looking for in terms of skill set for product manager? My friend Saeed Khan, who I mentioned earlier, said most of us are looking for a non-existent super person.

I saw one the other day you might like. I considered applying for it. The job was tremendous. It paid—I swear—$60,000 a year for this and they were looking for somebody with 15 years of experience in social media. [Laughter] I believe a few of us are the only candidates in the world who are qualified for that. I started blogging in 1999, so I just made it. So, often I find people who are looking for skills like—we want business skills and we want market skills and we want domain skills and we want technology skills. We want all of them; we want them to all be deep and we want them all in one person. And there is where it falls apart.

With Scrum, the founders of Scrum created a concept called a Product Owner. The Product Owner is supposed to be a business expert and a market expert. Most of the organizations that have implemented Scrum, however have turned that person into a business analyst. A technical expert who sits next to the developers reading aloud. [Laughter]

Sales people look at product management and say that’s where I go for domain expertise. A buddy of mine took a job as a senior product manager—director of product management somewhere—at a company and he brought with him an algorithm that detects fraud for banks. He had developed it while a VP at a bank. The word goes out: new guy on board, bank guy, algorithm, and fraud. His phone starts ringing off the hook from sales people around the country saying I’m going to call on a bank. Could you come with me to talk bank? You know? You bank people must talk the same way or something. So the sales people basically abused this product manager because of his domain expertise and he never got around to develop the fraud product. Well, not for that company; he took it to another company.

Typically the marketing team relies on product manager for technology expertise. I had a friend who—let me see how I can tell this story—mm-okay. I got a friend who got a call from marketing and they said we need screen shots of the next release. My friend said I could do that or, just for the fun of it, our product is designed for eight-to-twelve year olds. Maybe you could . . . use it yourself? [Laughter] And this was not well received apparently. Actually-well. [Laughter] Okay.

But when I get called in, a company I worked with recently, their new president came in and said I’ve seen the problem. Product management is not driving the business. They contacted—it was kind of funny—I had been trying to sell into them for quite a while and it was one of those idle accounts that was going to turn into some sort of business—maybe. Then the new president comes in, a week or so later says we have a product management problem, and the following hour I got a call from the client saying when can you be here? Are you available tomorrow? Yay. Compelling event. Anyway.

The president was saying we’re looking for some business expertise and we don’t find it. The product owners have gone technical. The sales people have created their own product management positions and called them other things. We often find that this kind of expertise is centralized in product management, but it doesn’t need to be. The real point I’m trying to make is that people in your organization have to have these skills. If they don’t—they often rely on a corporate function—often product management—to provide those skills. One of the questions I often get are how many product managers do I need? And my answer is—it depends on how many other departments are hiding their head count in product management. For instance, sales people need sales engineers. I talked about the other day at lunch and I think I offended everyone at the table, but I want sales people to know less about the product and more about negotiation. I mean—anybody can sell a dollar for eight-five cents, right? Discounting is easy. We need to have somebody on the other side of the table who is as good a negotiator as our customers are. But then customers ask them technical questions that they can’t answer. Which is why sales people need technical expertise in the field; it’s called a sales engineer. Anybody know this role? Sales engineer? Two people go on a sales call: one of them drives the car and one of them knows the product. [Laughter] Right? Now actually I was a sales engineer and I did know the product. After a couple of years of doing that, I went you know what? I can drive a car. I’ll move into sales. I found that it truly is more than driving the car; you also have to buy lunch. But what I really found is that I relied on my sales engineer to help the customer configure. As a sales rep, my job was to work with the business side on how to negotiate. How do we make a deal we both walk away with having succeeded?

So, let’s see where we are here. So—using this same tool—some companies use this as a score card as well. Looking at these different—these nine different boxes—and putting in metrics. How did we do in these different categories? And some of the metrics we learned about yesterday would be ideal to pop into something like this.

So let me begin my wrap-up here with a story about monkey’s and the electric tree.

I don’t know if you’ve ever seen it. These are bananas in the wild. Researchers, years ago, probably at MIT created a monkey room and they put bananas in the monkey room. They released monkeys into the room and the monkeys saw the bananas. They ran up the tree and as soon as they touched the banana they received an electric shock. They probably couldn’t do that today, but anyway. It didn’t kill them; it wasn’t electrocution. It just gave them a shock. After a while, the monkeys learned don’t climb that tree no good can come from it. Then they introduced a second generation of monkeys. The second generation of monkeys came in and they went hey! Bananas. Sweet. And they went to run up the tree, but the first generation held them back. I’m not sure if they talked or anything, but somehow they conveyed – bad idea – going up the tree. Then they removed the first generation entirely and the second generation all kept each other from going up the tree; they then introduced a third generation of monkeys who saw the bananas and ran up the tree. Second generation held them down; you’ll hurt yourself. I guess. They removed the second generation of monkeys and all that was left was the third generation of monkeys who had never been shocked and never knew anyone who had ever been shocked, but they didn’t climb the tree.

How much is that your company? How often do we hear we tried it once and it didn’t work?

I encounter companies, who say Agile is great for the little guys, but we’re enterprise; it won’t work for us. Not true. Lean is great, but that’s for startups. No, not so much. The concepts of identify a kind of customer, find out what their deal is, and then solve their problem? I mean that’s pretty fundamental. It works in any sized company. Instead of starting with the product and finding people for it?

One of the quotes that was attributed to me a while back was—it’s easier to find products for people you know than it is to find people for products you know. It would have been better if that was a slide. But…”If we always do what we’ve always done then you’ll always get what we’ve always got.”

One last story. Can you tell what this is? It looks a little bit like a jellyfish, but it’s – can you tell what this is? [Audience] Fire alarm. Steve: Fire alarm! So, my wife makes pizza on Friday’s and once a month we make steak. I’m not like a guy-guy, so we don’t have a fire-grill barbeque thing outside. So, I just broil it – stick it in the oven. The fire alarm goes off because the kitchen’s got smoke and stuff in it. So, I have solved this problem, I think—brilliantly. I was in a hotel and I grabbed a shower cap, brought it home and put it on the smoke detector—the fire detector and solved my problem.

Now you may be able to see this little red thing at the bottom? Okay, this is a three foot long—a one meter long—piece of red yarn. Does anyone know what its function is? [Audience] So you don’t forget to take it off. Steve: Exactly! Cause it’s now at my height. The reason it’s there was the last time I made steak; I went to put the shower cap on the detector and found that it was still there… [Laughter] …from a month ago—when I did steak last time. So, I think, a brilliant innovation. Frankly. Now I have an indicator, at my height, that I can see and I can take it down. This apparently is a problem many of us have.

Another problem apparently some of us have is three o’clock in the morning and suddenly there’s a chirping sound because you didn’t change the battery in your fire detector on Labor Day like you were supposed to, right? [Audience] Yep.

Steve: So what is your reaction? What you do—what we all do—is you climb up, you get down the smoke detector, and we remove the battery, then we go back to sleep. If you’re particularly OCD, you might even put it back up. So, now that it has no battery and it’s reinstalled, you’ll forget about it until Memorial Day. That is what drove Nest to build the product.

They noticed this sort of behavior. Unfortunately, they did find some problems—well, let me back up. So, when your smoke alarm goes off inappropriately, you can wave at it and will stop making noise. What they found, turns out, one of the things that we do when there’s a fire is we run away shrieking. [Laughter] So, apparently, the wave motion is not a good solution. None the less, I love what he had to say. When this product came out, the CEO said “Nest was never just about thermostats. At its core, Nest has always been about the home. We reinvent unloved home products to create simple, beautiful, thoughtful things.” Isn’t that brilliant?

And no longer are we going to be satisfied with MVP. If we define it this way: it’s the least we can do. This is a photo of my sprinkler. The control for the sprinkler system in my house and everyone everywhere hates this thing. It’s like, you get the guy to come out and do the thing with the sprinkler thing and we’re like – do something with the thing. [Laughter] Cause we don’t know what it does, right? [Applause] I think it took me quite a while to figure out that you have to turn that knob one notch to the left to turn it off because I always look at this and go—it is off. The vertical is off to me. There is a big instruction sheet next to this as well.

MVP is the right idea. It is. MVP says let’s build the smallest amount of code that we can test, but it seems like a lot of companies have said let’s build the smallest amount of code and then sell it.

Products are great. I’m a nerd. I love technology. I love Star Trek. I love products, but we need to look beyond the simple product and say . . . wait a minute. Before we get into product, what is our competence as a business? What makes us qualified to be the ones to solve this? What authority do we have to bring it to market? What market are we going to serve? And now that we’ve got the product, how are we going to promote it? And sell it? And support it? And operate it? And after the fact, let’s take a look. Let’s revisit and say, you know what, have we gotten customers we wish we hadn’t gotten? Should we start firing some of our customers? Should we hone our materials to be targeted more to the specific customer?

It’s easier to build products for people you know than it is to find people for products you know. Many of us are like the chef who prepares dishes based on the available ingredients rather than creating a mean that customers want to buy.

One of my favourite new books by the way, Creativity Inc., all About Pixar.

One of the things I really loved in the book is Disney went to Pixar and said it’s time for a sequel to Toy Story, but it doesn’t have to be good. We’re going to go direct to video; people are stupid. They’ll just buy it. And they worked on it for a while and finally said I can’t work on something that doesn’t have to be good. And neither do your companies. Your developers, your technical people, want to work on something that’s great. Because I think development is a lot more like an art than it is like factory work. Some of these stories are in my book, of which I’ve brought a couple of copies, and I’d be glad to sign during lunch if you’ve got one. If you didn’t, come to my website and check it out. Here’s my coordinates, so please stay in touch with me, and get the number of things you’re working on to under ten. [Applause]

Mark: Anyone got a question to kick off?

Audience member 1: When you’re looking for a product manager, you said that people tend to look for basically all of those things in one person. What are the primary things that you think are most important when you’re bringing on a product manager for a product that you’ve already launched and you’ve got customers for? What should you be focused on the most when you’re the CEO and handing things off to somebody?

Steve: Good question. When looking for a product manager, what are you looking for? Let me go back mentally to that slide. You’ll likely to find somebody who is deep in two of those areas, but not four. So, it’s important to think about, who is the primary person you want this to interact with? If it’s time for the senior product manager, also known as the CEO, if it’s time for him or her to offload this to someone who isn’t the founder – then you need a business orientation. One of the things that I see most often though is we’re looking for someone who deeply understands our domain. So we look in development or we look in support. Domain is one of the easiest things to learn actually, but fundamentally – no matter what kind of product manager you’re looking for – you’re looking for somebody who looks outside the building for answers.

My first job as a product manager I went to one of my client sites and I worked with them for a week. As a result of that, I knew everything I needed to know about that market segment and the domain they were in. So, I was able to supplement my original skills with feedback from the market. We can talk more if you like.

Audience member 1: I’m Brian Webb with Avantis. We send all of our employees to training, so that they become domain experts. So, support. Sales. And we found it to be really—even QA.

Steve: Cool! I totally agree.

Audience member 2: Have you any experience with that? Steve: Well, I believe that people should love what we do here. It drives me insane when I hear people say oh, I’m just in marketing. I don’t know anything about whatever your company does. I’m just in sales. A good sales guy can sell anything. I don’t find that to be true. In particular – one more time — I don’t think development as factory work and we send our work to a factory – to an outsource firm – you’re saying you don’t have to know our business to work here.

So, I agree with you. I would heartily recommend we send all employees to some sort of domain training to understand what it’s like… what makes your company special or… the market… the market you serve…understand the subtleties of it… can be done through training and sending… not just sales people and product managers, but developers and support and others to spend time with customers. Spending a few days, on site, with a customer is hugely insightful for everybody. The key is with developers you have to at least send them to two otherwise that one place they went will be the one hundred percent of the universe. And for the next five years you’ll be hearing, ‘You remember the time we went to?’ [Laughter]