Season 3 Highlights: The Product Science Success Path

To wrap up Season 3 of the Product Science Podcast, we look back at all of the great stories and insights our guests have shared.

As a framework, we use the Product Science Success Path, a five-stage journey to putting Product Science into action: Agile Product Developers, Product Discovery Practitioners, Continuous Product Improvers, High-Impact Experimenters, High-Growth Product Leaders.

Season Three has been a great ride, and we hope you’ll come along for Season Four.

Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, and more. Love what you hear? Leave us a review, it means a lot.

Resources

• The Parul Goel Hypothesis: Product Managers Should Prioritize Being Credible Rather Than Impressive
• The Marty Cagan Hypothesis: Extraordinary Products Are Built by Empowered Product Teams
• The Rajesh Nerlikar Hypothesis: Vision-Led Product Teams Are Focused on Customer Outcomes
• The Mark Donnigan Hypothesis: Successful Marketers Know the Journeys of Their Product’s Buyer and Beneficiary
• The Lisa Mo Wagner Hypothesis: Build a Diverse Team to Better Build for a Diverse Audience
• The Brent Tworetzky Hypothesis: Savvy COOs Can Use a Product Lens to Effectively Drive Company Operations
• The Heather Samarin Hypothesis: Customer-Driven Organizations Develop Products People Actually Want
• The Nacho Bassino Hypothesis: Success at Scale Starts with Setting the Right Product Direction
• The Susan Lindner Hypothesis: The Most Powerful Person in the Room Is the Storyteller
• The Amy Jo Kim Hypothesis: Drive Deep Product Engagement by Optimizing the Core Loop with Game Thinking
• The Paul Gebel Hypothesis: Products Succeed or Fail Based on the Trust They Build

Transcription

Holly Hester-Reilly: Alright, so we've reached the end of season three of the product science podcast and we're going to sum up the season with something I call the product science success path. The product science success path is a step by step journey from agile product development to product science leader. It really helps people understand how to go from your average feature factory team to a truly empowered product team in a truly empowered product leader.

‍

So what are the stages of the product science success path? Well, stage one is agile product developer stage two is product discovery practitioner Stage three is continuous product improver stage four is high impact experimenter and stage five is high growth product leader. And what i'm going to do now is share with you a little bit about each of these stages, how you know which one you're in.

‍

What the next steps are for that stage and quotes from our guests from different episodes of this season, that will help you hear from them about times when they worked with teams that were in the stage.

‍

So the first stage is Agile product developer. At this stage, product teams often take what direction they're given by their leadership and build the product design and development plans around it without doing additional product discovery research to inform their decisions. As a product manager, this can be a really difficult type of team to work on often product managers feel frustrated by the things they read in the literature and how different it is for them in their day to day. They don't yet have the tools to address this they're not sure how to make it better.

‍

The way that you know if you are at this stage is to ask yourself, do you develop and release new software on a regular basis, either in sprint's or continuously. If you're not even releasing software on a regular basis, yet then you're not ready for the product science success path. You probably would need to start with some things about Agile software development, but if you are releasing software on a regular basis, the very first step is Agile product developer.

‍

One of our guests who had some interesting things to say about being in this first stage is Parul Goel. Here’s what Parul had to say:

‍

Parul Goel: So, especially in enterprise space, you have customers who tell you, they really want this. And it's easy to give into that pressure and say, "Okay, I am going to build." But as a product manager, as product managers, we are responsible for building the right thing. So it is my responsibility to say, "Yes, I am looking at building it. But I need this time to do my research." I think making product decisions just to meet a deadline, and there are times when that's what the need is, but that can't be the norm. You do need time to validate the problem statement, do brainstorming around solutions, and then pick the right one. And I realized that, it is my job to fight for that time, it is my job to say, "This is what I need before I can build it." Otherwise, I will waste everybody's time and maybe not building the right thing. So it gave me the confidence to go back and say, "I need more time." 

‍

Holly Hester-Reilly: Yeah. And that can be hard, right? Like, sometimes we feel so much pressure to say, "Yeah, we can make it happen fast," because everybody always wants things faster. Right? 

‍

Parul Goel: Yeah. 

‍

Holly Hester-Reilly: So it sounds like for you, you really learned through the experiences of going through those pains of what happens that it's worth it to go and ask for this time, or to be firmer in what you need, or what can't be done. 

‍

Parul Goel: I think the other thing that has helped me is getting really good at discovery. Because if I were to say, "I need more time," versus if I were to go and say, "I need more time, and this is what I plan to do in this time. These are the customer interviews. This is the industry research," the second presents a much more compelling case. So in real world, the truth is, the discovery time does shrink. So how do you get the most important information quickly? I think that’s something else that, over time, I have learned to get good at.”

‍

Holly Hester-Reilly: When I spoke to Marty Kagan, Marty had some things to say about the frustrations that product managers working in a feature factory experience. Here's what Marty had to say about it.

‍

Marty Cagan: What happened was the second edition of Inspired came out. The first edition was basically just in the smaller tech community, but the second edition of Inspired was distributed by a big publisher in New York, and the result was it went a lot further than the first edition. And of course, product had grown in that 10 years. And that was great, of course, lots more people exposed to the ideas, lots more people telling me now they understand what product is and they love this, the problem was very early I started hearing from teams that they wanted to work the way it's described, good teams work, but there they weren't allowed to. Sometimes they were literally prevented, but more often their company didn't really have a place. They don't really even have a place for product discovery in general.

‍

The way they work was they are handed roadmaps, and they're told just, "Design the features, implement the features as fast as you can." And of course that's not discovery, that is a little bit of design, that's a lot of coding, and it kind of misses the point of making sure that product comes up with a solution that really works, it's valuable, usable, feasible, viable. And I started meeting with the leaders of those companies and asking them, "You said you want to work like the best companies, you do realize that's not how they work, so let's try to understand why and what it would take.

‍

And I started realizing what was really going on is while Inspired talked about the best practices for teams, there really wasn't anything out there that talked about how leaders at good companies work and need to work.

‍

Holly Hester-Reilly: Another guest who had something to say about being stuck in this state of being a feature factory and just responding to incoming requests was Rajesh Nerlikar. Rajesh, along with Ben Foster, is the author of Build What Matters, and has more than 15 years of product management experience. Here's what Rajesh had to say:

‍

Rajesh Nerlikar: It is so easy to have your head down, responding to stakeholder requests, customer feedback and bugs and usability issues that you look up one or two years later and you're like, "Everything we've done has been incremental changes to the product. We tweaked this button, we optimized this one conversion funnel." If you're not intentional about how you want to allocate your capacity, it becomes so easy to just respond to the things that feel urgent and burning in the moment that you'll never make progress towards long term goals. 

‍

That's really the reason we created the framework to say, "You spent all this time thinking about what the right vision is and the right experience to deliver for your customers two or three years down the road. That should be unlocking exponential business growth. Now don't just throw that away or put it up on a shelf and let it collect dust," which actually I've seen at a lot of companies. They have the vision and it literally just sits somewhere and people forget about it eventually. Now it's like, as soon as the rubber hits the road, how do I make that vision come to life? We have these three swim lanes or categories and the innovation one is, "Hey, what percentage of our time are we willing to invest to make that vision a reality?" 

‍

Like I said, there's a lot of factors for how you might decide on those ratios. I think the number one is really product lifecycle stage, right? In the book we kind of talk about some rules of thumb and we have a table that's like, if you're about to launch the MVP, or you're pre-alpha, you haven't even launched the product, then vision is 100% of what you're doing. There's no customer feedback that you can iterate on yet. But as soon as you launch, you might flip that drastically and say, "I'm in learning mode, therefore I'm going to listen to and capture all the feedback I can get and address a lot of it so that these customers feel like they're having a good experience with our product. Through that I can learn whether those customers are representative of other customers in the market that we could get to down the road. They're our first customers, but I need to verify that other customers look like them so we can build the right product for everyone." 

‍

Then, as you find that product market fit, the operational piece, you start scaling the user base and the customer base, the operational piece kind of takes over, because then engineering raises their hand like, "Our product is about to fall over. It was never designed for this amount of load and there's all these database issues," or whatever it is. Then you kind of shift into scale mode and most of your time is probably spent on the operational side of getting your platform to scale properly as your business scales. Those are the lifecycle stages and the real intent is, as a part of the road mapping process, before you just start slotting things in, think about this allocation. One of the other things we talk about in the book is it's really hard to compare a user story to a bug, to a new feature, to a tech deck thing that engineering is asking about. It's like apples to oranges. If you have the categorization first, it becomes much easier to compare apples to apples.

‍

Holly Hester-Reilly: So, as we heard from Rajesh, Marty, and Parul, you can definitely get stuck in a state where you're just focusing on incoming requests and not going out and doing your own product discovery. But that's not a good state to be in So what is the next step if you're there, well, I recommend you start small think about how you can get closer to your customers. Just talk to two customers first—focus on getting to know them and why they use your product if you don't have permission to talk to customers from your internal organization. Just find friends or family who are somehow related to what you're doing and start with that just get yourself exposed to having conversations with users or potential users and begin with that.

‍

So what's the next step after Agile product developer? Stage two of the product science success path is product discovery practitioner. The product discovery practitioner does some product discovery activities, but they tend to do them only at major decision points, such as the beginning of a project they miss opportunities to refine plans and invalidate assumptions.

‍

Product managers who are in this stage often feel excited to build based on their initial research, but then they can be disappointed after launch when users don't do what they expected. You know your at or past the stage if you're able to answer this question: do you or someone on your product development team plan and conduct research with users to help you design and build the right product?

‍

If you do, you're at least at the product science success path stage two. What did our guests have to say about stage 2? Mark Donnigan, a growth stage marketing consultant from D launch shared this story.

‍

Mark Donnigan: Well, a lot of times what happened was, was that for whatever reason, and this isn't ill intent necessarily, but at some point, questions were either not asked or the answers were not understood, or there were just assumptions made. And I'll tell you, I personally experienced all three of those. I personally experienced where we actually heard the feedback from the customer, but we just assumed, "Yeah, but this is so amazing, this can bring so much value to them. They'll find a way to make it work." And a lot of times in the kinds of solutions that are sold today that, where there's integration, where they're not just standalone, no, at the end of the day, they're not going to find a way to make it work. 

‍

And so, understanding how that customer is able to ingest or use your solution is absolutely critical.

‍

Holly Hester-Reilly: So you can see that even when you're talking to customers, you can still get things wrong. And we've heard this from other guests as well. Lisa mo Wagner had this to say:

‍

Lisa Mo Wagner: There's a lot of ego on product or can be. I'm not saying everybody, but I've seen it quite a bit. And that stops you from learning, because you don't look in the places where you should be looking, where those people are that care.

‍

I think I've learned most from not product managers in my career. Like senior engineers, senior designer. There's a lot of like different areas of product that I learned from the adjacent roles within it, so like my technology actually came from the developers. And my design and UX knowledge came from the designers I've worked with. And business and others comes from working with the managing directors in one company, the marketing people in another. Yeah. Find the people that can teach you stuff outside of product, to learn more about product in a way.

‍

Holly Hester-Reilly: Yeah. Well, product is so cross-disciplinary, so you do need to learn about all these disciplines.

‍

Lisa Mo Wager: Yeah.

‍

Holly Hester-Reilly: Yeah. That makes lots of sense.

‍

So if you're in Stage two we're doing product discovery but it's not yet continuous, what are the next steps you can take? I recommend you start with setting one learning goal for each sprint and make space in the sprint plan for your product manager, designer, and lead engineer to be involved in the learning.

‍

Begin sharing what you learned that your team demos along with what you built, if you can focus on that, for a series of sprints you'll begin to have the continuous product discovery that you want.

‍

And that leads us to stage three continuous product improvers at this stage of the product science success path. Teams have a regular practice have at least one type of product discovery activity, but they aren't yet getting the full benefits of product discovery. For example, they may be focusing on local optimization with usability and a B testing, but not diving deeper into motivations and opportunities. Or they may be biasing qualitative research or they may be guessing at the causes of things they find interesting and the data, these are things that i've often seen.

‍

At this phase, teams often feel confident in the area that they do the most research in, but they can often get stuck as they're lacking an Aha as to what will drive high growth or clear reason to prioritize amongst different ideas. So what did our guests have to say about this?

‍

One guest Brent Tworetzky, COO of Parsley Health, had this to say about looking at just one side of the information.

‍

Pardon my background noise, if listeners can hear that, I'm definitely recording from New York City

‍

Brent Tworetzky: Yeah, New York. To that point, Holly, I just learned how valuable it is to understand the why of product, of what's going on, the story behind the data. It empowered me or pushed me to both hire a user researcher in the companies I worked for, and be able to advocate for that position and two, train my product managers and product designers in the craft of user science to understand the what and the why. 

‍

I ended up writing a blog post about this, the product manager superpower of user science, that talks about all the tools in our toolkit, when to use them and how to use them appropriately. So much of that stems from my learning back at Chegg.

‍

Holly Hester-Reilly: Another guest, who had something to say about Stage Three, Continuous product improvers was Heather Samarin. She’s the Co founder of Product Rebels and has over 17 years of experience in design development and management of customer experiences she's also the co-author of Groundwork: Get Better at Making Better Products. Heather shared this story with us:

‍

Heather Samarin: Too often we see product folks. They might cherry-pick the data that they gathered that supports their decision. And because we are working with people in different functions, say sales, technical support, who also talk to customers maybe in a different context, if they're only hearing what you're cherry-picking they may give you the nod in the room with a product decision but as soon as you walk away they're going back to their leader saying, "I don't agree, this is what I learned." There's that distrust with cherry-picking or just lack of understanding or lack of gathering additional feedback beyond what you're seeing.

‍

And that's what I see a lot of failure in product managers, they never learn to create context, build logic based on customer insight, and being able to communicate that in a way that galvanizes the team around the decision. We call it the shared vision, that's a la-la term corporate speak, but I really do love this term shared vision. It's not consensus, it's being able to democratize the data at hand. What do you know? What does everyone know in the room and what's the most logical decision to be made at the time?

‍

And if everyone feels that they have the level playing field of data that everyone has in the room, and you're making a product decision even though you might have to make a leap because you have to make an assumption somewhere, if everyone feels they have the same data they're going to commit to the decision even though they may disagree with it because their gut tells them we should be doing something else. But the data shows this is what we've learned and we're going to make a leap right here, are we all holding hands and do we have shared vision to move forward? That's when you get commitment.

‍

Holly Hester-Reilly: Finally, Nacho Bassino, the Chief Product Officer at Best Day and author of Product Direction, shared this story with us.

‍

Nacho Bassino: I guess we can talk about the whole product process from a bigger perspective. So when we talk about product strategy, I think it's pretty much related to this diagnosis phase. And the problem I see is that many times, product teams focus on the product data, because that's the most readily available information and the one they're probably playing with the whole day. So we focus too much on that. 

‍

And one of the shifts we should have in this diagnosis phase—a more broader view. So we should probably look at our customer research for the last 12 months or the customer feedback through our customer service, if we have customer service unit. We should also look at industry and market trends. And that's also an interesting set of data, is that you have data that you can benchmark against and you say, "Okay. This is my conversion and how much conversation rate looks like for my industry, for my niche." So if you can come up with that, you have insights into if you are behind or above market. So that's one side. I believe it really helps with the diagnosis and you should be getting that information before you decide which insights to pursue.

‍

Then on the discovery phase. So if we're talking about phases, probably the discovery is next. And during discovery, I think again that we should use data to inform our decisions, but, as with my poker game, we should mix the data we have from our product metrics with wider information. And of course the way to balance that is, what's happening and why it's happening. That's what the qualitative information can provide. 

‍

Holly Hester-Reilly: The one question you should ask yourself to know if you're, at least at Stage three of the product science success path is do you or someone on your product development team plan and conduct research at least each sprint or more frequently. With users to help you design and build the right product, if not, then you're still at product discovery practitioner, but if you do you're, at least at continuous product improver.

‍

What if you are there, what is the next step you're trying to get to a place where you're getting the full picture and you're able to tell what customers are likely to do and you're able to use the research that you're doing to make smart decisions and the research is making your life easier that's where you want to get to. If you're doing research regularly but you're not feeling that experience, I recommend you start with a pre-mortem risk assessment exercise to think through the biggest risks in your product plans and then use that to tailor your research to focus on the biggest risks this might be known challenges or areas that your team knows the least about.

‍

When you make that research plan, you want to consider adding different types of research to your mix you want to make sure that you have qualitative and quantitative research involved. You want to get data from different points.

‍

When you have a well rounded research plan and you focus that research on the biggest risks you're much more likely to do research that matters research that makes a high impact, and that will bring you to the fourth stage of the product science success path: high impact experimenters.

‍

At this stage, teams have gotten good at figuring out what Customers need and what they will likely do with a given product design, but they are not yet skilled at conveying that information to decision makers in their organization. They often feel frustrated by their marching orders and find that their research doesn't have the impact they want, often feeling like they were stuck putting lipstick on a pig or working on something not as big as what they imagined.

‍

The one question you want to ask yourself to know if you've reached out to the stage of high impact experimenter is: do you commonly find that once you release software to your users your data shows that they use it in the ways that your discovery research suggested that they would? If so, you're, at least at the stage of high impact experiments which has stage four of the five stages of the product science fast path so you’re doing pretty great, but you’ve got some distance ago.

‍

Let's see what our guests had to say about being at this stage. Susan Lindner CEO and innovation storyteller at Emerging Media had this to say about wrapping data in a story.

‍

Susan Lindner: Our friends at Pixar and Disney have this figured out. They know that when we inject drama into the story, we release serotonin and dopamine and adrenaline. And those chemicals in the brain is actually what holds us to the story, it engages us. And we have these excitement and pleasure centers that say, "More please. For those storytellers out there our product managers will think, "This is so boring there's no way anyone's going to listen to me. It's just this thing I built. It's really cool, but..." We know that we need a little bit of drama, we want to know where the weak points were, where the hard points were because that's where we connect as humans. We connect at the pain, we connect at the challenge not at the success. We don't want to hear how you built it in three days and it was perfect the very first time you tried it.

‍

Holly Hester-Reilly: Which is probably not true, anyways.

‍

Susan Lindner: We don't believe you.

‍

Holly Hester-Reilly: Nope.

‍

Susan Lindner: We do no not believe you. Authenticity and credibility also really important. And one of the things I just want to mention, many product folks are really great at presenting data to bosses who say, "Look, I don't have a lot of time. Give me three bullets, tell me where we are. Just the facts, Jack." And a lot of folks in product management also like operating at that level. But I can tell you one thing, go back into your bosses office 12 minutes later and see if he remembers what you told him. A Stanford study proved to us that data alone is not memorable. Our brains are not built on Excel spreadsheets, our brains are built on memories, are built on story. When you wrap data in a story it's 22 times more memorable than if you just provide facts alone. And you can quiz yourself—

‍

Holly Hester-Reilly: Awesome.

‍

Susan Lindner: Read a newspaper article and see if you could remember the statistics six minutes later. If you're just zooming in on the statistics, everyday on CNN we see what the death count is and the number of new cases and five minutes later you can't tell me what those numbers are. But if you wrap them in story the human brain holds on to them and we continue to build the story in our mind after that so that it locks in there. The more adrenaline and serotonin and dopamine, excitement, drama, failure, success that you can build into the story, the longer people will hold onto it and be able to share it. That's the science around a story.

‍

And Amy Jo Kim, founder and CEO of Game Thinking Academy, shared this tip about how to share research results effectively.

‍

Amy Jo Kim: On that project, the way we did it was in layers. We started by carving out a squad of people internally, which included some higher-level, director-level people to work through all the ideas. So we worked through those ideas. That wasn't always easy, but we worked them through. And then we collected our analysis and our findings, including feedback from customers into a brief, a product brief, which is something that I do a lot on projects. And we have a very specific way of doing a product brief, which includes short interview clips from the interviews and play test that we do with customers. And so that product brief, we presented to the leadership at The New York Times.

‍

There's a group of people, I think they called it the G9 or the G7 as a reference to the G8. But the leaders of The New York Times, including the very head, have to approve all major initiative. So at the end of that project, we went up to the top floor in this very tall building in Manhattan and presented our product brief and our findings to these people, and they did not crack a smile. It was so nerve-wracking. But it worked out pretty well. We got started with one of the initiatives that we presented because you got to start somewhere. And that's often how it goes, especially with larger companies, more established companies. 

‍

We do work with a smaller group. We make sure there's a stakeholder involved in the smaller group at least for weekly check-ins so that somebody is championing us and understands what we're doing. And then there's a presentation at the end, which where we summarize everything we learned, how we learned it, how we collected the data, how many people we talked to, and what we found. And what I've discovered is that, that's all great, that works really well. But there is nothing as convincing as short video clips of real customers saying the key messages that you're trying to communicate to your stakeholders. You can't just have that, but if you have a very well-organized presentation that let's people get inside and understand your process, how you got the data, and then you show them their customers giving feedback on these ideas, that's very convincing.

‍

I have worked with many game companies that got games that have been struggling for months to get greenlit, greenlit meaning they get budget to be developed by using this methodology. And it isn't just a convincing, it isn't just it's a nice convincing presentation, it's that we've actually validated ideas with real people and found out what's going to work and what's going to be a dud before building anything. And it's that validation process and then the expression of it that I have found so compelling for working with stakeholders.

‍

Holly Hester-Reilly: And finally, I want to share another quote from Heather Samarin, where she talks as well about communicating research across the team and organization.

‍

Heather Samarin: Sit in the shoes of your manager or sit in the shoes of your CEO at all times. Don't think projects... This is actually one of the things I learned from Bill Campbell again. I got the feedback, "Heather, as long as you're sitting in my shoes when you are proposing decisions, doing analysis, and thinking about the implications of the decisions that you're proposing, you will win every time in your career." And I did, that was something I learned. And if I don't know what the CEO might think about a potential decision, I go and I ask, I trial-balloon. "Here's what I'm thinking about, what do you think? What are the implications? Am I missing something?"

‍

And that even in the product manager one role, if you are not thinking in one manager above you, or as the CEO, again, I'm not saying that the product manager is the CEO, I'm not a huge advocate of that. I think product people have a very specific role in the company. But if I'm not thinking about the implications of the decisions in strategy or in features or the like on how it's going to impact the organization, impact our overall growth, how it fits into the overall business strategy, then I'm failing as a product manager, and that's the best advice I've ever gotten in my career.

‍

Holly Hester-Reilly: So if you find yourself at this stage, what can you do to move to the next stage.One of the things I recommend doing is using the built learn to planning DEMO updating your team DEMO to include what you learned and what you're planning next,  So that next to what you've built you're also communicating that you're constantly learning and that plans change based on those learnings.

‍

That's a good way to communicate out what the research results affects stakeholders, alongside what they are used to asking for and hearing about, which is what got built. Make sure the key stakeholders are invited, or have another forum for regularly engaging with them, so that you can talk about discovery and its results.

‍

Whether you do the built learn planning DEMO or you do something else, the key is that you need to have a regular forum where you're sharing research results. You're engaging with them with those key stakeholders you're giving them a chance to ask questions and you're giving them a chance to process in their own minds what these results mean not just constantly telling them what conclusions to draw. If you're able to do that, then you'll reach stage five of the product science success path high growth product leaders.

‍

At this stage, teams are both effective and impactful in their continuous product discovery practices.They can not only predict the business impact of their product decisions, but they are also so good at communicating the research that leaders within the organization trust these teams to make decisions and consistently drive high growth in their products teams and companies at this stage team leaders are confident and trusted yet remain curious and authentic.

‍

You know you're at the stage if you can answer yes to this questionL]: do your stakeholders trust your product team to make good decisions and consistently deliver on the desired outcomes for your users other teams and the business?

‍

Now one thing to know here is that it doesn't mean that you don't have experiments that fail, you have experiments that fail, all the time, but it means that you're able to drive the outcomes, through your continued work continued experimentation and continued product discovery. So what do our guests have to say about being in this stage?

‍

One guest who shared some information about becoming a high growth product leader was Paul Gebel, the Director of ProductI innovation at ITX. Here's a story Paul shared:

‍

Paul Gebel: I think the thing that matters most and the thing that companies are going to live or die by frankly in the next decade is whether or not they're resilient enough to trust their people. I think that's where it comes back to. When you look at the companies that are thriving, it's those who are empowering their teams. I think Marty Cagan has been preaching this for years and I think he's spot on. I think the way that you make products that are going to change the world aren't by finding this ivory tower mountaintop moment and bringing it down to the teams for them to build, it's freeing the teams up to do what they do best.

‍

I think that product managers who maybe fall prey to the imposter syndrome, I must be the expert, I must know all the information are going to fail. I think the product managers who have the humility to realize it's a big world and I'm playing a role, and the fact that I have influence in it is an honor, I think that's the way that I approach my job every day, and I think that the way that you see product managers start to shape the conversation in bigger issues than just cool products and helpful interfaces is when you start to see it's people that were helping. If we shave five seconds off of a workflow, yeah, we optimize that KPI, that's a good thing. But that five seconds aggregated over time means I get to go to my kid's soccer game. And those two things aren't often mentioned in the same sentence, but that's what happens when you do your job.

‍

Holly Hester-Reilly: And finally we're going to return to Marty Kagan to hear his perspective on empowered teams.

‍

Marty Cagan: there's all these books then make the argument that if you really want to get the talent of your people, work like Google, work like Amazon, and most of the time they not only knew of that, but they had read at least a few of them and liked them. But when I asked, "Okay, then what's the problem?" Well, the problem is they didn't trust their teams.

‍

They felt that they don't have the caliber people that other companies do, that the good companies do. Which is explicitly why I chose the subtitle I did on the book Empowered, which is Ordinary People, Extraordinary Products, because that was the missing piece of the puzzle that I think that so many of those leaders didn't know. They thought, unless you hire these rockstar type, they have to come from MIT or Stanford. Of course that is not the case at any of those companies. They might have been at Google for their first few hires, but not at scale, not for a long time.

‍

And so what I point out to them is, "No, they have the same people. In fact in many times, I've been introducing people from companies like yours, where they're not happy, into those companies and see how great they could do."

‍

And so to me it was very clear it wasn't about that, it was about how they were using their people, the environment that they were providing. In fact, one of my favorite quotes is Bill Campbell, Coach Bill Campbell's quote about the job of leaders is to realize there's a greatness in everyone and to provide an environment where that greatness can shine. I'm paraphrasing, but that's what he's basically saying. And he literally coached Bezos, and Steve Jobs, and Larry and Sergey on exactly that point, your job is to provide an environment where people can do good work.

‍

Holly Hester-Reilly: Marty does a fantastic job of describing what it's like to see an empowered team at play to see a team that's trusted that's earned that trust and to see how they work. If you're at the stage, what are your next steps, well, you need to keep you need to keep focusing on growth, you need to keep focusing on getting stronger and better at what you do. You want to coach your team constantly create tools frameworks and training so that other product teams can collaborate using the same tools and for research and communication.

‍

I'll tell you a little secret there's actually a sixth stage of the product science success path as well the sixth stage is the true. The six stages, the true organizational leader, this is someone who's doing continuous evidence based products leadership for people managers or organization leaders. At this point, a team has evangelize their product mindset, making it visible and accessible throughout the organization and beyond.

‍

You know you're at this stage of product managers and others throughout your organization collaboratively develop evidence based product strategy consistently practice continuous discovery and delivery and deliver high growth products. These are the leaders that Marty talks about in his books.  And this is the kind of leader that we at H2R Product Science strive to help our customers be.

‍

So, in summary, the product science assess path takes you from these stage of agile product developer to product discovery practitioner to continuous product improver, to high impact experimenter and finally to high growth products leader. At each step we give you a tip about what you should do next, and we're used to working at custom we're used to.

‍

At the last step we’re able to help customers figure out what they need to do next to get moving towards continuous high growth product development. If you're curious to learn more about how we do this sign up for our newsletter and you'll know when we're doing workshops, where you can come and join us and we'll talk about it together.

‍

Thanks so much for listening to season three of the product science podcasts. Keep growing.

‍