“Digital transformation isn’t, ‘up the IT budgets and sprinkle software in everything.’ It’s organizations waking up to the fact that, ‘hey we are now a technology company. We used to be a bank, and now it’s impossible to be a bank without delivering everything we do over technology.’”
Show Notes
The theme of this week’s Product Thinking Podcast is agile development, and Melissa Perri’s guest this week is Jeff Patton of Jeff Patton & Associates. Jeff is one of the first agile product managers, and his company helps other companies use product and customer- centric thinking to improve their market and the way they work. Jeff and Melissa to discuss agile development in this week’s show, including what’s currently going wrong with it.
Here are some key points you’ll hear Melissa and Jeff talk about in this episode:
How both Jeff and Melissa got into agile development.
The issues agile development was created to mitigate.
How agile development was understood when it was first created.
The difference between agile development now and agile development in the past is understanding what an outcome is. “[Product] outcome is measured by whether the customers and users see you try and use it, and keep using it,” Jeff tells Melissa.
Product development is about prototyping, experimenting, and spending time with customers.
Three things you should never not do in agile development.
Companies are now conducting more business via technology which requires them to become more agile. However, they’re not adopting the agile manifesto in the right way.
Jeff hopes that agile development will morph and become what it needs to be in the future.
Resources Jeff Patton | LinkedIn | Twitter Jeff Patton & Associates
Episode Transcript
Melissa Perri: Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perry.
Melissa Perri: Welcome, Jeff. It's great to have you on the podcast today.
Jeff Patton: I am super happy to be here. You and I have talked a lot. It's nice to talk formally now.
Melissa Perri: I know. I'm excited about this discussion too, because we're going to be talking all about agile development today. And it's something we're both passionate about. And you have been such a resource for me to understand the history and what's going wrong. And I'm so excited that everybody else gets to hear it too.
Jeff Patton: Happy to talk about it.
Melissa Perri: Great. So for the people who don't know you, as well as I know you, can you please introduce yourself?
Jeff Patton: I am Jeff Patton. I am old. Been building software since like 1989. I think it was building websites. And actually even before that, I was doing something. I think my claim to fame is accidentally being first in a lot of places. In the year 2000, I started at a startup that was practicing this cool new process called Extreme Programming.
They'd hired this guy named Kent Beck who wrote this book on it to come in and help the company. And my job title at that company, or at least my business card, said Product Manager. So that makes me one of the first agile product managers. Well, we found out in 2001 that what we were doing was called Agile Development, because the Agile Manifesto was written.
And I learned a lot of stuff about how to do this. I went back to my product management job at the company I used to work for, which is now Salesforce Commerce Cloud today. But back then we were just a small couple of hundred person company. I went back, did this agile stuff, worked for consultancy for a long time and then building on top of agile development for a very long time.
And I'm known for the story mapping stuff. Story mapping for anyone who knows anything about user experience stuff. It's journey mapping, but kind of adapted to help you do planning stuff.
Melissa Perri: Which is a great book.
Jeff Patton: Yeah. Awesome. Also an O'Reilly author. I'm surprised. I read the book and I think, God, was I that smart? I'm surprised.
Melissa Perri: It was a labor of love too, as you know. And I know writing a book is not easy. So that's quite an accomplishment. Stands the test of time too. So I remember we were in Utah last year on our little ski trip.
Jeff Patton: Oh my God, was it last year?
Melissa Perri: Yeah, right before COVID hit. You were like one of the last people I saw, I think before.
Jeff Patton: That's right. It would have been January of 2020.
Melissa Perri: Yeah, before lockdown happened. And then we played a game of how did you meet Jeff? And you were not happy about that. You were like, I hate talking about this stuff. But we did meet at the Mind the Product Conference. And I remember Martin Erickson came over and he was like, oh, have you met Jeff Patton?
And I was like, no. And I'm sitting there going, oh my God, it's like one of my idols. I'm so nervous to meet Jeff. I want to go do that. And we went, I went over and you're eating breakfast and I ate breakfast with you. And you were like, you want to hang out? Do you want to go to a show or something later?
And I was like, sure. We were both in London for two weeks. So that was a pretty great introduction.
Jeff Patton: Since then, I've enjoyed our conversations. It always surprises me that I'm famous anywhere. Never been famous around my own house.
Melissa Perri: Yeah, I was so excited to meet you. And at that time too, I was on this quest to understand Agile. So for me, I had been training all these teams. I talk about this a lot in my book too, but I didn't come to Agile from like a traditional, here's Scrum, go to a Scrum training type thing or organization is just going to learn Scrum world.
Like we were just kind of failing in our team. And one of the guys was like, let's try this thing called Agile and taught us a very loose framework to try to work better together. Like we just weren't communicating. The developers and I weren't getting along. We weren't breaking down our work. We were just having a really big struggle of how to work together.
So then when I ended up in this, kind of more traditional Agile world or the Agile manifesto world that we know, I was really shocked when I went to these organizations to teach them product management. And then everybody kept arguing with me that that was not in their job as a product owner. Like they learn this thing about Agile and the product owners manage the backlogs and then they manage the developers and then they ship everything and they monitor it and then they iterate on it.
And half the time they didn't iterate either, which I always thought was interesting. But I kept going, everybody kept telling me, you're wrong, Melissa. Like this is not what product management is. This is how they describe it in Agile. So I went on this whole quest to talk to people who knew Agile and who were there when it was being developed to understand like where this came from.
And that's why I got really excited to talk to you because I was like, how did we get here? Right, like how did it end up like this? I don't see people doing great product management. And that's why I wanted to talk to you about today because like you saw it from the beginning, right? Like you were early in the Agile phase.
So what did it look like then?
Jeff Patton: I think the thing to take into account is some people have never been here when we talk about the product thinking and what we mean by product organization. And that's where Agile development came from was someplace where there wasn't product thinking. First off, it took me years to understand even what that was or what that felt like and see if I can explain it.
I started at a small product company in the late 1980s. I was always in a product company, was always in a product company up until about 2005. By product company, I mean, we built and sold software as a product. The thing that we sold was what made our company money. And we knew that we were successful, not when things were finished on time or not when we delivered more software faster.
We were successful when we were successful, but when we sold more of the stuff and our customers were happy, we knew that. It wasn't until I started working at a workshop consultancy called SpotWorks for a long time. It wasn't until I got there and started working with really large hospital groups, banks, insurance companies that I saw people didn't, people were not product-centric.
Now, so if I rewind back, Agile development for me, when I first found it was freaking awesome because I already had my product head screwed on straight. I already knew what mattered. And Agile development gave me kind of a night working in short cycles and predicting in short cycles makes us a lot more reliable, pushing the collaboration in, making sure that we are collaborating as a team more often.
All of that stuff was awesome. It made things better. But I didn't start feeling the tension that you were describing until I started going into what felt like kind of traditional IT places. Yeah.
Melissa Perri: So what were those IT places like and what were they doing differently than what you were doing originally?
Jeff Patton: So let me tell you this is, somebody may have already heard me deliver talks about this before, but I'll start a talk by asking what makes a product great. And people will say all kinds of things like it's easy to use, it's fun, it solves a problem, it makes money for a company, all kinds of things like that. And I'll point out, I'll write a bunch of things down.
I'll point out to people that nobody said finished on time because nobody says I love this product because it was finished on time. And I'll point out that all the things you're describing are outcomes. These are things that happen after the software comes out. They're not what you did, they're what your customers and users did.
And I'll say what they do say and think. That's where the outcomes come from. Then I'll change the subject. And I'll say, look, there's another kind of product you should be aware of. I'll use whatever's going on in my house. Lately, I've had somebody, a landscaper, redoing landscaping in my backyard in Park City where I live.
And I said, well, if you're gonna hire a landscaper, what makes a landscaper great? And they will say things like they're a good communicator, they've got a good reputation, they can translate my needs into a better vision than I could. They show up, they're cost effective, and they finish on time. And then when I look at those two things, I'll say, which are your teams evaluated based on?
And they'll quickly say, well, we're not evaluated on any of these product qualities. We're like landscapers, we do that. Landscaping is a business, it's a product. But the product is selling custom work. And what the anti-pattern baked into most organizations is that we use IT as a custom development shop inside our organization.
The business is the customer, and IT is the vendor, more or less. And everything that IT is asked to do is custom, like my landscaping in my backyard. And the traditional processes tend to evaluate success based upon custom development success. All those things I said, finishing on time, being good communicators, things like that.
And you have to be aware that that's the place that Agile development was written from. That the people who wrote Agile development were trying to clean up this nasty kind of tension between the business organization and IT. My friend Alastair Coburn, which was a local, one of the manifesto signers and was a local person, said that, yeah, Agile was written to deal with hostile work environments.
And it solved a lot of problems, but it is not based around a technology product model. It's based around a service product model, not service like a Spotify or bank account, but service like a custom development service account. And that's why it's not important to know what the customer wants. If you go back and reread the Agile manifesto, and stop me if I'm droning on too long here, one of the big value things is customer collaboration over contract negotiation.
That's exactly the kind of thing I want out of my landscaper. It's definitely not the thing I expect out of Spotify or Atlassian. I don't expect that. I'm not collaborating with Atlassian for anything. I'd want to buy the product I wanted to work. If you look at Agile principles, very first one is-
Melissa Perri: I got it. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. You know, the seventh principle?
Jeff Patton: You have that? Well, now I got to go count.
Melissa Perri: Ready? One, two, three, four, five, six, seven. Working software is a primary measure of progress. Yup.
Jeff Patton: Doesn't that sound like it's written from somebody whose business is building software for customers?
Melissa Perri: Yes, it does.
Jeff Patton: It doesn't sound like somebody whose business is to build a software product and where the outcomes are product success, not continuous delivery of working software. Nobody says, I love Spotify because they continuously deliver more features or more working software. That again, that's not product success.
It is service provider success. It is specifically custom development service. So that's the mindset that Agile comes with. That's why it, you know, when you look at the process that my, when you look at the process that my landscaper goes through, we discuss things, we agree on requirements. He gives me an estimate.
We negotiate over that estimate and jostle around. I'm focused on trying to get as much as I can for my money. We finally agree. He does the work. He focuses on time, cost, and scope. There's predictable problems arise. We renegotiate and change estimates. And then he finally gives back a delivery. That flow of requirements to delivery, that's a project management flow.
That's the customer experience for a service product provider. But we think of it as our process, but it's, yeah, that's, look, if you were saying, look, I want to start a business remodeling kitchens and you were to map the journey of your customer's experience, it's going to look like that. Yeah. And that's what Agile development is optimized for.
I think I lost the plot.
Melissa Perri: No, I think that's totally true. I remember when you told me that, like my mind was blown. I was like, yes, that makes a whole lot more sense now. And I had never heard before that most of the people who wrote the Agile manifesto were, one, developers, which I think is interesting that we should get into. And two, they're all working for larger companies in the IT organization. And I was like, that-
Jeff Patton: Most of them were consultants. Most of them really were hired to build software. So when they say the customer, they really was their customer. They were really hard hired by a bank or a big insurance company. And yeah, they were trying to service that customer. It really was their customer. So whenever you see customer user in the business and the manifesto, again, it's from the perspective of being on the service provider side of that model.
Melissa Perri: I think it's so funny because I've said that in a couple of my talks and I've gotten so much hate from it. I've had some people be like, no, it's not. That's not what they mean. And I was like, did you talk to the people who wrote this? Cause I did. It is freaking so what they meant.
Jeff Patton: Yeah, thank you. I've met every single one of them over time. Talked, you know, the local manifesto was written in Utah where I'm from, partly because two of the signatories of the manifesto were Jim Heisman and Alistair Coburn and they had to plan a workshop. So Jim and Alistair said, let's do it here.
And that's it. That's why it's here. But they were close by and do you know the name Ward Cunningham? Yeah. Yeah. So I was working at the years ago at the company in Portland where Ward at the time was the CTO. And he had brought me into focus on this product stuff. Ward was super clear that what you're doing is not agile development.
It's past that. It's something more. And I had a lot of back and forth with Ward. I said, should we give it a name? Is it something different? And he said, well, I don't think it's quite ready for a name. It hasn't baked quite yet. That's what Ward said years ago. But look again, as one of the creators of the manifesto, he was clear.
This is not what we're talking about here is not what agile development was. That's really interesting.
Melissa Perri: So yeah, I've heard you use the term post-agile a couple of times about that. I don't know if you really like that word or not, but.
Jeff Patton: And if it catches on, I like.
Melissa Perri: Yeah. You're like, I'll bring that.
Jeff Patton: That's how I'm known for story mapping because the term caught on. Yeah.
Melissa Perri: So what did Ward mean when he was talking about what was not agile development? What were the characters of what you were doing or what people do now that's not what he meant by agile development?
Jeff Patton: I spent a lot of time pondering that. I can't say that Ward was able to clearly articulate it other than that this was something different. There's a long backstory behind Ward and Lean UX. Ward. Interesting. Come about. So that's another history story I could tell you too. But look, I've focused in.
The big difference for me is understanding what a product outcome is. And again, outcomes aren't measured by customers saying, I give my approval, that's great. Or stakeholders saying that. Outcome is measured by where the customer's users see it, try it, use it, keep using it, and say good things. Or acquisition, activation, retention, referral.
Those are the more syllables way to say that. We measure those kinds of outcomes. If that's missing, any recognition of that, any discussion of that is missing in agile development. And then the acknowledgement that predicting what your customers want and will do is hard. Again, we're not in a service environment.
We can't just ask them what you want and give them what they want. My landscaper can do that with me. Incidentally, my landscaper, if I put crap in my backyard that I never use, it's not my landscaper's problem. It's my problem. Because I'm the one that said I wanted it. Now, if we acknowledge that we can't predict our users' behavior, then we start to realize that building potentially sippable software, working software, isn't our highest priority.
It's figuring out what people actually want. That causes discovery work to be part of your process. This work we do to understand our customers, to prototype and test possible solutions and things like that. Those are the big things that are missing out of agile development is recognition of outcomes and recognition that outcomes are not certain and doing discovery work.
Melissa Perri: Yeah, and that seems more like what we talk about in product and UX work is how do we make sure that we are oriented towards outcomes for the customers? How do we make sure they're gonna actually use it? And that does get completely left out though in all of the agile training that I've seen. And I think people are weaving it in now and your training is very good, I've seen it.
But how did we get then to this product owner role, where we go through this Scrum training, which is transactional managed backlog and then start working with developers to ship software repeatedly? How did product morph into that, into this world? How did agile and the manifesto morph into that?
Jeff Patton: First off, the word product is in Neanderthal manifesto. The product owner, actually, I told you, I started with this process called extreme programming. My business card said product manager, but in XP, I was called the customer. Again, it's a huge step. I was the customer. In XP, we would call this the customer role.
But Scrum called this the product owner role. So I have a hunch, I have a belief that this is where it came from. That's one more history lesson here. You know where Scrum got its name? Could you ever, anybody have? No. I'll help you on that. There is an old Harvard Business Review article written in 1986 by two Japanese authors, Takiuchi and Nonaka.
I'm sure I'm mispronouncing some of those, couple of those, both those Japanese names. The paper was written in 1986 and the paper was called the New New Product Development Gang. Now, they were talking about new product development, which in 1980, what the paper is about is cars, cameras, computers, printers, fax machines, stuff like that.
Things that are hardware products. And the paper points out that people working on new product development, that's what they meant, developing a new camera, work together. The most effective teams work together in cross-functional teams. All the phases overlap. The teams are self-organizing. And they said, and they explained that the most effective teams work in this way that looks very chaotic from the outside, but inside, there's some order to it.
And they said, it's a lot more like the sport of rugby, where we're trying to move the ball down the field together. It's not like baseball where everybody has their position or a clear role in responsibility. It's more of a mess. Yes, there are roles and responsibilities on a sports team, but they're not, they're fluid.
They change in the moment. And we know what winning the game means. It's at one point in this paper that there's a little section called moving the scrum downfield. And this is where scrum, as a process gets its name. But I believe this is where scrum borrows the idea of product and product building also.
The irony about that paper, if you read it closely, is it is all about product discovery. Because you do not develop a camera by saying, I'm gonna build a backlog and every two weeks I'm gonna build part of a potentially shippable camera. No, that's not the way it works. That's nuts. It's about prototyping and experimenting and spending time with customers.
And if you highlight the property of that paper, you're gonna find it's about discovery. That's what it's about. That's what product development actually is. So, anyway, so why product owner? I think it's because that paper exists. Because Ken Schaver and Jeff Sutherland that created scrum wanted to acknowledge there's a product that actually, again, if you don't really separate that idea of IT as a service from building products, you get confused about what your product is.
And if those people called product owners think their product is a service, well, maybe they're doing the right thing. When you're doing IT as a service and the service is the product, it looks a lot more like project management. So, not surprising that it is. That's it. So that's what you see.
Melissa Perri: Yeah, that's really interesting. That's where the product owner came from. So then how did all these companies start to expect that product owner is the role of product management? And like, what are they doing wrong there?
Jeff Patton: It's a good name. It makes it sound like, hey, we have products and there's someone that will take responsibility for it. So that sounds like a good name. I've heard a lot of big successful companies use that term. A lot of companies that are very product-centric use that term. It's just that the problem isn't with the term or the role name.
The problem is what the organization recognizes as its product or as its products. It's how the organization views IT. Do they view IT as a service or do they view IT as the people who build the products that they sell? Does IT or does the business view themselves as a customer or do they view themselves as a partner?
We're co-creators. We work together. Don't see that as a problem in companies that build software for a living. You do see that. Well, you don't see that as a problem in a lot of companies that build software for a living, but not all of them. And you definitely see that as a huge problem in any company where software isn't their primary product or isn't their end product.
Does that make sense?
Melissa Perri: Yeah, that does make sense. Yeah, I do see it mostly in the larger enterprises that I've worked with, ones that, as you said, were the IT departments were common and now they're like, oh, we want to start to be more product-centric. We want to be more user-centric. We're going to create a software department that's a little bit more connected, but I see them gravitate towards Agile probably because it's just as comfortable for them as the IT was because it's all project-related.
Jeff Patton: And it does push it. There's the foundation that we get from: Agile is working in short cycles, stopping and measuring and reflecting. And there is absolutely: do not ever, don't not break down your work into small pieces. Don't not stop and reflect. Don't not measure. Don't, of course, it's a good idea to stand up and plan and replan every day.
There's nothing wrong. It's just this weird posture that's taken Agile development. And so we have to overlay some other principles on top of it. So one of the things I got asked to do by a company is: I do this complain thing a lot. And one of the companies I work with asked me to put my money where my mouth is and said, you know, I'll say the problem with Agile training is people take this and then we have to come back in and fix it, change what people think.
And I said, well, we've got people that need to be trained on Agile development. What would it look like if we trained it in a way that we didn't have to go back in and fix it? Which alerted me to the fact that I'm better at complaining than I am solving problems. But I have put together a class that actually works.
A class that has all that core Agile development stuff, all the stuff that's good about Agile development, but then overlays the acknowledgement of what an outcome actually is, acknowledgement of who our customers and leaders actually are, and acknowledgement that in a sprint you might have discovery work and delivery work, or that thing that gets called dual track development, where we're doing discovery and delivering the same thing. One of the exercises, the first day of the class, I want them to understand the Agile foundation. Second day of the class.
And it's a post-COVID class, it's drawn out over several days. The second day of the class we'll talk about product centricity and then I will have them pick up the manifesto again, because we use it the first day and then red line it. Tell me all the values and principles that no longer make sense to you now that you understand what a product is.
Now I'm surprised how many things people say, no, that's not quite right. That's my aspiration with the classes. People come out of it saying, okay, Agile is all that, or at least not originally all that.
Melissa Perri: Yeah, what do you think are the biggest ones in the Agile manifesto that they typically say, no, this isn't relevant to us anymore?
Jeff Patton: Yeah, well, the three that we just talked about, the customer collaboration over contract negotiation, the highest priority is to deliver working software continuously, I will work in software continuously, that working software is the primary measure of progress, neither the product growth outcomes are the primary measure of product progress. There are things like business people and IT working together every day that starts to get questionable. One of the things I'm sure you worry about is this us and them language that springs up.
Yeah, I bristle when people say the business and I tell them, now how can you just say our business? Say our business and then see how that sentence comes back out. See how it takes the themness out of that. So yeah, those are the big ones, but I was surprised at how many, I almost need to pull back the exercise in the mural board that I have and see which ones they put dots on, but I can't see the others, I'm looking at the thing here.
Melissa Perri: Yeah, those are good ones, those always felt a little weird to me, it's just like we're gonna measure success by working software. And that's what I just saw, I see so many organizations learn Agile, they go through their product owner training, everybody is like put into their place, it's usually a lot of people who've never done product management before, a lot of leaders put into like, oversee the product managers who've never done product before and then they just start shipping a bunch of stuff and it never stops. Right? It just keeps going.
Jeff Patton: And it makes perfect sense why they do, it's the first principle, that's what you're supposed to do.
Melissa Perri: It's what they teach them, yeah.
Jeff Patton: Yeah, that's what they teach them. There's nowhere in the manifesto that said we should stop and actually measure the outcomes, there's nowhere in the manifesto that says we should expose risk and create tests to test our ideas before investing in shippable software, not in there.
Melissa Perri: Yeah, so why do you think this became so big, right? Like how did all these organizations start gravitating towards Agile and be like this is the thing that's gonna solve all of our problems?
Jeff Patton: Because most organizations really do use that, IT as a service, what I refer to as an anti-pattern and because Agile is a hell of a lot better than what we were doing before. It is an awesome solution to a big problem that most organizations have. Now, give me one more. We, you and I talk about products a lot, but we don't really talk about products.
I mean, we talk about technology products and we don't really talk about technology products. We talk about 21st century, but post 2005 to 2008 technology products because back in the good old days, software products were put into boxes and they were shipped on floppies and CDs and DVDs and you took it home and you installed it and if it didn't work, there was no freaking internet to download a patch. There was no way to continuously upgrade it.
It had to be right out of the box. That's the way a toaster oven has to be. That's the way a refrigerator has to be. That's the way toothpaste has to be. Those are traditional products. Posts, post iPhone, post ubiquitous internet, post internet of things, post everybody has multiple computers on their wrists, in their pockets and things like that.
Those are products that continuously change and evolve. If, look, I have a toaster oven and it's been the same way for the, if I bought a brand new one today, it would look exactly like the one I bought six years ago, but if Spotify looked the same way today as it did six years ago, that would be a problem. If any contemporary technology product looked the same as it did a year ago, that starts to be a problem.
It starts to smell like they're just not keeping up. Traditional products have that traditional cycle of, they say explore, exploit, sustain, retire, but the goal, a technology product can be in sustain mode almost indefinitely because it continuously changes. That we can keep it alive by continuously evolving it.
So when we talk about product management, that's the kind of product management we're talking about. It's not the same one that you would learn. Look, you teach for Harvard Business School and they teach more traditional product management there. Does, well, I should be asking you this. Do you have to help make that distinction between what we're talking about?
Melissa Perri: Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past seven years, I've been working with individuals, teams, and companies to upscale their product chops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma.
Visit productinstitute.com and learn to think like a great product manager. Use code THINKING to save $200 at checkout on our premier course, Product Management Foundations. Now, I think they've come to realize that those are not the things that we typically manage today. So most of Harvard's curriculum, which is great, is more towards SaaS-based startups, but we do have some physical goods.
There are definitely people, there was somebody in my class who just did, for example, like a women's custom fashion brand where she was making custom blazers for people. So she's got to do the whole, she's got to manage the actual product and then she's got to manage her actual software product to sell that thing.
Jeff Patton: Yeah, exactly. She's going to find the software product changes continuously, changes a lot faster than the blazer she's designed.
Melissa Perri: Oh, for sure. Yeah, she saw that during the semester.
Jeff Patton: Out of curiosity, how often does she redesign those blazers?
Melissa Perri: She did a big upfront design process, testing it out, seeing what was happening, and that she's partnered with a manufacturing place to put it out there. So I think she's got some samples coming in now, which she's going to test with more users and see how that goes before she launches everything. She's not going to try and iterate the blazer or something in the market. I don't know. It's a good question. Our class is really focused on the software part of that. So I don't know much about what she's got in store for the product part, the actual blazer part of it.
Jeff Patton: It'll be interesting to see. There was, when we talk about clothing, there was a movement to, gosh, I worked with Nike many years ago. And for the clothing people, the development cycle for clothing is, I believe, 18 months. Meaning, this summer I'm working on design for clothing that will be for winter season next year.
Not this year's winter, but the next year's winter. So it's a long cycle to get things done. But they were trying to say, okay, how can we reduce the cycle time of this? How can we go from idea to something that gets into stores in months, not 18 months, not over a year? The reason I'm kind of going to this is software product management learned from traditional product management.
And now software product management is informing traditional product management.
Melissa Perri: Yeah, that makes sense.
Jeff Patton: Faster cycles and things like that is part of it. So I think if I were to answer, why are you and I in business right now? It's because of that stupid digital transformation thing. Digital transformation isn't up the IT budgets and sprinkle software and everything. Digital transformation is organizations waking up to the fact that, hey, we are now a technology company.
We used to be a bank, but now it's impossible to be a bank without delivering everything we do over technology. That's impossible to be a bank, insurance company, retailer, any of these traditional organizations where their end products were things like a retail experience or an insurance policy or a banking account are waking up to the fact that we are technology companies now and this way of working has to kind of can feed forward into our products and we have to work this way to make successful products inside.
Melissa Perri: Yeah, and that's what makes me so scared about the way that larger enterprises are adopting the Agile manifesto and Agile, right? You see it everywhere now where it's like, we're going to be an Agile company. We're going to have Agile HR. We're going to have Agile like everything. And I never see them.
I do so many, just like you, like I do so many trainings with leadership and with product managers in these larger companies and never once have they approached me and said, we are trying to reevaluate our entire product strategy across the organization and figure out how do we integrate technology into our products? Instead, it's always, how do I train all these product owners down here to manage a backlog better, right? It's never, how do we take these existing products like the credit card and figure out how to make it more of a technology product, right?
Like how do we integrate technology into that concept and how do we change our strategy with technology?
Jeff Patton: I need to tell a credit card story. You travel a lot. Like I do, you had situations where your credit card got stolen or your credit card was used fraudulently and the credit card company calls you and says something's wrong here. And then they cancel your card and they send you a new one. With my Apple card, this happened to me two days ago.
First, I get text messages right away and see it pop up on the notifications on my phone that these two charges came through. Did you do these charges? They go, oh, I did not do these charges. And so they immediately shut it down. I call them up and they say, do you wanna reissue the card? And I'm thinking, I don't wanna reissue it because I don't wanna be without a card for a while.
They said, no, we're just gonna change the number on the card. There's no number on your Apple credit field.
Melissa Perri: Oh, I didn't know that. I don't have an Apple card, yeah.
Jeff Patton: I'm gonna put it up so people will listen.
Melissa Perri: Oh, cool.
Jeff Patton: Yeah, there's no number on it. And that's the back of the card. There's no number on it. And look, if you're a credit card company, you say, hey, what would it be like if we were a technology company? Why do we need those numbers? They use the chip anyway. Wow. We can associate that chip with any number. And so they just changed the number. And my credit card never stopped working. That's amazing.
Melissa Perri: It is for me.
Jeff Patton: And again, that's what happens when a traditional product company starts thinking like a technology product company. And to your point, organizations are coming to you and saying, how can we recognize what products are or can be technology products? How can that affect our product strategy? Yeah. For Apple, it certainly affected their product strategy.
Melissa Perri: Yeah, that's amazing. You do see these products coming out of larger companies, Google, Apple, right? Ones that started as a product company just kind of blow things out of the water. And I always think it's fascinating too because you don't go to Google and they're all like, oh, we do Scrum. Nobody at Google and Apple does Scrum. Like I'm sure maybe some teams have adopted it in a loose way, but.
Jeff Patton: They do. And they will say, but they realized that point. And then again, if I go back to my origin story, yeah, I used all that agile stuff. But I knew the purpose. What we're doing here is creating products. I never once, I just was thinking, okay, agile development is for the development part. It isn't for the whole product part. So I just, I learned agile development and sped up delivery. It wasn't all that. It wasn't everything. And maybe the way it is at Google too, they're gonna let it go. They don't forget they're building products.
Melissa Perri: Yeah, and that's how I learned it too. Like I had learned like a very traditional waterfall method of product management. And then I learned agile. And you know, I did have to sit there and like think through requirements, but I had to think through the persona. I had to build those like MRDs and those PRDs.
And it made me really go through what are we building and why, right? Before I got into the logistics of actually writing out those spec docs and handing them over to the engineers. And albeit not the best way to work, but like I didn't lose that whole discovery process when we started to move towards Scrum, right?
In the startup that I went to. Instead, I just got better at chunking things down into smaller pieces, releasing them, testing them, and then, you know, using that to inform and iterate. Like I got better at doing smaller things, but still keeping that higher level view of the product vision of where we were going.
And that's nothing bad about that.
Jeff Patton: That's awesome. And the idea of working in smaller things. Again, a few years ago, I used to kind of give a talk that we don't invent processes. Our products force us to change our process. The fact that technology can change so quickly has forced us to use processes that allow for us to change quickly. And that old research or that MRD research, PRD, the process doesn't work anymore, not with contemporary technology products. So it's the process we have to use today for technology products change because the technology underneath them change. If we were still shipping CDs in boxes, maybe that process would still work.
Melissa Perri: Yeah, that makes sense. I worked for a company, actually, like two years ago, a client, that actually did ship things on CDs still because they hadn't figured out how to migrate it over into the SaaS-based environment yet. And they had a whole room in their basement that was just a CD printer where they were like burning CDs and shipping them out to customers still. And I was like, wow.
Jeff Patton: What I see is that, go back to, I was telling you, I'll ask people what makes a product great, and they say all these things. And then later, one of the other tricks I'll do is later also, let's talk about all these technology products, what makes them different, these current technology products and what makes them great. And then we start adding to that list.
It updates, it changes frequently, it adapts to my need. We look at all those things that motivate or make a traditional product, technology product, better. Those are things you couldn't get before. It's the changes in technology that afford it. And the company we were just talking about, if they have competitors, especially a competitor that starts today, a competitor is not gonna start by printing and saying, cow, we gotta have a place in the basement to print CDs.
Definitely not. And they're gonna end up with a product company that can iterate and respond to change a lot faster. Responding to change, that's a great agile principle. It's a great value out of the agile manifesto. Nothing wrong with that. And that's what we expect out of products today, is to respond to changes in the world or the market.
Melissa Perri: Yeah, I think that one has always resonated with me a little bit more than some of the other stuff on here. What's next, right? What should organizations, they looked at agile, like what should they be doing? What should they be striving for?
Jeff Patton: One thing we were talking about agile, let me give a, because I know I'm old enough, like when I was just starting out about this, just starting with this stuff, I would get a lot of hate for controversial things I used to say. Now I say the same stuff, but I'm old. So people think, he must be wise.
My beard went gray, it used to be red. Anyway, all that make things different. But I'm sure that a lot of people are thinking, hey, but thinking of things like, he's kind of slamming this agile stuff. But one of the things I'm also thinking to realize is when people say agile, they mean something different today than they did in 2001.
First the world wasn't, in 2001 we were still shipping CDs. That's the way it was. There was barely internet and barely decent internet back then. I hear people saying agile development and they are really thinking of outcomes. They really are thinking of discovery work. They really are thinking of lots of good things in there.
And they really couldn't read or cite the manifesto to you because it's come to mean something else. Look, a long time ago, Christianity meant the inquisition and it does not today. So I struggle with it when you say, what's next? I don't know. For years I said, we've just got to scrub this term agile.
It doesn't mean what you think it means. We need more, we need something else. But one of the things I'm starting to notice is the definition of what we mean by this is changing underneath us. It just, for the people who have evolved their definition, it doesn't mean what the manifesto says anymore.
And I think what's next is that nobody wants to revise the manifesto issue amendments or something like that. I don't know. But I think what's next is agile, the definition of agile. Look, it's a sticky brand. And product thinking doesn't, product management doesn't have a sticky brand. I think what's next is the agile development is hopefully gonna morph and get a little bit more sane.
Melissa Perri: Yeah, I worry that agile has changed, but are we doing the same processes and the same practices, right? Like with all of these different trainings and stuff, as we were back then. And that feels like that hasn't changed. Like, it feels like we try to change it. We try to add things on it, but we always start from a place that was, this is what we did in 2001 and this is what we'll continue to teach. And then we go, oh, we need that other stuff too.
Jeff Patton: Yeah, interesting. Yeah, I don't know. That's got to change. They'll keep you informed if I start, I'm teaching this class for a big company in Australia. I taught a first pilot class a couple of weeks ago. I'll teach another one next week. What I'm striving for is teaching something that is what agile development should have been.
Cool, but not, excuse me, maybe not what it should have been in 2001, because maybe it was what it needed to be back then, but what it should be now. But I think we're a long way from that. I think for me, it boils down to the people still have an IT as a service provider mindset. And even when they start to get a product mindset, they still have a 20th century product mindset, not a 21st century product mindset.
Yeah.
Melissa Perri: A couple shifts here that need to happen.
Jeff Patton: Yeah, there's a lot. For the term paradigm shift before. Yeah. Yeah, that term, somebody will correct me if I'm wrong, comes from a book called The History of Scientific Revolution by Gainey Kuhn. And one of the quotes from that book that always comes to mind is that change travels in a hearse. What he means by that is sometimes change doesn't happen until the old guard dies.
It's morbid, but it makes sense. Sometimes it is just for people to have a different paradigm in their head. It's just hard to unstick that. Hard to unstick that IT should be a service. You work with CIOs and even CIOs and companies who believe, yeah, we're here to do a service. We build what they say, efficient.
So that mentality's gotta change. And then people have to adapt to what a product is today, what it was in 1995.
Melissa Perri: Yeah, that makes sense. That's why lately I've been trying to shift the way that I work too, to kind of train future leaders of product companies because I think those are the ones that are gonna have the most impact on the world in the future. And that's why I started CPO Accelerator because I just looked at, there's so many executives out there, there's so many current CPOs who are not really CPOs with that title.
There's not enough really good CPOs in the world. And I'm like, if we're gonna have a chance to work the way that we're describing, I think we need leaders in those positions who actually get it. They understand what product thinking is. They understand how to build 21st century products. All that to me, it starts at the top.
It starts with people. And I don't think if people change, anything is gonna change.
Jeff Patton: Trying to, the way you're talking, I just couldn't. I had to try and remember the lyrics to this, there's the children are the future. So I was ready to start playing that while you're talking.
Melissa Perri: Yeah, it's up to when we're training people coming into this, we can train them with a different mindset. If they come into companies expecting different things, if a typical MBA comes out of Harvard Business School, recognizing that there's a different way we work with products today, that'll be a good thing. That's my job. That's what I'm trying to do. Do that. I'm trying. Yeah, that's my mission there. So that's awesome.
Melissa Perri: Well, thank you so much, Jeff, for being on the podcast. This has been really enlightening. I hope everybody is listening, understands Agile a little bit more. If people wanna follow your work, can they connect with you? What can they read?
Jeff Patton: I have fallen off, fallen out of the habit of writing very much, but you should go to, my website is, look, Google Jeff Patton, but the full website is jpattenassociates.com. Look, I teach classes routinely. There's a schedule there. And one of these days, I will start writing again routinely. It will be on that website, but I just have to clear away some cobwebs in my head. Yeah, there's so much piled up that I've gotta write about. Yeah, that's where.
Melissa Perri: Well, I hope you get a chance to do that soon. Thanks so much.
Jeff Patton: All right, thank you.
