Product Hero is our bi-weekly series to highlight outstanding members of the product management community. These industry leaders share tips on processes, team building, how to be a better product manager, and who they are outside of their careers. This week our product hero is Melissa Perri, Founder and CEO of Produx Labs.
C. Todd: I’m lucky to be joined by Melissa Perri. Thanks for speaking with me Melissa! Can you start out by telling me more about your path to product management?
Melissa: My design background actually goes back to high school. I went to an engineering high school, which a lot of people don’t know. It was a very good high school mostly focused on math and sciences. One of my electives was called Computer Applications and they taught us one of the first versions of Photoshop. I became really hooked on it and started competing in these design competitions with the Technology Student Association. My competition was called Desktop Publishing.
Before that I made all the printed materials, like brochures and menus, for my dad’s restaurant on Microsoft Word applications and Publisher. My teacher convinced me to use Photoshop in competition while everyone else was using Publisher. I won that competition, went on to win the national competition the second year I competed, and won states every year. I started really getting into design that way.
When I went to college, I wasn’t really focusing on design and instead chose engineering. I quickly hated chemical engineering and transitioned into operations research engineering. I still liked design and joined Cornell Marketing as one of my two on-campus jobs. I made all of their marketing material for the organization, using the Adobe Suite. I designed all the fliers for campus activities and fooled around with the logos and did a lot of design work for them.
I got started in product when my friend working at Capital IQ sent around a job posting looking for developers. I replied saying I could code, have a design background, and understood engineering. My friend connected me to the Head of Database Engineering who thought my background was good in for Product Management. He brought me and taught me how to do that role. I was one of two product managers then.
Apparently, design plus code equaled product manager for them. That’s where I started learning about it. They were really very waterfall, which everybody was ten years ago. They taught me how to do product specifications and how to gather the requirements from the business people. And apparently I did it very well because they said I was awesome. They really liked my work, probably because I wrote like a thirty-page spec for a landing page. I never had to talk to people about product. I thought that was the key to success – documenting every little thing.
When I got to OpenSky, I quickly realized that was not the way product management worked because I tried that with my developers and a month later they gave me something back that was completely not what I wrote. They were like, “I didn’t read that shit. Are you crazy?” They’re like, “You wrote forty pages for this stupid little database thing. You think I’m going to read it?” That’s when I stopped writing specs.
C. Todd: Tell me a little bit about what are you working on right now.
Melissa: Right now I’m focused on educating product managers. I am developing an online school, which I’ve been doing a lot of experimentation around. For the last couple years, I have been doing a mix between coaching in-house at organizations, where I come in as a consultant and guide them in good product management processes … And I’ve been doing outside workshops and education. I realized over the last year that I missed building products and I wanted to start a school for product managers which would be in-person in New York. So I did what I do. I put up a landing page, and tried to find people to interview. What I quickly found out was that a lot of the people who were interested in this were not in the US. Or they were in the US and they were not in New York. I did get a some interest from people in New York but I realized they had solutions readily available here, like General Assembly. The others didn’t so two-thirds of the couple hundred people who signed up on that landing page the first week were not in New York.
My school called Product Institute is focused on discovery, improvement, and optimization rather than focusing on how to do story points or write user stories. We don’t even go over that in this class. It’s really about how to think like a product manager.
I’ve been full speed ahead on that, doing some more in-house training for large clients and coupling it with the online portion, getting feedback. I’ve experimented around the most effective videos for people to watch, what keeps people entertained, what’s the best content. Now I’m putting it all together and am going to launch it within the next month. People can head to productinstitute.com for more information.
C. Todd: You have a good story about your recent travel to the UK. You had this interesting experience about feeling like you were blamed for something when it really wasn’t your fault. You put your product management hat on and wrote a little bit of a blog post about that. I’d like to unpack that a little bit. Maybe tell us a little bit more, the story behind it, and some anecdotes that maybe aren’t shared in the blog post that we can talk about here. Then dig into how that relates to product management.
Melissa: This all started where wonderful airline mishaps start, and that’s United Airlines. I’d been flying United this past year because they go to most of the places I have to go to. On the way to London this time, I flew business class. I don’t do that often but I was exhausted. On the way back, I said I’ll look for one of the cheaper fares and try to take economy. The lowest cost ticket was business class to Ireland, so I had to do a layover in Dublin and then economy class on the way home. I said, “Oh well it’s at eight o’clock in the morning. I have to wake up at the crack of dawn to get to Heathrow. It’d be nice to take business class, even if it’s for an hour. Then I’ll just take economy on the way back.
So I booked that. On my reservations, on my confirmation and everything, it says that I was booked in business on Aer Lingus and then I went to check in at United. At first I tried to stand by to see if I could do a direct flight, and the lady was like, “No you can’t do that!” I was like, “That was mean but okay. You could’ve just said no I’m sorry.” Then I went to Aer Lingus to check in and they gave me seat 27B and I said, “Oh but I think I’m booked in business class.” I showed her the United thing and she’s like,”I have no idea where that’s coming from because business class does not exist on this flight.”
I was like, “What?” I tweeted at United and said, “What’s with this bait and switch? You sold me a business class ticket and there’s no business class on this flight.” The person asked me to DM them and I DMed them. I sent them a screenshot of the app where it says business class and everything. They wrote back and they said, “Well Z class isn’t business class on United.” I’m like, “Well you literally wrote the word business on my ticket. It doesn’t say Z class on here. It says business class.” They’re like, “YOU DIDN’T BUY A BUSINESS CLASS TICKET.”
It’s an hour flight so I’m not going to sit there and hem and haw about this all day, but I felt very duped that they would do that. They were just saying, “This is a bug. We’ll have our digital team look at it.” I’m like, “No no no. You sold me a business class fare.” I continued to argue with them and I tweeted about it again. They wrote back to me, “Melissa, you did not buy a business class fare.” I was like, “Come on.” It was just the rudest customer service I’ve ever seen.
C. Todd: One of your other posts was somewhat similar in talking about goal and target conditions. In this case, United wants the passenger to do this thing and the target condition is this thing. How do you actually go from one to the other? Can you maybe explain that a little bit for our readers?
Melissa: Sure. That’s the post on Product Strategy. The goal and target condition is a larger framework for product strategy. The goal that you’re really looking at is usually a business goal like increasing customer satisfaction or fixing our code so that people get what they book a hundred percent of the time, thereby increasing retention of users. Product managers have those goals. Teams are assigned those goals. Then you break it down with smaller, achievable targets which are target conditions. That’s a smaller goal on the way to get there.
United should have a goal around the retention of customers. The way you retain customers is that you don’t have terrible experiences with them. From a product manager standpoint, if I was part of the booking process, one of my target conditions should really be that customers get exactly what they buy a hundred percent of the time. We don’t have to change our fares that way, or if we do, we’re able to mitigate it with very low risk that they will be unhappy. Then I would try to really understand what can we build or what can we improve in our current systems to help meet that benchmark. Checking fares across partners is key. Aer Lingus is a partner. They’re not under the United reservation system, which also makes it frustrating for the user to check in. I can’t check into my first flight online because Aer Lingus won’t let me. As a product manager for United, maybe I would look into fixing that. Try to partner with them if I see that it’s causing tons of dissatisfaction for the users in that they’re not booking with us next time because of this.
Or looking at the classes of fare that Aer Lingus has, making sure that we have it correctly in the code. Ensuring people are going to get what they expect at the end of the day. I think those are the steps that you would take to try to meet those target conditions and really understand that all of this is intertwined between your business goals and your users’ problems. The way that you reach business goals and the way that you create value for your company is by solving user problems.
That’s what it is at the end of the day. I think we miss that a lot when we get so heads down in delivering features. Because we say, “Oh the value is this feature,” but that’s not it. The value is that the feature actually solves the problem for the users. It’s an outcome that matters, not the output. We miss that so much when we get into crazy release mode.
The value is that the feature actually solves the problem for the users. It’s an outcome that matters, not the output.
Melissa Perri
Founder and CEO of Produx Labs
C. Todd: Because you have the vantage point of working with a lot of different teams, have you seen patterns in how they measure the success of their products? Where have you seen good examples of that and where have you seen bad examples of that?
Melissa: I’ll give you the bad examples first because that’s what I deal with on a daily basis now. Every team that I come in to train is usually transitioning to Agile and they’re still measuring the success of features as the fact that they shipped it. Literally, “Did we ship this product? If we did, okay good.” That’s it. There’s no follow-up to it at all. A lot of it is still very delivery focused.
Teams that are doing it well, though, are very much in line with measuring success through achieving business goals. “Okay we shipped this product but we’re not done yet. We will hit success when we actually meet our measurable business objectives and we’ll keep iterating on our product until we get there.” Good goals are around things like, “We increased our conversion rate five percent by doing X, Y, and Z.” Maybe there are a bunch of different features, maybe there is one. It’s a system of enhancements that actually work toward a measurable outcome rather than just saying, “We shipped it,” and then moving on.
Most large organizations are not aligned by those things. They look at the digital section as a cost center or this place that’s going to optimize everything and put everybody else out of business so we don’t have a large headcount. They’re looking for these tangible features that come out of there and they’re saying, “You’re only successful if you build these fifty products this year.”
Companies that are actually doing well and make it, for example, Spotify it’s hard to even pinpoint a lot of companies that are actually doing this), but a lot of Silicon Valley companies do this as well, they have measurable outcomes that each team is centered around.
I don’t necessarily use the exact format of the OKR. I always just tell my team, “Let’s just figure out what we’re supposed to do for the business and go back to our overall strategy canvas.” That product strategy canvas starts with our vision for where our product line is going. Then we have this challenge which is the first measurable goal that usually sits at the middle management level. This is the first measurable goal we’re going to hit. Then the target condition are the teams’ objectives to help hit that higher goal. They’re all very outcome oriented. They’re not about shipping features. I yell at people if I see that in there. It’s never about delivering something. It’s always about achieving something. For the user, for the business, it doesn’t really matter which one your choose but it should be balanced in the end.
It’s never about delivering something. It’s always about achieving something.
Melissa Perri
Founder and CEO of Produx Labs
C. Todd: What have you seen that’s worked in terms of roadmapping? How does that play in teams’ processes?
Melissa: I haven’t seen many things that worked. A bad perspective: almost everybody has a Gantt chart. Even if they’re trying to be Agile, they have a Gantt chart. It’s because in large corporations, the budgeting process is so screwed up that they have to commit to building features to get the money to build those features and then they have to deliver it by a certain date. It all stems from there. That’s the biggest issue.
I spoke to some people at Spotify. They were telling me that their roadmaps are more like bets. They set the direction for where the company’s going, and they let the teams come up with ideas on how to get there. The teams have to pitch what bets they want to take to management. Management then gives the budget to go and try it.
The product management team can come back and say that bet didn’t work. They’re not beholden to dates and delivering necessarily what they promised. Management knows it is what it is; it’s a bet. If it doesn’t work, at least we contained it in a small, experimental way to actually test it. Their roadmaps are structured more like that. I don’t know exactly how they’re laid out, but they have a series of big bets for the company and they position them for sustaining, improving, and doing innovation.
C. Todd: What is missing from the product management conversation right now?
Melissa: So much. Discovery and experimentation in small ways. Some companies do this very well, but the majority of companies don’t do this at all. They’ll do the user research, they’ll understand the problems, and then they’ll build an MVP and their MVP is the first version of the product. They don’t descope it, they don’t experiment. They just build a first version and launch it, then usually they’re not measuring success on it. What’s missing is a logical step-by-step approach of answering the lost list of questions the team has about the product before coding anything. I don’t think product management is doing that right now.
That’s why I’ve been using something called the Product Kata to teach teams to take a step back. Teams will think they have all the information on their users, understand their problems, and go right to building. Then they’ll start specing immediately and breaking down work and writing backlogs of stories for developers. They don’t stop to understand the context of the problem or even in the solution phase, consider all the details before building features.
The Product Kata works with the target condition of your strategy and helps you identify obstacles standing in your way of reaching target conditions. It’s designed to make you stop and assess what you know and what you don’t know, which gets you coming up with a lot of questions.
I do a little workshop with my teams on the Product Kata, they have to go make paper pizzas for a customer. A customer usually has a ridiculous set of requirements but I don’t tell my teams what they are. All the teams just start making pizzas. They’ll go up to the customer and ask, “What do you want? Do you want pepperoni, do you want onions, do you want peppers?” Then the customer will tell them what they want and the team makes a normal pizza. They don’t stop. Then I stop the teams like fifteen minutes in and I say, “What obstacle is standing in your way? What don’t you know right now?” When they start to realize it’s the context in which the customer wants to eat the pizza, that’s when they can start solving it.
We rush to build things and get it out the door and that’s partly because we’re measured for success in delivering features instead of learning and hitting goals. That whole discovery phase actually lets me think about uncertainty and what I know and what I don’t know and logically experiment in ways that don’t even involve software to uncover more certainty. That whole piece has been missing for so long in product management and we don’t teach it very often either.
You’re not the product god. You’re just one person in the machine that has a specific role to do.
Melissa Perri
Founder and CEO of Produx Labs
C. Todd: What kind of advice would you offer a new product manager, regardless of how they got into it?
Melissa: Become BFFs with your team. I think that’s step number one. The best products I ever created were with the best team I ever worked on. I don’t think that was mutually exclusive. My first real manager who showed great leadership was Chris Keene from Open Sky. He really pushed me to build relationships with people in the company. Chris was a very good manager as well because he forced me to make sure I understood where other people were coming from and made sure I got to know my teammates better. I think that made all the difference. We became a very close team and we did really awesome stuff. Make sure to hang out with your team. It doesn’t always have to be at work. Grab drinks. Make sure you know your developers and then lean on them, ask them their opinions, ask them for advice. Let them give ideas and be receptive to it. You’re not the product god. You’re just one person in the machine that has a specific role to do. I think, even if you’re new, you can go so far if you have a great team behind you. They’ll help you. If you are close, everybody helps each other. I think that’s the most important thing I learned.
Another one is start talking to other product managers. Find different ways of working with it. Experiment until you get it right. Find a process that works for you, master it, then make it better. Start questioning, “Can we do this better? Can we do that better? What if I try that?” Take small, little calculated risks around what you do everyday, too, to make sure you can keep improving your skills. I think that’s key. Don’t just follow some training or some advice for face value. Give it a shot, try it for a while, but then question and make sure, “Is this really right for me?” I think we all need to get a little bit better at that instead of just following whatever the flavor of the week is.
C. Todd: When you’re not productizing and product-scheming and product-strategizing, what are some of the things that you do? What’s fun for you?
Melissa: Most of my hobbies are usually work related, it’s sad to say. However, three years ago I started taking bass guitar lessons from a neighbor down the street. I also love cooking. The rest of my family works in restaurants.
C. Todd: No way, that’s awesome. Well thanks for being one of our Product Heroes!
Interview notes:
- The commonality amongst successful product teams: measuring success through achieving business goals, and not measuring success purely through the action of shipping features.
- Learn a new framework: Melissa has implemented a four step systematic way to plan and experiment called the Product Kata. Each step makes teams focus on the specific goals and outcomes of implementing a new product or feature.
- Read more about Melissa and Produx Labs and follow her on Twitter.