A Fine Balance Between UX and Monetization

Suzanne: Why don't you start by telling our listeners who are you? What's your role? Where do you work?

Jen: My name is Jen Choi. I am head of product development at McKinsey & Company. McKinsey, you may know, is a big management consulting firm really focusing on delivering strategic advice at the Fortune 50, Fortune 100 level.

McKinsey developed a almost internal startup group called New Ventures. Within New Ventures, there's a group called Solutions. In a sense, it's a consulting light model that is more affordable, it's scalable, and sustainable. I'm head of product development for one of them called OrgLab, which specifically helps organizations look at their business, the people, and decide if their organization structure is aligned with how they want to grow and how they want to drive towards their business objectives in a really increasingly complex world where there's lots of changes and macroeconomic shifts. Having the right people in the right roles has become more critical than ever. OrgLab is helping leaders make those types of strategic decisions.

Suzanne: For my own clarification, perhaps for the benefit of our listeners, is the idea that McKinsey is through this kind of product group, product-defying parts of its own service offering or frameworks? Or you're specifically taking the consulting model and pointing it at organizations that themselves want to develop products?

Jen: It's the former. Not that we're cannibalizing on our own kind of bread-and-butter, which is management consulting, but I think if you look at the future, software will be a part of every consulting engagement. Management consultants today will almost have to transition to be product managers, or what I call solution managers, where the product is not just a software application, but it's how do we talk to our clients? How do we guide them to make the right decisions? What's our go-to market? How do we market this externally?

I almost feel like management consultants today will almost have to be product managers in the future, because I think there's going to be a technology component to every type of strategic engagement that a consulting company does.

And so McKinsey - we've developed some really awesome proprietary solutions which eventually clients can use on their own. We do provide guidance on how to use it, how to deploy it, how to interpret the results.

Largely, the work that we do potentially could've been done by humans in a very manual way, but now we're putting those solutions at their fingertips and saying, "You have control of the software, here's how to use it. Here's how to interpret it. Go forth and use it to help you make decisions."

Suzanne: It's interesting because a lot of the time when we talk about product, we immediately in our minds default to B2C product. There's, of course, a lot of interesting B2B product as well, but in this context, they're similar in so far as they're these kind of end-user applications, and a lot of the time top-line revenue drivers.

It sounds like in some way what you're describing is the lesser talked about side of product but equally invaluable to organizations, which is creating tools that allow you to be more operationally efficient, that allow you to increase profitability from the bottom line. Not about necessarily replacing people, but allowing humans to focus on more interesting tasks and allowing automation to become just part of making the organization flow more smoothly.

Jen: Absolutely, and that's a great point. I think when people think about consulting, a lot of people think about cost cutting. How can I save money? Sure, there's always opportunities to cut costs, and you see that happen with offshoring, or divestments, or things like that, but it's also about looking at the people that you have and really leveraging their strengths and understanding what are the critical roles? Who are the key talent? Are we mapping those together appropriately?

Oftentimes, we create big organizations, but we're not necessarily tapping into the real potential of the talent that we do have. Part of the product really allows us to have that conversation with clients as, sure there's a number that may look great and shiny and compelling, and perhaps you can capture some of it, but the real value is look at the people you have, and you probably have some very talented people.

Are their skills being leveraged and optimized appropriately? Because those are the people that probably could make a huge impact. You've already made the investment of bringing them on board, hiring and training them. There's a lot that could happen if you put the right people in the right roles. That's the better conversation that we want to have, and not just where can we eliminate roles? It's really creating what is the right organization? 

Suzanne: One of the things that I tell students a lot, people who are coming to me looking to get into product management for the first time, is where are the opportunities? The obvious opportunities are, I've got an idea for a product or a working prototype, and I want to sort of bring it into market.

Along these same lines, the lesser known opportunity to become a product manager right now is, is there currently a process or workflow or tiny piece of technology that you have been managing perhaps without the title, but all of this time you oversee a series of steps inside of a manual workflow. If that is your position, you have an opportunity to bring sort of a product-centric point of view to that and say, "Well, let's treat this like a product. Let's treat this as its own thing, and let's look at how we can make it more efficient. Let's look at how we can acknowledge the users that are participating kind of in this sphere.

Jen: Absolutely. It's really interesting working at a company like McKinsey where you have really brilliant great talented folks with really diverse backgrounds, but they're traditionally focused on the business problems, and I think product management absolutely, you start at what is the problem we're solving for? How do we, in McKinsey's case, deliver good client impact? I think the perspective that I bring is, I'm an ex-consultant. I used to work in management consultant as well, and I made a pretty rapid and I would say sudden shift towards product management.

The reason why my role is interesting is I understand where McKinsey comes from, but now I can look at it from a technology lens. When you think about our product, which is a software product that our clients use, I would say it's easy to get trapped in business, business, business and not think about technology, and how do we build this product right?

That's where I've kind of come in and really try to put some discipline and rigor around what does good product development and management look like? I don't think that you can take someone who is a genius rock star management consultant and then all of a sudden say, "Here. Go run a software product." They're different. There are transferrable skills, but they're fundamentally different perspectives on how we look at what a good product is.

I think the product manager's responsibility is to consider the business. What is the impact to clients and our users? I think on the technology side, it's also how can we develop product in a sustainable and scalable way when everyone is knocking on my door saying, "What's the roadmap look like? When is this feature going to be built?" Understanding that things don't happen in product development overnight, at least not in my world.

Suzanne: They don't. Lots of people are going to be upset when they find this out.

Jen: Exactly, and that's kind of the art of product management also is baselining everyone to the same understanding that development engineers are a limited resource, a very precious resource. We can't just expect that things can be built and work perfectly if we're not putting the upfront investment and time into making sure that we define what that looks like.

Business people tend to say, "I want this. Make it happen." I say, "We can make it happen, but I need to sit down with you, understand the use cases, the problems we're solving for, what's the journey, how should it work? I want to bring in my product designer. What is the optimal flow? Define everything."

I was like, "Then we could build you a good product that is reliable and functional, that we can take to our esteemed clients without worries about bugs in production and things like that." A lot of it is introducing some discipline and just some knowledge around what is product management here at McKinsey? What should it look like? How do we adapt it for this very unique, what we call acid-base consulting, where we are still consultants, but now we're deploying an actual piece of software.

I always, again, tend to think of product as the app, the website, the software. Here at McKinsey, it's far greater than that. It's the solution, it's the delivery of that product as well in addition to, okay, how should this software work? What do we need to build in it?

Suzanne: Absolutely. It sounds a little bit like service design thinking in that construct where we're not just talking about any one single asset, but kind of the whole of the solution. Though it's curious when you describe it that way of management kind of handing down the mandate and saying, build this, and not to suggest that that's what happens here; in fact, it sounds like it's the opposite, but it does I think shine a light on the challenge that the average organization faces when they themselves want to create product.

I have personally consulted for organizations that birthed a product based on a whim or a good idea that a couple executives had. There was some budget available, they put together a few scrappy resources to work on it part time or whatever until it was finished. Then there's this sense of, well now we have this thing, what are we supposed to do with it? Or having to correct the understanding that when you create a product, you have a responsibility to nurture it, to help it to evolve, to continue to maintain it. Otherwise, you let it fester for two or three years, and then you have to rebuild it again because the platform that you built it on or the languages or frameworks you used are obsolete. No one has connected to the ROI in the first place.

Jen: That's an interesting point, and I think, again, a lot of organizations who want to get into technology that aren't traditionally technology organizations kind of go through that problem, or that kind of conundrum.

I think there's two things: I think there is value in getting together with folks and doing a rapid prototype and coming up with an idea that's rough, that doesn't have the elegant back-end code that really is just an idea that some people hack together. I think there's tremendous value in doing that.

I think what happens next is, there has to be a pause, then there has to be a business case that's developed around, do we want to invest time and resources against this because we think we have a really compelling idea that can then transform into something that's a growth driver for the company? Depending on the size of the company, maybe yes, maybe no.

If it were me, I want to see a really good business case for that. I want to see the rationale behind it. I want to see scenarios. I want the financial models behind it. I just want something that will prove to me that, yes, I can and I'm willing to take X amount of money and X amount of resources, because I think this idea has a chance.

The problem is, is when you start building on top of that, you're essentially creating a Jenga model, and that could topple any time if you don't stop. If it means refactoring, refactor.

I'm a big believer in do things right. The rough prototype can be a mess. Just take it and test it. Do people like it? Then there has to be some discipline around building good product, and especially in enterprise you have to optimize for reliability. You don't want to keep building on top of something that isn't solid because, again, that Jenga piece will eventually fall down.

Here at McKinsey, and I think generally my product management ethos is, I'm not feature-driven. If you come to me and say, "I want this feature," I don't really want to know about that feature, but what I want to know is what experience does that fall in? We have a product that people interact with, different folks interact with. There's a set of experiences that folks go through. There's a journey.

Sometimes it's sequential, sometimes it isn't, but I'm not looking at things at a feature level. I'm looking at what experience are we trying to solve for? We know our clients are doing this. We know our consultants are doing this. We also know the context in which they may be doing it. Mergers, divestments, outsourcing, automation. Within that experience, we build features. I want folks to shift towards that mindset of you can build a feature in isolation, but if it doesn't fall nicely within the experience of what someone actually does today, they won't know how to use it.

Part of my role is really getting folks to transition into that thinking of being today we're feature-driven, tomorrow we need to be experience-driven.

Suzanne: Another way to I think frame what we're talking about is, what's the why behind any of these decisions that we're making? Sometimes when it comes to features, we gravitate there because it looks cool, or it's a way to leave a mark, or we just tend to err on the side of tactical. I think y ou're speaking to that discipline as a product manager to say, "Well, hold on. Let's just not put features there because we can."

Jen: Exactly.

Suzanne: I'm curious. You brought up MVP in this idea of a scrappy prototype. It's interesting, this concept has been around now for some time. A lot of people know the term. They don't always know what it means, but they use the term. I even struggle with clients who come, they've got an idea that's here. I push them to bring that idea down six notches. Let's build this landing page and drive some traffic. Let's see what happens there.

Jen: Absolutely.

Suzanne: The resistance that I see a lot of the time is that fear of imperfection. We're talking about at the startup level, even. I'm curious how that fear of imperfection manifests when you're in an enterprise environment. Are there stakeholders who feel terrified to put something scrappy in front of a client, in front of colleagues?

Jen: Yes, and sometimes I am the terrified one. I've joined McKinsey not too long ago, so I've come into a product that has been developed and is out in the market today, but obviously, we're always looking to improve and enhance.

I think there's a distinction between putting together a prototype that is so blue sky, and putting that into market can be very scary because that becomes an expectation, that it's going to be this cool new thing, whether it's a redesign or it's a new feature.

When I mean prototype, especially in my context, we're looking at a small piece of functionality, and I'm saying let's just test to see if it works. A prototype for me is let's pilot it first and get the right feedback before you kind of broaden it out to all our clients or all of our users.

I think one thing is making sure that the folks who are deploying it and giving it to clients know its known limitations and know how to use it inside and out so there's no surprises. Two, I think it's around the conversations you have with the client around we have this new feature. We know that it's been asked for. People want it. We have it here. It's not perfect, but we're listening to you. We've heard your feedback. Here's how this feature can help you in your unique experience.

I think at a startup level, and I've worked at smaller startups where we had more flexibility I think to go ahead with something that wasn't quite perfect. We could always revert back, but I think the prototype is really for testing. You should have that mindset that the prototype, or the pilot, is really a feedback mechanism, but you have to be iterative.

I think once you go into that mindset and you position it right especially to your clients or to your users, suddenly it becomes a little bit more understood and there's a little bit more breathing room.

Suzanne: There is a freedom in embracing imperfection. Candidly, I've been embracing imperfection almost my entire life, but I recognize it's not everyone's experience, but there's something to say for like just don't worry so much about it. Let it be a little rough, and we'll make it better for the right reasons.

Jen: Totally. Working in software, for me, what's important is if it's a front-end thing, if it's something a user sees, we can change that, but I am concerned about making sure our platform, our infrastructure, is stable and extensible and configurable so that we can add new features. Let's get that in tiptop shape, that we can change how it looks, we can change the flow.

I'm all about let's be okay with things not looking perfect. Sure, that color's off, or that pallette is weird, or you're missing a button. Those things to me are cosmetic, but if you have a good foundation, those things can be remedied pretty easily.

When I worked in web and mobile, those user things are really important. There's a lot around perception. It's just a very different kind of ballpark when you talk about enterprise software, and you talk about something that's purely B2C, content-driven, and things like that.

Part of being a product manager, I think, is to be well-rounded. I personally loved working in a B2C area. I liked working at a bank, American Express, doing product. Then here I am at McKinsey, which is fundamentally a consulting organization where our clients are businesses and not necessarily users. At the granular level, a human is using it, but we serve clients.

Having a range of experiences I think helps you understand at what point you should be developing what. The difference between an MVP on web versus an MVP in software testing, so there's just so many components that are a little bit different kind of in each environment. I feel fortunate that I've had the chance to experience that in different organizations.

Suzanne: You actually touched upon I think two really important themes, one of which is a common one we talk about on this show. Frankly, it's one of the reasons the show exists, which is to say that being a product manager changes drastically from different roles. Hearing you frame it up that way I think is beneficial because it's not just about culture, which is another thing, and maybe we can talk about that a little later, but actually just the concerns are different. The concerns about a B2C product and getting the right things right, and the things that can be switched, as you rightly point out, are fundamentally different than those which can't be wrong when you're playing in an enterprise space.

The other thing is I think an important concept, especially for product managers who aren't inherently technical, and that's understanding the impact or the cost of change. There's always a cost to change as we know, and in software, that cost of change gets more expensive the deeper down into the foundation you go.

When you describe scalable infrastructure as an example, that is an important part of it, because if you need to be able to have burstability to 20,000 users or 2,000,000 users, and you know to some extent in a validated way that that's where this has to go, you have to invest very differently in web server configuration, very differently in database architecture than you do if you're building a SAAS product in PHP, and it's like I'll get my favorite misnomer of the landscape, a full-stack developer.

You might find a great developer or two who know a little bit about each layer in the stack, but there's one thing to hack together a simple MySQL database for a basic app, it's another thing to build encryption systems that hold deep financial information and how that's going to be leveraged.

Jen: In my role, I really protect my development team's time. They're a valuable resource that are working on incredibly important things. For me as a product manager, one of my big goals always is let the developers work. Minimize the disruption. If you know anything about developers, oftentimes they get in a zone and they just want to code and engineer, and I don't want to disrupt that flow. That flow is extremely productive and it makes us move faster.

For me, I do not want to put anything in front of my developers to actually engineer unless it is thought through, it's fleshed-out, it's spec'd out, they have the assets that they need to really move forward.

When I worked at HelloGiggles, we had two engineers, two, and then we went to one engineer, fabulously talented engineer. We could be a big more scrappy. We could involve her in more of the conversations up front.

Suzanne: Is it a her?

Jen: It was a her, and she's probably ... Sandra, if you're listening to this, you're a rock star engineer, probably one of the best engineers I've worked with, not from just a technical standpoint but the kind of thought leadership and bringing a perspective.

Suzanne: I love that.

Jen: Yeah, she's fantastic. When were in HelloGiggles, we had more room to experiment and, again, being a B2C product, our concerns are going to be different. For us, it's all about are we being authentic? Are we showcasing the brand? Are we really bringing forth who we are and being true to our name and our ethos? That was a big driver. That was our mission statement. For me, making sure that that was reflected across not just our website, but also in our ad products, what's really important versus if I look at OrgLab, very different concern.

We do, of course, care about the McKinsey brand and the name and new ventures and solutions, but we're also solving for specific client problems.

If you're in a scrappy five-person startup, you're probably not just the PM, you're the PM, you're the ops person, you're the marketing person. At HelloGiggles, I kind of had some of that where it's not just I'm focused on the experience on mobile. I'm also thinking what if we AB test this ad over this ad? What makes more money? There's other things you have to consider.

For HelloGiggles, absolutely our mission was let's be true to our brand, let's make sure that we're promising and delivering on the name of creating a safe and empowering place for young women.

Every company has its different ethos and focus and mission. As a product manager, I think you have to find the right balance of making sure that you're still being true to that in every decision you make.

Suzanne: It is a really diverse range of experience that you bring to this role. I'm glad that you brought up HelloGiggles, because it reminds me that you recently gave a talk at Facebook, and you were talking kind of specifically of the rise of native advertising, and we can, for our listeners, we can get the resource out, so if you're interested in that talk, you can look into it more deeply.

Specifically, it was rooted in kind of understanding your users and understanding their habits which is, of course, as we know, such a critical part. It's a critical part of the marketer's role, but that's always been understood, but it's such a critical part of the product manager's role. Can you speak a little bit about kind of your philosophy on that as it relates to sort of advertising and the importance of knowing the user groups and the user habits?

Jen: Sure. I think we all know we live in an interesting world of a lot of click bait and catchy headlines. Fake news has become the centerfold of a lot of debates that we're having today. We want to be a place that we need to weed out that kind of content. We're not looking for the eye-catching headline. We have a market. We have a niche group of users that love our content, that trust our content.

I think if we want to continue to grow and develop that audience, we need to think about who they are, what they like, what they don't like, what is intrusive and what is not intrusive. When you think about sites you may go to that you open it and there's five popups and all kinds of things going on, you have to page through ten pages, that's all because they want views.

What HelloGiggles does, and I think personally I am very hyper aware of sites that do this well, is around native. If you understand your user, you can start creating compelling advertising that speaks to their user.

Whether it's sponsored content that is still in the tone and voice of the site, whether you're creating a video series that are humorous, that, again, are in line with the voice of the brand or the company. Those are the ones that make the most impact not just from a monetary perspective but in an engagement perspective. If I'm a user on a site that's related to sports, I don't want to be served a ad that is catering towards insurance or something that does not pertain to me.

If they showed me a highly curated cool video series, I love to ski, on skiing, and there was a product that, like a GoPro or something like that, that to me is a much more effective use of my time spent on that site and will probably keep me on the site. I'm not leaving. I'm not having that high bounce rate because I'm like, oh man, just like another ad that I don't care about.

Oftentimes groups can be at odds. Sales sometimes wants to run something because it hit a mark and product or editorial. They say, "I don't want to do that". Sometimes product manager is the arbiter. They're the person that comes up with the solution that could maybe fit both. Product can kind of step in and say, "How about these alternative suggestions?"

I really do think product managers are at the center of it all. In every single role I've been in, I've touched every single other stakeholder group in the organization in some way or the other.

Suzanne: I want to stay on this topic for a minute, because it's one that gets me all hot and bothered on my own time, and you've brought up a couple things that I think are important. First of all, I think about sites like Mashable which, to me, is like the number one offender of this. They have been increasingly modifying their user interface and experience to essentially trigger false clicks.

The see more button which is weirdly placed right above the browser chrome, so that even with small hands like mine, I'm constantly hitting the ad, and there's a few things that are happening for me as a user. Number one, I'm getting pissed off. I'm not enjoying my experience of being on the Mashable content platform. I'm not enjoying my product experience there.

I'm certainly not retaining the information of the brand whose ad I've been forced to inadvertently click, but if I am so lucky as to see it, I'm definitely sweeping that brand into the doghouse with all of the other offenders who sort of forced me into this position.

I think to myself, why are people participating in this? I understand for certain content platforms there is that pressure of which way are we going to go? Are we going to swing toward fiercely protecting journalistic integrity? Or are we going to swing toward click-through rates and revenue dollars? Then the advertisers themselves, aren't they wanting to make sure that the users who are seeing those ads are seeing them in a positive light? It seems like, no. That's part of it.

Jen: It's a really fine balance between creating good user experiences and monetizing. There's no secret formula as to what will yield the best user experience and also yield the most money. I think a lot of what I've done as test, let's run something for a week and see where we see drop-off or uptick in metrics. That's where testing becomes really important, because the placement of something can dramatically change conversation rates or whatnot, and you see this a lot in ecommerce.

I totally agree with you that there are ad units that are prevalent on a lot of sites that are really unideal. They're at a place that you'll inevitably click it because just the nature of how we swipe and how we just share and interact with our phones. I think there's kind of learning on everyone's part.

As a publisher, it's important that you respect your users and understand that you do have to protect and have a role in protecting the journalistic integrity and making sure that your content doesn't just become a farm mill of click bait. I think HelloGiggles has done a great job of that, because we do have a very dedicated loyal group of people.

Suzanne: I like that you still refer to it as "we" even though you're no longer with them. You have to let it go, Jen,

Jen: I do, but I still consider myself part of the family. I always will. They're just such a great group of folks to work with who truly do care about our users.

Then there's the advertisers. I think advertisers need to understand that we should not be living in the age of the banner anymore. We've got to go beyond the banner. Again, that's where native really comes into play is, let's create a story. There's so many other ways you can advertise that is not a banner. Influencer networks on Instagram, on Twitter. That's very compelling these days. Find the right people to be ambassadors of your brand. That's not intrusive. If you have followers, they're going to be looking at your Instagram feed.

I think that's part of the advertisers to say what new ways can we actually create stickiness with the people that are viewing our ads? It's not the banner anymore; in fact, it's probably detracting people from coming to your brand.

I really believe that. It's just tough to find the balance. You just have to keep testing what works and what doesn't and find the optimal mix of where are we making money? Where are we not compromising on our user experience?

Suzanne: The other side of that sort of same argument and that balance is, if you look at products like DoubleClick or Facebook Pixel. These products have been tremendously helpful for creating ever present ads. You put a pixel in. If somebody comes, you can stay with them forever, but what I think people are starting to connect with is it creates a stark contrast in certain experiences.

You talked about wanting to, yeah, I want to see a ski ad when I'm on a sports site, because those two things relate in my mind. If one day I happen to be over here at the Thinx website, because I love Thinx by the way, they're one of my favorite brands. Then I'm somewhere over here on a product management blog. I don't want to see those Thinx ads. I don't want to be reminded of that brand in this moment; in fact, you would have a much higher conversion rate serving me up an ad that feels like an extension of the content that I'm there to see and feel.

Jen: I think there's a really interesting phenomenon now where back in the day we wanted to see custom pages that were designed for us. It just makes it feel more personal. I think that's still right, but now we're getting to a place of intrusiveness, where you can be ... Sometimes I get creeped out where I may be talking about a brand, and then I'll see it right in my Instagram feed and may Facebook feed. It's just weird. It's like a big brother phenomenon.

I'm seeing folks starting to get apprehensive about that, where the brand is following them on every single medium that they are, because we have so much data on what they visited, their shopping carts, and things like that. It's interesting to see how we wanted something curated for us, but not too much. I think it'll either be a push and pull.

There was a great talk I listened to by the, I think the CEO of Upworthy. He was talking about how in the future everything will be curated for you. He said you'll be seeing things that they think you want to see but not necessarily what you should be seeing.

It goes back into if you are a hardcore liberal, and you're seeing all these liberal things, is that helpful to society? You should probably want to see the other perspective. I think there's almost a push towards reverting back to maybe not being hyper-curated. I think the idea of following you everywhere is not going to work.

Suzanne: We call that stalking in the real world.

Jen: Right, and no one wants a stalker. There's laws against that. I think what I hope to see is, it doesn't follow you everywhere, but it may suggest other things similar to that product in the format, again, of the page you're on now.

Suzanne: We have been talking about the differences between enterprise and startup. I think you're rare in so far as you've lived and played in both of those spaces very equally. That's not common. Sometimes people will go to an enterprise organization, quickly realize that's not for me, and then never return, and sometimes it's the opposite. You sort of were enterprise, you went to startup, you came back to enterprise. What is your sweet spot?

Jen: That's a great question. I was a management consultant for about four years. When I was consulting with executives, it was such a big focus on technology. What should we be doing in the digital age? All these kind of buzzwords. I thought, "Man, that sounds cool. I'm kind of young-ish. I want to get into that." I thought, what role would be good for me, because I have a business background. I thought, as I read through the Internet and kind of thought about what are the roles that are in technology today? I thought product could be a good fit for me, a couple reasons: One, stakeholder management or working with tons of teams and people is really important. I did that in consulting.

Being able to be articulate and clear in your communication. I had to learn that in consulting. Being able to manage teams. Again, I had to do that in consulting. I think the key for me was, and for anyone who's looking to get into product management, if you're in a marketing, sales, whatever role that's nontechnical, I think the key is to find the right transferrable skills; being articulate, being clear in communication, working well with the teams, being an analytic thinker, being able to just roll your hands up and get dirty. Taking a backseat when you have to.

When something launches, I'm always making sure my development team is at the first and foremost ... Like you've got to be the unsung hero. I think if you want to be a product manager and you want to get into it, it's demonstrating those skills.

Then for me, the reason why I kind of went all over the place is I wanted to get a really well-rounded experience. Amex was my first product role, because they took a gamble on me. I tried to show them I have these transferable skills, I really am passionate, I want to do this, give me a chance.

Suzanne: Wait. When you applied to join American Express, you were that quintessential I-don't-have-any-product-management-experience, please-hire-me-as-a-product-manager person?

Jen: Yes.

Suzanne: This is good, because there are a lot of our listeners that are precisely in that role. Tell us how you succeeded in convincing them.

Jen: It's an interesting story. I joined Amex in September in an internal consulting group. Six months later, I'm told we're re-orging, my job no longer exists. They were great. They gave me a lot of time to find a new position within the company. One of the great things about Amex is they really encourage people to try new roles.

I found one role, and it was a senior product manager, so it's not even just like a product analyst- it's a senior product manager role in a business unit I never worked in with people I do not know in the company. I met with them, and I said, "Listen. I have zero product experience, but I read about product, I'm in the know about it, I'm really eager to learn about it. Here are the things I've done in my past that I think translate nicely into product. I'm willing to come in and work hard to compensate for my lack of experience in this senior product role. Will you give me a shot?"

They went away for a while. I think they liked the fact that I was really going to be scrappy and kind of get my hands dirty. The other thing I liked is, I think companies sometimes like people without product experience, because you have a fresh perspective. You don't come in so rigid and defined and you've got to run agile and scrum this way. Our retrospectives have to use this template.

You come in with I don't know that much. I can pick it up, and then I can adapt it to your organization or this team. I've heard this a lot from product leaders that sometimes they really prefer that. You can hire a rock star guy from Google or Facebook, Amazon, Microsoft, but they may not be the right fit for a six-person startup, but they'll come in with all these ideas about how it should be done.

That was one of the other things I said is, "I will bring a fresh perspective and adapt it to this team that is slowly adapting agile." I was confident about the role, and then they told me, "Actually this role has been frozen, so we're not really sure if this is going to open up or not." I've had about four weeks until I have to just leave.

Suzanne: From your other job that...

Jen: I got my notice from my job at Amex that I got laid off from. I was like, "Man, I don't think this is going to work out, so I'm going to buy one of those around-the-world plane tickets and just travel for like three months." I was planning my itinerary, and three days before the date where I was supposed to leave American Express, they called me and said, "It's re-opened. We'd love to give you the position."

All the stars had to align for me, and I almost never got into product. I don't know how I would've gotten into product if this didn't happen. Knowing me, I probably would've done some finagled something, scrappy, and got my way somehow, but that was really the door opener. I think those things about transferrable skills, the determination, and bringing fresh perspective are all really good selling points if you don't have any product experience. I had no digital experience, really. I was a straight management consultant.

Suzanne: I love these stories. We've had a few guests on the show share similar experiences, and I think tenacity is the takeaway. A colleague of mine used to say, "If not in through the door, then in through the window. If not in through the window, then in through the ceiling." You do have to fight for it if you want it sometimes. Sometimes the stars can align and things can happen, or there's a lot of people who get promoted to the product manager role, they didn't necessarily ask for it, and they're in the position of listening in and going, "Yeah, that's my thing. How do I do this job? What is this job?" Tenacity counts.

Jen: It's not just getting the job. It's once you get it, you have to prove yourself extra. I started going deep into the technical architecture and diagramming it on my own, which is we have someone kind of in charge of that, but I was like I want to be so involved in every part of the product. I want to understand the database. I want to understand how data flows, the calls, APIs. I want to show them that I care not just about the product from a user perspective and being the advocate for the user, I want to go deep in the technical stuff.

I started kind of teaching myself some basic code. I started blogging about it. I was like I want to prove to you that I not just want this job, I want this as my career, and I'm willing to make the investments in myself developmentally to prove to you that I care about this, I care about the product, I care about the product as a discipline, and I'm willing to go and do what I need.

That's kind of to your earlier question, why I've kind of hopped around is, I want to get the varied experiences, then I went to a more technical API product role. All of a sudden, I'm reading and writing JSON. Do I know anything about it? Not really, but I understand how you APIs work, how authentication, web hooks.

For me, I think if you want to be a good product manager and you care truly about it as a career, I encourage you to get varied experiences on both technical and nontechnical enterprise and non-enterprise. I think you'll learn so much about how to handle these kind of different unique situations.

For me, I was like I'm just going to go into it. If I'm in it, I'm going to go full throttle. I blog about it. I read about it. I try to attend conferences when I can. That's just a commitment to this is my career. I found what I want to do for the rest of my life. How do I hone it? How do I refine it? How do I get the experiences I need to get to where I want?

Suzanne: Jen does blog a lot and, in fact, we've got a bunch of content that you've written that we're going to be putting up on the site as well, so you have an opportunity to hear all kinds of insights beyond just this awesome conversation we're having.

That's at least the second time in this interview that you've organically led me to where I wanted to go next.

Jen: Sorry. I probably took you on a crazy trip, so I apologize.

Suzanne: No, no. We like to wrap up by doing a segment called "Get the job, learn the job, love the job," and you just organically I think spoke to get the job, which is advice for how to get in, especially without experience. Talk to us about the hard lessons. Have you, either yourself, or seen in other collaborators, people fall down in the PM role because there are certain aspects of it that can be more challenging in practice than in concept?

Jen: Absolutely. I think with product, it's part art, part science. I think most people can reasonably run an agile or product development process. There are things that we know we need to do. I think it's the conversations that can be difficult. That's the art part. A lot of product managers have to really balance between all these requests coming in from the different groups saying, "I want this. I want that. Where's the roadmap?" How do you prioritize? It's being able to talk to those people and understand when you need to push back, how you need to communicate to those people.

That to me really distinguishes a good product manager who can check off the boxes and get a feature out the door to an awesome product manager who can really be the person that others view as the GM of the product, that can have the hard conversations, that know when to push back, who understand the business, the macroeconomic climate, how to prioritize. It's a continual balance.

I think the product manager role is like you're always walking the fine line of what do I build? How do I communicate? How do I make this product awesome and balance all the feedback I'm getting at the same time, and make sure people are happy? Not just your users, but everyone else in the business. That's I think the hard part of product management is finding the right way to do that, especially it can be difficult when you're in a big company and you have a lot of people asking you where's this, where's that? And putting your foot down when you need to.

Suzanne: If that's the hard part, what's the fun part? Why do you love product so much?

Jen: For me, it's being able to, whether it's B2C or B2B, seeing people use something that you've built, that you've spec'd out, that you've thought about for months or weeks, and then seeing a result come out of that. At McKinsey, we have specific outputs that can really help influence a C-suite level executive to make a decision. For our users, it's so gratifying when they tell me, "I love the site. I feel safe here. It's my home. I'm part of this community," whether it's for an API product manager, opening up your platform for other developers to come in and plug in new products on top of yours.

I think that's the best part is, you see real impact that's tangible, and you're creating something that's value add. A lot of times it's hard to see that in your job. You think you're doing it, but in product, you can. Also, just the creativity, especially at McKinsey, there's a real environment of I can just speak up. If I want something, I'm like, "What about this? Let me just go work with one person and hack it together." It's an idea.

I think that's a great perk of being a product. You can just test ideas. Hopefully where you work has the flexibility to allow you to explore that, but you can create brand new stuff, stuff that doesn't exist today. That's really cool. You can explore something that you had in your head since a year ago and sketch it out on paper and maybe put together something really rough, and then ask some friends to use it.

I think having that creativity and that creative license to be able to take ideas and actually see them in application is one of the most rewarding parts of being in this job.

Suzanne: Well put, and I couldn't agree more. Talk to us about resources. Are there any books, blogs, podcasts that you listen to or love that you think are just like gold, hidden gold waiting to be mined?

Jen: Yes. I'm a huge podcast junkie, which is one of the reasons I'm super excited to do this, and I'm also an avid reader of technology and non-technology books. Obviously, Ken Norton, he's kind of the godfather of product. I love what he says about product management and finding the right people. I love First Round Capital. I think their blog produces a lot of really interesting content, not just on product in general, but some provocative ideas around product.

You talk about Airbnb and how they have these really cool elastic teams. The three types of product managers you want in your organization depending on what stage you're in. That's a great one. Podcast-wise, I love The Moth, which I know is not technology focused, but I think there's something to be said about storytelling that's important, and a part of a product manager's job is you have to tell the story. You have to know why this product matters, why this feature matters, why it's valuable.

I think there's something to be said about telling the right story, so I love The Moth to help me kind of look at great storytellers, what makes a story really good, and I think Malcolm Gladwell in Revisionist History does an impeccable job of telling a story centered around an idea and a theme. TED Radio Hour does that really well, as well.

I love this podcast, it's fairly new, called How I Built This, by NPR. They interview founders of companies and how they've kind of come to where they are, basically how I built this. There's one I would really encourage I think folks who don't come from business or product backgrounds to listen to, and it's the Airbnb episode, around the founders who are these art students from RISD who don't have any business background. They're not indoctrinated by econ 101 or poli sci 101. They're designers. They're art students.

If you see their journey and how they pivoted drastically sometimes... if, one, you want to start your own business or, two, you just want to know kind of the genesis behind some of the most powerful brands in companies today.

Suzanne: I love that. I always equally love and feel equally terrified in this moment when I ask guests about this, because if a long list like that one comes up and there's a bunch of stuff that's new, and now I know that I've got a whole bunch of reading and listening ahead of me, which is exciting, and also there's so many resources, that it's like sometimes you just want ... Can I just take a six-month timeout, consume it all, catch up, and then keep going? Of course, we can't.

Jen: On the books front, Sprint is a great book, how to test ideas in five days. Building Products That Inspire, I think, by Marty Cagan, is like a good one. Then I like the one, I think it's called Think Fast and Slow. That's a great one as well.

I think it doesn't have to be a product-related book, but I think there are a lot of good books. I love Tiny Beautiful Things, which is a book around kind of struggle and perseverance, around life in general. I personally think a good mix of fiction and nonfiction, technical and non-technical, can always help you. I don't purely just read product blogs and things like that. Hence, like The Moth to me is a great one I think that product managers will probably overlook, but give it a whirl.

Suzanne: Last question for you, Jen. Do you have a personal or professional mantra or sound byte, some philosophy that you use to govern yourself in life, in business, or in both that you want to leave behind for us and our listeners?

Jen: Yeah. I'm not sure if this is a great sound byte in terms of being a pithy one-liner, but I'm a really big believer in fail-fast. For me, I'm kind of rogue in a sense where I will do something pretty much until someone tells me not to. When I have been told not to, it can be considered a failure, but I fail fast. I get up and I literally look back at what I've done, extract the learning. I write them down on post-its, then I start, I shift. For me, when I fail, I fail. That's it, but the next day I'm onto something else, a new idea, a new concept, a complete pivot. That to me is really important as a product manager is to, you gotta be quick, and you have to be quicker than ever. If I look at where the industry is going, there's all kinds of product roles, and you just have to be able to get up and go.

Suzanne: Love it.