In this episode Charles Humble talks to Silicon Valley Product Group partner Christian Idiodi about how he got started in product management, the Certified Scrum Product Owner and MBA pathologies, how product management is badly taught, the skills you need, and how to improve.
Subscribe: Amazon Music | Apple Podcasts | Google Podcasts | Spotify
About the interviewee
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 and Merrill Corporation as well as clients such as Starbucks, CarMax, and Macy’s. He teaches product management and innovation at Virginia Commonwealth University in Richmond, VA. He also gives back to his local product community each year by supporting and advising two student-led startups from concept to product delivery.
Christian is passionate about helping companies implement the discipline of product management to build world-class products and new technologies. At CareerBuilder, Christian founded and managed CareerBuilder Institute, the industry’s first combined human capital and consumer training platform, creating a new stream of revenue for the company.
Resources mentioned
Full Transcript
Introductions
Charles Humble:
Hello, and welcome to the 8th episode of "Hacking the Org". The podcast from the WTF is Cloud Native team here at Container Solutions. With this podcast we bring together some of the most experienced software engineering leaders and talk to them about their experiences covering topics, including building and leading high performing software engineering teams. I'm Charles Humble, Container Solutions' editor-in-chief, and for this episode I'm joined by Christian Idiodi.
Christian is a partner at the Silicon Valley Product Group, working with clients, including Starbucks, CarMax and Macy's. He's been a product leader for over 15 years, and before joining the Silicon Valley Product Group, he was the global head of product for Merrill Corporation. Christian built the company's product organisation and led them through a transformational large scale industry launch of the first SaaS app for due diligence in the finance industry.
Before we get into the podcast, it would be remiss of me not to mention that our conference WTF is SRE, is back for a third year and it will be held in-person for the first time. The conference takes place in London, May the 4th to the 5th 2023, with four tracks covering observability, DevSecOps, reliability and DevEx. Save the date and register your interest at www.cloud-native-sre.wtf. Or you can just Google WTF is SRE and find it there. And with that, Christian, welcome to the show.
Christian Idiodi:
Charles, such a pleasure to be here, looking forward to our talk.
How did you start in product management?
Charles Humble:
So I've spoken to a lot of product managers over the last few weeks, and every time I've said to them, "How did you end up in the field?" I've got a variation on, "Well, kind of accidentally." Was that your experience? How did you start in product management?
Christian Idiodi:
I often joke with people like, "Well, I have my bachelor's degree in product management and my master's in design, and a PhD in engineering." And I was like, it's just absolutely not true, there's just not a lot of people that I have met that actually deliberately got into this discipline. I actually got into this discipline by winning a competition at a company. I was 23 years old, I worked at a high growth stage company at that time, and they had a business plan competition where anybody could submit an idea, and if you won the competition you got a million dollars to run this business.
And I ended up winning that competition, it was my first exposure into actually trying to go from an idea into building a company, and it really sucked, and it was hard and I struggled. I finally figured out how to grow that business significantly over the next 18 months. I had another idea and I submitted it to the competition and I won again. And at this point the CEO said to me, "Why do I have to wait for a competition for you to share all your great ideas? Maybe you should manage our innovation budget. If you think of a great idea, just do it and you could manage or oversee some of the work we're doing here."
And this was my first introduction into some kind of formal role of innovation management. There wasn't really a product management discipline back then, and I started to fail woefully, doing it consistently. The first two ideas sounded great, but everything that came out of my head after that was just failure after failure. And what really struck me is how do people consistently innovate, consistently go from idea into something that customers want to love? And that was what really attracted me to the study of product management, by learning through my failures, by trying to do this consistently, and I built over 80 products after that, and I've not had a single product failure then, it's kind of part of my journey evolution into products.
Tell us about the the Certified Scrum Product Owner pathology
Charles Humble:
For the listeners at home, I want to say that you're wearing a fantastic T-shirt which says, "Product is hard." This is a phrase that Marty Cagan, who was the founder of the Silicon Valley Product Group likes to say. And I've heard you say that, "If product isn't hard, you're not doing it right." My introduction to the Silicon Valley Product Group really was a couple of articles that Marty wrote on what he called pathologies.
One was on the MBA pathology, and the other was the Certified Scrum Product Owner pathology. In the latter, he says that "the fastest growing pathology I see, especially outside the U.S. is people confusing a product owner that is the role on an agile delivery team with a product manager." Can you talk a bit about this, please?
Christian Idiodi:
Sure. And at the core, product management is the job, and a product owner is the role on an agile team. I can understand the genesis of this confusion. Many organisations in their legacy or traditional way of building, were essentially a waterfall, kind of a top down, the business or the technology teams serving the business in some ways, to build things. In those environments, people had to gather requirements from another group that wanted something built or created.
And so they had your traditional role of a business analyst that wrote requirements documents, or business requirement documents, or marketing requirement documents or documents of documents, they just write a lot of documents. When companies started to change how they build things, meaning that shift from waterfall to agile, they realised that there was not this traditional role of a business analyst.
However, in this agile teams, they had the role of a product owner, and unfortunately what many companies did was just change the title of their business analyst to a product owner, and they still did the same thing, gather requirements in some ways, and then companies started to shift in some of their transformation, in changing how they solve problems, and this whole product mindset movement.
And they could see that there was this job of a product manager, and they thought it meant the same thing of a product owner because as a product manager, as a product owner. And managing the rituals of a backlog, managing the agile ceremonies, it is part of the job of a product manager, but it's not product management at its core. The job of a product manager is to solve a problem, to work collaboratively with a team of people to solve a problem.
It's not to gather the requirements for what needs to be built, it's to understand the problem that we need to solve by building something, and to ensure we deliver it. Communicating to an agile team what needs to be built through documenting stuff is such a small percentage of that job, maybe five, 10% of the job.
And unfortunately many people think the expertise in doing that is what it means to be a product manager, and they lose sight that this job requires you to have a deep understanding of the business, the customer, the data, your industry and your products, so that you can contribute a decision on what we are doing, and ensuring that it's valuable and valuable for the organisation. So obviously this movement has a root in some historical trends.
I do advise organisations that I talk to that if you have a product manager and a product owner, that does two things that are challenging in an organisation wanting to reinforce these handoffs, in some ways reinforces waterfall, because one person is the business, one person is technology. So I have to communicate from the business to technology what it is, but also it's just not good for an individual's career. There are no modern product companies that are hiring for a product owner. The job is a product manager. So if your title says product owner, chances are you are in a legacy environment, in a delivery team or a feature team, and not in a modern product organisation.
Can you talk about the problem of equating management and leadership?
Charles Humble:
In the other of these pathology articles that I mentioned, the MBA one, Marty sets out four areas of what he says are problematic thinking. So he has equating management with leadership as one; not knowing what you can't know; the role of technology; and the command and control leadership style as the other three. I'm really interested in getting your perspective, particularly on the equating management with leadership, one, because that's something that from my own experience, I've seen people confusing and conflating an awful lot.
Christian Idiodi:
A lot of these concepts differ for me. I have an MBA, I have a masters in project management, and a masters in business administration. I don't want to suggest that people that have that, have fundamentally flawed thinking, but it does reinforce some of the anti-patterns that we see in the current product environment. But let's start with this management versus leadership piece, at its core, the way I separate them in my head. The core of leadership is to provide two things, context and culture, at its core.
Context means, why are we here? Context means, where are we going? Context means, how do we plan to get there? Context means, how do we organise ourselves to get there? Context means, how do we measure success? What's important right now? That's what I call context, we call it strategic context. Context reflects itself in our environment with elements like your mission, your product vision, your product strategy, your team structure, your topology, your team objectives or your KPIs, or whatever you use to measure success. That's the core of what leadership provides.
Now leadership also provides culture or drives culture, the environment in which you go do those things, and that's reflected in the language, reflected in the behaviours, but mostly in those values that drive what you do. That's the core of what leadership does. Management on the other hand, is really at the core, focused on three elements—staffing, coaching and objectives. Staffing, meaning my job is to find, now that we understand why we're here and where we're going and the problems we have to solve, I have to find, recruit, build a talented team of people. I have to retain those people.
But most importantly, I have to coach them to make sure they have the necessary skills to go accomplish those goals, go solve those problems, and I have to align them with what those problems are. Now, in almost all cases, a leader is a manager. You could be a CEO and you have people directly reporting to you. Very large companies, you could just be a people manager and many people might not look at you for most of the leadership aspects, like craft our vision and stuff.
The higher you go in an organisation, the more leadership responsibilities you are called to do, than management responsibilities. It's like if you're the CEO, your management team or your direct reports are very competent executives. You don't have to spend time every day coaching them like you would an intern or someone that just graduated from university. So you can understand that the management work at its core for all leaders and managers, the most important element is coaching, because at the end of the day, regardless of the problems you have to solve, regardless of the parities you've established, the measures of success, you have to have a team of people with the competency and the necessary skills to go accomplish those tasks.
That's really the core. I mean, I typically look at teams from a sports lens, kind of how high professional teams organise themselves, at the core of the job is coaching teams to succeed, because you're bringing skilled people together, you're actively coaching them to go play a game and to win a game.
So management and leadership, unfortunately many people emphasise the administrative aspects of management, interviewing people, firing people, writing performance reviews, being a task master at the core of the job. This is absolutely not right. The core of the job is getting people better, building an environment for people to succeed. That's what it is. So the leadership, focused on the context, focused on the culture. Management, focused on coaching, focused on staffing, focused on the objectives.
What are some of the common product management anti-patterns you’ve seen?
Charles Humble:
I'd like to come back if I may, there's something you said right at the start of that answer, which was that people who were studying for MBAs in product management were often having antipatterns kind of reinforced as ways of behaving. And I think that's a really interesting point. Can you unpack that a little for us? Are there specific anti-patterns in the industry you've seen?
Christian Idiodi:
Yeah, a couple of things that have been concerning to me in the industry over time. I don't excuse why it happens with an understanding of its history, but I have to understand the genesis of it to understand why we have to work very hard to shift that thinking. I mean most of the people that are teaching MBAs, teaching this thing, you can imagine the structures they came from, large, maybe consumer package goods industries. Not a lot of people today are traditionally tech executives that are coming now to teach people how to build companies or use technology to solve problems.
In this mindset, the role of technology, kind of one of those anti-patterns we talk about, is subservient. So the role of technology is to serve the business, rather than solve problems for customers, rather than being an enabler. So it might seem nuanced, but if you talk to some companies they might say, "Look, we're a media company, we are a finance company, we are a banking company." If you talk to some of the big companies like Netflix or Apple or Amazon or Google, they'll say, "We're a technology company." There's not a distinction between technology and the business. Technology is the business.
However, people are taught, the IT role is to gather the requirements of what the business wants, make sure it's on budget, make sure it's on cost, write the estimates, measure all of the output. Your job is to deliver what the business needs are. And it's reinforced in some of these teaching by some of the methodologies, some of the tools that people are equipped with. So they come into these organisations not looking to solve problems in the way of collaborating, but in a subservient way, Tell me what to build. Tell me what you need.
And my job is to project manage the delivery of it. These are very common anti-patterns that I have seen in just how we have taught people how to do product over time. So people think their job is to gather requirements. People might think their job is to validate an idea. People might think their job is to gatekeep, and all of these things. I can understand the natural thing. I say the same thing with coaching, the number one reason many people do not experience good coaching is because their managers have never experienced good coaching themselves.
At the core of it, the number one reason I think many people are not taught great product management work is because the managers themselves were not taught, they are only passing on what they've learned, in how they build things. And so we don't have enough in today's environment of people that have built products in some of the most successful companies, teaching other people how to do it. It's getting better, but some of the concerns in the industry that make product challenging for the last 20 years are still the same things we are seeing today.
How did you unlearn the things you were taught doing your MBA?
Charles Humble:
When you did your own MBA, and presumably had this experience of having certain kind of anti-patterns reinforced, how did you realise that and unlearn that? Was that a case of going back into industry, trying things and having it all go horribly wrong, how did that work out?
Christian Idiodi:
Well, through, a lot of failure. So I'll give you an example. So I won that competition, I told you I got a million dollars, and I cried myself to sleep the first night, because I was terrified, "What am I going to do now?" And I have presented an elaborate case for what we're going to do, and it was going to be a tech product. I'm 23 years old and I pitched an idea to use technology to solve a problem with learning and things like that. So I spent my first three months writing an elaborate business plan, we'd learnt this stuff in the MBA program. All of the edges, I'm in research studies. It felt very good writing this business plan.
I went to my first board meeting, kind of the key executives that were behind this, and I was pitching to them all of the elaborate things I would do in the business plan. And it was probably the single hardest day in my professional career, because all of these senior executives from some of the bigger companies in the world that were on this board, they kind of looked around and they kind of laughed at me.
They kind of said, "This is a waste of our time. We could have put that million dollars in a high yield savings account in some investment somewhere, and the three months you spent writing a business plan of how to spend the money, we would've gotten more profit from it than you keeping that money in the bank account thinking about the best way to deploy it."
And they said to me, "We are here as your board because we expected you to come here with some stupid decisions you would have made over the last three months, and that we could advise you and guide you and shape those decisions so that you can actually get results. Your job is not to avoid risk, it's to tackle risk. And we're here to support you through those risks to ensure that we are minimising the impact in a way that protects our brand, protects our company, protects our fellow employees and our revenue."
And I remember sitting in the parking lot that day, it's probably ended at 2:00 PM, to maybe eight o'clock at night, and I'm calling my parents up, "I think I'm going to go to medical school, business is not for me. This is hard and painful." It really opened my eyes.
One of the most important comments I got from an executive that day was that every single thing in my business plan was wrong. Not wrong because I didn't do the right research or the stuff, but that the data today was already old, it was already stale, the facts that will guide my decision from what I prepared yesterday as of today are just a little slightly off, and that the real learning will come when I actually start to do those things. And I started to wonder what was the need for this?
It was trying to answer two key questions, how much is this going to cost us, and how much are we going to make? But it was filled with assumptions, there were no facts inside of it. And the only way for me to do good work was to get evidence about what will happen, and to test and to learn, and those things we were not taught. We were taught how to do C.Y.A, to cover our butts, to protect ourselves from looking bad, to sound good and how to pitch things well, and how to get a good marketing plan and a business plan, but not to do, not to create value at its core.
We were taught all the things about talking about value, all the right buzzwords and all the right phrases, and none of these things meant anything. When I put my head down to actually build the product, I realised that my first two products were very good, the next 17 I failed. When I started to reflect on why I was successful in my first two, the most important element of my learning was that I didn't know anything, kind of that point to know what you didn't know, because I joined the company three months in when I had this.
I was asking questions, talking to customers, talking to leaders, really trying to learn. My other failures were happening because I was sitting in a conference room making decisions, calling a team of engineers at a far location, "This is what we should build." All assumptions. And the second I realised, "So you mean my not knowing was the secret to actually knowing?" Validating, like going to learn, not presenting some case with facts and stuff, but testing, being connected to customers, being close to my engineers.
I mean, I wrote the list of those things. They were not magical, they were not some elaborate plans, some analysis, some tool. They were simply not knowing is your key to knowing. Don't guess, just test. Talk to customers, have a close relationship with your engineers. These were the early things I wrote after a series of 17 failed products. It wasn't a magical framework, some elaborate plan, some thesis I got from a presentation. This is what's come from doing real product work.
How do you advise people figure out what it is they should be building?
Charles Humble:
What advice do you have in terms of the discovery piece? How do you advise people figure out what it is they should be building?
Christian Idiodi:
Yeah. First I often do tell a lot of teams, which is often hard for them to understand or wrap their head around, that discovery is not a phase, that discovery is the job. It's kind of hard, particularly if you're thinking, I'm a product owner and maybe I'm gathering requirements and stuff, and I have to do discovery and then I have to go build things. And I'm like, engineers are engineering all the time, product people should be discovering all the time.
I often tell people, discovery for me is like a lifestyle, I am always discovering. I've done a lot of discovery, but I'm always discovering. And so at the core I always first have to ground people in like, "You're coming to work, discovery is not something you, I'm going to check the box, then I have 10 meetings and then I'll do some discovery." Discovery is the core of your job, and what you're trying to do with discovery is to tackle risk.
Whenever you're trying to create value, there's risk involved, there's a risk that whatever you create may not be something people want, people will choose or people will buy. There's a risk that they may not be able to use it. There's a risk that you cannot build it, you don't have the skills to build it, the time to build it. You don't know how to build it, and there's a risk that your business may not support it. These are the core risks you're trying to tackle. The whole essence of discovery is to tackle those risks.
If you can answer those questions with evidence in five minutes, and clearly describe what you are going to create as a result of it, you are done with discovery, but it often doesn't take five minutes, and sometimes we need to spend more time on one question than another. All of those things are okay, but the idea here is that you're continuously discovering and you're continuously tackling those risks as you discover them. In some ways I tell people, "Discovery is coming up with a list of things you don't know, and coming up with a plan to know those things."
At the core of it, discovery is working with a bunch of smart, talented people to solve a problem. So many people often will say, "Okay, well the job is to define the problem, we will spend 90% of our time doing this." I like where you're thinking in this, love. But at the end of the day, the core of the job is to solve it. If that 10% doesn't equate with you solving the problem, you've still failed. That's what we want. So Einstein said, "If I had a problem, spend 99." I like that thinking. I want people to believe that it's good to spend time understanding the problem, identifying the problem, defining the problem, understanding the problem. But the reason you do that is to enable you to come up with a solution worth building.
Charles Humble:
Right.
Christian Idiodi:
Because I've had teams that will boast to me, "We have a great definition." I say, "Oh, that's great. So now what?" Or people will say, "We realise that is not the right problem." I said, "Okay, what is the right problem?" And they tell me. "So do we have a solution to that?" Because that's the job. There is a contract that companies make with customers, this idea that if I solve a problem for a customer in a meaningful way, in return they will give me something, I call it a certificate of appreciation, in the form of revenue, loyalty, engagement, whatever that is.
So we've hired a team of people to continuously honour that contract. That's what a product team is, the contract of, "Let me continuously solve problems for you in a way that you love, and in return the company will get value from it." So I coach teams all the time with discovery and I say, "Look, first you've got to know that it's a mindset, a lifestyle, it is your job. It is not a one-time thing, a one-off thing. It is an always thing. Your job is to tackle risk on everything we're going to do and ensure that you're determining what we do next is not risky." That's it.
What would you say are the core so-called soft skills that you need to be a successful product manager?
Charles Humble:
What would you say are the core so-called soft skills that you need to be a successful product manager?
Christian Idiodi:
Oh, boy. I've always called this job problem solving in some ways. I often get a variant where people ask me how do I get into products or someone in college if I do a talk at a university or a college will say, "Well, I love this discipline, it sounds super cool. I want to be a product manager that builds the next Spotify, or that builds the next cool thing. How do I do it? What skills do I need to learn?" Often I tell people, "You don't get mastery at anything by avoiding it."
And so I say, "Let me describe what the job is, and I want to challenge you to start doing it right now." And I say, "Well, at the core of the job, you are working with people to solve a problem." And I say, "There are so many problems today in the world all around you. You have to practice getting good at immersing yourselves in problems. You can volunteer to help solve a problem at a local charity or a local community event. You could volunteer, you could do your own startup."
And I say, "What you are doing with some of these things is you are building the muscle you would need to play the game, understanding that winning the game will come with mastery. But developing the muscle means that you don't want the first time that you lift weights to be in a weight lifting competition. You realise quickly how much muscle you don't have. So what I want you to do is start with a one-pound weight, just play around with it."
And that is as simple as a problem you might have in your house. When you get good at feeling good with problems. Many people are good at solving problems by themselves. And then I have to say, "Okay, now let's shift it, product management is a team sport, because the kinds of problems you will have, have different variants with that, particularly cannot often be solved by one person." Meaning there may be technology things that you may not have expertise on, there may be experience aspects you may not have expertise on, there may be risk or finance or legal. So you want to get good at working with people to solve problems.
So I want you to practise problem solving, I want you to practise true collaboration, working with others to solve problems. I want you to practise empathy, getting good at talking to people, to understand their problems, getting deep insights from them. See all of these things are things that I tell people, "You don't have some magical degree, you don't come out being taught this at the practical sense in most colleges or things, where you can start to practise this today."
And I said, "Don't waste an Uber ride, don't waste an aeroplane. So if you're sitting in an aeroplane beside someone and they want to be nice to you and ask a question, engage in conversation, take that as your first discovery exercise. I want to learn more about that person, have a deep understanding of their problems, and see if I took a challenge." So what do you look like? You're trapped on a plane for an hour or more, you might as well learn something, you might as well participate.
That muscle you build will help you in your career. So at the core of it, I love people that feel comfortable with problem solving, feel comfortable with teamwork, have a deep empathy for others and can connect with others in that mindset. I do believe a lot of some of the other hard skills you can be coached, you never know. I tell people product management is like being a doctor at its core, you have to get good at diagnosing a problem and coming up with a solution. But you can specialise, you can be a heart doctor or a kidney doctor and stuff and go deeper.
But all doctors at the core, want to save a life, all doctors at the core would jump in to help somebody, like you want to get good at building that muscle. That's foundation for us in product management. Unfortunately, what more people learn is being a firefighter than being a doctor, because when they're truly in an environment, it's always urgent, it's always a fire drill. They always prioritise, "We want it now." And so they learn how to put out fires and run around. And while that skill might be good, it's project management.
Product management is more like being a physician, it's more like being a doctor. So it's kind of that mindset. Some of these things that is typically what I direct people with soft skills in the industry. Lea Hickman always says she looks for people that are intellectually curious, people that have plenty of grit, they can persevere through a lot of things in there, and are great with people. So these are some of those things truly collaborative people that people look for.
What should engineering teams be focused on?
Charles Humble:
What about from an engineering perspective, are there particular things that you've seen in some of the best companies that you've been into, in terms of what the engineering teams are focused on, what they're working on?
Christian Idiodi:
I ask a lot of companies I work with, I always ask the question, "Where do your engineers spend a lot of time? What do they spend their time doing? What are they actually doing in their time?" The number one answer or number one and two answers, the first answer is often coding, they are coding, or they are engineering. The second answer is often meetings, they are in meetings. This is consistently true in the majority of companies that I talk to, they are coding or they are in meetings.
When I ask these exact questions in some of the most innovative companies in the world, the best companies in the world, you know what interestingly the answer is, solving problems. It's always consistently... It's very interesting to me when I see that big difference, but it's kind of what engineers understand their role to be. Now, I've seen this question to almost be directly correlated to the operating model of an organisation.
When a company is a delivery team, meaning the engineers see their job as just there to ship things, build things and ship things, almost like a feature factory. "We just build things, whatever is told to us, we crank it out. That's what we do." Then of course the answer is, "We don't have time to do anything else, because we have a long list of backlog items that may be prioritised by somebody for us to go deliver." When a company is in what we call the feature team, where they are given a roadmap of items to go design and deliver, it makes sense that they spend their time in meetings, because somebody just came to you and said, "Hey, we're going to build a house."
So what's your next question? "How many rooms do you want in the house? What kind of house do you want?" So you have a lot of questions. You have to gather those requirements. So you're going to spend a lot of time in meetings to try to understand what you are going to build. But you see in the best companies in the world, the engineers often are the ones coming up with the solutions themselves. You're just saying, "Hey, I need a place to live." And they're like, "What about the house? We've got to solve that problem, let us think about the best way, let's understand your needs."
So engineers participate in solving problems, they see the core of their job as solving problems. Coding is just how people will experience the solution that they've come up with. It's not the job, it's just part of how people experience the solution to the problem. They have to code it so that they can deliver it. So in the best companies in the world, the engineers are working on outcomes.
Bill Campbell will often make this argument that the most important thing is having an empowered engineer, and the way I describe that in companies or how I assess that is, I go to an engineer and I say, "Charles, what are you working on?" Charles might say, "I'm building an API for this, I'm building a new mobile app." And I say, "Charles, why are you working on it?" In some ways, if Charles says, "My product owner told me to do it, my manager told me to do it, it was assigned to me on a ticketing system. I pulled it out of a list of things. It was the next important feature."
See, he might know what he's doing, but he's very disconnected from why he's doing it. He doesn't truly understand the problem he is setting out to solve, he understands the solution he's called to build. It creates this missionary versus mercenary concept. It's the difference when I tell people of like, "What are you working on?" And someone says, "I'm laying brick," and somebody says, "I'm building a cathedral." It's just that mindset. The empowered engineer understands what they are trying to create, more so because they have the context, the idea that authority has made its way all the way down to information. This is the core of what great companies have their engineers do.
For listeners who want to get better at being a product manager, what would you recommend?
Charles Humble:
That's such a fascinating and fantastic answer. Thank you. We are unfortunately running out of time. Maybe as a way of bringing this to a close. For listeners who want to get better at being a product manager, what would you recommend? Are there particular books you should read or articles, or how do you get better at the craft and the skill of being a good product manager?
Christian Idiodi:
Some of the best product people I have met have learned from great product leaders. Often today I don't even recommend companies to people, I recommend leaders to them. I say, "Look, you want someone that can coach you and get you better at doing product management." It's often not something that you can truly do on your own. I've had to come to terms with that. You could learn a lot through a mass series of failures, but not a lot of companies have an appetite to just let you continuously fail and do the wrong thing.
Charles Humble:
Yeah.
Christian Idiodi:
And this is often another thing that is challenging because when people join a company, they don't have all they need to be successful. They don't understand the business, they don't understand the industry. They may even come from the industry, but they don't know the nuances of the organisation and the team. So they have to learn, however, what do we demand from them on the very first day? "We want them to start doing product work, per excellence, highest quality, don't do anything wrong."
And we set up this pattern where people cannot even be in a safe learning mode, because they are in a full delivery mode, they are in a full performance mode. And so often I tell people, "If you want to get better at product, you've got to commit learning to your leader, or whoever can get you better." Be it a find a coach, ideally that person is internally, they have skin in the game. What I go to them if they don't haven't done an assessment with me, is I demand one.
And I say, "These are the areas that I need to be competent at for good product work." Hopefully everybody can come to terms with that, "I need a deeper understanding of the customer, a deeper understanding of the business, the data, the industry and my product. I need to have these competencies in, whether it's communication, working well with people, dealing with stakeholders." You're going to map these things up, and you can do a self-honest assessment of yourself, because you know what those things are, but you are not going to get better by avoiding them.
So you may be very good at talking to customers, but terrible at using data is to inform your decision. The only way you're going to get better at that is by having somebody coach you to get better, or by trying to use data and failing and getting good feedback on how to do better. You see, so I say, you've got to be very realistic with these opportunities. Now, don't get it wrong. I often tell people this, "You are not hired for your weakness, you are hired for your strengths."
So the idea of saying, "I'm terrible at this," doesn't mean you're a terrible product manager. You are hired for your strengths. But if you're asking the question of getting better, you have to find the things that's like, "Played any spots?" "I need to work on three point shots because I'm great at a two point shot." What are you going to do? You're going to take more three point shots in practice and during the game, you're going to have a high level of confidence on the two point shot. You see, what we don't have. And it's one of the biggest things that I struggle with in this industry as a coach, is we do not have enough safe places for product people to practise. We just don't.
And so often product people are kind of what I would be like on the war front. There's no practice on the war front, are you at war? There's no safe place of getting it wrong and stuff. And I say the best teams in the world, at any sports, in any stuff, in music, we practise before we get out before people. This is how we get better. So I say, if you really want to get better, you either got to find a leader, a manager that can create that safe place for you to practise, or you have to find and create that environment for you to practise the things you want to get better at.
Charles Humble:
Yes, absolutely. I think that's really the key to being a product oriented organization or a learning organisation. It's creating that environment and letting people try things and accepting that not everything is going to work out. Failure is very much part of how we learn, it's part of how we build great product ultimately.
It's been such a joy for me having you on the show, Christian, thank you so much for taking the time to be my eighth guest on my Hacking the Org podcast, from the WTF, it's the Cloud Native team here at Container Solutions.
Previous article
