Everything Is A Product - How To Apply Product Management Practices to Technology Services

Slide 1

Slide 2

Who am I? My name is Matt Stratton. I'm a devops evangelist at PagerDuty. I'm an organizer of DevOpsDays Chicago, one of the global devopsdays organizers, and the creator and co-host of Arrested DevOps. Oh yeah. And my license plate says "devops"

Slide 3

before digging into the nitty gritty, let me tell you a little bit around how I got here

Slide 4

By Daniel Schwen - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=7429653

I'm from Chicago.

Slide 5

We have built some amazing things

Slide 6

Some of those things seem weird to places outside

Slide 7

but the problem is, we tend to become rigid and dogmatic about them.

Slide 8

I worked in a lot of traditional IT shops. There is a lot of insurance, finance, things of that nature in Chicago. It's what we do. Salt of the earth. You know how it goes.

Slide 9

Then I got to meet Marty Cagan. I was working for Apartments.com at the time, and they had brought Marty in to speak to the developers. I'm not quite sure how I got invited to the two-day session...but it was very eye-opening.

Slide 10

we tend to think about our services as processes, or ways of doing work. Well, everything is a "way of doing work"...everything is work. think about lyft - we would say lyft is a PRODUCT. But it's not CPG (consumer packaged goods) - it's a customer experience. Yes, there is software that plays a key role. And tools. And humans.

Slide 11

Slide 12

Slide 13

Slide 14

Slide 15

I'm not sure i spelled productize properly. I am also not sure it is a real word.

Slide 16

I need to explain something. Blah blah blah Emily's mom at Charlotte

Slide 17

Here's the tweet that gives a little context.

Slide 18

Do me a favor. For the rest of my talk, even though I'm sure you can think of 100 reasons why this would never work at your company or organization...humor me. Let's pretend it will. Just for, what, another half hour? you can do that.

Slide 19

She's probably not really watching. I don't think this is livestreamed. But on twitter yesterday I threatened to include her in this talk, and if we start lying on Twitter, what good will that platform be?

Slide 20

Slide 21

Slide 22

Slide 23

Slide 24

Slide 25

We are used to working in projects in IT. We are going to have the "Service Desk Revamp" project. Or something like that. The problem is, projects are output based. "Look, I made a thing! Look at how many things we made!" But what matters are business outcomes.

Slide 26

discovery is HARD. Our customers don't know what's possible.

Slide 27

This is tough. But without it, you are screwed. If there isn't a compelling value to your customer (be it software engineers on other teams, your help desk, etc) nobody will use your product, even if they are told to do so. And your product will fail in your internal marketplace.

Slide 28

this one is hard. Think about what it will be like for the people using your solution - a lot of them will spend hours and hours of every week with this, perhaps. Can you make it more delightful?

Slide 29

Again, remember that most of your ideas won't work out.

Slide 30

try to build/implement as little as possible. For processes, often times role-play workshops with your customers - experiment. Walk through the stuff on paper.

Slide 31

You might have heard of MVP's. You probably use them all the time. But they are unfortunately named. They should be called "minimum viable prototype" an MVP is never something that should be considered anywhere close to production ready. It's just sometime to try out to get a feel, etc.

Slide 32

See the problem? It will take us a LONG time to get to a point to even see if we learned anything (the installation of chef on the 10,000 nodes isn't going to be instant) Let's always think of our mvp's as the smallest prototype required to answer the question we need to know now

Slide 33

as always, anything you are doing needs to service what the business is there for. How does this product help a business outcome? you will need to convinvce your stakeholder's that you understand what their constraints are - and that you won't screw them over

Slide 34

Slide 35

Slide 36

In any given sprint, you should have just as many discoveryrelated stories, work, whatever you want to call them as delivery ones.

Slide 37

Every time you find yourself saying "what if THIS happened? Or what if we hit THIS corner case, I want you to imagine Samuel L. Jackson telling you he doesn't want to hear about any... if's.