Peter Merholz talks product design

Currently Senior Director of design with Jawbone, he was previously VP of Global Design at Groupon and is a co-founder of design agency Adaptive Path.

I caught up with him recently for a wide ranging interview which covered the definition of product management, the evolution of design, how best to organize and manage designers and the rapidly changing economics of design agencies. You can listen to the interview in full below.

If you like what you hear, check out more episodes. You can also subscribe in iTunes, Stitcher, or over at Soundcloud, or grab the RSS feed, if you’d like to automatically receive new episodes of the Inside Intercom podcast which will feature interviews with some of the best thinkers and do-ers in the startup world.

If you’d rather not listen to a podcast, a lightly edited version of the conversation follows below.

Des Traynor: Today I’m joined by Peter Merholz. Peter is the Senior Director of Product Experience at Jawbone, and before that was a founder at Adaptive Path. We’re going to talk a bit about product management – we both have opinions on this. The role has become so popular lately, and whenever you Google it, you get all these older papers where the most common phrase is, “The Product Manager is the mini-CEO”. What’s your take on that?

Peter Merholz: A friend of mine, Jonathan Korman, tweeted about this recently and said, If you believe the product manager is a mini-CEO, you know neither what CEOs do, nor what product managers do. That’s kind of how I feel about it. The CEO is the person most responsible for the success and health of an entire organization – primarily the financial health – while a product manager’s trying to ship product. Some product managers have business case responsibilities. They’re responsible for some form of P&L that suggests their success, but that is not CEO behavior, and it’s also not true of all product managers.

I don’t know if I necessarily have a definition of a product manager, just because I think there are a number of different ways to tackle it, and it feels to me like it’s a field, a practice, a role that is maturing. But I would definitely not refer to it as “The CEO of a product”.

The designer as product manager

Des: That’s certainly my experience. If you have a really mature senior experienced designer and a great really advanced engineer both of whom have shipped lots of software before, to introduce this third-person as a mini-CEO makes no sense.

Do you think a design background is advantageous/necessary/optional for a product manager?

Peter: I would say it’s advantageous and optional. Product management has become the singular definition, unlike designer – you have visual designers, product designers, interaction designers, UX designers. But product manager is always product manager, and I think that speaks to its immaturity, because depending on the nature of the product, or the part of the product that you’re working on, you might have something that’s more consumer-facing. You might have something that’s more technical. You might have something that’s more of an analytics challenge.

You want to find product managers who can address whatever that product or feature need is. Frankly, a lot of product managers work at the level of feature as opposed to product. At least, that was my experience at Groupon. If you’re doing a consumer facing product, that is where it is definitely advantageous to have that design background. We’re seeing more people with design and UX backgrounds becoming product managers in those types of contexts, because leadership recognizes a design perspective actually helps deliver better product, as long as those design leaders also understand the technical and business underpinnings.

Des: It’s certainly a trend I’m seeing, of people who have a lot of components that in 2007 would have made them what we called “the UX designer”, becoming product managers. They’ve got good empathy and reasonably decent abilities to research things and chase things down. What’s the bit that they add to that to make them a product manager?

Peter: A recognition that design isn’t the end all, be all of the work to be done. There’s a recognition and an appreciation for understanding the business context in which the design work is happening. An engagement with the technical capabilities and constraints. Not every designer has that interest, right? A lot of designers love the craft of design and want to do design design, and that’s great. But then you find other designers who tend to think a little more systemically and feel their designs are better when they understand the business and technical constraints. Those designers tend to be the ones who then become product managers.

It doesn’t necessarily even have to be a formal distinction. At Groupon, I hired an old school UX guy as a design manager for a team. As an old school UX guy, and that’s my experience, you worry about technical constraints, you try to understand the business challenges, right? That’s how this guy continued to practice, to the degree which, I had a meeting with a product manager who was working with that team, and he thought this design lead was the product manager for that product. Because the product manager, I don’t want to say was incompetent, but was basically a technical manager. Groupon had a philosophy of hiring CS-backgrounded product managers because they saw product management largely as engineering management. That is a strain that pretty much started with Google and you see in a lot of places.

The problem is, when you’re trying to create a consumer product, that doesn’t get you that far. This guy appreciated those concerns but brought other things to the table. He was driving feature prioritization, driving the roadmap, having conversations with engineering and other product managers, other designers, to make sure it was all going. So he was acting like a product manager, it just happened he was the design lead, and he was just filling a gap. The work needed to be done so he was doing it. And it turned out that work by any other name was product management.

Des: The trait there seems like an excessive amount of curiosity. Some people want to go back and keep designing, while others are “What happens now?”. I think if you have that drive and curiosity you either end up rustling feathers or becoming a product manager.

Peter: Speaking from my own personal experience and mindset, design is a means to solving a problem, and that problem is, you know, delivering some experience, getting some engagement, solving some problem in the world, and you want to know did it

As a product manager you’re paying attention to a different set of concerns, and you might not be going as deep on design craft. You might not be Wilson Miner, Mike Matas, delivering things that are beautiful and amazing, but what you are delivering, you’re making sure is getting better and better, with every successive generation. It’s delivering on whatever the value was that had been identified.

The discipline of hardware

Des: If you take a startup, a couple of people in a garage type startup, is the role of product manager paired with entrepreneurship? Or does it exist before the product exists?

Peter: I think it could, right? We’ve been talking a lot about process here at Jawbone, and I’m part of this ad hoc committee trying to think about how we can work as project teams better. We tend to be a little more functionally organized. You know, designers, engineers, product managers, and then we have a project, a program that we pull designers and engineers in on to work on, and then they move on to some other thing. We’re trying to move away from that model to one where the same designers and engineers continue to work together on a program over time. It’s not rocket science, but it’s something we’re evolving into, and I think for us the challenge is evolving from a hardware company to a software company.

With hardware, you can do that. Once you ship a product, it’s literally shipped. Out the door, in boxes, on shelves, and you move on to the next thing. You don’t iterate necessarily. I mean, you might do the next generation of it, but there is a starting over that happens. The challenge here is moving away from that hardware-driven product management mindset towards a software-driven one that is going to be more agile, that is going to be more iterative. That’s never done. Ship/launch is the beginning, not the end. Whereas in hardware, ship/launch is the end.

In that kind of model, to answer your question, does product management happen before the product begins, potentially. We’ve been borrowing from Spotify, if you’ve dug into what Spotify’s written about product management. They have the Dream It, Think it, Build It model. That Dream It model, where you don’t have anything, product management can definitely play a role there in helping shape whatever that initial idea is.

Des: What’s your take on this? Because you have to get it right when it’s hardware, you could probably justify yourself more research, more upfront thinking,or attempts before you go into manufacturing. The lean or the agile world would have you ship a lot quicker, make a lot more mistakes, possibly spoil your reputation a lot earlier. Are people here excited about going, “Oh sweet, now we’re agile. We can make mistakes.” Or are you carrying the same discipline that you had when it was hardware?

Peter: We’re bringing some of that hardware discipline in. One of the things that I really appreciate working here is the recognition of the value of that early exploratory work to figure out why you’re doing something and what you should do before you start executing against it. It’s born of that hardware practice where, because of the risk involved, in the money that you’re going to commit, to spinning up a factory and shipping hundreds of thousands, if not millions of units of something, you want to mitigate that risk through lots of exploration and pre-shipping iteration.

When it comes to software, we’re doing some of it. I’m not a fan of “ship early, ship often,” for its own sake. Which, I think, is kind of how people think about it, right? I still think there’s more value to be iterating in a prototyping, internal mode when you can iterate more quickly, and you’re still feeling your way forward, than trying to ship something sooner and iterate in public. With a lean model you can ship your first build sooner, but it will take you longer to ship the right build. There’s a balance to be struck. It’s a failing if you spend too much time in the earlier kind of definition phase, exploring ideas and concepts, the market can move before you’re done.

Des: I’m not even convinced this makes that much sense on web e.g if you’re hoping your product’s going to go viral and you release a sh*t app, it’s not going to go viral. I think people assume you’ve got 15 chances to launch, but you really don’t. How many times am I going to try out the latest fitness tracking app from somebody?

Peter: You’re right. At most you’ll move on to a different app if you’re still interested in the space. Remember when Path launched? Everyone was very excited about it, I played with it. It didn’t make any sense to me, I didn’t play with it. Then at some point with their 2.0, eventually people I knew started using it, and years later I came back. But whatever goodwill they had built, and interest and buzz, they haven’t really been able to re-capture that.

Design as a centralized partnership

Des: Let’s talk a little bit about team structures, the topic you spoke about, at IA Summit 2015. One key point in your talk was how design gets located in the software team and at Intercom, we’ve had different versions of this as we’ve grown.

There was design as a unit, where it was “talk to the designers”. That was when we had one or two designers. Then design as part of each team, so there was a designer on each team. You spoke about the pros and cons of those two models and you also proposed design as a centralized partnership. Can you talk us through that?

Peter: I coined that term, centralized partnership, when I worked at Groupon, although I’m sure I’m not the first to realize that form of organization. Back when I started doing this type of stuff 20 years ago, design teams were essentially internal services firms, like you had an agency internally. Designers would get farmed out to work on a project, and then they’d come back to the centralized design team and then wait for the next project and get farmed out again.

The problem with that model is it reduces design to an execution function. Make it pretty – all the hard problems have been figured out. A good designer, even coming in late in a process like that, will recognize problems in what they’re designing, problems that had already theoretically been decided, and might try to push on those. But because that designer doesn’t really have skin in the game, they’re not part of that team, it’s easy for that part of the business to just dismiss the designer’s concerns and contributions. That’s one model.

As design is being taken more seriously, particularly in tech companies, design has become embedded in product teams. The example I used in my talk is this idea of the e-commerce experience. You’ll have a product or feature team dedicated to search and browse, and another one dedicated to the product page, and another one dedicated to reviews, and another one dedicated to the checkout flow.

Those teams will have three, four, five, six engineers, usually one product manager, and one designer. The good thing about that model, is you have a designer on that team, dedicated to that team, so that team respects the contributions of the designer. The problem with that model, is that the designer is working on their own, usually not coordinating with the other designers. The people they work with most are non-designers, who don’t understand them, don’t think like them, don’t speak the same professional language. They get lonely. I’ve heard that from folks throughout my career who found themselves in this environment.

That model wasn’t going to work for me as I was organizing the team at Groupon, because I needed a coherent experience across all those features. It’s the same shopper going through all these features, and I didn’t want anything to get in the way.

Achieving a coherent experience

Des: From the shopper’s perspective, does it feel, either subtly or maybe obviously, like you’re going through different eras of design?

Peter: Yes, that’s what happens. When I give this talk, I use Facebook as an example but I haven’t done it recently. Years ago though, you clicked on the left hand nav of your Facebook newsfeed, to get into Photos or Messenger. Each of those products within Facebook, apart from the blue and Arial, is totally different in its design. Some have left hand navigation. Some have top navigation. The orientation of what’s in the middle is different, how you interact with it is different. There’s no systemic cohesion, and that can be okay for Facebook, if they’re approaching themselves as a portfolio of products. Maybe people are dipping into one or two, by and large and ignoring the rest, that could be okay. In an experience like Groupon, or any e-commerce app, where you’re leading people through a flow very purposefully, you have to make sure it’s coherent.

The centralized partnership, is trying to combine the best of both worlds. At Groupon the whole design team was centralized under me, as the head of design. When I started there were about 30, when I left there were about 60. The 60 people were broken up into roughly 10 teams, so anywhere from 5-7 folks per team. But those teams were dedicated to specific parts of the product e.g a consumer platform team that worked on anything that every Groupon user would touch.

We also had lines of business. We had the Local line of business, that’s about the daily deals, going out, restaurants and spas and all that stuff. We had the Goods business which is more traditional e-commerce business, and then Getaways, which was a travel business. They had dedicated design teams as well, because there’s things that are specific to them, and then this platform business was responsible for the stuff that is common to everyone. There was also a set of product teams that worked on stuff that we just determined was platform. Like what we called “funnel optimization”, which is essentially the checkout flow.

The best of both worlds meant, this team of people, this team of six or seven people, was consistently working against these six or seven products. These six or seven platform people would never work on a Getaways product team. We wouldn’t cross those lines. So you had that degree of commitment and engagement that you want from the embedded designer, people who understand the full life cycle of that part of the product and are deeply wedded to it. But by being part of a team, by not embedding someone in the funnel optimization team and someone in the user-generated content team, and someone in the personalization team who weren’t talking to each other, by being one order above that, we ensured that there was consistency across those product teams.

The product teams were meant to be these autonomous forces pulling in all directions as they saw fit, and then the design team was this counter balance that was meant to kind of cohere that effort and make sure it wasn’t going off in too chaotic and too fractured a mode.

Key to making the centralized partnership work is design leadership. You know, I was a VP, 20 years experience. I inherited 13 product designers who were all in their mid-20s, who were just kind of pinging around the organization like pinballs. What I spent much of my first nine months doing, was recruiting and hiring design managers and design directors that I could form these teams around.

These design directors, they became this kind of crucial leverage point within, not just design, but within the organization. They would manage down to get the most out of the team, manage across, work cross functionally with the director of product management, director of engineering and manage up and make sure the executives and senior stakeholders understood what was going on. Before I had those leaders, I would have a 25 year old product designer talking to a 35 year old product manager with 10-15 years experience, maybe an MBA, and then some dude who’s, you know, a hot shot designer but not a lot of experience, not a lot of gravitas to bring to conversations. I don’t know if this is a fair analogy, but basically it led to an unfair fight. The designer would just basically do what the product manager said because they didn’t have the ability to meaningfully push back.

By bringing in design leadership who could engage those product managers as peers, that allowed us to drive design thinking back into the product more actively.

Des: In terms of the consumer platform team, did they own a pattern library for all of the company?

Peter: That was their property. That was one of the key things that they owned was, we called it the Gig, for Groupon Interface Guidelines, but you could imagine it as, like Twitter Bootstrap. It was a library of design patterns and code snippets, so that they could be farmed out to all these different teams. The analogy is a little bit flawed, but I basically considered it like the platform team manufactured the Legos, and then the other design teams would put together those Legos to create whatever they needed. Sometimes they would have a special problem and there were two ways to solve that. They either fix it themselves, and submitted it back to the platform team who served almost in an open source model – “that’s approved or not approved”. Or they would go to them, to the platform team, and say, “Hey, we need a widget that does ‘blah’, can you spin one up?”

Des: The knock on effect of that is you go from the Las Vegas strip problem, where you have multiple conflicting calls to action because every team doing their own thing, looking out for their own part of the product, to the platform team becoming a moderator of all this. Who ensures that different parts of the product don’t fight for attention?

Peter: Ensuring that kind of coherence and cohesion, that’s another place where design leadership was important. I had a head of platform design, a head of Locals design, a head of Goods design, a head of Getaways design. The four of them were responsible for the entire consumer experience, the shopper-facing part of Groupon, which could be managed by a conversation of four people. You couldn’t get that same number of product managers in a room and have a meaningful conversation. You’d need way more. And engineering needs even more. One of the things that I realized at Groupon is, is you need way fewer designers compared to any other role. Maybe not product manager, but definitely the engineering roles and all the attending engineering roles; QA, analytics, data science, BI and all that kind of stuff.

Des: It sounds like with the centralized design partnership, you get the benefits of both design on demand, but you also get long term depth of knowledge.

Peter: You definitely get the long term depth of knowledge. You don’t necessarily get design on demand and this is actually one of the challenges with this model. There’d be parts of the organization that would ask for design and we didn’t have any ability to give it to them, because we were understaffed or it wasn’t a priority.

If you buy in to a centralized design function that is committed to serving the rest of the organization, instead of embedding designers within each of these product teams, what you have done is you have taken power and an ability to be the masters of their own future away from these product managers, right? We expressly denied peoples’ ability to hire designers. I even once had a product manager say, “We will give you a head count for a designer, but that designer has to be able to work for us.” I’m like, “No. That can’t be how it is,” right?

It’s hard on these product teams that are otherwise being told, “You’re autonomous. Be free. Go do what you want,” to have this key function that they don’t have control over. But I think ultimately it’s a good tension to have, and I think it ultimately leads to better product.

The economics of design agencies

Des: Speaking of demand, there is an industry that does design on demand; agencies. You have various thoughts about the future of in-house, and you cited how the big design agencies seem to be shrinking in their numbers, or evaporating into the ether. What’s going on there?

Peter: Well, what’s happened is companies have recognized a different order of the value of design. To the degree to which businesses understood the value of design, it was from an execution function. It was to stay on brand. It was to be appealing, to be stylish, to differentiate yourself. But it wasn’t as a key strategic contributor to whatever it is that business is doing. Essentially with the ascendency of Apple, and a bunch of other factors, that has changed. Businesses have begun to realize design is a core competency for any business that has customers, i.e. any business. Design delivers a type of value different from what other functions were delivering so they’re all building in-house design teams. That ends up having a couple of pressures on agencies.

Agencies are now not just competing with other agencies for talent, they’re competing with these in-house design teams, and one of the things, at least, specific to the San Francisco Bay Area, is in-house design teams can afford to pay designers way more than agencies can. As I understand it, that is not true in many other geographies, but that is definitely true here.

What is true, regardless of geography though, is that companies with a design budget, used to outsource most of that spend, maybe 80% outsourced with 20% kept internal to manage those relationships. That is now flipped, where the budget is 80% internal and 20% outsourced.

Also, in San Francisco/Silicon Valley, originally Google and now Facebook have just decided to throw giant sums of money at designers. They’ve probably been doing it with engineers as well. Because both of these are machines that generate enormous profits, they have totally changed the hiring market for design. Here at Jawbone, a pre-IPO 15-year-old startup, we’re not going to offer Facebook and Google salaries, but we have to pay something closer to that. If your venture funded and you have enough money, you can afford to do it, but design firms that are paying for themselves though the profits generated by work, the economics just doesn’t work out.

Des: Has the nature of the work changed? Does the work of an in-house team differ to the work an agency would do in its place?

Peter: Not necessarily. There are things that in-house teams, particularly in-house Silicon Valley product tech teams, could learn from agency work and have either chosen to ignore or don’t know about. Things such as user research and personas, prototyping and visions and sketch workshops and all of that, that could make in-house design better. But in-house design can get so caught up in ship-ship-ship-ship-ship-ship-ship, that it loses sight of that ability to pull back and frame the problem, not just try to solve the problem.

There’s a flavor of design agency for every type of design, and Adaptive Path, at least while I was there, definitely was shifting towards strategic design consulting. What’s interesting about that, is you’re starting to see the big consultancies move into that space. We just hired a woman who was working at Fjord, which was acquired by Accenture. McKinsey is spinning up an internal design practice. I just talked to someone who works at Boston Consulting Group’s digital design practice.

So these big management consulting firms have all caught design religion, and are building design practices, and I am sure they are charging two to three times for that exact same design work that Adaptive Path was doing, but they’re now applying it in these different modes. They’re doing it top down, and they’re doing the Lord’s work from a design standpoint, because they are influencing the highest level of strategy within these organizations.

Then for the more kind of execution-oriented design work, the challenge that agencies are facing is, it’s not just about a boatload of wireframes and then a boatload of mockups, and shipping that to someone. I recently did a podcast interview with some friends of mine who have a small consultancy in Austin called Funsize, and they basically approach agency design in an agile way. They are doing two week sprints, they’re working side by side with their clients. Which is not at all how I worked in a design firm before, but if you’re on that end where you’re helping people execute and ship, those design agencies are having to change how they work, and the relationships they have with their clients. So you’re seeing this kind of bifurcation happen from an agency standpoint where you’re either going way upstream or you’re in the trenches. Whatever that middle thing was? That’s what’s evaporated. Maybe what’s kind of gone in-house to some degree. To the degree to which there is some kind of strategic design work happening that is happening now in-house.

Des: You’ve been very generous with your time, so I’ll stop here. Thank you so much Peter.

Peter: My pleasure. This was a lot of fun. Thank you.

Keep in touch with Peter through his blog, Twitter, or Slideshare.

For more conversations on design, product management, marketing and other startup topics, check out all the episodes of The Inside Intercom Podcast here.