The Mindset That Kills Product Thinking

My friend Marty Cagan released two articles, this one and this one, describing some of the challenges to product thinking. You should read them. He’s right. 

This article is about something more fundamental than that. It’s about the service provider anti-pattern baked into our processes. It’s baked into the governance of most large companies. It’s baked into agile development. And, this way of thinking has been baked into your head since childhood. It’s hard to escape. And, I believe it’s behind a lot of the well-meaning people who lose their way when trying to apply product thinking.

I don’t have a solution. I just want you to recognize it when you see it.

We all know what makes a product great

I start lots of classes and talks by asking “what makes a product great?” Try this yourself right now. Think of a product you use routinely. Ask yourself why it’s great. Really. Pause and do that.

I’ve done this long enough to know that a few things always come up. Things like:

• Easy to use
• Solves a problem
• Fun
• Delightful
• Saves me time

These are all the things people who buy and use your product say. In fact, for a product to be successful, your customers must find your product, try it, use it, keep using it, and say some of the good things you just thought of. Real product people use more sophisticated terminology like Acquisition, Activation, Retention, and Referral. If you didn’t already know that, you should watch this old Dave McClure talk explaining it. He’s the one everyone credits for it. Notice users go through this progression with your whole product AND they’ll need to this for every new feature or capability you release into that product.

What I, and lots of other people call these things are outcomes. 

Outcomes are what your customers and users do, say, and feel. 

The other thing that really makes a product great if you’re the one that built it is the return on investment you’ll get from building and selling it. If you’re a non-profit, you’ll celebrate moving your mission forward, and getting more donors and volunteers. I call all this stuff impact.

Impact is the benefit your organization, and the world, gets when lots of people use your product

We measure product impacts with things like:

• Monthly or annual recurring revenue
• Customer sentiment or net promoter score
• Customer retention
• Lifetime customer value
• Brand awareness and market share

Our customers don’t care about that stuff. But, if you build products, you’d better. 

I’m being pretty precise about my definition of these two words. If you’re trying to build a successful product you’ll need to focus on outcomes and impact. Once again with feeling:

Product thinking moves your focus to outcomes and business impact. 

If you want to see me unpack that outcome and impact thing in a more entertaining way with sharpie markers, watch this video.

Output vs. Outcome & Impact from Jeff Patton on Vimeo.

Now forget all that… let’s remodel our kitchen

Go with me for a minute on this. Imagine you did want to remodel your kitchen. Some of you may have already survived this horror. If you had to hire a great kitchen remodeler, what would you look for? No really. Think about it for a minute. 

When I ask people this question I get answers like:

• Easy to work with
• Good communicator
• Helps me turn my vision into a reality
• Good prices
• Knowledge and skill
• Actually shows up
• Keeps me informed when things go wrong
• Finishes on time or reasonably close to on time.

A couple years ago I did remodel my kitchen. This is Ed. He’s the guy we hired to do it. Actually, it wasn’t just Ed. Ed has a whole cross-functional team of carpenters, cabinet makers, tilers, plumbers, electricians, drywallers… and lots of skills I don’t understand. Angel was the guy on the ground managing all those people. That’s him standing by the hole in my wall.

If you’ve ever hired a kitchen remodeler, or anyone else to do some sophisticated work around your house you know how this goes. At least this is the way it went for me.

1. First we talk: I explain my vision. Ed listens, works to understand, and offers me back specific solutions and alternatives. We’re trying to get to agreement on the work we’re about to start doing.

2. Estimation: Ed needs to understand all this stuff so that he can figure out how much it’ll cost and how long it’ll take.

3. Negotiation: I don’t know about you, but every time I get a first estimate I recoil in horror. It’s always more money than I imagined. How would I know what this stuff costs. I’m not an expert. Ed is though. Given my sticker shock we begin to discuss all the details and try to figure out what we can do that fits in my budget. I’m worried about getting as much as I can for my money. But, Ed is worrying about actually making a profit, and maybe buying a bigger boat. OK, I’m not sure Ed has a boat. But I know he’s worried about keeping me happy so I say good things about him later on, and because he’s that kind of guy.

4. Order: We eventually agree on what we’re doing. I give him approval and some money, and he starts working.

5. Build: While he does the work Ed pays attention to what we agreed on doing, the scope. He watches the time, both to stay on schedule and because he’s got other jobs running and people scattered around doing work. It’s complex project management. He pays attention to the costs too. He’s got lots of people to pay, tools to buy, and all that new stuff going into my kitchen. Lots of questions come up and lots of smaller decisions need to be made along the way. Lots of little things go wrong. Thank goodness he’s a good communicator so every time we discuss time, cost, and scope the discussion isn’t more painful than it needs to be.

6. Delivery: Eventually all this stuff gets done, really done. And it did. We know it’s done because together we do lots of walking around and inspectiving everything. And, I finally give him the last bit of money I owe him to call the job complete.

You probably didn’t need this explanation, but it’ll likely sound hauntingly familiar. If we change the first step to “requirements” we end up with this six-step process:

1. Requirements
2. Estimation
3. Negotiation
4. Order
5. Build
6. Delivery

The flow looks like this.

I can almost guarantee that this is the process that you use inside your company to get software built. Cross out “customer” in the drawing above and label it “the business.” Cross out kitchen remodeler and label it “Technology.” See what I mean? Scary, right?

My first agile project in 2000 was using XP. My business card said “product manager.” But in XP, I was known as the “customer.” If you’re using Scrum, you could also cross out the word “customer” and replace it with “product owner,” and the other side with “delivery team.” See how this is baked in?

So what?

So what if the process your kitchen modeler uses happens to match the process we use in our company? I’ll tell you what. Some nasty things happen if you mistake your business for your actual customer.

We focus on the wrong outcomes 

You’ve seen it before. The business stakeholders say they’re happy. Then the thing you built never gets used. Or sometimes things go terribly wrong. You build a fraction of the scope requested. You go way over time and budget. But the thing you build gets used tons and makes or saves your business far more money than it spent building it. Sometimes we never really know what happened after we shipped it.

For Ed, my kitchen remodeler, me being a happy customer is his desired outcome. Ed isn’t responsible for the ROI of my kitchen. I am. The kitchen wasn’t built to satisfy thousands of users. And whether I really use it, all of it, isn’t Ed’s responsibility. Sure, Ed checked back a couple times to make sure things were still working. But he’s certainly not monitoring metrics to find out how many times we use that second sink we paid lots of money for.  I often say good things about Ed. He gets referrals and more work. And that’s great. He makes money selling time and materials. Let me say this again:

Service providers make money selling time and materials. The service they provide is the product.

Interestingly if your stakeholders love your work it likely doesn’t impact your business one way or another. And, I bet your company doesn’t make money selling your time and materials. And happy stakeholders giving you even more work isn’t helpful. It just buries you in more work.

The team can’t really own outcomes

If it’s not obvious from what I said above, the customer ends up holding the bag for product outcomes – really getting the value from what was built. That’s because they decided what should be built. It’s hard to take responsibility for the outcome when you don’t understand your real customer, the real problems you’re solving, or make any real decisions on how to solve them.

The service provider model separates those responsible for product outcomes from those responsible for product delivery.

Lots of people believe this is a healthy separation of responsibility. I’m not lots of people. 

We emphasize maximizing output, not outcome and impact: 

The customer in this model seeks to maximize the amount of stuff they can get for their money. I know I did with my kitchen. More stuff for your money is good, right? However, if we focus on maximizing real customer outcomes we start to find that more stuff isn’t always so good. The best products aren’t those with the most features. The most successful product companies aren’t those with the most products. 

To make money on a product we try to minimize output and maximize outcomes

There’s really no product discovery needed in this model: 

Lots of our product ideas fail. We all know the failure rate of startups is pretty high. For those paying attention to the features we put into products we know that most of them are rarely used as much as we hoped, if at all. Outcomes aren’t guaranteed. But, when doing product design, we’ve got a solution to that high likelihood of failure.

We use product discovery work to identify real customer needs and really test that we’ll get the outcome we hope for.

If your desired outcome is stakeholder satisfaction then all your investigation will focus on what makes them happy. All of Ed’s focus was on me and what I wanted. Ed doesn’t design kitchens for IKEA. And just like me and my kitchen, your stakeholders have strong ideas about what they want to see built. They don’t really want you questioning and testing their ideas. Not really. In old school IT teams engage in “requirements capture” because everything the business wants may be a requirement.

I wish Ed would have questioned my choice of flooring. He did a little, but I didn’t listen. I chose this cool grey color of wood. I spent thousands buying it. And, when Ed’s team started laying it down I saw pretty soon that the flooring I chose really clashed with the wood on the cabinets. This sucked. It sucked because I then paid Ed’s team to pull up the flooring. I had to buy all new flooring. I had to sell the cool grey colored wood flooring stacked in my garage at pennies on the dollar. It was an expensive mistake. And, in the end I paid for it. Remember, Ed sells time and materials. The mistake wasn’t his fault. It was mine. I paid the extra money and dealt with the delay in my kitchen project. Because my choice caused it.

I really wished I’d done an experiment. I should have bought and laid down a little of that wood close to the cabinets we had. Just looking at the sample wasn’t good enough. I was pretty confident in my decision looking at the sample, but I was wrong.

We spend money to test our ideas before we invest in building them.

How often does this happen with your business stakeholders? Do they take responsibility for the delays? Who pays the extra cost?

Doing this well isn’t actually how our company makes money:

Remember, Ed makes money selling time and materials. Too much work, or extra unplanned work is a good thing for him. It’s called “demand” in product speak. If he has more demand than he can satisfy he can: 

1. Hire more people 
2. Raise prices to reduce demand 
3. Turn down work – which often makes him more desirable enhancing his brand 

If you build software for your company, none of those moves make sense. Because your company likely doesn’t make money selling your time.

Your company only earns or saves money when the software you build gets used.

It’s the same with my kitchen. I get ROI every time I cook, do dishes, or host a party. Ed doesn’t get that ROI. Ed got it from selling his time a long time ago. 

How does your company earn a return from the software you build? If you don’t know, that could be a problem.

The process we use is the service-provider’s product experience

For my kitchen remodeler, this is his customer engagement model. Doing it more efficiently and effectively could make him more money. But not always. If he’s charging by the hour, more time equals more money. More efficient may not be better. You might have noticed this if your organization has hired an outside vendor to build its software. Like Ed, they make money from selling time.

The service model may be your process flow. Don’t mistake it for your product experience

For your organization doing things more efficiently and effectively decreases the time it’ll take to start earning a return on your investment. Exposing risky ideas and testing them helps you avoid bad investments. Breaking ideas into smaller valuable releases increases your investment even more and minimizes the risk of bad investment. 

None of those things are true for Ed, my kitchen remodeler. Remember, his ROI came from doing the work. 

It’s baked into our our organization

You know this model is baked into your organization. It’s been the de facto way of working in IT since there’s been IT. 

For most of you I can almost guarantee you don’t have metrics that’ll tell you how many times your last feature got used – whether it’s really generating value.  But, you do know if your last project finished on time.

Most traditional process and governance focuses on on-time and on-budget delivery of desired scope, and not successful outcomes or impact

On time and on budget are metrics Ed uses to make sure he’s providing a good service. Those aren’t the metrics your organization needs to know if it made a good product investment.

It’s baked into agile development

It’s no secret that the agile manifesto was written by 17 people who focused on building software. Reread the agile manifesto and all those values and principles. Notice how they’re written from the service provider’s perspective. Notice how customer, user, and the business are used almost interchangeably. Look at values like:

Customer collaboration over contract negotiation 

That’s exactly what I want when I hire a kitchen remodeler. But collaboration doesn’t make much sense when I choose a product to use. 

Look at principles like: 

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

This makes perfect sense if you’re building software for money. Ed’s priority is to satisfy me through continuous delivery of parts of my kitchen. But, if the software is your product, not the service of building it, then your highest priority had better be outcomes like more people trying, using,and continuing to use your product. Because those are the things that earn or save your company money.

The biggest missing value statement in the agile manifesto is:

Successful outcomes over efficient delivery

Just like the manifesto, the thing on the right is valuable. In fact it’s necessary. But, the thing on the left matters more. 

Listen to me rant about this stuff more in a conversation I had with Melissa Perri.

You can deliver what you said you would every sprint, and it may not matter if the work doesn’t result in the outcomes your organization predicted. Doing agile by the book may result in you being a great service provider, but not a successful product creator.

It’s baked into our heads at an early age

I’ll submit that this project-style delivery process that service providers use is baked into our heads from a very early age. We’ve all spent years building good muscle memory and habits around it. I remember being in school. When I was given a paper to write there were requirements and a deadline. I needed to deliver it on time otherwise I’d be graded poorly or not at all. On-time delivery was critical. After that, I was graded on quality. The outcome I needed was a good grade. And, the only one I needed to impress was my instructor. My paper wasn’t really a product. No one else ever used that paper. Certainly no one made money from it. 

After a decade or more of focusing on time, cost, scope, and quality and never needing to worry about outcomes, I’ve got to be deliberate about thinking about outcomes now. I need to see what I’m making as a real product, not just an assignment that needs to impress an instructor. I need to worry about who will use my product and how valuable it will be to them.

If you’re reading this, it’s a product. It’s not written just for you. It’s written for thousands of people I’ve never met. I hope it gets read often. I hope you help your organization recognize this anti-pattern and take steps to avoid focusing on working this way. That’s the outcome I’m looking for. It would be a lot easier if I could hand it to one person and get an “A”. I’d be Happy with a “B-”

Stop it, just stop it

You can’t easily change your organization’s process. You can’t change the agile manifesto. And, you can’t easily change the mindset and habits you’ve built over decades of education and work. But, in the words of GI Joe:

“Knowing is half the battle”

Recognize when you and your organization are falling into the service provider process trap, and stop it. Or at least try to.

One thing you can do right now

There’s one simple thing you and your team can do right now to start breaking the habit:

Reflect on the outcome of everything you release.

After releasing a feature, use part of your team’s  routine reflection or retrospective to discuss how long the whole feature actually took relative to what you’d planned. Discuss its quality. Those are the service provider outcomes and they do matter. But, remember, they’re table stakes. What matters more is the outcome.

Every few weeks talk about the feature’s outcomes. It’ll take a while to observe outcomes. Because outcomes can’t be observed or measured until customers see, try, and use your feature. The outcome is what really matters. This is where your organization is really earning value. If you didn’t get the outcome you expected, now you can really make the product improvement decision to change your product to improve that outcome.

The practice I recommend that teams add to their regular process is here: Keep actual effort and outcome visible

I’ll go out on a limb and say that:

Focusing on product outcomes will shift you to a product mindset

Do this as a team and you’ll breathe life into product thinking in your organization. And, ultimately your organization will thank you for it. Just not right away. Remember, outcomes and impact take time.

Yes, I’ve been whinging about this for a while

You might have seen me discuss this concept in a talk or class before. In case you haven’t, here’s one: