The Christian Idiodi Hypothesis: Great Product Management Starts With Admitting “I Don’t Know”
In this episode of the Product Science Podcast, we cover the importance of humility in product management, the benefits of diverse thinking, and how a contest kick-started Christian’s career in product management.
Holly Hester-Reilly
Christian is a partner at Silicon Valley Product Group. 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 Microsoft, Starbucks, and Squarespace. Christian 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 conceptualization to product delivery.
In this episode of the Product Science Podcast, we cover the importance of humility in product management, the benefits of diverse thinking, and how a contest kick-started Christian’s career in product management.
Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, YouTube and more. Love what you hear? Leave us a review, it means a lot.
Resource Links
Silicon Valley Product Group
Follow Christian on Twitter
Follow Christian on LinkedIn
Follow Holly on Twitter
Follow Holly on LinkedIn
Questions We Explore In This Episode
What does Christian say are the fundamental tenets of great product management?
- You really don’t know what will work until you experiment, try things, and learn
- Talking to customers and understanding the nuances of their problems is key
How did Christian develop his skill at collaboration across disciplines?
- Christian went to a boarding school with people from around the world
- There, he started to learn languages and worked with different groups of students
- He realized that the teams who could pull people in with different skills would do the best
What does Christian look for to identify a successful product transformation?
- The real magic of transformation is in changing how you decide which problems to solve
- The product teams are truly agile and able to respond quickly to customer needs
- There is a clear vision of what problem they will solve, who they will solve it for, and an insight-based strategy for how they will solve it
- When an engineer knows why they are building the technology because they know what business problem they are solving
Quotes From Christian Idiodi In This Episode
The fundamental tenet of really good product is that you really do not know. And that how quickly you can go through experiments, how quickly you can go through testing, how quickly you can gather evidence, how quickly you can validate and learn what actually will work is really part of the secret sauce of what makes good products.
And so in any story or journey that I tell people about my transformation efforts, I have stories about when I realized those things were true, you know when you start to realize how oh my, we are finally there. We have captured agility. We have an empowered team. For me it's when an engineer is solving a business problem, and not just building tech. They know why they're doing stuff and they're leading those kinds of outcomes.
I have always been very deliberate if I'm building teams to not build people that look the same, think the same, approach problems the same. It's almost like a recipe for disaster. …I'm very deliberate about the teams that I build and the diversity of thought, the diversity in backgrounds.
The Product Science Podcast Season 5 is brought to you by Productboard
Check out their eBook: 10 Dysfunctions of Product Management
If your product team is struggling, it could be one of the 10 dysfunctions of product management. Learn more about each dysfunction and how a product management system can help you address and avoid them.
Transcription
Holly Hester-Reilly: Hi, and welcome to the Product Science Podcast, where we're helping startup founders and product leaders build high growth products, teams and companies through real conversations with the people who have tried it and aren't afraid to share lessons learned from their failures along the way. I'm your host, Holly Hester-Reilly, Founder and CEO of H2R Product Science. This week on the Product Science Podcast, my guest is Christian Idiodi. Christian is a partner at Silicon Valley Product Group and 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 Microsoft, Starbucks and Squarespace. Christian also teaches Product Management and Innovation at Virginia Commonwealth University in Richmond, Virginia, and gives back to his local product community each year by supporting and advising two student-led startups from conceptualization to product delivery. Christian, I'm so excited to have you on the podcast.
Christian Idiodi: Holly, thanks for having me. Happy New Year to you.
Holly Hester-Reilly: Happy New Year to you too. I always love to hear stories about how people got into product and I haven't really heard yours, so how did you get into product?
Christian Idiodi: My story is like everybody's story. I absolutely got into product by not trying to get into product. I actually got into product by winning a competition and I had a chance to start my own business and a company funded it. And after doing well at this, the company thought I could do well at managing their innovation budget and it was not a real formal discipline of product management at that point. I was actually pre-med in college, going to be a medical doctor and stumbled upon this opportunity, while waiting for medical school. So a big career shift in going into business, starting my own startup, and then really trying to discover how do companies consistently go from idea, to having something in a market that drives revenue. And, I failed woefully after my first initial success. I failed woefully at my next 18 ideas, nobody went at anything I was coming up with.
I'm talking not like, I thought it would make a $1000 and it made $1, zero, failure after failure. It was a very painful streak of failure. And I started to learn really the hard way through a series of failed experiments, I will call them now in hindsight, what it took to consistently and constantly go from having a great idea into really deciding what to build, and then actually building it in a meaningful way that solves problems. And my career starting in products really came from an opportunity to build one grid product, and then through a series of failures.
Holly Hester-Reilly: So, tell me more about these. Let's start with the one that worked, the first one. What was that?
Christian Idiodi: I worked for a company in the job board space. And the company had a competition, they call it like an Ideas for Anyway, anybody in the company could submit the business case or idea, as long as it was generally related to the company or the industry, you will get a million dollars to run this business. And I didn't really have an idea, I just joined the company, I heard about the competition, or maybe about a week before the competition was over, I just started talking to people. Like I got out, spoke to customers, was learning about the business at a rapid pace. If you made it to the top 20, you got a $5,000 cash prize and that was my goal. Can I just make it to the top 20 and just get 5,000? And so, I probably a week before the competition, I come up with an idea, really about incorporating just-in-time learning with a job search.
So if Holly's looking for a job and it says, "You need Excel skills," and she don't have Excel skills, can I quickly train you on Excel before that job expires, so that you can be satisfied and apply for that job very quickly? And, this was the very first E-learning platform built, and what you might consider today as a learning management system and a platform to expose people to skills. But back then, that was just the idea to get people just-in-time training. And I made it to the top 20, I thought I was done and happy, then you got to keep going. And this is done like American Idol style, where you're pitching on stage and stuff. And, I was like 22-years-old freaking out throughout this competition. But I win the competition, I get a check for a million dollars to build a technology enabled product. And I probably cry myself to my hotel room that night in panic, because I have no clue what to do.
It was just a good idea, it sounded good on paper, but now I actually had to make it real. And I struggled my first couple of months, because I spent a lot of time talking about how I will spend the money, all the business plans and elaborate ways I will go about doing it and I did nothing. I was just talking about what I was going to do, and my very first board meeting was probably the single biggest humbling day of my career because they all laughed at me. "You didn't try anything, you didn't make mistakes, you were just..." "The money is still in the bank." "And at this time, we could have made more money if we had just put this in a high yield interests account right now, we want you to try things, we want you to fail, that's why we're here to guide you." "And, [inaudible 00:04:48] I let into the mistakes?"
And, I put my head down. I actually thought I was going to run away and go back to medical school at that point, but I put my head down and I grew that business to about 10 million over the next 18 months. And as I was going through that, I had an idea for another business and I submitted it to the competition and won again. And at this point, the leaders were like, "Why do we have to wait for a competition for you to share all your good ideas?" "Why not just manage our innovation budget?" "You take some money, you think of a good idea, just do it." So, this was really my first introduction, there was not a formal product management discipline back then. In some ways, it was innovation management. I'm like the coolest kid on the block, you mean I just think of an idea and I do it. This is school. And then, I just had a streak of failures, like nobody went at anything. And I started to reflect, because the first two ideas were very good.
They were successful in the market adoption and I started to recognize some patterns. First in the beginning, part of my success was because I did not know. I was learning, I had really realized I didn't know. And so, I spent time talking to customers, spent time learning from people in the business, spent time engaging with the people that will create this product, because I had no clue. But in the streak of failures, I was making assumptions from a conference room, sitting in Chicago when all the engineers were in Atlanta, and then calling them to tell them what to do. And I never saw their faces and I never spent time with customers. I was also making assumptions about what customers wanted and who they were.
And, I started to look at really the differences from the very first success I had to the streak of failures. And, this was before Mary Kagan wrote an amazing book. And I always joke with Mary Kagan like, "Where was your book when I was failing?" "You wrote it after I failed." I learned all of these things the hard way in some ways. And, I started to shift my streak of success and I built over 80 products with this company. I moved my family to Atlanta to be close to the engineers. I got out of the building, as a philosophy. I needed to spend time with the people I was solving problems for.
And then I started to understand really what it really took. Because for me, it was just not about having a great idea, and then magically it becomes a great product. Its, what does it take to consistently go from this is a problem worth solving, to building a solution that will compel people to switch their behavior, to adopt this solution, to pay you for it? This was a different mindset at that point. And so, it took most of these products over 14 different countries around the world and built over 80 products in now most jobs, they are found. And, this was really my entry into this discipline of product management.
Holly Hester-Reilly: Wow. That's the first time I've had anybody tell me that they got into it by winning a contest.
Christian Idiodi: Blows my mind too. I never thought any discipline, I was really pre-med in college and I thought I would be a medical doctor. And I took a year off and traveled the world and I got broke, so I needed to work a real job before I started medical school. And this was the part of the path of working this real job, and then winning a contest into it.
Holly Hester-Reilly: Wow. I'd love to hear a little bit more. Were there some things that you still practice or gain insights from that went well with that first one?
Christian Idiodi: Absolutely. The fundamental of, I think Mark Anderson says it, "The most important thing is to know what you don't know in some ways." That has always been the biggest product management lever for me, really this sense of humility, that ego and arrogance, and people arguing in conference rooms about what people want and what customers desire, and what the right thing is and what the best thing is. It's really a lot of waste in our discipline, that the fundamental tenant of really good products is that you really do not know and that how quickly you can go through experiments, how quickly you can go through testing, how quickly you can gather evidence, how quickly you can validate and learn what actually will work, is really part of the secret source of what make good products. And because it's one of those things like, you don't want to be like a one hit wonder.
People come up with songs and stuff, and then we have one great song in that stuff. And then, you see artists or musicians that are consistently putting out good music. You start to say, "What's the difference between like the person who had just one hit in their career and could never come back again and the people that do it consistently?" And, that was my moment of Zenning product, like the whole sense of, "I don't want to be that person with just one great product I built 20 years ago and I never can build it again." And I had to go back to the root, was it luck or was this something fundamentally true about that initial success? And for me, it was truly the fact that I was the dumbest person in the planet and that just that humility of going to say, "I don't know, I need to learn," that hunger.
And coming up with the idea did not come from just sitting outside, it came from like me going to learn, talking with the customers, understanding the nuances and the problems of people trying to find a job. And if I carried something from that piece there, when I'm building products today, I often joke when people are arguing in a room, I pull an empty chair and I say, "This is the customer." If somebody here can go in and sit in the chair of the customer and tell me a story from the customer's perspective, he will listen to him. If not, we are argued in a conference room. And so, we all need to get out of the building. And I constantly remind myself of those are assumptions, those things that might come from, I have been in this industry for 20 years, so I know what people want, or the ego, or the I want to be right or my interpretation of the data. I've never led to magical products.
What leads to magical products is really a deep sense of the customer, the people you're trying to solve problems for, a deep understanding of your ability to collaborate with different people and bring in different perspectives and work together to discover a solution we're building.
Holly Hester-Reilly: Yeah, I love that. I love the humility. And one of the things you hit on there that made me so happy to hear is just the idea that thought about what had happened and you realized, you were wondering if it was just luck, and then you realized there's more there. One of the other things you just mentioned that I would love to hear more about is about collaborating across disciplines. How did you develop that skill?
Christian Idiodi: Oh, this is actually a very interesting one because in some ways, is it land, is it natural? In some ways, naturally collaborative people do exist. I went to a boarding school in Africa growing up. They had people, different parts of the world spoke different languages. I'm talking like 80 different languages within this place. I realized at a young age that my ability to succeed was to be able to speak the language of the people. If I spoke a different language, I could get closer to a community of people and involve me in things that they do, if you're playing sports. People align themselves by different things, backgrounds, religious, race, sex, gender, all of those kinds of things. And, I started to learn languages very quickly. I started to work with different groups. It was a gifted program and you've work on problem solving. And I realized very early, and I was 12 when I started this boarding program, that teams that were able to solve problems well were the ones that could leverage teamwork very effectively.
That if you could pull people in with different skills, you can imagine we were always given problems to solve this program. We'll come into class and they'll write the problem and they'll leave you alone. And you see very smart geniuses work on the problem and they will choke on some aspect of it, either that they were good at the scientific parts of it, but not theory, or they were problematic in presenting it clearly. And the teams that won, they were always like three or four people and they all had different little skill sets that they all chipped into it. And, I recognized this very early on. So the kid, when you're picking players on the basketball court, everybody raises your hand and I'll pick you, you pick here, everybody goes one by one on the team. And I learnt at that very early stage, don't pick all the tall kids, pick the kid that can dribble.
Pick one kid that can shoot, pick one tall kid that may be able to dunk or block. And that diversity of thought, just know one's differences, I learned very early on. So I have always been very deliberate, if I'm building team, to not build people that look the same, think the same, [inaudible 00:12:40] problems the same. It's almost like a recipe for disaster. But I learnt in my career that, unfortunately at a very early stage, and that has always permitted my thinking. It's like, I'm very deliberate about the teams that I build and the diversity of thought, the diversity in backgrounds. They always say, "You always have a cowboy on your team." I'm like, "Yeah, because sometimes I need as well to just go in and shoot somebody." It's kind of like the mindset of thinking, and then you need somebody super analytical. And very early on, I recognize that solving a problem required different approaches, mindset, thinking.
In our world of product, the risk involved in solving a problem actually leans itself towards this specific skillsets. We need to be thinking about what customers want and will value. We need to be thinking about what will work for the business and what's important for them, what constraints they have, what policy, what's important in how they make money or how they get profit. And people thinking about that are the skillset of a product manager. And so, we need that on the team. And then, we need people that can think about the experience and does it work the way people expect it to walk, and how do we drive value in a meaningful way that people can perceive it, and understand it and the design and how it feels? Those are people we call designers, and then doing it is a whole different ballgame. Can we do it?
Do we have the skills to do it? Do we have the time to do it? What technology do we leverage? And, that's the engineer. So in some ways I'm thinking about my basketball team here and I'm like, "I am not winning this game, if I don't have at least those three people walking together." And I often joke with executives all the time when I tell them, "If you're solving problems, it's a different sport." Now you could be like, Holly's great, she played hockey for years, she's a great athlete, so let's go play basketball. I say at some point, if Holly's two feet tall, it's very difficult to convince her that she can dunk the ball. There is no training in the world you can give... You might need different skill sets, it's a different sport. And the sport of solving problems, identifying and solving problems requires collaboration. And those people on the team, product manager, design engineers are core skills, core competencies. You need to solve a problem in a modern product organization.
Holly Hester-Reilly: Yeah. Wow. Okay, so you went to this boarding school, and then you were pre-med in college, and then you fell into this competition. What happened after managing the innovation budget and all of those failures? How did you move on from there?
Christian Idiodi: I built over 80 products. I had a streak, I've not had a single product failure since then. And I'm not even going to knock on wood about that, because there is a set of principles, there is a mindset about how to do product well that yields consistent results. And it's not saying I haven't had a bad idea, or I haven't had experiments that have failed, but when I say I haven't had a product failure, is because I haven't brought anything to market that is not what customers want. And that means that you can learn, because the whole point is to solve a problem. And sometimes you naturally pivot, because you have a deep understanding of the customer before you launch a product in there. So, I haven't had a product failure since then and I've built over 200 products in my career. Every year today, I start by doing two new products every year.
It's a way I stay connected. So I go from idea to revenue, I want to make sure the techniques and the things I teach people are still relevant. I want to learn new techniques. It's one of my passions. Maybe my brain can't stop thinking about solving problems, so I pull teams together, I go from idea to revenue and it's just something that I do. But when I left this company, I thought I've done growth stage. I went and did a startup for a couple of years with some people in a similar space, focused on the hourly job. And then, I thought it'd be great to teach people about this. So I thought at a local university, a startup internship and a product innovation class. So what will happen in this class is students who come up with ideas, we'll pick two random ideas from the class, we will bring the class into two groups, and we'll go from idea to revenue or to value in 14 weeks, by the end of the class.
And that was the whole essence of the class, is you're going to learn everything about product, learn everything about building a startup and you go all the way to exits, or you are going to go raise money or you have product market fit at the end of the class and that's good. And you never know what kinds of ideas you come up with in every semester and what ideas people like and it could be. But the whole idea is that if you focus on the customers and the problems you're going to solve and you work collaboratively with a team of diverse people, you can actually build an innovative solution. And, we coaching them on the skills that are needed to do that.
So I thought there for a while, it was really fun and several great ideas and products, they came out of that class. And then, an executive I had worked with before joined the Legacy Financial Services company and invited me to help with their transformation. I joined this company as global head of product to leader transformation effort. That's how my career trajectory went. And then, I'm now in the Silicon Valley Product Group, where I share all these stories with companies with the hope that I can convince them that nothing stops them from walking in a similar manner or better.
Holly Hester-Reilly: Yeah, I want to hear a little more about that class. So, I also teach a class and we have students going through validating their ideas and making a case that they would use to ask a CEO for investment in their idea. Of course, the class I teach is shorter. So I'm curious, how do you actually build the thing and get it to revenue within the constraints of the course?
Christian Idiodi: Great, first of all... Needed to do it. What we do, we pick ideas. The core of it is tech enabled in some ways, whereas as the root, the role of technology is ever-changing and that there's this digital sense that whatever solution people want today, they probably start on their phone and even if there's not an app for it, they are going to Google an app, so I'll Google something to find it. So people are going to a generation, where tech-enable has to be part of every business. So obviously, this class has people that are coming from business school, different backgrounds, interested in a startup entrepreneurial type of lifestyle, or innovation as a concept and they want to understand what it looks like to be a founder of a company, what the work will entail. You're going to get a variety of backgrounds in here and we're going to leverage skills.
There are people that are more tech-centric in their work, or approach or career path. There are people that are more design-centric, so we split the class. You've got people that are, I'm in the business school, that's why I'm here, I love business kind of stuff. I've got people that are like, "I love to design things." And so, we want to make sure that they have the skills in these two different sets. So we, first of all, want to look at competency and a necessary range of skills. Then we provide them access to resources, because none of them are skilled at building apps or building things like that in some ways. But very quickly, the technique that we typically use with this, is the Cost My Development Program or the Discovery Program. And, my goal is to auto manually do some of these things. So, I'll give you an example.
One of the ideas that came a couple of years ago was about mechanics, like you're fixing your car. There are problems around that with I don't know what the cost is, the inconvenience of going to a shop, I don't know what shop to go to and all of the nuance about what's wrong with the car, you go in for an oil change and there are 17 other things wrong with your car. And so, there were all of these pain points that were identified by this. And part of the idea was, what if we could bring the mechanic to you? There are lots of little things in there. We're having a conversation right now, wouldn't it be great if someone was just fixing your car right outside your house? And, you don't have to take it there and there was transparency. So, we identified a series of problems around this. And the way the class was structured in the area the first couple of weeks after we go through a deep problem identification and problem definition type of thing.
We are understanding how people and they are spending time talking with customers, gathering stories, gathering all the nuances, understanding how people solve the problem today and who has this problem. Those are part of the very core aspects of the class. And so, they built a nice list of people that have pain and we don't have any technology, we don't have anything. And so, what do I tell the class to do? I say, "Solve the problem." The next person you talk to, if Holly needs an oil change, say, "Okay, we will change your oil." Go find the local mechanic out there, if you have to drive them in your car to take them over to Holly's house to change her oil, bring the stuff to them, change the oil, manually transact the price and stuff. It's painful, but what you are doing here is you are getting an understanding of what a solution to the problem looks like.
In some ways, you're writing the requirements of what needs to happen. [inaudible 00:20:49]. I need to know Holly needs an oil change, I need to find somebody close to bring it. I need to schedule a time for her to get the oil change. I need a way for Holly to see the person working on her car, so that she can feel safe. How do I vet? How do we convert the trust element? How does she know she's getting a good price? And, these were associated manually for weeks, almost a month of this class manually solved the problem. The goal was to find 25 to 30 people that we could solve these problems for and identify six to eight mechanics that you trusted in a local market that could work on cars. No technology involved here, no need to build apps and things in here, but do it manually, painfully, getting out of the building, spending time with those customers, calling up mechanics on a phone book, vetting them.
Running into problems, so people showing up late, not on time, not collecting payments. And so after they had done this, they became experts in the marketplace of people looking for help with their vehicles and people that could fix the vehicles. Now after we've done this, we said, "What technologies could we use to enable these connections more effectively, to ensure that we identified the blue ocean around this in here?" And so, the class actually comes with some grants. So, every team gets about like $5,000 of something in here. And so, they are able to go out into marketplaces and look for technology help, and some little things to build some version of an MVP or a prototype of their solution in this way. And so, they started personal mechanics, .com and an app for this through it. And so, at the end of the class, the outcome of the class in product market fit is that they have 25 customers that said, "We love this solution and we're willing to tell people about it."
And the goal is to have a website with five star reviews or 25 reviews, so your exit part of this exercise, not like you build magical technology, but if you get 25 customers that said, "We had a problem with our vehicle and stuff, we used this app or this solution and it solved it," then we've gotten through the process of what it takes. Typically, people opt in after the class. I want to work on, this is so much fun. I want to be a co-founder, I want to own equity in this. That particular app was sold to a firm, a venture firm. It's a real app today, Call My Mechanic.
It yielded in excess of almost $3 million dollars in that sale from that IP. So, great exit is just a short amount of time and we're talking a 16-week program year going through this. That's the whole model that we went through. And it was really fun for me, just every year going through two things, coaching teams, learning nuances, working through people, many of those [inaudible 00:23:16] are founders of companies today. They are working as product managers, or they are sharing those stories and they're learning in the real world. So, that's really a benefit.
Holly Hester-Reilly: Yeah, that sounds amazing and it sounds like so much fun for you.
Christian Idiodi: Yeah, yeah. I miss that. I no longer teach the class because of my work demands, but I love the idea of doing the two new startups every year, so I keep doing that. I will work with teams every year, my friends know what I want for my birthday. It's a problem worth solving in the world. So, everybody shares ideas and we pick something to work on. And that's really, sadly for me, in some ways what's fun for me. Like, "Really, that's your hobby and stuff?" And now, I'm doing a lot of work in Africa, working with a lot of companies and doing a lot of startups in Africa. I had the false assumption that problems we've solved already in Europe, or in North America have already been solved in other parts of the world. And, you go to parts of Africa and you realize people still find jobs in the newspaper. And I'm like, "Wow, I solved that problem in 1998." And you're like, "It's too [inaudible 00:24:12]." And, it was really a humbling experience for me to realize that there was still significant opportunities to leverage technology to solve problems.
I started Innovate Africa as a brand and we focus on different areas in employment, in healthcare, in power, in infrastructure to try to bring in technology enabled solutions in Africa. So, most of those startups that I do today in Africa.
Holly Hester-Reilly: Yeah, that's really great that you're able to do that. And for any listeners that are thinking about starting something, I've recently had a conversation just over the weekend, over New Year's, with a person from a Caribbean island who was telling me that, "They want to start something that would bring medicines to their island that are accessible in other places." And I'm curious for people like that, how do you tell them to get started? If they're from that place or they've been to that place, but maybe they don't have the relationships with organizations there or people there, how do they even begin?
Christian Idiodi: Yeah, it doesn't have to be in Third World countries or out of the States. Its, the problem exists everywhere. How do I get start that problem with things? I am always of the bias of solving the problem for one person. Because remember, I fundamentally believe we do not know and I fundamentally believe that the best way to learn is to actually solve the problem. And, I say that in the... Because people always have great pitches, and great plans and only if I had $10 million, then I'll build this infrastructure and build this and I will help millions of people. And I love all of that. I want to. And I always just say, "Can we just help one person?" And I say, "Holly needs a medicine and she's in the Caribbean. "And, where is the medicine she needs?" "Oh, it's in Canada." "Okay, let's just get Holly, forget everybody else, just one person," because we want to solve a problem for millions of people and we are not going to quit, until we just help Holly.
That's our first thing to do. When she say, "How do you get started?" I just say, "Holly, great, let's solve her problem." "If we manually have to place 100 phone calls to people in Canada, if we have to travel somebody to go bring the medicine to Holly, let's do that." "Whatever we need to do to solve Holly's problem." Because when we solve Holly's problem, we will have a lot of validated learning, because we'll have to identify the pain. That was painful. Can you imagine we had to fly to Canada to go get the medicine? Are there not better ways to do that? So we're going to say, "Okay, we've solved Holly's problem, let's pick somebody else." "How about Susan?" "She needs medicine."
"What have we learned from our experience with Holly that we can either automate, innovate, leverage technology, find an alternative, what was really painful about the first way we helped Holly that we can improve with the way we are helping Susan?" So, most people that... I get a lot of people that pitch me ideas or want to come for me for investments and stuff, and I always give... The product challenge I give them is to go solve the problem no matter helping painful. I say, "I don't need to hear your tech, I don't need to hear your tech stack, your cool innovative idea or your unique value proposition and all of your textbook terms you're going to give me." I just say, "Just show me five people you've helped manually and painfully," and all I will do is call Holly up and say, "Holly, tell me about how you got your medicine." And, "Oh, they were so kind, they brought it for me."
And for me, cuts through all of the nuance of what it takes to be an entrepreneur because you did some work, you understood the customer, you spent time with them, you understand what the value of your solution is. I start to see the path to money. Once you do that painful, it's going to be painful. It's going to be hard because truly for me, the other stuff, "Oh, I'm going to use technology, hire a team, product people are going to design stuff or build a cooler app, now you can get your medicine." There's a lot of apps in the world, there's a lot of unused tech in the world. There are lots of things in the world that do not solve problems in a meaningful way. What solves problems is solving problems. I want to know how to [inaudible 00:27:48] that. Show me Holly happy that she got her medicine. You've solved the problem.
And now you're asking me, "How I can do that at scale for millions of people in there?" I have stories to tell, I have Holly's to learn from. I know who the customer is. I can see, I can understand value, I can understand what will work for the business. I know that we can leverage technology to enable it to drive meaningful solutions. So people ask me, "How to get started?" I say, "Solve a problem." Is even how I tell people, how do I get into product management? I said, "There are so many problems in the world, just pick anything that you're passionate about, practice." It's like lifting weights. You want to go lift a Google problem, that's like a 500 pound weight. Just pick up little stuff in your house, wash dishes, I don't know. If you are not comfortable solving a problem like, "Why do I go place you now..." I'm like, "That's what the job is." You're going to work collaboratively to solve problems, so get comfortable solving problems.
Holly Hester-Reilly: That's beautiful. So, I also want to hear more about the transformation that you got involved in. So, tell us about that.
Christian Idiodi: You mean the transformation that makes you lose your hair or grow your hair in the same year?
Holly Hester-Reilly: Yes.
Christian Idiodi: What transformations do? Transformation are hard and I think I never truly understood that I was signing up for a transformation in the sense of what it truly means. You just recognize that things are broken, they need to fix it. That's kind of what mostly... It's like, this is not working or what got us here is not going to get us where we need to be. And, typically most companies recognize this in different ways. Either they recognize clearly competition, there some new technology enabled companies coming into their space and disrupting their space, or they are losing market share or they're not growing as fast as they used to grow. Or more importantly, their customers are changing, their customer. The newer generation customers are different, in than the ones they've had for years.
So the whole essence is, we've got to be able to do things we could not do before or what can we do now that we could not do before? And I joined this company, very legacy company, about 50-year-old company in financial services. And the company, "Yeah, we want to become a modern day technology company." "Is this a joke?" Like, "You print documents today, you are services oriented." "Okay, are you thinking of moving from waterfall to agile?" They're like, "Yeah, we need to do that." "Are you moving from like on-prem servers to cloud?" "Oh yeah, we need to do that too." "Do you have anybody in products?" "No, we have no product organization." "We got to do that too." "How do you make..." They say, "Oh, we are sales driven." And this is one of those, everything needs to change. It's like, "Where do we start?" "What do we do?"
And I was brought into this company, fortunately I had a group of people that worked in before, in the technology leadership, and I had a technology in there and we recognized the shift that needed to happen, first in changing how we build things. We had to change how we were able to move from waterfall to... Which is almost the baseline today of what people think as transformation. Our tech stack is not working, we don't have the technology to do the things we need. And even if we have the technology, we are not building things in a manner that we can go fast. But that's just one aspect of transformation, changing how you build things. And so, in some ways, that's startling your tech [inaudible 00:30:46], building a foundation that allows you to build things, building a methodology or a way of working that allows you to respond to changes in your marketplace or industry quickly.
That's what agility really is, can I respond to changes, threats, opportunities quickly? It doesn't matter what framework... That's the whole point. Like, the master output of this is truly daily releases, continuous deployment, that's really that goal. If I see an opportunity to win market share or can I go build it, deploy it and go capture it. If I find a bot today, can I go fix it and go deploy? Foundationally, most people think that when they've done that, they've transformed. But remember, you can build a lot of crap that doesn't work or add value. So it's not just about changing how you build things, but it's important that if you have the right solution, you can deploy it fast. But just changing how you build doesn't mean you even solving the right problem. It's almost a little garbage in, garbage out. So in this organization, that was one of our first investments, changing how you build and hiring our own team. The company had a group of engineers all outsourced, and which is a common thing because companies look at technology as a cost center.
And [inaudible 00:31:54], "Oh, we need to use tech." "We are not a tech company." "Who knows tech?" "Oh, let me pitch you my tech company, we're a tech company, we can build it for you." So, they outsource and this leads to a ton of mercenary like behaviors.
Holly Hester-Reilly: Yeah.
Christian Idiodi: Work for hire, we are not in there. We do whatever you tell us to do, which it could also be the bad thing too as well. We don't care if it's good or bad, you're paying us. Whoever signs the statement of work, as long as it's approved and you tell us to build it. And so, we had to build an engineering organization from scratch and we had to build a case for why this was important to do. And that we could deliver value to our customers, because the engineers were tied to those outcomes, than work for hire.
So, a big shift in changing how you build is changing the technology and the infrastructure you use. We are moving to a microservices platform, we're moving to cloud. We're then changing how you work to build things, moving to agile, changing who is involved in building things, going from outsource to in-source. So foundationally, a core path of that transformation really focused on that piece. Then realizing only if we have the engine, we still have to solve problems. Remember, most transformations and similar in this story here, we were just told what to do. Things were projects. We have funding projects. "Oh, We should build a new app." "How much is it going to cost us?" "How long is it going to take?" "Let's build the app." "Finance, we're going to give you a million dollars to deliver this project, we'll put the project manager to oversee it and ensure that it's delivered within scope on time and budget."
Now, where most methodologies, they are waterfall, but we are changing how we build to agile. How is this going to work? We are no longer delivering projects, we need to solve problem. It's a different sport. One is delivering projects, the other is solving problems. And now, we need a different skill set. And so, we now had to build an empowered product organization with the necessary range of skills and competency the company did not have. They have business analysts that will write requirements and ship them to the outsource technology. I had hundreds of these people and I had to inform them that, "Hey, I like you, you're a great hockey player, but we've decided no longer to play hockey." "We are going be playing basketball." "And for those that want to learn basketball, we might have opportunities to coach you, for those that really love hockey and stuff, unfortunately this may no longer be the environment for you."
So you can imagine, there is some transformational shift where you are dealing with people issues and people personnel of what you need on the team. They had no design discipline, so you had to build a design competency from scratch. You're bringing engineers in-source, they have the right skill sets to work with people collaboratively to solve problems. So, the solving problem is that you're now going to be doing something new to a company called discovery. In the old sport, we don't need discovery because if I'm a salesperson and a customer says, "I wish your app were blue." You tell the team, "Make the app blue, I need to sell." "And go deliver blue, so that I can make more money." Nobody needs to discover if you think the blue is a good idea or what the real problem behind it, because you are delivering projects.
So now with the new empower team, it's not about making the app blue, it's about why do we want the app? Many customers have told us, "If it's blue we're going to get money." So the real problem is driving revenue, that's the outcome you want or the desire you want. What if there was something better than turning blue that will get us more money? We need to discover those things and we need to validate that actually turning blue will make us more money. So you see, this is a different sport, and a different culture and mindset shift for a legacy organization.
Because salespeople are saying, "Why can't I just tell you what to do?" Because we care about why we do it. And that's the second transformational shift, is changing how you solve problems. So now the organization is going from a top-down model, from a subservient model where technology serves the business through let's collaborate, let's work together to understand the problem that we're trying to solve and let's give a team of competent basketball players an opportunity to make the shots, to find out which players will help us solve the problem.
And, that's a big shift in the culture. You've got to hire the team, you've got to coach the team, you've got to manage the team. You've got to give them problems to solve and give them features to build. You've got to provide the right environment for them to work collaboratively, so new muscle. Now, the real shift in that and the company really lingered in their transformation on that stage, because big shifts culturally, like how do we work together? In some ways, you have to earn the trust of the organization. Because in the past, they told you to make it blue and you just do what we say. Now, you are going to decide the best solution. Okay, what if it doesn't work? Who do we hold accountable? How do you know I'm a salesperson? My salary depends on being able to sell and now I have to trust you with my career.
Now, you're going to build a product that people will buy. And I cannot push you, and I'm meant to work with you or collaborate with you, new muscle. So, that takes a while for a company to adjust and you have to earn trust. But the real magic of real transformations, I think really comes in changing how you decide which problems to solve, how you decide what to do. Many companies are sales-led, operations-led, founder-led, CEO-led, whatever the boss says. The best companies in the world know when we talk about product-led, yet that term in some ways, what it really means is that it's not the business driving what product does, it's the product team driving what we go after, because you've discovered the problems worth solving. You have the best... If the product organization represents the customer best and then somebody says, "What's our goal for this year?" "We want more customers."
You don't go to the head of sales, you go to the people that are the experts in the customers and say, "Hey, we want more people." If the problem is we want to keep our customers, you go to the experts in customers to say, "How do we keep our customers?" So when a company shifts to really becoming product-led, like certain things are true, first the person, the group that represents the customer the best is now the product organization. But, the way that comes across in a company is that they have a clear vision of what problems they are going to solve and who they're going to solve those problems for, and then they have a strategy for how they will solve those problems. Because that magical decision of the strategy is what tells the company, we're going to win. We're not going to react to like, "Customers are screaming."
You're like, "We have something cooler than all of your scripts." "We have something that we're working on." "We are going somewhere that will change your life." And., That's that magic of product like... Now, to do that, you are talking some serious product leadership work. You have to have a clear vision, you have to have an insight-based strategy for how we get to that vision. You have to design teams in a way that they can go after that vision and you have to give these teams problems to solve. I always look at transformation in that lens and I recognize that different companies are at different stages of that journey. There's not like a one, two, three, this is the steps in which you take it, whether you're doing just a little of this or a little of that at the same time. But in changing how you build, can you respond quickly to changes in your marketplace or industry through agility?
Continuous integration of deployment is really the magical end of that kind of journey, if you can get there. Doesn't mean that you have to be there, but the idea is we want to be able to capture opportunity quickly. Changing how you solve problems means you have a power teams doing discovery, changing how you decide which problems to solve means that you have a strategy and they're your product plan. And so, in any story or journey that I tell people about my transformation efforts, I have stories about when I realize those things were true. When you start to realize how, "Oh my, we are finally there, we have captured agility, we have an empowered team." For me is when an engineer is solving a business problem and not just building tech, they know why they are doing stuff and they're leading those kinds of things, the outcomes. And then you have product, people come into the product organization for like, "How do we hit our sales number?" That's a different narrative. So I went through that, this is why I lost all my hair and my mindset.
Holly Hester-Reilly: One of the elements in there that I'd love to hear a little more about is the vision and strategy. What is a product leader? What is their role in developing the vision and strategy?
Christian Idiodi: Oh, boy. At first, I think they have to recognize their accountability in creating a vision and strategy. Unfortunately, this is something that I see constantly outsourced in many companies and most of the dynamic that comes from it may look like our body's pressuring us for a strategy. And some board members, there was a company I advised that used one big of those big companies. And they're like, "Let's bring them in and to help us." And most leaders are like, "Yeah, that's a good idea because even the strategy is great, I was smart enough to bring in Accenture or McKenzie." "And if it sucks, then I can blame them for it," in some ways. And so, what happens here is that there's this cycle of leadership where they never really get good at building a vision or strategy, because they've constantly outsourced it their whole career.
There's no substitute in your strategy. It's always interesting to me like, you are closest to the business, closest to the team. You see the sport. If you are the coach, you see the landscape, you are the best person to call the plays. I would love any NFL team to ask for my advice. Just, "Hey, tell me what place we should call." I'm like, "How?" "How?" But this is what we do, we literally bring people from the outside, they come and do a little crash course to tell us what our play should be. And you're like, you don't know the skills of the people, you don't know the design of the team, you don't know the nuance of the industry, the domain, customers, the insights. So the best people, I always say first you've got to get your mind that this is your job, product leaders, to craft and communicate.
The vision is no good if nobody knows it, because it's meant to be a North Star. So it's not just, "I have a vision." If nobody knows it, then I don't know. We are still in the dark. So you have to craft the vision. And I say, "Don't go crazy about what this is." You're trying to answer two questions. What problems should we solve in whatever that horizon is? Five years, vision three. I've started to see a trend where people are going longer in their visions now, like several, 10 years. Most software companies, it should be three to five. But I've seen like 20-year visions on some, people are going crazy on that vision, which is okay. It means your companies are going to invest heavily in backing a vision, but not many companies can afford to place bets that long. And then the strategy, visions for me are not really unique.
Many visions are things many people want to solve, those problems. They had us part of this, is how? Because, that's what's unique. I use sports analogy, so forgive me because my mind is that shallow and I can see the world clearly with it. Every team wants to win the Super Bowl. It's like, "We all have the same vision, I'm playing to..." But how they choose to win, how they play, that's the unique part of their game, their style, their... So the strategies, what's unique is how you plan to solve those problems and you can't do that without focus. You just can't. And, this is not a game and you've got to pick a play. You got to pick a stance on how, in some ways. That focus doesn't mean, "Oh, we're going to do 20 things." So you've already said, "These are the most important problems we want to solve in our vision."
How is some logical, sensible way of saying this is what we're going to focus on first, and this is what we're going to focus on next and this is what we're never going to focus on. And, here is why. That's the empowering part of it. Because here is why, here's all the data, here is all the nuance. We are going to focus on keeping customers, because we recognize that the lifetime value is 500 years or whatever it is, and if we can keep the... This is the data, the insights that we're leveraging, whether it's qualitative, quantitative, industry insights, this is what we are capable of, our technology. I tell you this first, you recognize that it is your job. Next, in terms of the strategic framework that I use, you've got to find what to focus on. You've got to leverage insights, then you've got to translate those insights into action, which is what we might do with OKRs or we might do with any kind of objective.
You're trying to communicate this is the most important problem we should focus on now and here is why. And, you're going to bring people along on that journey and seeing them map. We need a roadmap, because how we... We need to know it clearly, I said, "You don't even know where you're going." "I don't even know why you're going there." If I come tomorrow and say, "No, we are going to go left now." Sure, in the absence of strategy or a plan, you're saying anything can happen. That's kind of really what you're saying. But if you know where we're going, if I say, "We're going left," you're going to look at a bigger map. Does this two get us to the same place? And why? Oh, we found... "We tried right last year and we had some roadblocks." And so, left allows us.... And, that understanding is what empowers teams.
That's the essence. So, strategy is not saying you're stuck in a way of doing things. You're saying, "You are leveraging insights and you're informed that this is the right problem to solve and you're revisiting how you solve that problem based on what you are learning." You are ultimately, you're still going to the same vision because you're stubborn, this is the right problem. So, that's really the job of a leader. And I tell people all the time, I say, "Vision, strategy work, context work, [inaudible 00:44:09] important, you're going to pour your energy into it because it will buy you some time." If you got a good vision, you can... It's a 20-year vision, you bought yourself 20 years off [inaudible 00:44:17]. I know where we're going.
Now the strategy, maybe you revisit it every three months. It's not an everyday shift, but you have to coach all of those things constantly. Because if everybody is having all these things are not great, if people don't leverage them in their day-to-day work. That's the whole empowerment of it. I know why we are solving this problem and I know how we plan to tackle this problem, and I understand the insights and data and all of the things that informed us that is an important problem. So, I am empowered now to discover a solution to it.
Holly Hester-Reilly: Wow. So I think unfortunately, we are about out of time, so we will have to wrap up. Where can people find you if they want to learn more.
Christian Idiodi: Please get to our website, svgp.com. We have a great newsletter. You can follow me on LinkedIn, or Twitter too as well, for insights. But most of our really great insights and our work are on our blog and on our website. Happy to talk to anybody about the journey of transformation, the journey of discovery, the journey of building great products. It's clearly my passion and what I love to do, and I can talk about this all day because I have not found any more meaningful profession in the world, than one that exists to solve problems for other people.
Holly Hester-Reilly: Awesome. Well, thank you so much. It's been such a pleasure to talk to you today, Christian.
Christian Idiodi: Thank you, Holly, and have a wonderful rest of your year. Thanks for having me.
Holly Hester-Reilly: You as well. The Product Science Podcast is brought to you by H2R Product Science. We teach startup founders and products leaders how to use the product science method to discover the strongest product opportunities and lay the foundations for high growth products, teams and businesses. Learn more at h2rproductscience.com. Enjoying this episode? Don't forget to subscribe, so you don't miss next week's episode. I also encourage you to visit us at productsciencepodcast.com to sign up for more information and resources from me and our guests. If you like the show, a rating and review would be greatly appreciated. Thank you.
.png)
.png)