Podcast: Play in new window | Download

Sean [00:00:19] Hello and welcome to the Product Momentum Podcast. This is a podcast intended to entertain, educate, celebrate, and give a little back to the product leadership community.

Sean [00:00:32] Paul, I can’t believe we are at the fiftieth episode of the Product Momentum Podcast.

Paul [00:00:37] Who’d have thunk?

Sean [00:00:38] Who would have thunk we’d ever get here? I’m so excited. Since Joe Hoffend and I started it, it was a twinkle in his eye a couple of years back, I can’t believe we’ve had the honor to interview such incredible guests and produce such incredible content for the product management space. We’ve got to celebrate. We got to do something about this.

Paul [00:00:56] We need to celebrate. Absolutely necessary. We’ve been graced with a few guests that I never would have imagined being able to pick their brains. And I think it’s only fitting that we give back to our listeners in a way as meaningful as we can, sharing a couple of books that our guests have written, contributed to, recommended. So we’ve got two stacks of ten books each to give away to two folks listening right now.

Sean [00:01:23] 10 product leadership books. So go over to giveaway.ITX.com/50. That’s giveaway dot ITX dot com slash fifty, the number 50. It only takes a couple of minutes to fill out the form and we’re going to choose to focus to win ten bucks each.

Paul [00:01:40] From Sean and I, thank you to everyone. We couldn’t have done this without you. We appreciate you being part of our journey. Let’s get after it.

Paul [00:01:49] Hey, Sean, how are you doing today?

Sean [00:01:51] Doing great, Paul. I’m on cloud nine after that interview.

Paul [00:01:24] I am too. I have a question for you. What if I told you that laziness was an attribute that we need to start hiring for?

Sean [00:02:01] Yeah. His definition of lazy product leadership is authentic, insightful, and useful.

Paul [00:02:07] I think so, too.

Sean [00:02:08] I think we should change the definition.

Paul [00:02:11] At so many points today, I think we found unconventional bits of wisdom that are really just common sense that isn’t so common.

Sean [00:02:20] I would agree. And if product’s not fun, you’re not doing it right.

Paul [00:02:23] Let’s get after it.

Sean [00:02:25] Let’s get after it.

Paul [00:02:28] Welcome to the podcast. We are excited today to be joined by Christian Idiodi. Christian has been a product leader for over 15 years, building teams and developing enterprise and consumer products that have shaped companies such as CareerBuilder, Merrill Corporation, as well as clients such as PayPal, Etsy, Starbucks, Dell, and Macy’s. Christian is passionate about helping companies implement the discipline of product management to build world-class products and new technologies. Christian, welcome to the show. So happy you’re here.

Christian [00:02:54] Thank you, Paul and Sean. I’m glad to be here.

Paul [00:02:57] Excellent. So I want to get right into it. You’ve been leading not just product managers, but product management as a practice, pretty much since day one since it kind of became known as this modern concept. What are some of the risks that product managers face? Where are some of the things that we’re looking at today as obstacles to overcome and challenges that we need to take head-on?

Christian [00:03:16] Well, look, I often joke with teams that if your product work is not hard, you’re not doing it right. You know, I see product management today as such a fascinating career path. You know, no modern product manager probably has a degree in product management. It’s a continuously evolving field with variances by industry, by business type, by geo, by [inaudible] the solution you’re working on. I think I saw a study recently that about 70 percent of product managers are self-taught. You know, it sounds cool at first but then you start to think, like, you know, “would I go to a self-taught doctor or a self-taught dentist?” You know, the scary dynamic is that managers back off of training, coaching, and equipping product managers, I think for two reasons.

Christian [00:04:01] One, when companies move to Agile, they believe they need less management and oversight as the teams are meant to be self-organizing and empowered and semi-autonomous in some ways. And two, you know, there’s this sense that the people in the role of product or product manager, these are smart, creative, driven, intelligent people. They are meant to be self-starters and independent. You know, all of the things. Everybody wants rockstars as product managers, and so since they are rockstars, we don’t need to manage them or coach them. This is scary because if you think about it, you know, find me the best athlete at any sport or any game in the world, and I’ll point you to a coaching presence that was always active in their life. You know, Marty Cagan will argue, look, “great products are built by great product teams and great product teams are made up of ordinary people.” You know, coaching is what turns these ordinary people into extraordinary teams. And I think this is probably the biggest risk facing the product discipline today.

Paul [00:05:00] That’s really interesting. So the concept of extraordinary teams sort of belies the notion that extraordinary individuals have to stand out or get this hero complex going.

Christian [00:05:11] That’s right.

Paul [00:05:12] It’s really building an environment that’s safe for people to be vulnerable, to have creative ideas, to fail and learn. But it’s ordinary people making up these extraordinary teams. That’s really powerful because I think it does fly in the face of a lot of conventional wisdom going around today.

Christian [00:05:28] Yeah. Look, fortunately, the best product managers in the world have learned from great product leaders, period. And the sadder part of it is that many product leaders have not experienced good coaching themselves and don’t know what good looks like to pass on.

Sean [00:05:43] I think underlying what you’re saying here is that, if you’re familiar with Carol Dweck’s work and the growth mindset versus the fixed mindset and applying that to product and the concept of product teams, we’re never done learning. And the moment we stop learning is the moment we start, you know, failing.

Christian [00:05:59] That’s right.

Sean [00:06:00] So, you know, any product leader that even thinks they don’t need to be looking to the outside, especially in this space, in this career field, if you’re not constantly looking to the outside for better ways and better things to do to adapt your product to your teams, you’re in trouble.

Christian [00:06:15] That’s right.

Paul [00:06:15] You know, one of the things that you’ve written about that has inspired me to help build a better experience on our teams is the notion of onboarding. And you talked a moment ago about, you don’t even know what good looks like to help other people. And I have tried to put together some kind of onboarding, some boot camp kind of training. But it’s really, I think, inspired by a lot of what you wrote about. What is it about that magic period of new hire, of onboarding, that’s sort of a sweet spot to get culture and process right?

Christian [00:06:48] Well, you know, I get flavors of some variance of questions like, “who should I hire; should I hire a product manager that knows the industry or my business very well, or a product manager that knows the discipline of product management?” I have always leaned to a product manager that knows the discipline because while you can teach somebody about your business and your industry in three to six months, it probably takes three to five years to really get a competent product manager. Plus, you know, the good product managers recognize that they must contribute to good knowledge of the industry, the business, the customers, and the data to do what they have to do.

Christian [00:07:23] You know, I’ve always been a big fan of the new hire onboarding. I actually do mine as a week-long boot camp. You know, I put on boot camp. If you think about it, why does the military have a boot camp for new recruits? The military will say, look, it’s to prepare them for all elements of service: physical, mental, and emotional. The idea is to give new service members the basic tools necessary to perform the role that they assigned to them for the duration of the tour. But when you break down the elements of that military mindset of a boot camp, they are doing a couple of things. They are evaluating and getting in shape for the challenge ahead. They are clarifying the common intent, a common vision, a common strategy, a common purpose, objectives, kind of getting you ingrained. “This is the reason we exist, where we’re going, this is how you work together.” They are all the dynamics that I think are extremely important. You’re building relationships and camaraderie with a cohort of people. You see, your boot camp class is like your safety net relationship, right. We’re all guided to this, so it’s a trust in the cohort. What is the dynamic of the team that you’re coming into? Right. Other people that are already in the military. They want to believe that the people that are coming in have been trained on the parts, they understand the rules, most importantly, they are equipped to have their back, you know, like I’m going to go to war with somebody that I don’t trust. You say, “no, no.”.

Christian [00:08:47] This is a similar mindset in our product work. In many cases, we set up product managers to fail when we just throw them into a new team or into a new environment, no matter how great they are at whatever company they come from. You know, I say, “I got this product manager from Google or Tesla,” or call it whatever company. “Why are they failing at my company? They were great there, why can’t they be great here?” Well, guess what? Your company’s not that. They don’t know the dynamics, the stakeholders, the players, the politics, the history, the decision framework. It doesn’t mean they are not great product managers. But then you throw them in with the team and the team is meant to trust them, that somehow on day one they will make the decision on, “what do we build?” And so product managers have to overcome this cliff of trust very early on when they join a team. That shakes them up.

Christian [00:09:37] So when I get a boot camp, I focus on similar concepts. I focus on strategic context. I want clarity and alignment on the vision and how we plan to make that vision a reality. I want to give historical context. This is not, you know, “welcome to the new company history.” No, this is how we got here as an organization, the technology decisions and the vision we’ve got and the strategy we plan to get to our future vision. I want the product manager equipped with what’s important right now. I also focus heavily on relationships. To build trust, new PMs have to be known to others and know other people. The PM has no direct reports, but a large scope of influence. You know, they have a team to lead, an infinite amount of customers and stakeholders to manage, and often a very complex company environment to navigate. So this is all about equipping the PM to succeed in your environment.

Christian [00:10:28] And then I want practical applications of discovery, because no matter how great you may be with the skill set in another company, it may not work well in the current company you are in. So what I do is I actually have the boot camp put the product managers to practice with the team they are going to work with. This is now a safe environment to do that. I bring the members of your team into the boot camp. We do team-building exercises, trusting, but we actually start to do some work. So we start to go through the storming and forming parts of the team very early, under the guidance and supervision. Right. And then, you know, this whole trust mindset, you know, most product managers be working with a designer and a lead engineer on a daily basis to determine what the right thing to build will be. When they start, there is a learning curve on understanding their teammates and this allows them to work safely. I also use it heavily for expectation setting. This is often a big concern with coaching. We just don’t know our employees well enough. You know, what is written in the job description or offer letter is sometimes very different from what is truly expected in the role, right, or what you might need to do to be successful. So this is role clarity: “this is the definition of good. This is career progression. This is my commitment to you on how I will help you grow in your career.”.

Christian [00:11:45] See, the whole focus for me, the first 90 days in an employee is all about trust. And no matter the role, if I’m a Head of Product, a VP of Product, the Chief Product Officer, I personally manage the new employee onboarding for the purposes of growing trust. One, I want trust between the product manager and myself. You cannot trust me if you don’t know me. Social web dynamic: because you make all your assumptions and get all your information from somebody else and I’m responsible for providing your vision, your guidance, your direction. So, I want to spend time with you. I also want trust between the new product manager and the organization. In some ways, I have to lend my trust to you. People have to see me walking around the building with you to know that you know. “Oh, he taught him everything he knows, he taught her everything she knows.” Right, and I want trust between the product manager and the team that you’re working on. The best way to do that is for the team to know that a product manager is battle-tested in the environment that will be doing the work in. Where did the product manager get that idea that we will do this? How did a product manager learn about our business, our customer? The boot camp allows them to say, “oh, I saw them spend time with sales and marketing; he spent time with our executives, I saw them in meetings, I saw them go out and meet with 20 customers.”. When the product manager starts the first day with the team, they don’t come in with stories of things they’ve done in the past. They come in with real customer insight and data of the business they’re in, getting the credibility of the team in that way.

Christian [00:13:18] So, you know, I take it very seriously. You know, I always think in my head it is my responsibility to ensure that every product manager understands context, is safe in their environment, has the trust necessary. You know, we joke about the level of influence we know a product manager has. How in the world do they get that influence? And this is about setting them up to be successful in the job. So I totally love it. I think everybody should make ideas. The environment, you know, once you realize the difference between getting a product manager to competency can go from six months to 90 days or one year or two years to 90 days just by this concentrated effort early on their journey.

Sean [00:14:00] Cool. If I could summarize what I think I heard you say, it’s that the context is determinant. Like the context that you’re going to be working in, the team, the product, the environment, the customers, is really critical to establishing a product manager, a product leader of any sort. And a key component of trust is this concept of credibility.

Christian [00:14:22] That’s fair. Product managers start off with a big deficit. I see that over and over again. We hire them, and we just throw them right in with the team, and it takes them six months where the team doesn’t even trust them and there’s all this back and forth. And, you know, the saddest part about it is the default to become disempowered quickly. The second an executive says, “we’re going to build this,” they say, “oh, thank you, because now somebody else has told me what to do because I didn’t know but I cannot be seen as not knowing because my job is product manager.” He or she should know and should have the influence and the direction and the context to make those decisions. And that cycle repeats itself because the second you run as a future team, taking a roadmap and delivering, you become dependent on it. So this is about setting them up for success.

Paul [00:15:11] Christian, I thought I knew how you were going to answer my question, because I had read a couple of things about what you’d written, and I’m still coming away with homework because we just onboarded a new product manager two weeks ago and I’m realizing I need to go back to her and catch up on a couple of things that you’re talking about. One thing that I picked up on that I love is, we joke about the influence without authority motto, but then we don’t even give them influence.

Christian [00:15:33] Right.

Sean [00:15:33] All the time.

Christian [00:15:34] All the time.

Paul [00:15:35] And that makes me chuckle and cry at the same time because it’s so true. We’ve been talking a lot about common sense that isn’t so common. We’ve talked about risks, a lack of coaching because we expect our product managers to be heroes. We’ve talked about unconventional onboarding being sort of this introduction to the organization, which we should be able to take for granted, but it’s so rarely happening. One of the other things that I’ve been really intrigued by in terms of your unconventional thinking is being a lazy product manager. Can you tell our listeners, what does that phrase mean and why is it a good thing to be a lazy product manager?

Christian [00:16:10] Well, I will say, if product is not hard, you’re not doing it well. But if product is not fun, you’re probably not doing it right also. Right? And part of why I see I’m a lazy product manager is because I don’t do a lot of the conventional things that people believe are important to the discipline. I don’t write stories. I don’t make up facts. I don’t argue about opinions. I am not stuck in meetings all day. You know, I believe that meaningful customer insights and data will trump assumptions. You know, someone was asking me the other day, “why don’t you write stories? Really?” I said, look, I don’t write stories mainly for three reasons. One, they are only as good as the writer and the reader. If I’m not a good writer, then my stories kind of suck. If I am not a person that can read well, I’m also going to think your stories kind of suck. The second piece is that it seems to stifle true collaboration and reinforce handoffs. Right, because I am writing a story to tell you to read it. So you’re going to read it back and come back for clarity and then I’m going to tell you, and we’re kind of handing off stuff to each other.

Christian [00:17:11] But most importantly for me is that they are riddled with assumptions. You see, if I said, you know, “Paul, would you jump off a plane for a million dollars?” You know? You might be like, “Hmm…” You know, what about you, Sean? Maybe one million is too small. What about five million dollars? You might start to think, “well, maybe if I have a parachute or something, you know, I’m a smart product manager, I can think critically.” But what did the airplane was on the ground? You see, the very first assumption the second I say airplane is that it’s in the air, and this is what we see in stories over and over again. They are filled with assumptions. If I told you both to draw me a flower, you would probably have very different flowers. But if I showed you a picture of a flower, then it may be limited, to some extent, to your artistic or creative ability to recreate my flower. But at least you have a sense of what I am trying to get across.

Christian [00:18:02] So the alternative for me is true collaboration. You know, I’m a lazy product manager because I don’t like to repeat myself. Someone says, “oh, go talk to a customer and then come back and tell the team what the customer said.” I am way too lazy for that. We are all going to go to the customer. We are all going to hear what the customer said at the same time, and then we’re all going to share our learning and elevate our learning because we all had different perspectives on the same thing. You know, I am a lazy product manager because I don’t make assumptions about what customers want. I see that the whole lot. We write textbooks and essays on market research and it is such a weird dynamic. And I said, well, who’s your customer? I say, “well, Joey is our customer.” “Have you asked Joe?” “Well, in a study of 10 people that look like Joe, we saw this statistic.” I’m like, that is a lot of work to dissect the knowledge.

Christian [00:18:53] So my favorite technique is the customer discovery program or the customer development program. And the idea that no facts exist in the building, just opinions, and that you go out of the building even trying to solve a problem, I find someone that has that problem, and I don’t stop until I solve the problem. It’s a very simple framework when you hear it, but people like what they consider to be the more organized, but to me feels like the harder part. That sounds very easy. It’s “Hey, Paul, it seems like you have a problem with headphones, and I’m just going to hang with you until I solve that problem.” It feels challenging to other people, but it’s the laziest form of product management. It’s probably how most great discoveries were done. They were pressure cooked in the environment of the problem. Right, and the laziness is not that you’re not doing the work. It’s more or less you are taking out the false assumptions. You know, when we do roadmaps, they are filled with…

Paul [00:19:48] The abstraction.

Christian [00:19:49] The abstraction. That’s right, and you’re just focusing on what is true and fact to do your work. And you’re not trying to repeat, interpret, you know, you’re really not trying to be a middle man or a bridge of information. Like I’m all about, you know, bringing people together, collaborating around a problem. This is kind of the job, right? It’s not me saying, “I know it all and I’m going to tell you,” it’s not me, you know, overly thinking about what things should mean. No, that’s too much work. You know, why not just get evidence, validated learning that this is what people want? You know, I used to have a principle, “don’t guess, just test,” right.

Paul [00:20:24] Love that. One of the guerrilla tactics that you’ve talked about, and I don’t know if it was a joke or not, but you mentioned, I forget if it was an article or a talk but you suggested that maybe starting a Facebook group saying “Product X Sucks” and seeing who joins is a good way to see who is a detractor and creating a fact-finding mission based on who joins this anti-product group. Have you ever actually done that and did you find anything out?

Christian [00:20:47] Oh, I do that the whole lot. And I teach teams to do this, too, as well, because I either get the challenge with, “oh, well, Christian, you’re so adamant about customers, customers, customers. You want us to talk to customers, learn from customers, identify customer problems, discuss…” You have customers in everything. Where in the world do we find these customers? Right. People are always like, “we’re going to saturate all of our customers; they are so hard to find.” And I tell people, “look, we are all customers.” There are so many companies in the world that are begging and looking for people like us to talk to and learn from. And my favorite technique is through Google AdWords to recruit customers because I’m not necessarily looking for a person. I’m looking for a problem. And you can buy any keyword in the world. You know, if I am in banking, I can buy a banking keyword, people, “I hate my bank,” and if you come over and I find you, I know your problem already. I don’t have to ask you, “so do you hate your bank?” You literally typed in Google, “I hate my bank, right.” So, you know, whatever problem you’re trying to solve, you can buy all kinds of phrases or keywords.

Christian [00:21:45] But I’ve started to love social media and Facebook and Reddit groups because I just see how comfortable people get on social media. Boy, they can talk and they can write. They will type up a whole storm and then comment and comment, and look, I may not use it personally as much, but it is excellent for recruiting customers. You know, pick any product in the world that you’re working on. You know, go on to Facebook, type in “(that product name) sucks.” If the group does not exist, create one. Ask some of your friends to join. Talk about the degrees of connection, I promise you, in like a month or two, you will get people joining this group. And, you know, you will uncover people that not just feel that way about you, but are willing to share. Not only are they good place to find attractors, they can often become your biggest advocates when you fix their problem, too. They become very loud. Now, don’t feel like it only has to be “your product sucks.” You can also create a fan group for yourself. Just go on all of these forums and search. There are many communities where your customers hang out or get together. Participate in those, naturally and organically. You know, someone was like, “do I have to hide my identity?” You don’t. They actually love it! You know, I was teaching a team the other day and he did it in real-time in the session. And he was showing me, the moderator said, “this person that works here wants to join, should we let him in?” And everybody was like, “yeah, let us tell him our mind, he’s the product manager.” And, you know, he was telling me, “this is my best customer recruiting group. They are eager to test things and try things, they are very active.” And he has just an arsenal of thousands of customers at his disposal to get validated, learning, and facts back to his team, right.

Sean [00:23:26] Yeah.

Christian [00:23:27] Look, there are many creative ways… When you start to humanize customers, it exposes you to amazing things. You know, people that know me know that, you know, my friends, none of them come to my house for a cookout without asking questions like, “are you going to be asking me?” Yes, I am always in discovery. Always. There’s no free food around me. You know, I’m the guy that gets into Uber and I’m very nice, but the second Uber driver wants to have a conversation, I’m like, “all right.” I’m always learning. You know, people say, “well, is your Uber driver your customer?” Well, they may not be my customer, but they are only categories in my head. “You’re not my customer and you should be you. Are my existing customer and I want to hear from you, good, bad, or ugly, or you have no clue about what we are and I would love to understand why.” Right. Either way, I am always learning. So I talk to my Uber driver. I sit on a plane, you know, I’m always nice and quiet, but the second you bug me on the plane, it’s on. We get to discovery mode and I turn it all around. I’m like, “oh, so tell me more. Have you heard of this product?” “No.” “How do you solve your problem today with this?” And I’m constantly learning and building relationships. So these are all creative ways in our modern world, especially now, that we can reach customers, that we can attract users, we can gather feedback. I want to remove the mental obstacles that we have that hold us back from this.

Sean [00:24:43] All right. I did pick up on one thing that I feel is very important, that you’re looking to find people to connect with that are advocates of the problem. Think about that, whether they’re positive or negative in terms of your product, those are the folks that you learn from because they actually care about solving that problem. And I think that’s a key insight for our industry.

Christian [00:25:01] Yes.

Sean [00:25:01] Like, we got to find people on both sides of that fence that really, really care about solving the problem. And the other thing, which I’ve seen you talk about before. I think you talked about this at the Mind the Product Conference, all problems at the end of the day, are people problems, and figuring out how to dig in and understand these people. You know, with all the stuff you talked about in terms of onboarding, you said, “we don’t know our employees well enough.”.

Christian [00:25:22] Yes.

Sean [00:25:23] Like that’s a people problem, and that’s a really important problem to solve. And we don’t know our customers. We’re even dehumanizing our customers by calling them customers. This is another people problem.

Christian [00:25:33] Yes.

Sean [00:25:34] The better job we do as product leaders of understanding the people, on all sides of our ecosystems, the more successful we’re going to be. That’s the lesson here.

Christian [00:25:43] That’s right.

Sean [00:25:44] All right. Well, I’ve got a question for you. You seem to take your words very seriously and I value that. So how do you identify with the word innovation? How do you define it? What does it mean to you?

Christian [00:25:52] Oh, so innovation to me, it’s just an outcome of how many iterations you could have and technology that is just now available. And in some ways, that plays out more in a mindset. And I say this because when I look at a lot of what we may call technology innovations or advancements, the problems don’t tend to be very new, they are just solved with technology that is just now available. But the mindset of, “how quickly can I go through iterations to discover the best way to solve a problem?” So innovation is like this, you know, solving an existing problem a new way. It is going after creating a new source of value. It is new customers, new markets, new industries, new opportunities. Those are the things that come out of it. And so I’ve always looked at innovation in more of a mindset than as those buzzwords that people use to maybe excuse very lengthy investments or make things take too long. You know, it’s more or less the mindset of, we are going to place a bigger bet on how we solve a problem because we’re not thinking about just improving the existing solution, but solving it in a new way or leveraging technology that is just now available or rapidly iterating to a point in which we have created such a big result or outcome from where the problem is today to the new approach.

Sean [00:27:16] So given all that, would you agree that the prime directive of a product leader is to rally the ecosystem around that problem? Love the problem, you hear that a lot in our space.

Christian [00:27:26] Yeah, I mean, people say a lot about loving the problem and I shy away from that somewhat because I have seen people get stuck in it where, you know, I have to remind teams, let me be clear, your job is to discover a solution to the problem. Now, to discover the best solution to the problem, you need to understand the problem well, so that argument is sound, but I get many teams focused on validating an idea than discovering a solution. Many teams fall in love with it and they’re like, “ha-ha, this is not going to work,” and I’m like, “OK, that is not the job; the job is to discover the best solution to the problem.”.

Sean [00:27:58] Yeah.

Christian [00:27:59] The solution may fail, but the problem will still be there, right.

Sean [00:28:04] And to keep pulling on the same thread, you can’t really do that unless you really understand your audience, the people that you’re straight solving this problem for. And I firmly believe that you need to dig into that before you go too deep into the problem. I agree with you one hundred percent.

Christian [00:28:17] Yes. Customs doing a lot of personas after the fact. They did do the personas and then they try to match problems to that. I just love understanding people and stories. And you get a lot of the context of it. And I know what defines a person, you know, not because I put you some bucket prematurely and then tried to make things work and call you an outlier, which again goes to dehumanizing customers a whole lot when I see the specific studies, but different argument.

Paul [00:28:46] I want to ask a related question, but back to the notion of empowered teams and the people on the empowered teams and one of the things that we chatted about earlier was the over-enthusiasm about getting right to day two activities. I assumed that what you meant was in the context of sort of the Bezos quote, “it’s always day one…

Christian [00:29:04] Yes.

Paul [00:29:05] …”And as soon as you get to day two, you’re stagnating.” And we relish process, right. We tend to be organized people. We attract thinkers who put things in boxes and try to solve problems in ways that can be understood by other people. And we often jump to those day two-type activities. What are some ways that we can challenge ourselves to stay in day one and be comfortable just getting the basics right, getting better at our ground game?

Christian [00:29:32] Yeah. I love that even at a company as big as Amazon, this is still their biggest fear that they fall in love with process and they become complacent and comfortable where they are. And as companies get older and they go through time and cycle, they solve their problems about the same way, with more people and with more process. And they tend to reinforce themselves, right. You know. “We had a bad lawsuit so we need to create a governance committee and a steering committee to prevent this from happening. Now there are new rules in place. Now it’s gotten very big, we need to hire more people to manage the process. Now there are so many people and we need a new process to manage how those many people who work together,” and before you know it, you have layers and layers of all of this in place.

Christian [00:30:12] The most innovative companies in the world, they maintain this scrappy mindset with this discovery nature, right. Marc Andreessen says, you know, “the most important thing is to know what you don’t know.” And they’re ingrained this culture of learning in the minds of people, one that allows them to continuously respond and adapt to changes in their marketplace or industry, but one that does not allow them to get locked in or satisfied. An interesting example could be Spotify. You know, many people have been running around with Spotify’s video and concept for how to build teams and organize themselves and then you find out from Spotify, “Oh, we don’t even do that, that was so old, we’ve changed it like 12 times.” You know, at every point in time, that is just a snapshot of where we are.

Christian [00:30:50] You can look at the alternative. If they were locked in in the process around that and the mindset was not learning, they would have evolved that whole methodology to you know, “now this is Spotify for scale.” “This is now Spotify version 3.0.” Right. And I see this a whole lot with many processes. Right. It’s an unfortunate reality. The ideal is like, “at this point in time, this is the best from all of our learning that allows us to maximize our ability to respond to changes in our marketplace. Tomorrow it could be different. We’re going to learn and evolve a new way.” This is one of my pet peeves this day with like SAFE or scaled Agile framework. My goodness, I mean, look, it’s an executive framework for waterfall.

Christian [00:31:29] I know this is not your question, but it drives me crazy because I get many teams and they tell me, “but you don’t understand, we are very big and we are very complex, we have all these layers, we need a good framework to manage all of this.” And then we break it down, I said, “OK, so what is it?” “This is scaled Agile.” “Oh, so you’re doing Agile at scale. So are you Agile?” They say, “well, we’re not really… We’re trying to, some parts are not Agile, some parts are, we’re evolving,” you hear all these kinds of stories. You are going to scale whatever bad behavior you have. It is just that simple. I have met organizations where people are very good at writing business cases to get funding. They are not very good at solving problems, but they are good at getting funding because they have scaled a great way of ensuring that the most important thing here is to get your business plan approved. So in some ways, when I say all problems are people problems, this is a leadership problem because leaders are responsible for context and culture and you have to create a culture that says, “we are not going to be stagnant and satisfied by what works, we are going to continuously learn, continuously improve, continuously challenge our culture of learning to ensure that we are adopting new methodologies and techniques that may or may not work for us.”.

Paul [00:32:38] The last thing I wanted to hear your thoughts on before we get to wrapping up our time together today is one last question on wording. You’ve talked about MVP’s and this is one of those product terms that’s thrown around. Everybody assumes that we’re all talking about the same thing, but often we have very different models of what an MVP is. And one quote that stuck out to me is, “if it takes more than two sprints, it’s a half-baked product, not an MVP.” And that flies in the face of a lot of what I see in MVPs today.

Christian [00:33:07] Right.

Paul [00:33:08] What is an MVP to you? How is it a useful tool? Is it still useful?

Christian [00:33:12] Now, the second part, “it is still useful,” is arguable because there are many techniques that we use to discover if something is valuable, usable, feasible, and works for our business. But the MVP is the smallest experiment we can devise to prove an idea or a risk in discovery. Actually, the full name for it was MVP test. But everybody forgets the end part that says test. They just like MVP. You know, it’s like minimum viable product test. I think if you change the world product to prototype, maybe it’ll help. Right. Because if you think about it, if something takes four months to do, what is minimum about that? Right. The MVP is not meant to be an actual product. You know, it gets confused a lot with what we may call product-market fit. Right. The product-market fit, this is the smallest delivered product that meets the needs of a specific target market and our business, right. In most companies, you know, people think MVP is, “I’m going to build something in four months that really should take eight months to build.” What? It’s a discovery technique.

Paul [00:34:12] And the first time a customer sees it is when it’s released to production.

Christian [00:34:06] That’s right. And then what happens if it’s not great? We’ve just spent 18 months working on it. Who is going to go back and tell our team that was a bad idea? “No, we’re not doing that. We need to talk to more customers and find a one that likes it.” Or better yet, you know, the one I hear is, “well, nobody really liked it, but nobody really hated it and we spent all of this time building it, so let’s just roll it out.” You just rolled out tech debt, that that’s what you just did.

Sean [00:34:39] Yeah. From our earlier theme, I think talking about an MVP without talking about the minimum valuable or viable audience, is the real dangerous part, like you’re solving problems, but for who? Or you’re building a product or a prototype, for who?

Christian [00:34:53] That’s right.

Sean [00:34:54] I actually want to pull on one more thing from something that you said earlier. I’m fascinated by your take on user stories. You said that teams can become dependent on being told what to do. You didn’t say it quite that way, but that’s when they become feature teams. And it’s a self-fulfilling prophecy. And I just want to pull on it a little more. It’s something every team I’ve ever dealt with struggles with, like, what is a quality story and how do we know that we’re building the right thing?

Christian [00:35:09] Yeah. Obviously there’s also a leadership problem there when you don’t empower your team and give teams a roadmap to just build and deliver. And please, you know, let people not run around and say, “I don’t write stories anymore; this guy said not to write stories.” You have to have a good alternative in your environment. You know, my alternative is true collaboration, meaning if I’m working very closely with my designer and my engineer, the best person to tell other engineers what to do is an engineer. So if my lead engineer then came up with the idea of what we’re going to do, he’s asking all of the stories, he knows all of the information, he knows the customer very much, what am I going to tell him in a story that he doesn’t already know?

Sean [00:35:52] Right.

Christian [00:35:53] We drew the picture together. We all agreed to it. His job now is to break down the work for the team to deliver and tackle the risk around how to deliver it. So you’re right in some ways. This self-fulfilling stuff is, you know, somehow the stories, the assumptions, the roadmap, they feed our dynamic that we are here to serve the business and not the customer. And so what happens is that, because somebody else told us what to do and they’re smart maybe, or they’re a leader, we assume that it’s valuable and that is the right thing to do and we forget that our job is to discover a solution that is actually valid. How many times do you see a team that delivers things and then the leaders say, “yeah, that’s not quite how I thought about it.” Or they focus on, “now I need this other thing.” You’re like, “but you promised me that if I gave you this, we will sell ten million dollars, but now you’re saying it’s not this, it’s that.” Right? This is exactly what happens when we ship and deliver a roadmap. So the alternative is for teams to truly have a deep understanding of their customers, a deep understanding of the problems they are set to solve, recognize their responsibility in discovering the solution to that problem and they feel empowered and measured on due outcomes.

Sean [00:36:59] Love it. Great answer. I’m also going to repeat your quote that, “a story is only good as the writer, and the reader.”

Christian [00:37:06] And the reader too. I’ve seen great stories then, you know, just engineers that don’t like to read it. They say everybody’s stories suck, right?

Sean [00:37:14] It’s true. Oh my god, how many times have I heard that? Alright, last question for you and then we’ll let you get back to your real life. Books that you’ve read recently, or a book that you’ve read recently, that you want to share with our community; a book every product leader should read?

Christian [00:37:27] Let me see on my stock of most recent books.

Sean [00:37:30] Oh, he’s going to the bookshelf.

Christian [00:37:31] I always have them out here. So recently, we’re coming out with a book in December, Empowered, which is focused on product leadership. It has my favorite topics in there. We focus a lot on coaching. So, you know, I talk about onboarding teams in that book, too, as well, and strategy, vision, how you do context. So I heavily recommend that for product leaders. I love Ben’s new book, What You Do is Who You Are, really around culture. I think that’s great. If you haven’t read The Hard Thing About Hard Things, that’s also a great recommendation, too, as well. So [those are] some of my favorite books for product teams. Books aside and all of those things aside, the practice of good product management, I have not found anything better than finding a really good product leader and having them coach you.

Paul [00:38:12] Can’t think of a better way to sum it up. I have enjoyed every minute. Thank you for spending time with us today, Christian. It’s really been a joy to get to know you a little bit and to learn from the source.

Christian [00:38:24] It’s been my pleasure. Thank you for having me, Paul and Sean.

Paul [00:38:27] Absolutely.

Paul [00:38:30] Well, that’s it for today. In line with our goals of transparency in listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get, so please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.