(upbeat music) - I tend to think of myself as a design guy not a product guy, so I feel perhaps a little bit out of place. But hello Product 2019! I'm gonna lead you through a brief history lesson. It's 1886, you go out to your mailbox, if it actually made it all the way here to Australia, and you pick up the Scientific American Supplement. And in this issue there is an article about a new photographic apparatus featured here. And there's an article that goes along with this image. I just wanna highlight that the letters that kind of help you understand how to operate this photographic apparatus go to S, which means there's about 20 steps in order to take a picture.
And in 1886 this was considered-- It was probably about the size...
Might have been about the size of like this laptop but on a tripod.
Kind of laptop...
If the laptop was a full box.
So it's a decent size item.
In 1886 this article points out, and this is the latest thinking, this article points out that this is one of the most practical of systems for the itinerant photographer.
What you would call mobile photography, right? This is for the photographer on the go.
So a box about ye big with 20 steps was considered kind of the advanced technology at the time. Until right around that time, someone else had a different idea.
There was a gentleman in New York named George Eastman and he had an insight in a vision.
He invented a roll film and needed something to do with it. And he had the insight that for a new type of camera that had the idea of, you press the button, we do the rest.
That was for the original Kodak camera and instead of 30 steps it had only three.
Pull the cord, turn the key, press the button. And what George Eastman understood 140 years ago is that the experience is the product that we are delivering.
And that is what I will be talking about today. So that's me, you can email me, you can tweet at me and that's the website for the book that I co-wrote with Kristin Skinner, Org Design for Design Orgs.
So getting back into the talk, lets hear from the World's Greatest Product Manager. I don't actually mean that facetiously, I would consider Steve Jobs probably the World's Greatest Product Manager, was.
And he has this quote that I love and I'm going to use to kinda unpack some ideas. "When you start looking at a problem and it seems really simple with all these simple solutions, you don't really understand the complexity of the problem.
And your solutions ar way too oversimplified, and they don't work." And what he's referring to is at the outset of any kind of technology or product-- At the outside of any product lifecycle there's this focus on technology, just this idea that you can actually make something is good enough.
That does a new thing, doesn't matter if it does well, that it does it is what's interesting.
So in this example this Nokia communicator was the first mobile device that you could get on the internet with.
And the fact that you could do it at all was what mattered.
It was ugly and clunky and slow, and difficult to use but as Samuel Johnson suggests, "Like a dog walking on his hind legs, it is not done well; but you are surprised to find it done at all". Right? That you could get on the internet anywhere was good enough. Going back to Steve, "... Then you get into the problem, and you see it's really complicated.
And you come up with all these convoluted solutions. That's sort of the middle, that's where most people stop, and the solutions tend to work for a while..." So if we begin this kind of-- With the technology phase, when it comes to something.
What he's referring to is what I would call the features phase.
Where you now have an explosion of options in the market and they are competing with one another on how many features they can cram into the device. And you get...
This array of choices that overwhelm you but also you often get devices that are hard to use, difficult to understand, kind of opaque.
Because what the businesses is at this point is trying to do is just simply get as many checks on the side of the box to say how many features this thing has.
But you tend to live in this space for awhile. So now going back to our friend, the end of the quote is, "... But the really great person will keep on going and find the key, underlying principle of the problem. And come up with a beautiful elegant solution that works. I know you all know already what's about to be shown, and this is the stage in a kind of product categories evolution that the experience matters.
Right, it's no longer sufficient to compete on features and capabilities, there's a gestalt that you need to deliver and that ends up winning in the market as the iPhone did. At the time, you probably remember the time that iPhone was released.
From a feature standpoint actually it suffered compared to the competition, it was slower, didn't have 3G, its camera was pretty crappy.
Some people considered the lack of a keyboard a feature deficit, right? Feature by feature it didn't win but as an experience it set the template for everything that followed.
And you see this repeated in other categories, IRC becomes Intra Office Chat becomes Slack, right? You see this type of evolution, again, Slack when it first launched was feature-poor compared to other competitors, Hip Chat or IBM Sametime.
But it was a joy to use and folks wouldn't give it up, they insisted on using it.
So you see this type of evolution again and again. I've given a version of this talk, this part of the talk, for well over 10 years.
Around technology, features and experience and how product categories evolve.
Something occurred to be a couple years ago when I was invited to speak at a different product conference, mind the product.
Which was how these three items are not unlike these three items.
Everybody drink.
(laughing) Every time you see these three circles you get to drink. (laughing) The elements of technology, features and experience kind of map to these three circles.
Which I found quite interesting in that parallelism and as we know product management in theory lives at the heart of those three circles.
As I've experienced product management in reality, you have your tech, you have your business and then you have your user experience, there it is.
And it's really actually often much more about managing kind of tech and business than it is anything to do with the user experience. And my contention is that designers who are operating in these contexts, we had to create the field of "user experience" because product management had neglected its duty. It was paying attention to the user experience, it wasn't paying attention to customers and their needs. It was so focused on either the business challenges, a lot of people with MBA's becoming product managers or the technical challenges, engineering becoming product managers.
That the idea that someone was going to use it had become neglected.
Chapter two.
A few years ago wearing this shirt-- (laughing) I tried to define the profession of "UX Designer". That's my background as in user experience but I don't like how most people try to define UX Designer because they...
There's not a good definition of it, it usually just means Interaction Designer or something like that.
So I tried to define it, I started with this diagram that Dan Saffer created years ago for his book, that shows User Experience Design and then all these other elements.
And what I would contend is that, User Experience Design is not all these disciplines. Those disciplines are those disciplines.
What User Experience Design is, is what's left. It's the ability to coordinate the efforts within all those disciplines.
So what would a User Experience Designer do? If that is what you would kind of-- That's where you're saying they're operating, right? So what's left? Well there's a bunch that's left.
And I drew on my experience having help run Adaptive Path for 10 years, we were a user experience firm.
So I thought what we did counts as User Experience Design.
So what were some of the things we did? Well, generate user insights, right? Talk to customers, create journey maps, generate user insights.
We would make business cases for design.
Working with our clients helping them connect the design... Connect potential design impact with financial outcomes. We would help figure out where to focus our design efforts for maximum impact, right? You can't do everything, there's not enough time.
So where can we focus our efforts so that we can actually have a real impact. We would facilitate cross-functional ideation, get a bunch of different people, engineers and marketers, designers and product people, CEOs.
That gentleman there was a CEO of the company we were working with.
And that's Kate Rudders, some of you might be familiar with her, she's got a podcast with Laura Klein.
We would facilitate cross-functional ideation and in doing that we would generate tonnes and tonnes of concepts.
And have a lot of ideas for what we could build. We would come up with kind of a way of phasing an experience over time.
So this was for a Genealogy website, where you're just kind of, take what you've got and how you evolve it. The little stories at the top collaborate, convey and make it smart.
The point there is this kind of experience planning, kind of looking forward, how are you going to phase things? And we had what we called the Cake Model of Product Strategy.
Where you would start where most people begin with cake and then add filling and icing.
You don't wanna go that way 'cause no one wants plain cake.
Instead you wanna start with a cupcake, something small but delicious.
And then gradually grow that.
This is obviously quite similar to Henrik Kniberg's skateboard to scooter diagram.
We did this, I believe earlier and independently, I don't think he had necessarily seen this, right? And then this UX Designer is going to help articulate an experience strategy and vision. It might be mock-ups of future experiences, there might be models of ecosystems.
There might be prototypes that you build.
And things like experience principles that help keep a team together and understanding what it is that they're trying to kind of design toward.
And then as the work is being done, this UX Designer would be involved in ongoing oversight and orchestration, making sure that what is begin built, what is being designed and built, kind of continues to adhere to this user experience that had been defined.
In this talk that I was giving there was even more to it but these are some of the highlights.
I had gone through these elements and when I was done with the talk, the lights came up and Christina Wodtke actually, if you know of her, said, "Um Peter, isn't what you're talking about product management?".
(record screeches) (laughing) And at the time I said no because I'd never worked with any product managers who did those things.
This wasn't that long ago.
Because when I left Adaptive Path and went in house, what I saw and I still see often, is somebody has initial insight.
I have an idea! They develop a plan, here's what it needs to do.
And then they go through some process to build it. Maybe they do some user testing and refining through that process but then they ship it and then they analyse it and I think as Johnny said earlier today, they're like, wait, how do we even know we're successful 'cause we never actually bothered to figure out what we were trying to do.
Someone just had an idea that we were shipping. Some savvier teams maybe would try some stuff first. They would sketch and prototype.
And try some things out before they got into this model or this approach. But I continue to find myself wondering, where's the thinking? Real user understanding? Strategic alignment? It just felt like people were producing stuff for the sake of getting stuff out the door. And no one had stepped back to try to consider what is it we're trying to deliver.
And why? Why are we doing these things? At my first job outside of Adaptive Path, when I was working in house.
It was still possibly the only time I've ever had my own office and in my office there was a whiteboard.
And on the whiteboard I drew this double diamond diagram. This is the first time I'd ever drawn the double diamond. I was familiar with it but working at Adaptive Path, I didn't need to use a double diamond 'cause everybody knew what I did.
But when I went in house, I needed to explain, this is how I work.
This is how I think the way that we work should be done. There's a lot of sticky's here, I won't get into those details, right.
The double diamond is basically a model for thinking about a somewhat generic design process that begins with definition, figuring out what to build.
And then execution, figuring out how to build that. It's important that you diverge, consider a lot of ideas before you converge onto a particular plan.
And then diverge again as you're exploring solutions and then converge to get to something that you ship. In the first diamond, design's job is largely to make the strategy concrete. So that it doesn't feel that femoral or abstract but it gives it real presence.
And in the second diamond, design does the work that design does to deliver delightful engaging experiences. As I was kind of reflecting after I was told what you just articulated was product management, and I'm like no it's not, it's User Experience Design.
I was reflecting on this photo of that diagram that I had in my office.
What you can see here is that the yellow sticky's are UX, the orange sticky's are product and the pink sticky's are UX and product.
And it turns out many of the sticky's are UX and product. There are some that are specific to UX and there's a few that are product sticky's. But a lot are about UX and product.
Oh look, design the box, I agree with Shereef, you should do that.
That's a really good exercise.
It's a remarkable tool to get teams having better conversations.
The insight that I then had was this isn't a model of good design practise, this is actually a diagram of good product management practise.
Since I've started talking about it in this way, we have seen the emergence, and you might wanna get ready to take another drink, of things like dual track agile.
Johnny had this very exact same image, I'd never met the man before in my life.
So clearly it must be right if we're both using it in a talk.
But the thing about the dual track agile is that it basically maps to the double diamond, definition and execution.
All those definition things being a lot of the work that a UX Designer would do in the way that I had talked about it. And so these things are converging.
Kind of shifting a little bit again, chapter three or four, I don't know what stage I'm at here.
But kind of the next set of things I wanna talk about. Going back to George Eastman, going back to the Kodak camera.
The genius of his wasn't simply the design of the product, where you press the button.
The true genius was the rest of the phrase, "we do the rest".
There was a factory in Rochester New York, that would take the film that people shot.
You would send it to them and they would then develop it, print it and send that back to you.
And what he had figured out was that in order to make it such that folks weren't overwhelmed by a product experience the way that that prior camera was where you had 20 steps and you're doing everything yourself.
That there was a responsibility for the company to take on some of that work.
And essentially he realised that his product was a service. And this is something that we are starting to become-- And anyone who took my workshop you can take a brief five minute nap, you've seen these slides.
This is something we are beginning to realise again in the software driven world. So this is a photograph of an interaction that is happening less and less over time, the idea of someone buying a car.
And the reason is you don't need to buy a car to use a car or have access to a car.
Because cars are becoming services.
Everything is, or is becoming, a service.
You have ride share, early ride share or sorry car share programmes like Zip Car.
More recent ride share services like Lyft and Uber and Ola. In the Bay area there's a service called Gig, where I can walk up to a car with my mobile phone, unlock it, drive it anywhere around Berkeley and Oakland. Park it anywhere in Berkeley and Oakland, lock it and walk away.
And because of this, where I live as a nuclear family of a husband and wife and two kids, almost everyone we know in that situation has two cars. We only have one because we don't need to buy another car 'cause we can always access one if we need it. With everything becoming a service, that has implications for kind of product experience. Because products, features and the marketing of them are simply a manifestation of a service relationship. If everything is becoming a service, at the heart of a service is the relationship between the customer and the company who's delivering that service. This is a experience map that Adaptive Path created for a client, Rail Europe, the folks who help you travel all around Europe on trains.
They allowed us to publish it and it got some notoriety.
And the point I'm making here is simply to recognise that in order to deliver this service, it's not about any product.
There's kiosks and websites and all that kind of stuff but then you also have to pick up the phone and call someone and there's gonna be customer service experiences. And there's whole bunch of different things that need to be orchestrated.
And the responsibility we have is figuring out how to weave all that together.
And to remind ourselves that with a service all that customers have to consider, when it is done, is the experience.
And I've kind of zoomed in here on the thinking and feeling areas of travel, right? This is the product that is being delivered by Rail Europe, not a couple of tickets.
But the travel experience that people are having and what are they doing to make it a better experience or are they not doing enough and the experience is causing stress and vulnerability. But then if it goes well it's causing excitement, right? So in this vain of thinking about...
Thinking about services and thinking about experiences, what I've been advocating for my design teams for a long time, is that instead of organising design by products, instead of having designers embedded in these teams that instead you organise your design teams by customers and the experiences they're having. So as was pointed out, I worked at Groupon.
And at Groupon we had a market place and there was a buyer experience and I had a design team that designed the buyer experience. And there was a seller experience and I had a design team that designed the seller experience.
And they would, to make sure that this experience kind if cohered across this set of features. That was their mandate, not to design the features but to design an experience that took advantage of these capabilities.
So I had been arguing for this model of organising design teams for a little while. I then came across a news letter written by Ken Norton. Ken Norton I'm sure many of you are familiar with 'cause this is a product conference.
He's the product management kind of, thought part leader within GV aka Google Ventures. And he wrote, "Organise your product managers around customers, not code repositories.
Connect PM areas of ownership to users and their product experiences." I kind of thought, hey he's taken my...
He's taking from my hymnal.
He's taking from my song book.
And then he had a response, and Noah Weiss was actually quoted yesterday so, you can drink again or whatever you wanna do for things that keep popping up over the course of these two days.
Noah Weiss in a response to him that Ken published said, "Just like it's ideal to organise your PM team around customers and use cases, the same goes for engineering." And what I thought was really interesting about this exchange was that...
It made me realise that others are also recognising that in a world of services where that relationship with the customer is the most important thing to maintain.
That you need to start organising how your teams are-- You'd have to start organising your teams and how they operate around the customers and what it is they're trying to get done.
Instead of organising by technology stack or whatever else, backend and front end.
Instead organised by customers, make sure you really understand those customers and that you are delivering value to them every step of the way in a coherent, coordinated fashion.
And it's worth slowing down but the potential kind of-- Speed of development of shipping because you're making sure that what you're shipping is the right thing to ship to deliver on that experience.
Oops.
One of the challenges-- So this is the next chapter.
One of the challenges with this kind of approach, historic approach to product management.
Where tech and business have been, I feel, overweight and recognition of user experience has been under-weighted.
I'll reflect on...
By taking a...
Using the analogy of the left and right brain. Which, please don't get Neuro biological on me, I know that this is a flawed analogy.
Strictly in terms of strict biological sense but I think it's useful as a metaphor.
The fact that technologists and business people typically have a way of thinking and approaching problem solving that is very similar.
It's usually highly analytical, reductive, think spreadsheets.
It's rigorous, think high detail.
Focused on edge cases, it's bottom-up.
It's evaluative.
It's about fixing bugs and fixing things that are wrong. And it often relies on quantitative measures in order to understand kind of how you're doing. Whereas the stereotypically rightbrain practises of UX and design are emotional, they're additive, they're intuitive.
They're top-down, generative, qualitative.
And when you only have kind of tech and business, you're missing half of the equation here.
And you're not serving the humans, right? This is a lot of the stuff that we tend to consider more humanistic.
You're ignoring that.
All that stuff about experience, all that stuff about feeling.
In that travel example, all that stress that they might be experiencing or anxiety that they might be experiencing or the excitement they might be experiencing. Doesn't get recognised when you're only focusing on... Or approaching from that tech and business lens. And the thing also to recognise...
Or that I believe to be true is this is the hardest stuff to get right.
The experience stuff is the hardest stuff to get right. This might be arduous, this might be difficult.
It might take a while but you kinda know where you're going. The challenge here is, it's so open-ended, right? It takes a while to figure it out but it's worth while.
Going back to the Worlds Greatest Product Manager, one of his last talks, he made a point of saying, the reason that Apple was successful was because it lived at this intersection of technology and liberal arts.
I love it.
He didn't say design, liberal arts.
Recognising it's more than just design.
And that is what allowed Apple to realise the success that it has had from the Macintosh and contributors like Susan Kare who is a fine artist.
Who is the...
Kind of famously the icon and font designer for the Macintosh obviously through iPhone. And the involvement of people like Johnny Ive and as an industrial designer, not just someone who was given a set of requirements and told to build it but someone who is very active in figuring out what that thing should be.
I'm gonna take a little pause here or not a pause but I'm gonna totally shift gears before I get back to my point.
Because I wanna actually think back on something that David referred to at the very beginning of this session.
I have an opportunity before you all leave.
Because I found David's talk excellent, I don't think I had seen an explanation of product management that was as both thorough but kind of well structured as David's talk. But it also gave me pause or it gave me a little bit of concern.
The idea of that ideal associate PM, right? Is this.
And you've got these five areas.
And I'm not saying that David said this to be true or said this was the intent.
But it has an implication that in order to grow, you're growing all of these, all of these.
All of these until you're able to do all five of these really well.
And when I think of that-- (upbeat music) - Plate number five.
- [Peter] Kind of reminds me of plate spinning, right? Bouncing back and forth between all these responsibilities you have, trying to do them but probably not doing (mumbles). He's doing it okay but it's only plate spinning, right? But you're just kind of frantic if you're in that mode.
You're frantic trying to do all these things and it strikes me as unfair to product managers to expect them to be able to do all of these things.
It is in fact not unfair, it's kind of insane.
One of the things that we have done in the field of design is recognised that there are people who are stronger at different kinds of skills than others.
And that you team them to get a complete set of skills brought to bare.
The unicorn designer.
If you're trying to work with unicorn designers, good luck.
It doesn't really scale.
We've kind of recognised that was a...
That's not a sustainable solution, right? But for some reason we seem to believe we need unicorn product managers. I don't know why I don't hear about teaming product managers.
And this is my provocation for you as you leave. Maybe you have a product manager who is really good at execution and domain knowledge and weaker at strategy, storytelling and leadership, that's okay.
Partner them with someone who kind of balance them out.
Don't try to have one person be all things to all people. Anyways, that's my provocation for you, I'm now gonna go back to our regularly scheduled presentation.
Already in progress.
And I'm about to wrap up, right? What I would encourage us to do and encourage the field of product management to really embrace is a more well-rounded approach to the work and not such a focus on technology and business. Not to only hire MBA's and ex-engineers and computer science folks.
But instead to recognise that we have to have each of these in equal way.
I would encourage you to move away from thinking about this is UX and calling it design. Because really, in the centre UX lives there, right? That was my realisation in going through that experience trying to articulate what a UX Designer is.
If it's not all those specific design disciplines, right? UX is at the heart, as is product and that's because in this world of delivery of service, where all people have is the experience to take away, the experience is the product that we are delivering.
And all that your customers and users care about. Thank you.
(upbeat music) (applause) (upbeat music)
