The Jeff Patton Hypothesis: Successful Teams Focus on the Who Before the What

Jeff Patton helps companies adopt a way of working that’s focused on building great products, not just building stuff faster. Jeff blends a mixture of Agile thinking, Lean and Lean Startup Thinking, and UX Design and Design Thinking to end up with a holistic product-centric way of working. Jeff is author of the bestselling O’Reilly book User Story Mapping which describes a simple holistic approach to using stories in Agile development without losing sight of the big picture.

In this episode of the Product Science Podcast, we cover common challenges to product discovery, what tools and techniques Jeff teaches, which ones he’s changed over the years, and why.

Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, YouTube and more. Love what you hear? Leave us a review, it means a lot.

Resource Links

Check out Jeff’s up coming events

Follow Jeff on Twitter

Follow Jeff on LinkedIn

Follow Holly on Twitter

Follow Holly on LinkedIn

Questions we explore in this episode

What are the common challenges to product discovery that Jeff sees?

• Decision makers think that doing product discovery will take too much time.
• Stakeholders think they already know the answers.
• People focus too much on pleasing stakeholders instead of figuring out what will please the users.

How does Jeff teach story mapping?

• Jeff has teams map out everything they do at the start of their day to get ready.
• Jeff points out that they are not writing down features but rather the steps that they take. Thinking from the person’s perspective is important.
• Then Jeff flips the goal on them and says now they want to get ready as fast as possible for their day.
• The participants discuss how getting ready as fast as possible changes the steps that are necessary. Changing the goal changes which steps must be included.

What really happens when organizations move to a product culture?

• It’s a lot easier to worry about keeping your boss happy than to worry about keeping your customers happy.
• As organizations grow, more layers of management make it harder for people to stay focused on product success.
• Even when there’s success in transitioning to product thinking, when the right people leave, organizations backslide.
• Like Sisyphus, product managers have got to keep pushing this boulder uphill. Jeff says to think of it as a beach ball and have fun with it.

Quotes from Jeff Patton in this episode

Your stakeholders aren't actually your customers. They're not actually your users. There's no business that thrives when stakeholders are happy. That's not where the money comes from. Your business model isn't making stakeholders happy. Money comes from outside customers and users. Money comes from people using your product and being more efficient and more effective.

One of the things that happens is companies that start off very strong and product centric, as they grow, they start to lose that they start to become more bureaucratic. And people start to worry more about political safety than product success.

I want people to understand that we don't prioritize features in products. We prioritize people. It's deciding who you're focused on and who you're not focused on.That's the hard part of product thinking. You're not deciding, again, what features go into your product. You're deciding who to make happy and who you're not gonna make happy.

The Product Science Podcast Season 5 is brought to you by Productboard

Check out their eBook: 10 Dysfunctions of Product Management

If your product team is struggling, it could be one of the 10 dysfunctions of product management. Learn more about each dysfunction and how a product management system can help you address and avoid them.

Get Your Copy

Transcription

Holly Hester-Reilly:Hi, and welcome to the Product Science Podcast where we're helping startup founders and product leaders build high-growth products, teams, and companies through real conversations with the people who have tried it and aren't afraid to share lessons learned from their failures along the way. I'm your host, Holly Hesta, Riley founder and c e o of H two R Product Science. This week on the Product Science Podcast, I'm excited to share a conversation with Jeff Patton. Jeff, welcome.

Jeff Patton:Thank you. I'm super

Holly Hester-Reilly:So I usually begin by asking people to tell me a little bit about how they got into product, and I would love to hear more about how you became the person you are today. How did you get into this?

Jeff Patton:How does anybody get into product? Nobody gets into product deliberately. You accidentally arrive in product. Everybody who's a product manager, especially a tech product manager, got there through someplace else. They were doing something else and then they just stepped forward when everyone else stepped back and you end up being a product manager.So I got my start. In product management in the probably very late eighties, early nineties, and honestly, the company I worked for didn't use the term product manager. I think it was called a Solutions Architect, but I was the one that stepped forward in the team and worked directly with customers and made decisions about the product.The company I used to work for ultimately acquired by Salesforce and is now Salesforce Commerce Cloud today. But part of the reason I am who I am. Is because I got bugged at my company right around 2000 and left and joined a startup in San Francisco that was using this cool new process called Extreme Programming.And while I was there from 2000 to 2001, the term Agile was coined, and my job title of that company was product manager. And so I've got a very early start with agile development and product management. In that context, I did eventually go back to my company, then became Salesforce Commerce Cloud. When I did go back, they did have a job title product manager, and that's the job title I took.We didn't use that job title Product manager throughout the eighties and nineties. We didn't quite know what that was, and it wasn't until 2000 that I actually had that as an official job title and been doing that, started doing consulting in 2008, and I've been working with other product managers in other product

Holly Hester-Reilly:Yeah. I'm curious, because you've been at this for a long time. What did you see in terms of how the industry came to embrace the term product manager? What was going on there?

Jeff Patton:Oh boy. I dunno if I've got anything insightful to say there. I think other software companies were adopting that term product manager. Risk of name dropping of friend and colleague is Marty Kagan and everybody in tech product management knows that name probably. And I know that he was using the term product manager in the nineties and it just, my company wasn't, we just didn't understand what we were doing.We knew we were creating software and that software was a product, but we just didn't have a mature perspective on that. When I heard the term product manager, I was thought of product managers or people at Proctor and Gamble that manage brands of toothpaste and things like that. And I think even still, even today, tech product management is a very different thing than managing traditional products.And we are just realizing what tech product management is. Tech product management has really changed. That's another, might wanna spin off on that tangent about why it's different and why traditional product management is becoming more like tech product management. I think tech product companies were a little bit slow to adopt the concept.There were techies adapting to a world where software is becoming a product and moving very quickly to get products in the market. A risk of name dropping. Again, I'm old and I'm lucky to have met a lot of people. One of the guys I met early on in my career is a guy named Alan Cooper, if you know the name.

Holly Hester-Reilly:a little in case any of our listeners don't.

Jeff Patton:Alan Cooper is considered the father of the persona and credit for adopting personas for use in technology. He gets leave, gets credit for coining the term interaction design. And for people who are UX or product design people, they'll know who Alan Cooper is, is a big name in ux. And I remember a conversation with Alan years ago.He said, I regret calling What? What I'm doing, design calling, what I'm doing, interaction design. What Alan said is, what I meant was product management. And Alan, who arguably created a lot of products back in the eighties and nineties, referred to what he was doing as interaction design and design, but what he meant was product management, so we didn't understand what we were doing so much back then.

Holly Hester-Reilly:Yeah, and I think that's, from my perspective anyways, it seems like it's that function of just the relative infancy of the tech field compared to like toothpaste.

Jeff Patton:Yeah, yeah. Very traditional products like

Holly Hester-Reilly:And so it does. I think one of the things that we see still today is this constant maturation of the language and what words we use for different things, and then changing over time.

Jeff Patton:Exactly. Uh, topic that I hit into before about why tech product management is different in teaching. One of the teaching models I use and talking about this stuff is what I refer to as a continuous product improvement cycle, and I don't wanna talk about that. But what I wanna point out is that tech products don't behave like traditional.Products, traditional products improve themselves with an obsolescence model. I just picked up coffee from my coffee machine. I'm sure the coffee machine manufacturer's hard at work trying to come up with better coffee machines, and when they do, I will throw away my coffee machine and buy a new one.Same with your car, and same with any traditional products. And I'm old. I remember when software used to come in a box and in that box were floppy discs, and then eventually CDs and things like that. And a new version might come out a year or two from now. Now when we talk about software products, contemporary software products may be post Apple, iPhone, post ubiquitous internet, post cloud-based computing.We now have an expectation for software to continuously improve. There's no new version of Amazon Prime or Netflix or Spotify coming out. We subscribe to Spotify and we expect it to continuously improve, and when we talk about. Software product management. We're talking about managing a product that is not meant to stay the same is not meant to be designed, marketed, and sold.Traditional products we talked about is having a product lifecycle of introduction and growth and maturity and decline. There's model. It doesn't make sense anymore for tech products. We wanna get products on the market. We wanna keep growing them and we want to keep them relevant and mature. Always.That's not the way. A traditional product that's made of atoms and molecules can't continuously improve. Not the same way software can. And the other thing, the characteristic of tech product management is we don't have big releases. We don't repackage and rebox and try and sell the next new big thing and get people to throw away their old thing and replace it with a new thing.Rather, we improve tech products with lots of little changes. It's easy to ask people, when's the last time you saw a big new release for Zoom or Spotify, or. Something like that because you don't, that's not the way it works anymore. And we could start to move that way. Building things for internal use. We could continuously release, but it took a change in the underlying technology.And with that, a change in how our customers expect the product to work. After we all bought smartphones and iPhones, we got the hang of apps continuously being available and I improving and changing and it's changed the job. And then as a consequence, we now start to expect similar behavior out of.Other products. I may be the only person who doesn't love Teslas, but part of the reason is Tesla upgrades the app and you get upgrades on your Tesla multiple times a month. And I can remember getting an upgrade on my Tesla and not being able to turn on the windshield wipers because they move the button for that and super annoying.So even hardware continuously improves. I know I've got a smart vacuum cleaner that gets firmware updates at least once a month. So now we get products that are more hybrid, that behave more like tech products that we expect them to continuously improve. So it's a different way of managing a product than it's different than traditional product

Holly Hester-Reilly:Yeah, you really hit on something that is a major reason why I work in tech myself is I had studied chemical engineering and I studied product design in the context of chemicals. And then when I started exploring software and I realized, oh my God, we can just change this and change it again and change it again and we can just iterate like.Forever. This is so powerful to me. It makes the work fun.

Jeff Patton:Yeah, it does. And so it makes that process of continuously understanding customers and unmet needs and new solutions and turns it into a continuous process. Not a phase, not a cycle. We can no longer draw those models. Where now we do research, now we do design, now we do development. Now we release the product.It doesn't work that way anymore. It's all those activities are going on

Holly Hester-Reilly:Yeah.

Jeff Patton:Um, phases don't make much

Holly Hester-Reilly:So tell me more. I know you wrote a dual track Agile, not dual track article. Tell me more about in the best companies that you work with or in the companies that are following what you teach. How are these things happening continuously? What does that look like?

Jeff Patton:So we've always been working in a couple things to talk about there. After using an agile process or any kind of process, there's always dual tracks. There's always some amount of figuring out what to build and then building it. And so everybody's already doing dual track. Now the trick is recognizing these are two ways of working, two kinds of activities and not two teams.So the best teams doing this understand that we are one team and we are all responsible for understanding what to build. We're all responsible for ultimately building, and we work together to. Figure out what to build. We work together to build it companies that are best at this stuff. Look, I'm known for story mapping.I wrote that book on story mapping and there are two chapters on product discovery and story mapping. I've gotta write a second edition in that book, but I'm so lazy. I'm eventually, I'll get to that. But one mistake in that book, as I talked about, the concept of a discovery team that's working on discovery and the delivery team, and the thing I've learned from the best companies doing this is it's.Two tracks is not two teams, and the best companies doing this are figuring out how to involve the whole team in doing discovery work. I've worked with Atlassian off and on over the years, and when I first worked with Atlassian 10 plus years ago, they involved development team members in observing interviews and taking notes, and it was a good idea.And now it happens in most good teams, it happens there. Other companies I've worked with, the best companies figure out how to involve the team. Look, engineer's, primary job is to write code tester's. Primary job is to test code. Other people do that, but we teach them just enough to be able to drop in, observe an interview, take notes, help synthesize what happened or what they saw, and help make sense of it, and then get back to their job.They participate a little bit every week in doing discovery work, and they participate in design using activities like a design studio. Again, I mentioned Atlassian earlier, and if you worked in Atlassian, it's called a Crazy Eight session. You ever heard that

Holly Hester-Reilly:Yeah, the fold, the paper in eights.

Jeff Patton:Yeah, you pulled the sheet of paper three times, you get eight boxes and everybody sketches you ui.So now we're involving the whole team in UI design and solutions. We tried to involve engineering earlier in building live data prototypes, smarter prototypes than just prototypes. You could build with Figma or something like that. The best teams understand that it's a whole team responsibility. They keep the discovery work they're doing visible and the delivery work visible, and we all play like one team on the field.Even though we've got different specialties and we've got our own roles and responsibilities, we figure out how to involve everybody in doing that work that ends up being the best dual when those two tracks aren't competing with each other. That's, hence I was talking about, it's not a dual, it's a,

Holly Hester-Reilly:You have clients or people at the companies that you go into who are super skeptical about having the whole team involved in the whole thing. How do you convince them?

Jeff Patton:Yeah, let's hit one kind of skepticism first. And then the first skepticism we hit are engineers that don't wanna be involved and they don't wanna do that. So the general rule of thumb is you don't force, people don't learn the hard way not to force people. If you saved your responsibility, you must be involved.They're gonna do crap work and they've slow everybody else down. So don't force people to be involved. But in any given team, you're gonna find people that are excited to be involved. Let participation be opt in. They opt in to sit in and listen in on an interview. They opt in to participate in a design studio.They opt in to doing some of those things and don't make anybody participate. And then what happens is you start to build fomo. The people that opt in, enjoy it, feel like they were part of the decision. They know why decisions got made about what we're building, and over time, more people wanna participate.But I have heard engineers say, I understand how valuable this is and why we wanna do it. I just don't wanna be the one that does it. So don't make them. In the early days, we used to get a lot of pushback from design, from user experience designers that, look, we don't want engineers in my kitchen and I don't want them telling me how to design.I don't want others. But there's an old quote I'll mention from a lady named Leah Buley. She wrote,

Holly Hester-Reilly:UX team of one.

Jeff Patton:UX team of one. That's right. A quote from her that I'll reference a lot is, design isn't a product the designers produce design is a process that designers facilitate and what good design posture. Now, this is where we get practices like a design studio where we involve everybody in sketching, design, and other practices shake out of that.And good designers see themselves as more as facilitators in it. More of a collaborative approach. Now we don't want engineers making final UI design decisions. Anymore than we want UX people making final code decisions. People have different training and different skills or different expertise, but good ideas come from a lot of places and good UX people figure out how to involve them.Yeah, I used to get quite a lot of pushback from UX people, but we figure out ways to involve others productively. We can teach engineers some basic interviewing, listening skills and notetaking skills. We can lean on engineers for suggesting user interface design things. I, gosh, years ago, Used to work for consultants called ThoughtWorks, and one of the things I would run engineers through is a basic visual design bootcamp.They needed to understand some basic visual design principles so that they could detect and solve visual design problems. First off, they need to be able to detect them so they know there's a design problem that needs to be fixed and they can go get someone to help, not just not notice it, and then fix basic problems themselves.So learn how to involve. Engineers and doing more of this work. The biggest problem that everybody knows with discovery is organizations that don't believe it's necessary at all because they believe their ideas are awesome and they're gonna work, and no reason to test those ideas. That's a

Holly Hester-Reilly:Yeah. I'm curious if you've seen any shifts in either how many companies are in that camp or what types of companies are in that camp. In your years as a discovery coach, have you seen changes?

Jeff Patton:Certainly back in the nineties and early two thousands, there was no common language for this. We didn't all didn't use the same discovery word. We talked about design. We need design to happen and that wasn't clear what was going on in that we've, discovery has become a more ubiquitous word. We use that people know what it is, and more companies are adopting that stuff.How has that changed? I see more companies leaning in and doing more of the work, but one of the patterns and antipas that I see is the support for this kind of stuff, waxes and wanes. The companies will go all in and do this stuff, and then some people see this as a waste of time and we stop doing it.Or sometimes there's more to talk about here. Sometimes teams overdo this stuff they use. Discovery defensively. They're afraid to make decisions. They're afraid to fail, and things get lost in discovery. Never come out and take too long to do it. And eventually you get business people to throw up their hands and say, stop doing that.We know what the answer is. Just design it and build it. Stop testing things so much. Yes, I see a lot more companies planning to do it, but I still see companies that were really successful at doing a lot. I'll see the company starts to struggle financially if the leadership comes in and I see some.Times we see that good product practice being dismantled after it's been working for a while, and sometimes for good reasons. Sometimes they've been overdoing it, sometimes they've been doing it, and the company hasn't thrived as a consequence of doing it. Sometimes it's the team's fault and sometimes it's not their fault.Sometimes it's just there's other

Holly Hester-Reilly:Yeah. Are there any other common objections that you get to investing in discovery?

Jeff Patton:The most common objections are this is gonna take too much time, and we already know the answers. We already know what the right thing to do is. Gosh, one antipater I'll pick on a lot. Is what I'll refer to as the service provider, anti-pattern, where teams believe it's their job where teams start treating their business or their stakeholders as their customers, and they start worrying about satisfying stakeholders.They start running things past stakeholders. They ask stakeholders to make an approved decisions, and they start believing that their job is to build what stakeholders want. In talking about it, I'll use oftentimes a home remodeler, as an example. If you're remodeling someone's home, you wanna. Please that person, and they make a lot of the decisions, but home remodelers aren't responsible for the outcome.If someone comes in and they lay down the flooring I want, they put the cabinets in, I want, they install the appliances I want. If I later on hate the flooring, hate my cabinets, hate my appliances, it's some of my problem. It's not. My kitchen remodeler's problem, and it takes the outcome and it makes it your customer's responsibility.Now, the problem is when you lean on stakeholders for do that, your stakeholders aren't actually your customers. They're not actually your users. And if stakeholders are happy, there's no business that thrives. When stakeholders are happy, that's not where the money comes

Holly Hester-Reilly:Yeah. Yeah.

Jeff Patton:Your business model isn't making stakeholders happy.Money comes from outside customers and users. Money comes from people using your product and being more efficient and more effective. Happy stakeholders don't fund your company. They aren't actually your customers. They may be your users. The stakeholders being happy isn't making your company more money.Anyway, I, I don't see any company whose purpose is to make stakeholders happy, and teams sometimes forget that and do that. So look, if you mistake your team's responsibility is making stakeholders happy. Yeah. You don't need discovery work. You need traditional requirements

Holly Hester-Reilly:Yeah. At this point, I am allergic to the term requirements capture, requirements gathering is, I'm just like, oh, no. Are you just going to stakeholders and asking them what they want?

Jeff Patton:Exactly, so that's just a misunderstanding of what your job is. Again, I'll use, if I look, are you a kitchen remodeler and you're remodeling someone's kitchen, or are you designing kitchen stuff that goes into Ikea that has to sell to lots of people? Characteristic of a product is it's a leverage investment.We build a product that will get sold over and over to a lot of customers that we don't even have yet to satisfy a variety of needs. You're not just trying to please one

Holly Hester-Reilly:Yeah, so one of the things that you mentioned, maybe a concept or two ago, is writing the book on story mapping. I'd love to hear more about how. User story mapping came how it got developed and how you teach it now.

Jeff Patton:Yeah, I'm known for popularizing that idea in the agile world that anybody, look, if you've been at this a while, you should know it's not really an invention. The idea of. Mapping product experience using sticky notes or cards or using a simple model is super old. I thought I coined the term story map because I was using stories from an agile context, and I would say, look at, this is a map of stories and so we're gonna call it a story map, but somebody pointed out to me that the term story map has been in use for.Decades before that, if you were to go to Amazon and look type in story map and look for a book, the first books you're gonna get are books on screenplay writing and things like that. The idea of using something visual and spatial to map a story out has been around for a long time. I started doing this learning traditional task analysis from uh, as an interaction design practice.There's a design practice called Usage centered Design. Super old now, no one knows what it is or remembers what that is, but the way we did task analysis is we identified tasks or steps or things that people did as those into a model, and it turned out that most of these models started to shape up. We would organize the models organically, cluster tasks that were similar and similar things that by similar people at similar points in time, but most all the time they ended up organizing themselves linearly.Things that happened early and things that happened later, and it just became simple to create a left to right. Flow of that. So what you're doing with a story map is just telling the story about how someone's going. You can tell a story about how people use your product today. That's most often called a journey map.Or we can tell a story about how we imagine people using the product in the future, the product we're inventing, or I used to use the technique to figure out what the solution should be. I would create a map of my journey. I'm imagining people going through and use that to design user interface and use that to actually design the user experience.So yeah, in early days we used to just. Build these maps to understand how people are working today. You build the maps to understand what we would build, and it just turned out that they turned to be excellent tools for pointing and gesturing and telling the story. This is what people are gonna do, they're gonna do this and this.And then they also turn to be excellent tools for decomposition. People do this and in this step it breaks down to these smaller steps and each one of these are bits and pieces of the software we need to build. So it ended up being an excellent bridging tool for bridging from the big story that we imagined what people are gonna do to decomposing it into smaller things, and then starting to sequence what things were gonna build when, what things were gonna support in the product when.So it morphed that discussion about the solution into a planning discussion and started doing that early, and I wasn't the only one doing it. If you tell somebody about a great idea and they say, that's a great idea, it might be, but if you tell somebody about a great idea and they say, oh yeah, I do something like that too, that's a pattern.And story mapping is a pattern. When I tell people about doing this, other people say, yeah, I do something like that too. It's a pattern that's been around for a long time. I was lucky enough to help popularize it, but it's a pattern.

Holly Hester-Reilly:One of the things that I remember is you came into Shutterstock and did a workshop while I was there.

Jeff Patton:Oh my gosh. I knew you looked familiar. I didn't know. This is terrible.

Holly Hester-Reilly:No worries. You teach lots of people, but one of the things that I remember from when you came in to do the workshop at Shutterstock was the example that you used in the beginning about how people get ready for their day. And how you slice that when you oversleep and you can't do as much. I'd love it if you could share some of that with our listeners.

Jeff Patton:That seems to be the most reliable way I can teach people how to map experience is to ask them to think back to this morning when you woke up and write down everything you did from the moment you woke up until the moment you arrived at work, or were post covid, sat down to work. Probably in your home office, something like that.They can easily do that. And what they write down are steps, and that works out great. As an aside, we should find the link for it, but there's a Ted Talk from a guy named Tom wj. Jack, if you've got a wicked problem first, make toast. So when that Ted Talk first came out, People immediately sent it to me and said, oh my gosh, Jeff, this guy copied you.Because he talks them through a design exercise of asking you to write down the steps for making toast and then synthesizing them together into a common model for making toast. And he says, making a case for doing this kind of visual spatial modeling for modeling complex systems, things like that.First time I came up with that activity, I've been teaching story mapping for a long time and I had a huge room full of people and I walked them through the basics of how to do a story map and was asking them to map a product experience. And I was watching this whole room full of people just struggle with it.And I gave up a mid-class and I said, stop. Let's take everything you're doing and scrape it off the table and set it aside. And I said, look, honestly, this is not that hard. Let's. Take a break for a minute and let's do this. And I said, think back to when you woke up this morning and write everything down.And it just did this. And it was an act of pure desperation in a room full of a hundred plus people doing a workshop that did this. And I remember the first time I did it, I always played music and workshops and I had back then my iTunes queued up and I needed a time box and. I said, I need to write down all these things.And I said, this should take exactly the length of the song Kung Fu fighting. And I chose that song over 10 years ago, which is just over three minutes, and used that as a time box. And so still to this day, I use that song as my time box. Did I do that at Shutterstock? Did I use kung fu

Holly Hester-Reilly:Oh, you might have, you probably did. I don't remem. Remember the music that was playing. I remember the debates that I had with some of my colleagues about which things were acceptable to drop from your morning routine if you woke up late.

Jeff Patton:Yeah, exactly. So the message that says, want people to understand is what you're writing down or what people do. You're not writing down features, you're not writing down soap and towel and toilet and things like that. And that's what people tend to do when they start to think in software. They start writing down features.They start writing down nouns. They, they're thinking. Inside out, not outside in. I'm using that language a little bit more these days. When we look at our products, we try and think outside in or not about the product, but about the people outside the product and what they're doing. The biggest problem I have with people trying to story map is they think inside out, they think of what the software is and does not, what the people outside are doing.And using that exercise, they intuitively think outside in because they're the people they can think from a person's perspective because they're the person. Suddenly, when you tell them you're doing with software, they start thinking from their perspective because they're the ones that have to build it.So they get that, and then they started with a goal of getting ready in the morning, and I flip the goal on them and change the goal to get ready super fast. And then we have a goal of getting ready super fast, what do you drop and what do you add back? That's the exercise is get them a different goal.And I might have lost the plot in that answer,

Holly Hester-Reilly:I don't know if you always teach it this way, but I have this visual of got the horizontal of the steps that the. Human takes to get ready. And then in my visual, there's the vertical of, we've had a couple of those steps float up to the top as they're always there. No matter how much time you have, they're always there.And then underneath that, some steps of things that might be there, depending on how early you got up. And that's always been really helpful.

Jeff Patton:Exactly there. There's the things that we absolutely must do that are always there and the things that we could do if we had more time. But mostly the biggest thing I, I'll anchor it, honor. Point now in teaching, and I'm a little bit sharper about the messages. The goal here is to get ready in 10 or 15 minutes, and those things aren't there.Not they're there because the goal is get ready in 10 or 15 minutes. If I'd given you a goal of Best Morning ever, or we're focused on proper diet and exercise, that would change what's the necessity and what's optional. If the goal is good diet and exercise, then making good breakfast would be necessary.And looking at Instagram would be optional. If the goal was best borne ever, then maybe reading the newspaper for a while or reading the news online would be up in the necessities under the best morning ever goal. And eating an egg white omelet might be down lower in the goal. When you change the goal, it changes what's necessary.So I want people to get that. One of the things that you said, you remembered in class people arguing about whether it should or shouldn't be in there now. One of the ways I teach it is to say, don't argue. If you think it should be up in there, if you think it needs to be, if it's necessary, leave it up there.If it's necessary, leave it up there. No arguments, no discussion, no consensus is necessary. If you think you need it, move it up to the top and then we keep everything up there. Then at the end of this, I'll say, okay, how many people had tasks or steps left in there for things like taking care of their pets or taking care of their kids?And almost every group has something like that. And I said, great. You can make your slice smaller. By kicking those people out of your group. If you get them out of your group, you can get rid of their stupid kid stuff and pets, and that'll make this smaller. I want people to understand that we don't prioritize features and products, we prioritize people.It's deciding who you're focused on and who you're not focused on. That's the hard part of product thinking. You're not deciding, again, what features go into your product. You're deciding who to make happy and who you're not gonna

Holly Hester-Reilly:Yeah, I recently had a conversation where that was central. We were talking about making software that's not well maintained, we're reliable, and how we would go about it. And we had this conversation about, okay, which people are we gonna make happy? That's where we gotta start. We shouldn't start with which features do we wanna make stable.We should start with which people do we wanna make happy who are using this? And then we can figure out which things they use. But it needs to work for humans.

Jeff Patton:Yeah, exactly. And you gotta decide which achievements and if your product is trying to please, everybody said this before, but your mother should have told you you can't please everybody. And if that's your product strategies to please everybody, that's not a winning strategy. Not even iPhones. Please, everybody.

Holly Hester-Reilly:Another thing that I remember from the class that I'm curious to hear about is you taught pre-mortems and mapping risks. Do you still teach that in your classes?

Jeff Patton:Not so much.

Holly Hester-Reilly:How come.

Jeff Patton:How come I may approach it a little bit differently? I'll focus more on discovery work, and I'll focus more on identifying what your risky assumptions are or your risky beliefs are. Sometimes you call that a premortem. That premortem approach was a way of identifying what's risky, what's gonna go wrong, or what might go wrong here.The lean startup community and the lean user experience community focused a little bit more on identifying risks and assumptions. For years, I used to co-teach with my friend Jeff Got Health, who wrote the book Lean User Experience, and we were synchronizing content. We used to do things like identify assumptions and there's a practice called Assumptions Mapping that's out there from a great guy named David Bland.But we actually started to distill it down into just a list of questions to identify risks. First question is, are you solving a real problem and do you understand the problem you're solving? And I'll ask everybody on a team to answer the question on a scale of one to five, where five is yes, I'm confident we're solving a real problem, and I understand the problem.And if everybody says five, we'll move on to the next question. The next one is, do people when they see the solution, will they want, the next question is, can we build it predictably? Can they easily learn how to use it? And then what the last question is, will they actually use it and keep using it and really get valued?Now, ideally we wanna be able to answer yes to all of those questions, but if you start with the, are we solving a real problem and everybody's not confident about that, stop there. Somewhere in there is your biggest risk, and that's gonna warrant discovery work better understanding the problem. Now, that's not exactly a pre-mortem and a pre-mortem.We might have said something like, we solved the wrong problem where nobody even wanted to try the solution. That's what might come out in a pre-mortem. We use that approach to find risks. Now is this stack of questions.

Holly Hester-Reilly:I am fascinated by the things that you just listed. The questions that you listed map so well to the risks that Marty Kagan talks about. That's a central theme that I think comes up a lot in different angles on assumption mapping, pre-motor risk assessments, asking questions, these things.

Jeff Patton:When you say risk assessment to software people, most of the risks that they're so used to when you say risks to project management people remember the difference between a project and a product is projects are successful when you deliver what you said you would on time and under budget, and then good quality.So most people will think of project risks, things that will stop us from delivering on time. And then a lot of the risks that come up are technical risks. Now, those are all wrapped up in one of those questions is, can we build this predictably? And they're in there, but I'm looking for value risks. Are we solving a problem?Do people want it? Can they easily learn how to use it? Will they keep using it? Will they actually get value? And we actually get business impact as a consequence. And I've just found it necessary. Rather than just saying risks, people switch their heads into project mode a lot and most of the risks revolve around.We get back to that other thing we were talking about. Am I gonna make stakeholders happy? Are we gonna be able to deliver this on time? Those risks, cause people are so used to worrying about can we deliver stuff and not used to worrying about are we actually gonna get value from what we built? And so that's why we found it more necessary to be more deliberate about those kinds of

Holly Hester-Reilly:Yeah. That's interesting. And do you do most of your coaching in particular types of companies, or do you have just like a super wide swath?

Jeff Patton:It's a super wide swath right now. It's a super wide swath. Now, this last year I spent a lot of time with airlines, with game companies, with big retailers and banks, and next week I've gotta go to Budapest to work with a. Company that builds software for continuous integration for mobile apps. So everything from very technical development tools to things that are more consumer products, to things that are where one of the hardest things is taking a product mindset and putting it into a company where their primary products aren't tech products.If that makes sense. A bank's primary products are loans and credit cards and bank accounts, and to get them to use product thinking for their mobile apps and websites and for things they build for their own internal use sometimes doesn't compute for them. And so more and more what I'm getting are larger organizations that are trying product thinking all the way down and all the way into their

Holly Hester-Reilly:And what are some of the things that you've seen, what challenges do those types of organizations face when they're trying to bring in that product Thinking?

Jeff Patton:Some of the things we've already talked about, but the biggest one is that one of the things I'll teach is a kind of a decomposition model where we work from outside in and something that comes from the way Kagan teaches as well. But look, if I look at a bank, the products on the outside are things like loans and credit cards and checking accounts.And then we start decomposing that experience to find the products inside. We find customer enabling products like websites and mobile apps and employee enabling products like the things that people use in bank branches and things that they use in call centers. And then we have product enabling apps, product team enabling apps, things that product teams to build things faster, common APIs and services.One of the biggest problems is that cultural recognition that all those things inside our products are also products and we need to manage them. Like products, not projects, not, we build them and they're done kinds of things. It's using product thinking all the way in. That's one of the biggest things.And then, We're dealing with lots of cultural legacy things where it is the service inside of a company and we give it a budget to build specific features, and the budget builds the features and we don't tie teams success to whether those features get used or people are actually getting value from 'em.And the headwinds we're doing is treating things inside the product as products. How we budget for and budget work, the relationships. People and teams have with their stakeholders. That's the thing we talked about before, where stakeholders view technology teams as service providers like kitchen remodelers and teams think it's their job to build what stakeholders ask for, and stakeholders think it's their job to make decisions about what the team should build, and that redefined success as stakeholders happy, not actually people getting

Holly Hester-Reilly:I've seen that inside some of the companies that I work with too, and I think that, I don't know. I feel like the bigger the company gets, the easier it is to fall into that trap. Does that seem true?

Jeff Patton:Oh, absolutely. And one of the things that happens is companies that start off very strong and product-centric, as they grow, they start to lose that they start to become more bureaucratic, and people start to worry more about political safety than product success. And that starts to, those things can get in the way.Yeah. The bigger the company gets, the harder it is to hang onto that, and the more we rely on leaders to make sure we keep moving. Oh, what? There's an old saying that people care about what their leaders care about. I don't know who said it or if I'm paraphrasing it right, but when we get leaders in that are concerned about the wrong things, everybody below them starts to be concerned about the wrong things and everything breaks.The bigger the company gets, the more people we have in leadership, the deeper the leadership hierarchy, the more likely it is

Holly Hester-Reilly:It is, and it's a big complex system. And they change over time and sometimes they'll be really strong for a while and then they get weaker and it's fascinating.

Jeff Patton:Yes. Gosh, I, I spend so much time when I'm speaking and teaching, talking about the right way to do things and how hard it is. I get tired of winging about what's wrong, and so I had to give a talk a year or so ago on what C'S done to successfully move towards a more product-centric way of doing things, and in support of doing that talk.I did a whole bunch of interviews, tried to find people that were successful in moving towards a product-centric culture and what they did or what specific things helped make that change. And it was super, because what emerged out of that is there's not really a right answer. And what emerged out of that is that even when it was successful, there's always a chance of backsliding.And when the right people leave, we backslide, things like that. And so the overarching metaphor I ended up using for this talk I had to give was a Sisyphus rolling, a rock uphill. Metaphor. Look, you've gotta keep constant effort at keeping your focus on the right things. You've gotta keep pushing on that rock.The rock is never gonna get to the top of the hill. And the minute you stop putting effort into making sure that we're thinking about the right things and working the right way, is the minute that rock is gonna roll over and flatten you to, to end on a positive note, I had a Sisyphus visualization and I turned the rock into a beach ball and said, look, if you're gonna be rolling this rock, at least have fun doing it.This is the game we're playing here, and it's the never ending game. It's easier for people to worry about making their boss happy than it is to worry about making their customer happy. As hard as it is to predict how long it's gonna take to build something, it's a lot easier to predict how long it's gonna take to build something than it is to predict if people will use it and like it so people fall back on those easier to do things.

Holly Hester-Reilly:This has been fantastic. I think we're about out of time. So before we go, where can people find you if they want to follow you?

Jeff Patton:And the spirit of the cobbler's children have no shoes kind of thing. You can find me on my mediocre website@jpattonassociates.com. There's uh, things like that there. The thing that I do, thanks to Covid, I now schedule a class monthly. I either anchored around US, European or Australian time zones, so I teach classes that they're public classes in between consulting and coaching and working with companies directly.And it's easy to take a class from me on this. And the classes I teach are Scrum certified product ownership classes, but more than anything, their product thinking, product practice classes, that's what they're focused on. Find me there. And I've gotta do some more writing and hopefully more writing will appear over this year.

Holly Hester-Reilly:Awesome. That would be great. The products world would be happy.

Jeff Patton:I would be happy to.

Holly Hester-Reilly:Yeah. Thanks again. Really enjoyed this conversation.

Jeff Patton:We're really wonderful talking to you.

Holly Hester-Reilly:The Product Science Podcast is brought to you by H two R Product Science. We teach startup founders and product leaders how to use the product science method to discover the strongest product opportunities and lay the foundations for high growth products, teams, and businesses. Learn more at H two R product science.com. Enjoying this episode. Don't forget to subscribe so you don't miss next week's episode. I also encourage you to visit us@productsciencepodcast.com to sign up for more information and resources from me and our guests. If you like the show, a rating and review would be greatly appreciated. Thank you.

‍