Product Management Webinar: Product Development

Janna Bastow: [00:00:00] Hey everybody. Welcome, and come on in!

I’ll just tell you a little bit about this series of webinars that we run here. So it’s a series of webinars that we run, we call them the Product Expert series. It’s always a mixture of presentations or firesides with product experts, people who have insights from their years of product management. And it’s always with a focus on the content and the learning and the sharing. Today will be recorded and shared, so you can always follow along or you can share this with your colleagues afterwards. You can find it on our YouTube channel. And you will have a chance to ask questions as well.

A little bit about ProdPad before we get started.

So ProdPad was a tool that was built by myself and my co-founder. We were product managers ourselves, and we needed tools to do our own jobs. We needed something to help keep track of the experiments we were running in order to hit the business objectives that we were given and in order to solve our customer’s problems, and basically just to keep tabs on all the ideas and feedback that made up  And so building ProdPad gave us control and organization and transparency. And so it wasn’t long before we shared it with other product people around us. And today it’s used by thousands of teams around the world.

So it’s free to try, and we even have a Sandbox mode where you have example product management data, so you can see how things like lean roadmaps, OKRs, experiments and everything else all fits together in a product management space. And our team is made up of product people. So you can start a trial today and then get in touch and let us know your feedback.

We live off this stuff. We really love to hear how you get along with it.

Some things that you might find useful with ProdPad and this pertains to some of the conversations we’re going to be having today is that it’s really an outcome driven tool, right? It’s not just about tracking the things that you might do.

It’s about tracking the things that you have done and what was successful or what was a failure about it, so you can learn from that and track those outcomes as you go. So that’s built into both the ideas workflow section, as well as into the roadmap section of ProdPad. So by all means, dive in, give it a try and let us know how you get on with it.

So on that note, let me introduce our guest for the day. Everybody, this is Jeff. Jeff Patton. And I know Jeff Patton through Mind the Product, which is another company that I’m involved with. I have some fond memories of chatting to Jeff at the speaker dinner a few years ago.

Jeff, you remember that one? We sat down, we had some good chats. I also remember that might’ve been the same year that you were stepping in as a last minute speaker, closing keynote speaker.

Jeff Patton: [00:02:29] I was lucky, someone else wasn’t able to make it!

Janna Bastow: [00:02:31] Yeah, and you absolutely just blew the doors off with a great talk—almost a rant, it was brilliant—you just set the record straight. Agile and product development and all the things that we get wrong with it. So we’re going to be touching on some of that stuff today, I’m sure. So I’m really looking forward to this conversation today. So Jeff, thank you for joining today. Huge, welcome from me and everybody, say hi to Jeff!

Jeff Patton: [00:03:00] There’s going to be a bunch of Hi’s in the chat!

Janna Bastow: [00:03:05] Yeah, absolutely.

Jeff you’ve been a product manager since the beginning of time. And in fact, you were basically right there as agile was being born. Can you share your origin story with us?

Jeff Patton: [00:03:19] I started at a smaller software company in the late 1980s,  I think 89/90, something like that. The smallest software company I started with is now Salesforce Commerce Cloud. It grew and got acquired by somebody else and acquired by somebody else. And it’s funny, my lead developer’s now a VP of Product at Salesforce now, and it started there.

While I was there, I got really frustrated with the way that company did process stuff. And I jumped ship and I went to a startup in San Francisco that was doing this extreme programming stuff. I was a product manager there at that company, but while I was there, the term XP—XP is one of these agile processes the Agile Manifesto was written on. I found out I’m doing an agile process and I was running a product management role in that process. I don’t know though there’s much more to tell, but that’s my origin story or a little bit of my origin story.

Back when I started doing product management, I worked for a company that had no product managers because nobody knew what the job was.

It wasn’t a job. Just somebody had to run the team and decide what we were going to build. And somebody had to take responsibility for whether this crap was working or not.

Janna Bastow: [00:04:25] That’s a great origin story. And my understanding is that you were working with some of the folks who ended up developing the Agile Manifesto, is that right?

Jeff Patton: [00:04:32] Well, in kind of a backwards way. The Agile Manifesto was written while I was there. I happen to be working for one of the very early companies that were doing this. The guy that ran engineering went on to found a company called Pivotal Labs, a guy named Rob Mee, some people here will know who Pivotal Labs is, the company.

And when that startup I was working for imploded, I moved back to Utah. I don’t know if everybody knows that the Agile Manifesto was written at a workshop in the ski resort in Utah.

There were three Agile Manifesto writers that live close by me, I met those people. And then through being noisy and outspoken about, originally user experience things, and then product things in the agile, world over time, I’ve met every single one of them. I wasn’t there when it was written—I was at the 10 year and the 20 year anniversary. But I’ve met every one of those people and had a chance to argue with every single one of them.

And I kind of tend to do that.

Janna Bastow: [00:05:25] Excellent. That’s wonderful. And I’m thinking back to some of the things that I’ve learned from you over the years, and one of the biggest takeaways I’ve ever had from you was how you reframed my thinking about what the customer is, through the lens of Agile. It turns out there’s a lot of nuances with how the term customer has been interpreted and a lot of us had been getting it wrong. Can you help us set the record straight on that?

Jeff Patton: [00:05:48] Yeah, that’s one of the things I did in that talk a long time ago, and it’s a topic I’ve been kind of a broken record about. In the process, Scrum, which everybody knows now, because it won the agile brand war, the role that does the deciding is called the Product Owner.

In extreme programming— XP is where we get things like stories that everybody using an agile process uses, a lot of other concepts like velocity and things like that came from XP. But the role in XP was called The Customer.

So my business card said product manager and my XP role was customer.

And one of the things I’ll rant about a lot is that agile development, and most software development that we use inside of our companies is built around—and we were talking a little bit before this—built around sort of an agency model. If I want to hire an agency to design something for me, to build something for me, I go to them, I give them my requirements and they tell me how long it’s going to take.

And they build it. And the only one they have to worry about satisfying is me, their customer. Now, the stuff they built for me, I have to take out into the market and I have to worry about the outcomes of that stuff. But when you’re the agency, you’re not necessarily accountable for the outcomes.

The people who wrote the Agile Manifesto were mostly engineers, mostly consultants, and when they referred to the customer, they meant the people that hired them. And it was common to refer to the business inside of your organization as “Our Customer” and, still is common. I go to a  lot of organizations and they refer to their businesses as the customer.

 One of the things I’ll rant about is when we slip out of actual product mode and slip into custom service provider mode. Where, when we’re in customer service provider mode, who our customer is shifts, and what a successful outcome for a service provider is, “I love this service and I want to use it again”.

And the service isn’t the product, the service is buying custom development. So I used to think nobody’s focused on outcomes. They are! Just the wrong ones. They’re focused on keeping the service provider customer happy, not the actual customer that’s using their product. 

Janna Bastow: [00:07:52] Right, yeah.

So the big issue being that within companies, you’ve got this tech half—the IT half of the company—who essentially is being treated like an agency, but really we’re all the same team. So why are we treating this like an in-house agency with all the extensive time and cost wastage that comes with that?

Jeff Patton: [00:08:15] Within almost every company, the governance processes we use are built around that kind of agency model.

If I hired an agency to build something for me, I’d want to give them a budget. I’d want to know that they delivered what I asked for within budget and on time. And that’s the way most teams are graded, with the exception of companies that grew up and started as a product company. But even some very successful product companies, the people still feel like what’s more important, is “I finished that roadmap item on time”. Whether it actually helps my company or my product or not is secondary to finishing on time.

That, agency mentality or that “I’m a service provider” mentality baked into the culture of the organism.

Janna Bastow: [00:08:52] Yeah, that makes sense. And that jives with some of the thinking that I’ve had around whether an area of a business is a profit center or a cost center, and therefore how they’re measured.

Product and development and R&D and tech is generally considered a cost center.

The job of the CTO is to keep costs down and to get as much productivity out of that division for as little cost as possible. And so they’ve got ways of measuring it, right? If you’ve got a burn down chart and you are measured by velocity and you’ve got story points to deliver.

These are all ways of measuring your output, but they aren’t outcome focused at all.

Jeff Patton: [00:09:29] Look, when we operate a business, let’s say you’re operating a business. And part of your business is a call center, and you’ve got a staff of people in that call center.

Now I can lower the volume of calls by making my product better. So people don’t have to call, or I can reduce costs by making it more efficient for those people in the call center. But I pay them money to kind of operate my business. They’re not necessarily a leveraged investment. You might try and think of it that way.

If I were to hire super exciting call center people, might get so excited, they want to call my call center more. Okay. That doesn’t work. That’s a bad idea. We try and minimize that cost. It’s an operational cost. But when we’re building software that we sell—if that’s a leveraged investment, and that’s maybe what you mean by a profit center—ideally we’re building this stuff and the better stuff we build, the more customers we acquire. That’s great. It does drive profit. I think there’s some better ways to refer to how we’re doing things, but yeah, anything that company spends money on starts to feel like a cost and people operate IT or anything tech, like a cost center.

Yeah. And I think it’s underpinned with this assumption that at the end of the day, building more features quickly, more story points, faster velocity, therefore more features and more products in general is going to make you a better company.

Janna Bastow: [00:10:50] That’s not necessarily true, right?

Jeff Patton: [00:10:52] Yeah. It’s telling a stock portfolio manager, if you could just buy more stocks faster, you’re going to be a better investor. That’s not the way it works. Buying more stocks faster, doesn’t make you a better stock portfolio manager, and  building more features faster, doesn’t make you a better product manager.

Janna Bastow: [00:11:10] And so is this a particular mindset that companies have? 

Jeff Patton: [00:11:16] Yeah. Where do we unpack that? I think humans are wired for optimism. No one would ever found a startup, if they really, understood the failure rate of tech startups. There’s a lot of risky things that we do, and we are armed with the optimism, the belief that the thing that we’re building really solves a problem and we can build it and people will really see it and try it and use it and love it. And we, armed with that optimism, put things out into the world. The annoying thing is, we’re wrong, an awful lot of the time, and sometimes the safer thing to do is just not check and see if we were right. These fall into what my friend, Melissa Perri, refers to as the Build Trap and we get stuck in this trap of, if we build it, they will come. Or if we build it, we’re going to get an outcome.

And sometimes it’s politically unappealing to actually measure whether we got the outcome or whether we got the benefit from the thing that we built.

I think humans are wired for this and our bias is for optimism and we have to actively fight it, or actively realize, “Okay, this is  fabulous that we’re this way, it’ll cause us to really try and do really great things. But we’re in a world where a lot of the things we try will fail and we have to recognize that optimism got us over the hump to start to do things, but we have to be realists, when we start to evaluate how well they worked.”

And we suck at that as, a species.

Janna Bastow: [00:12:42] That’s actually really interesting.

Jeff Patton: [00:12:43] Hey, I have another rant. I spent all that time ranting about people are using service provider thinking instead of product thinking.

And they fall into trying to say what they’re trying to do, what they said they would do on time and do a good job at it. And I’ll rant that, “Okay that’s the way we’ve been wired from birth.” That’s the way we succeeded in high school and college was, doing things on time and being graded on the quality of our work, not necessarily the outcome. And often what we were doing in school, didn’t get used after that. So we’re used to that now.

So getting people to focus on our product and our outcomes is one thing. Now, the other thing that has happened is, when we finally get people wired to think about a product, but they think of traditional products, packaged products, things that we build and put on a shelf and get used, but right around late 2000s, 2007/2008/2009, what a tech product is, has fundamentally changed. So the field of product management we’re in right now, tech product management, is derived from traditional product management, but traditional products get packaged, put on a shelf and they stay largely unchanged for their lifetime.

Whereas tech must change often throughout their lifetimes. You look at my toaster oven downstairs. I expect it to stay the way it is for years. And it has. But if Spotify stays the same way, it is for years, it will fail or it will get lapped by its competitors. That’s the way it works.

I see people still thinking in a traditional product way, where they conceive of a big product. They launch a big project to build the big product. They launched the big product, and then they wait for money to roll.

But if we’re have tech product thinking, yeah, we launch a small product in a small market.

We iterate it till it’s successful and we grow it over time. When it is successful, we keep iterating it because we’ve got competitors and we keep it alive in the market in perpetuity, by keeping it alive.

So first I get people over the hump to product thinking. Then I have to get them into the 21st century.

And some of them start using 21st century tech product thinking and not traditional product thinking. 

Janna Bastow: [00:14:47] I love that thinking because I think that the term product has been misused in so many cases. And I think the clue is often in the term, like Software-as-a-Service product, which the clue is in the name service like ProdPad, for example, isn’t a product, you don’t get it in a box that you take home. You get access to a login that you can use, and every week it’s updated based on these things. It’s a service.

It just happens to be productized, which is a word us product people have made up, really. And the goal of it as product people is to constantly improve it, otherwise, you will have competitors nipping at your heels. If you don’t improve it, then your market share is going to get squeezed out.

Your competitors are going to catch you up. And you’re always building into uncharted territory, you don’t know what the final thing is going to be. There is no such thing as a final product.

Jeff Patton: [00:15:37] Exactly. Again, if I know what the final product is, and if it’s not succeeding, I build the next model year of the product or the next version and I retire the old version.

Janna Bastow: [00:15:47] And so looping back to what you were saying earlier, fundamentally we’re using software development processes that were developed in the nineties, right?

Jeff Patton: [00:15:57] I told you my agile story. 2000/2001, we were launching big things, or at least we did have the internet, then we could start to do things online then, but it wasn’t nearly as ubiquitous. We’re starting to get there.

Janna Bastow: [00:16:09] It’s a little bit like the business person going to some software house and saying, these are my requirements.

I want to build this product and can you help me build it? And they come back and try to build this thing for you, which great. But it’s going to cost you a lot of money. Remember how much software used to cost to build?

Jeff Patton: [00:16:23] Sort of still does. If you’ve ever worked at a bank or insurance company. It still costs that much.

Janna Bastow: [00:16:29] Thinking about it, software probably does cost that much, but we’ve just absorbed the costs because we’ve just hired all these people in. We all just raise a ton of funding and hire a whole bunch of people. And then we just absorb the costs into our business and just end up spending a lot of money, often building the wrong thing anyways, cause we still treat our team like it’s some external agency. We ask them to build things and they treat us like some customer that they deliver the requirements and then just leave us to it.

Jeff Patton: [00:16:55] Yeah. So, this is also one of the fundamental shifts that sort of came with contemporary tech product development was, again, the realization that we don’t have to do traditional product design, you would do a lot of the initial market research and to do talk to groups of people, put ideas in front of them and finally decide this is our product and get to work and build it all.

You would decide what the requirements were that you could put it in the market. Now we’re in a world where tech products can evolve and change. And this is where all this lean junk comes in and it builds on that agile thinking, of thinking iteratively, but when we add product thinking onto thinking iteratively, now we’re building a product iteratively, but we’re focusing on learning iteratively. Or if we’re focused on getting our product into the market iteratively, learning how it behaves. And we start to use patterns of releasing parts of our product to a subset of our audience and seeing how that behaves and then keeping the stuff that works well.

There’s so many more strategies now, but if you went to Harvard Business School and learned something about product management in the late nineties, early 2000s, there’s so many things now that we do commonly that people didn’t know to do back then it.

Janna Bastow: [00:18:03] It would blow their mind, the kind of stuff that we can do today. You know what still blows my mind is the fact that it’s still a tough pill to swallow for certain people, execs in businesses—it seems to be the larger, the business, the harder it is for them to swallow this pill that we want to work in this lean iterative way, where we’ll stand at the beginning of the quarter and say, we’re not going to tell you what features we’re going to deliver.

And when we’re just going to tell you that we’re going to do a whole bunch of experiments and some will work and some won’t, but we don’t know which ones.

Jeff Patton: [00:18:33] Yeah.  It is interesting. I think I’ve been trying. I would think it was an age thing, but I’m older now than a lot of people I work with.

Where does this bias come from? Why are some people’s heads wired one way or another? There must be a Myers-Brigg style test. It’ll help us detect which way your head is wired and why this is such a hard that some of these concepts just don’t make sense to people.

I would think that over time, things are going to shift, and over time, the way we’re talking and thinking about things 20 years from now, we’re going to laugh about the way we used to do things. Maybe, but I’m usually wrong about predictions though.

Janna Bastow: [00:19:11] I’ve got theories as to what’s going on. Now these are theories, these aren’t tested because I haven’t been on the other flip side where I’ve been the one saying, “No, we’re going to work to the project plan that you came up with last year.” But actually somebody in the chat just pointed this out: not being able to plan or predict in the future can be really uncomfortable for people.

And I think there’s something linked to the incentives that are built into the businesses. A lot of times people in the business have their livelihood hooked up to how well the business performs, they expect to be able to see the business performing in this way.

And so things aren’t delivered in a certain way, they don’t get their Christmas bonus or whatever. 

Jeff Patton: [00:19:53] There’s another rant in there. I’ve been teaching last week and this week. And one of the things that we all will draw this output versus outcome and impact model, and I’ll work hard to make the point that what your business needs is and what your customer needs, that if we’re trying to pay our paychecks and keep the business alive, we kind of worry about the money.

And we got to worry about market share and the quality of brand, and that the business will do what they need to get money. Oftentimes your business will give product people the goal of saying, we need to increase retention, or we need to get more customers into our product.

But one of the things I’ll tell product people is “you can never reach a business goal.” You the only way you reach a business goal is to the only way you solve a business problem is by finding the customer problem that led to the business problem. Yes. Your business needs to increase retention and you can’t go yell at customers and say, stop leaving.

That doesn’t work.

Janna Bastow: [00:20:58] Yeah. That doesn’t work!

Jeff Patton: [00:21:00] Yeah, you can do slippery things by making it super hard for them to leave as a temporary fix.

Janna Bastow: [00:21:06] Dark UX it doesn’t feel good, it doesn’t work. Don’t do it.

Jeff Patton: [00:21:10] If you really want to solve a business problem, you have to set it on the shelf and look at the only way your business makes money is because you’re doing this value exchange thing with your customers.

So you’ve got to take a business problem and figure out what customer problems lead to that because you can’t solve business problems. But you can solve customer problems and that’s what you end up having to tell your business, “We’re working really hard doing these experiments to find these customer problems, so that solving these, will solve the business problems.”

Sometimes, if you’re just focused on solving the business problems, you do crap that hurts your product and hurts your customers. And do some nasty things. There’s ways to make money that aren’t solving customer’s problems. And that happens a lot when people are too focused on solving business problems.

Janna Bastow: [00:21:56] I like that. And did you say that you were going to draw out that outcome impact thing? All of us product people, we talk about outputs and outcomes and impacts and all of these things, but it sometimes helps to just understand what it actually means and looks like and what we should be looking at.

I swear everybody has seen me draw this about a bazillion times. The model I draw over and over, and actually I’m gonna draw it a little different than the model I draw over and over is that we start with ideas and if it was, it could be for a whole new product, but with contemporary product development, we’ve got a product out there and we’re in this continuous improvement cycle, where we’ll add features and enhancements to it. And our job is to turn those ideas into something we can ship. And we know that all that stuff is called scope; that we worry about the time it’s going to take. And we worry about the cost and software is measured in people and how many people we take. And I’ll talk a lot about that triangle.

And when we talk about agile development is rooted in that triangle. If you’re using a Scrum process, you fix the time box and call it a sprint. You fix the cost and call it a team, your Scrum team. And because predicting scope is so hard, you make the team fix it on themselves by doing that sprint planning thing.

And they have to say how much they can get done.

So every sprint in agile development is a fixed time-cost-scope thing. And the other thing that matters that it’s never quite in that triangle is that quality thing, where I’ll tell people you fixed time, cost, and scope, and the quality squeezes out. Looking in Scrum—you demonstrate the product and you evaluate the quality along the way—just live here.

But none of this matters. What matters is what your customers and users do, say, and think and, say look, you released this thing. They need to see it, try it, use it, keep using it and say good things. Yes, this overlays with those traditional metrics like acquisition activation, retention and referral—the same kinds of things, that look, these are all the outcomes.

The outcomes are what your customers and users do and say, not what you do and say. What you do inside your company, that is output you’re focusing on output when you focus on this stuff, but the outcomes out there, and yeah, what we’re asked to do is predict that outcome. And then the thing we were just talking about is: You’ve got a business out here and the business has a job to sustain itself.  It is not your customer’s job to sustain your business. They don’t care about sustaining your business, but you do because you’re spending your business’s money here, and that you want to get paid for it.

Your business needs money to sustain itself. So it’s got to translate all this crap that people are doing into dollars some way. That’s what a business model does. Sometimes it comes from advertising revenue as sometimes it comes from paying licensing fees and things like that. But what your business breeds is money and it needs ROI and it needs a healthy brand and it needs more market share.

So this language system of output, outcome and impact came from the not-for-profit world where we see a problem. Actually I have to go backwards. These things don’t come from thin air. It starts with customers and users and we start with problems. And the other thing I’ll say is unmet needs. Face it, Facebook does not solve a problem, but it may be a compelling need for me to feel more popular or things like that. Yeah, maybe it is a problem, but look, that’s where those ideas come from. I end up calling that part of the stack opportunities and that’s where we harvest those things. And I want people to use some sharp language to separate that.

Now I was saying this language system came from the non-profit world where we perceive the problem in the world. And then we had to figure out something to do it.  If we were trying to get more people to get vaccinated, and we noticed people don’t trust us so we can say, okay, let’s have uh, famous people speak about vaccination and we can have those and say, okay, let’s launch a plan to do that. Famous people speak, and we can pay attention to whether people see what they did and pay attention to it and maybe act on it. But what we’re really concerned about is vaccination rates; that the ultimate impact is, did vaccination rates go up? It’s this flow of there’s stuff we can do,  and we can observe what these people do, but the bigger thing takes longer.

Now I’m pushing the same model into the product and I’m using the word impact, not for social change, but for business benefit. That’s, how I’m using it. 

Yeah, this is really good stuff. And every time I see this, I learn something new. There was something you said around the fact that agile is just tightly tied to that time, scope, cost, quality thing. And that’s, the reality is agile is a project management methodology, right? We talk about it as the end-all and be-all of what we do, but in reality it’s project management. It’s just a specialized way of doing it. And that’s what you’re managing there.

When we’re talking about lean, we’re talking about a wider set of problems to solve for our business and it, as you say, it does tie back to those customer problems. And it comes back to understanding what the customers are asking for what they say, what they think what, they’re actually using and tying that back to what the business needs.

And that’s a much bigger process.

Jeff Patton: [00:28:01] Yeah, yes. Agile development starts with the customer asking for things. And that’s why when you plug it inside of a business, that customer asking for things is your business or teams treat their product manager, product owner, like their customer.

And they worry about satisfying the product owner, product manager. And they forget the fact that if my product manager loves what I just did that does not mean our product is successful. And it doesn’t mean that our business ultimately benefits.

Yup. Yup. So does it irk you as much as it irks me when people say lean-agile, like lean hyphen agile is if it’s one word? I think that was developed as part of the SAFe methodology.

Yeah. There’s a lot of things that irk me. First off in the product world, I think we first started using the word lean in the context of lean user experience. And we’re thinking of an Eric Ries, build, measure, learn loop, or we like we identify risky assumptions and identify, test, and test our ideas and we’ll use that.

But people a lot of people listening here know that the term lean comes from manufacturing. It comes from Toyota and there’s a bucket load of other lean principles that, that matter a lot. So when we say someone, some people say lean-agile, they mean those lean principles that really intersect a lot with agile principles.

But when some product people say lean-agile, they mean while that validated learning loop or this exposing risk and testing things, it is just again, we were talking about what people mean when they say products that we use the same words and mean different things.

The illustration I’m best known for is that, we’re all saying the same thing and mean different things. Let’s just pop it really quick. It’s that thing the we believe we all mean the same thing and we say agile, or we say agile-lean, or when we say product, but we don’t actually mean the same thing.

Janna Bastow: [00:29:59] Yeah. I get that. I get that. And that actually takes me to one of the questions.

Massimiliano asked what makes product development really lean?

Jeff Patton: [00:30:08] I don’t know. It depends on what you mean by lean.

It depends on what you mean by product and what makes product development lean? Yeah, if I were to look at lean principles of people to own their process or own the way that they work to make sure we visualize things and make sure we pay attention to our process and make sure that we look for waste in our processes and things like that.

And agile development is super too, to paying attention to waste. By the way the, waste, the Japanese people pay attention to don’t include just wasted work. They include people working too much or too hard.  Edges into how you feel when you’re at work. That’s considered a waste. If, you’re unhappy, there’s a lot of other ways that we look for.

So they do that, but I don’t think even lean is particularly product centric. Again, the, when we apply that, when we started saying Lean Startup and Lean UX, yeah pulled the word towards that direction. This is a challenge with all words.

They morph over time to mean what we want them to mean. And, lean is evolving too.

I saw somebody in the chat said, yeah, lean is talking about value flow. That’s another thing that kinda gets me sometimes, is we talk about value flow.

Now value flow makes sense. We build lots of products. And most of the new products we build fail. We add lots of features to our product and a great many of them never get used. So how do you really figure out the value flow? I see people saying we’ve got all these things to build and our value flow is to get more of these things through the system.

But the problem is we don’t know which of those things are actually valuable or not. And so sometimes we take the thing that, okay, we’ll just guess and everything is valuable. And then we find out later it’s not.

Really value flow means doing work to figure out which of those things actually are valuable. And that’s where the experimentation comes in. Where it’s like test before you invest, or nail it before you scale it. Or if we really were focused on value flow, we’d do, it’d be doing an awful lot to validate that those things actually are valuable, before we flow them. And yeah, so lean should be about value flow.

But look, if you work in a Toyota manufacturing plant and you got orders for a million Corollas, yeah, getting those things built faster and cheaper is a sure thing. We know that every one of those cars is valuable. But when we’re talking about applying that kind of thinking to in a product world, we do not know.

Again, in a manufacturing plant, they know they have orders for, or demand for, every one of those things that they’re selling. Value is certain. However, in a product world, not so much.

Janna Bastow: [00:33:04] Good answer. I like that. And actually, we’ve got a question here that ties us back to it relating to the actual product world here.

So Richard asked, what advice do you have for a smaller startup on focusing effort? There’s so many things to do, so many things we could do, and just not enough people to do it, tempting to try so many big things. 

Jeff Patton: [00:33:22] I’ll see if I can offer anything, sensible advice. I do have to draw again, but people are probably have seen variations of this with the talk about the growth of a product over time. And I’m paraphrasing a lot and everybody sees a curve that looks like that. And we often chop this cycle into different phases.  Contemporary language for this is explore, exploit, sustain, and retire.

If you’re a startup, you are in pure Explorer mode. This is a pure R&D. You’re trying to get over to exploit mode. You need to find Product/Market Fit. By that, we need to find customers that we’re really are solving a problem, for a class of customers we’re solving the problem for. Not one, because if you solve it for one, that’s a service, that’s not a product, or it’s a service as a product not a product, as a product.

So look, when you’re in Explorer mode, all of your effort is focused on finding a customer, or a class of customers, that really want our solution. And startups go wrong, as they start in exploit mode, now we know we’ve got a product in a market, so we want to sell or grow it into that market.

And then the product will have to evolve as a consequence of that is as we go to the bigger markets and then in sustain mode, that’s where the ROI comes from. That’s where we move wheelbarrows full of cash around. And, yeah. Put more ideas into explore mode, things like that. If you’re a startup, don’t forget your job is to find Product/Market Fit.

Find a customer, find a market that really wants your product. I see a lot of startups—I’ll talk a lot about vision and strategy. If vision is where you want to be five years from now, and strategy is where you want to be this quarter the next quarter This might be controversial, but startups do not have the luxury of having a vision or a strategy.

It doesn’t help a company that has, does not have a product or Product/Market Fit to imagine how awesome their product is going to be five years from now. They don’t know if they’re going to be alive five months from now sometimes. Focus on—narrowly focus on— that one thing. Yes, there are lots of possible ideas if you’re a startup to go back to that question, but your job is to figure out how to try those ideas as quickly and cheaply as possible. Don’t worry about building them to scale. You don’t scale until you hit exploit mode. You don’t scale again, that old mantra of nail it, before you scale it. Most people have that again, back to the optimism thing. They believe they’re optimistic. They believe that this is the idea that works, and we do not want to go waste our money by going back in and rebuilding it to scale.

So let’s scale it before we nail it because we’re so sure we’re right. And yeah, startups run out of resources fast. If they forget that they need to focus on finding a market of—class of customers—with a problem they’re solving, or that really want to buy that product. I don’t know if any of that helps, but there’s no “how can you do more with less,” just don’t don’t focus on building your vision.

Don’t focus on your strategy next quarter, focus on this one thing and get there and prove that you got a product that sells, and then you can worry about all this other business.

Janna Bastow: [00:37:08] That was helpful for me. I really appreciate this and actually keep your drawing out here. Cause I’ve got a couple of questions here that speak to this this life cycle thing.

One) somebody here, she points out that she’s got a competitor who kept copying her. They innovated and added a bunch of things. They spent months of effort on that, but the competitor caught up because obviously they could just copy and spend less effort on that.

So how do you avoid escalation wars? And the other one that we had in was from Peter, who asked about any processes for sunsetting a product. So that retire stage. Is there a best approach. 

Jeff Patton: [00:37:45] One thing to watch out for, with the escalation wars, if your competitors copy your thing…

so first off what is the old saying? That copying is the purest form of flattery or some variations like that. And if your competitors copy you, at least it means they think your idea was pretty good. Go you. The annoying thing is if your competitor has a bigger market, that means that if they copied the idea, more of their customers will see it.

And if they can market better, and you’re the underdog who had the idea at first. But everybody knows that Apple was not first to market with with an MP3 player. Certainly not first to market with a phone and, things like that. Again there’s an old saying that best-to-market trumps first-to-market.

You might’ve even been best to market, but sometimes they’re better at marketing or getting that idea out there. You already have a market share that allows you to push an idea through faster. That’s annoying. The other thing to worry about with escalation wars, is I’ve worked with some organizations that are escalating: our competitor has this, so we have to do this, but they have no evidence that customers actually wanted the thing their competitor built in the first place, or that feature is successful for their competitor. And those escalation wars get weird where customers start asking for features because all these other products have it.

Why don’t you have it? They don’t know if they need it or not.

I don’t know if I’ve got any good advice for that other than man, that’s a slippery slope. And once we start focusing on our competitors, once we start focusing on getting more features out faster, again, we lost the plot. We lost focus on actual customers and actual problems and making sure they actually got a benefit for it.

Don’t, lose the plot there either.

Janna Bastow: [00:39:32] If I can just add something because I saw something in the chat fly by when you were talking about this concept of a product being, not just a product but somebody pointed out that a product has also the customer support and the other services that we add to it.

Remember that a product isn’t just a login to your system, it’s all the support and help, and the system that sort of sits behind it. So you know, your competitors may be able to copy your features side by side, but even if they had all the pixels and all the code, would they still have your business?

Would they still have your product? And the answer should be no.

Jeff Patton: [00:40:06] Yeah, exactly. And again, this is a characteristic again, of more contemporary product thinking. Again, now I’ve got—I love my Breville toaster oven, so I keep pointing at it—and I know their customer service absolutely sucks, and there’s, no—very little infrastructure to support that product. It’s a traditional product.

I recently was working with a large US company that makes faucets—if I said the name, everybody would know it. But look, they’re going into the IOT business. There’s something they sell that attaches in between your shower head that ‘s talking to water flow, it knows what temperature the water is, will talk to a light bulb. A smart light bulb will go the right color when the border is the right temperature for you to step in. It does lots of things. It gives you a lot of data and this is a faucet company and they’re saying, “Oh great. Let’s design the product and let’s get it to market”.

And I say “No, it’s an IOT product. We need a big infrastructure. We need to build an app. The app needs to be updated continuously, and we need to push or phase out to these IOT devices.” And there’s “That’s not what we do. We’re a faucet company”, but the minute you become a tech company, yeah, your experience gets—the kind of experience, the footprint of your experience—it gets a lot bigger and a lot more sophisticated. It really isn’t just the thing where the features of the thing you built, it’s that whole customer’s experience. It’s their ability to get help. It’s their ability to get updates routinely.

It’s a lot of other things. Yeah. All of that’s part of a product experience today. 

Janna Bastow: [00:41:40] I’ve got a tactical question here. So if you’re building products with dual track, so discovery and delivery tracks, do you advise managing two separate backlogs or combining into one? Do you have any tips on dual track?

Jeff Patton: [00:41:58] The dual tracking thing is the—my friend Jeff Gothelf refers to this at the disco and deli thing—where ideas start at the top and we do work to validate them. And then we’d eventually, we validate that we’re building the right thing. And then, we built the thing, and it’s a little bit waterfally and, in practice… in practice, there’s overlap where we, I decided I’m going to build it and we dropped parts of it and then keep going with discovery, keep dropping parts.

So it’s a chaotic, messy thing.

Now, do you maintain two backlogs? This is—the mantra I try and promote is—this is two kinds of work. And traditionally it was waterfall, meaning one kind of team did this work, and hand it off to another kind of team, who did that work. We’re doing more and more to try and pull people that are normally delivery people up here. We use things like a design studio, kinds of work to have them sketch designs. We teach them how to observe interviews and take notes and help them build empathy and help they participate in coming up with ideas. Now the original question is there two backlogs?

I like keeping those backlogs separate. Then my friend, Jeff Gothelf gets ticked off, when I say that. He and I teach together a lot and fight publicly about this a lot. He says, no, there should be one backlog. You’re prioritizing this work along with that work, but they’re very different kinds of work.

The, backlog down here is about building stuff. We estimate how long it’s going to take, well we try and predict how long it’s going to take. And we really focus on doing a good job here. This backlog is about learning stuff and I have no idea how deep it is because I can say, okay, this is the next thing I need to learn.

I don’t know what the thing after that to learn, is until I learned this thing. And so this stuff is it’s unpredictable. It grows, based upon what I learned and just, it behaves so much differently that I don’t end up liking, fixing, I don’t like putting them together now. Cause like I like putting an idea in the backlog and the idea spits out experiments.

And it will spit out an indetermined amount of experiments that are all time box and things like that, but eventually it will get good enough to spit out what’s called these buildable software backlog items. But it can’t spit those out until we really know what we’re building. It could start to spit them out, but yeah.

Okay. Call it one backlog. But I’m going to call these the experiment things and these things, the buildable software things, and they just behave a lot differently.

Janna Bastow: [00:44:47] I love that. So you’ve got two product experts, one who says, combine them one who says, keep them separate. So I guess it depends on what works for you, but Jeff I’m with you on this, I keep them separate for the exact reasons that you just outlined there. They’re different types of work and they serve different purposes, different audiences.

Jeff Patton: [00:45:06] So my friend, Jeff Gothelf, it’s really important to him that, again, this is part the, output fixation for organizations, are so fixated on building and shipping software that they tend to deprioritize this work to do this work. And they tend to be perfectly comfortable building things that are not validated, not tested, that they’re not certain of, because of that optimism bias stuff. So Jeff wants to mix them all together. So it’s crystal clear, we’re prioritizing doing this ahead of doing that, and he wants those things prioritized in the same queue. And that makes perfect sense too.

It’s having him in the same backlog kind of solves a bit of a political problem and make sure that they’re visible to everybody, make sure this work is visible.

Janna Bastow: [00:45:49] Yep. All right. Excellent. And so Pablo had a question that I wanted to clarify that, so you said, so there are two teams that disco and deli?

Jeff Patton: [00:45:57] Yeah. Discovery and delivery.

The short answer is no. The people have specializations. You could say in a typical delivery team, I might have engineers.

And there’s different disciplines. They do work differently. And we commonly now understand them as one. Yeah. And we’ve got a mixed team of engineers and testers, and that’s what it takes to get software built. And then when we talk about designing software, we’ve got product managers, we’ve got UX people, in sophisticated products, we might have a business analyst and yeah, they do different jobs also.

But yeah, saying, oh, that’s gotta be a different team than that team. It’s just like saying, oh, the testers need to be a different team than the engineer team because they do different work. No, this is a product team. Yes. We have different disciplines that do different things, but the minute we start separating them, what we actually end up doing is reverting back to a—Janna, you had the picture— yeah, that one, what I try I do is explain this relationship between a service provider, a service customer that gives their requirements.

And in the blog post I dropped this in, or a lot of times the way I talk about it, I use an example of somebody remodeling your kitchen as a service provider, because we’d start to understand that stuff. The big, important thing about that is when we call the person on the left, the customer, the business.

The people on the right are not responsible for the outcome. They’re responsible for the time, cost, and scope and the on-time delivery of this stuff. It’s not because those other people that figured out what to build, they got to take responsibility about whether they built the right thing. We just got to take responsibility for building it right.

If you separate those concerns, that may make the people in the bottom’s life a little bit easier, simpler, but it’s no longer a team. Suppose you had a football team and he said, these people are responsible for winning the game. These people are just responsible for wandering around on the field and doing stuff.

That wouldn’t be a football team. If everybody would be responsible for winning. And yes, they’ve, we’ve all got a part to play and we all might play different positions on a team and have different specializations. But yeah, we try hard not to make them two teams and we try hard to kind of punch holes in this.

Yeah, people from below have visibility of the work and can participate in the discovery work as much as possible. And if you’re product manager or UX designer, you’re going to get dragged into participating in the delivery work.

You’re going to have to answer tactical questions are going to have to be there. You’re gonna have to make fine grain prioritization decisions. If you’re a UX person, you’re making fine grain design decisions or building assets, things like that. So if you’re up in that discovery team, you’re gonna get dragged down into delivery.

Your job is to drive them up into discovery as much as you can. That’s maybe the short answer. So don’t fall into this trap of this, I call this the service provider model, but the minute you separate the tracks and discovery, you’re slipping into a service provider model where the discovery team comes to the customer, to the delivery

Janna Bastow: [00:48:58] Yeah, that makes a lot of sense. And so I think we have time for one more question, and this might be a bit of a doozy. Somebody asks, are there any tips on changing the mindset of a leadership team, where they just insist on creating a roadmap of outputs and deliver projects? And they said six years ahead, which I think is a bit on the extreme side.

Jeff Patton: [00:49:19] I will give the advice I give everybody and I cannot tell you how well, if it works or not. If you’re in America, you know who Dr. Phil is, and this is the Dr. Phil advice. It’s the, how’s that working for you?

And also I’ve heard my friend, Marty Cagan, say this over and over, take the last, the 5, 10 roadmap items you shipped or got through and ask, did we ship them on time? Are they good quality?

Then you can look at that stuff and then ask, what was the outcome? Did they actually get used? Did they actually achieve the benefit we expected?

And you will see the ratio that everybody sees and that’s that maybe a third of them actually performed as well as we thought. And two-thirds of them not so much. And some of them were dismal failures. So do that, the minute you can expose what the actual outcomes were for things, that’s how you start to—leadership starts to say— oh, we wasted money here.

And we managed to not look at it. We businesses play this trick on themselves. The same trick that magicians play for misdirection. If you’re a magician, you’re trying to pull up a trick. You get people to focus here while you’re doing something else. With this other hand we focused a lot on this costs.

We focused a lot on the impact stuff, and we’ve managed in business to stop focusing on the outcome stuff. Your job is to stop that misdirection and move the focus back up to the outcome stuff. So I will ask teams where everything they ship, talk about what they ship and then pay attention to the outcome and broadcast up to your business. We ship this feature. No one’s using it this month. No one—a month has gone by—no one is still using it or just a few. Few people are using it so far. If we iterated it, it might actually get a good outcome, help your business, see the outcomes and, do that after the fact, by showing them how bad the outcomes were and what they did do, but as you’re shipping, make sure you show them.

Janna Bastow: [00:51:10] Yeah. I think that makes a lot of sense. Proof is in the pudding, right? You show them what happened in the past. I think that’s really good tactical advice, really appreciated. Alright. So everyone you’ve had some really, great questions.

In the meantime, I’d like to thank Jeff. Jeff, thank you so much for coming by. This has been a great chat!

Jeff Patton: [00:51:28] I don’t care about all these other people. It’s just nice to see you and talk to you again.

Janna Bastow: [00:51:34] Yeah, absolutely. Absolutely. Every time I see something from you, every time I chat to you, I learn something really interesting. And hopefully everybody here got the chance to learn some really interesting stuff too.

I’ve been seeing some great comments here. So thank you so much. And take care. Have a great day.

Jeff Patton: [00:51:49] You too. Thank you.