Episode 153: Decoding the DNA of Successful Product Management with Quincy Hunte, Global Transformation Product Leader at Amazon Web Services
In this episode of Product Thinking, Quincy Hunte, Global Transformation Product Leader at Amazon Web Services, joins Melissa Perri to dive into the world of product management, operations, and transformation. They explore key components such as decision-making, product leadership, innovation, and outcome-based funding.
You’ll hear them talk about:
[07:07] - Organizational speed is a key component in product decision-making. However, many companies face common issues that stop them from making these critical decisions. One is decision-making by consensus, which often leads to delays. Secondly, businesses fear making mistakes, paralyzing decision-making, as no one wants to be accountable for potential failures. To combat these challenges, Quincy suggests adopting the concept of "one-way and two-way door" decisions, which ranks decisions based on their impact and reversibility. Moreover, there is a need to identify a "single-threaded leader", as well as foster an organizational culture that tolerates mistakes and values experimentation.
[17:21] - At Amazon, the process of developing new products, services, and features involves a unique and collaborative approach between different levels of the organization. It begins with an individual or team identifying a customer need and working backward to address it. Alongside this, tangible data from experiments bolster the proposal, demonstrating its viability. Once approved, the project details, including key metrics, resources, and financial requirements, are integrated into the organization's annual planning.
[27:53] - Outcome-based funding, especially outcomes that directly benefit the customer rather than just meeting internal project KPIs, plays a crucial role in balancing funding for product teams and encouraging innovative ideas. This strategy aligns funding with delivering real value to customers, ensuring that innovations are both business-centric and customer-centric.
[43:51] - The critical components for optimizing product operations include smaller, agile teams for rapid adaptation and decision-making, the need for clear leadership roles and principles in guiding organizational practices, as well as appropriate technology and infrastructure, ensuring businesses are well-equipped to respond rapidly and effectively to market demands and customer needs.
Episode Resources:
Other Resources:
Melissa - 00:00:37: Hello, and welcome to another episode of the Product Thinking Podcast. Today, we're joined by Quincy Hunte, the Global Transformation Product Leader at Amazon Web Services. Quincy's journey in product management has seen him navigate diverse roles from spearheading product strategies at IG to mentoring up-and-coming leaders at Startup Discovery School. His current role at AWS places him at the helm of helping organizations migrate to SaaS models and adopt better product management practices. Outside AWS, he shared his expertise as a product coach at Hunted Digital and provided oversight at TDS, which is Tenancy Deposit Scheme. Quincy's experience stretching across various sectors and companies promises to bring valuable insights to our discussion. But before we get into our discussion with Quincy, first, it's time to answer your questions from dear Melissa. All right, this week's question. Dear Melissa, back in episode 123 at moment 12:38, you mentioned the value of putting a PM software to sit on top of Jira. We recently purchased a PM tool and are piloting the implementation with one of our products. One of the issues we're struggling with is deciding the level that the PM software should end and Jira should begin. For example, it makes sense engineers need the autonomy to create their own subtasks, bugs, and Jira. But on the other hand, components at a high level are best mapped in our new product management software. What questions should we be asking to navigate the gray in between? Are we viewing this the wrong way? All right, so if you want to think about where Jira ends and where the product management software begins, the idea here is to roll up things into different strategic components. So for example, the tasks that you have in Jira are probably breaking down work towards a feature or an initiative that you're building. So there needs to be, I call this in my product strategy frameworks, options. So you can think of options like an epic, right? The epic should really describe what you're actually trying to release to customers, like a chunk of valuable software that's going to be delivered. That doesn't mean that you might not be releasing a few things before that or testing it, but like this is the thing that's going out to customers that's going to be valuable, that's going to have meaningful outcomes associated with it. And then many of these options roll up to make an initiative, which is something that's a little longer term, probably takes maybe like a quarter or six months to actually get out there. Those roll up to the strategic intents. So when you're looking for a product management tool on top of Jira, you don't care about the subtasks. You don't care about all the individual tasks that the developers are actually working on. The idea for this tool is to roll it up into something where we can look at it and say, what value is being delivered to customers in what form, like what feature are we releasing? What improvement are we releasing? What's that actually going to do from a outcome perspective? And how does that roll up into the next level and then into the company strategy? So that's what a good product management tool is. And that's what a good product management software tool is for. So you should really keep like bugs and subtasks and every little nitty gritty thing to like do the work out of the product management software. And the way that I think you should think about it is that the way that you use this product management software is to keep track of the big pushes so that you can communicate roadmaps and you can communicate valuable things for customers to the rest of the organization and within your product teams. So think of it as like, if I were to go to sales, and talk about this thing that's happening in the next month, do they care, right? They probably do not care about a developer building their API integration themselves to get into a platform. Like that's what they have to do. It's not anything that we're going to care about from a sales marketing perspective or from a product perspective, because that by itself doesn't deliver value. So you want to think about it rolling up. So I think if you're having trouble here as well, go back and revisit your product strategy cadences and your canvas. So, okay. I have a product strategy canvas that's online at melissaPerri.com. But think about your different layers. What are you responsible for as a product manager? What's your leader responsible for a product manager? What's the right way to communicate that? What types of things should be on the roadmap? A roadmap should not be just a bunch of tasks that developers are working on. It should be meaningful value that's being released to customers and how we're going to get there. So what's going to be coming out today versus tomorrow versus the next time, or how we're thinking about organizing those things towards the value. That's what we're looking for. So we want to make sure that those are the things that get communicated into our roadmap. One other thing I should add that I just thought of off the top of my head was that if you are doing some foundational work on the product, let's say like you have to do something about something that's going to be like released internally. Let's say that is a prerequisite for being able to release that value. You're going to want to think about who you're communicating that to, right? Sales probably doesn't care about that. So I would leave that off. I have roadmaps that could communicate to sales, but internally, if they're setting dependencies or things that we care about from a team level perspective, you may want to communicate that onto your roadmap. So you might want to say, these are foundational work that won't produce customer value, but things that we're going to have to do to get ready to produce the customer value. So when I'm looking at your PM tool, I'd probably want to see many different views of the roadmap. And I'd want to think about what's important and who am I communicating with internally? What do the other product managers care about? What do my leaders care about? What do other teams care about? And then make sure that you have that level of communication set up in your PM tool. So those are the types of things that you want that to communicate instead of Jira. Like you don't need all the nitty gritty on there. You want to roll it up. How do I roll it up into something that's meaningful? So hopefully that helps. All right. Now we're going to head over to talk to Quincy. Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past seven years, I've been working with individuals, teams, and companies to upscale their product chops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma. Visit productinstitute.com and learn to think like a great product manager. Use code THINKING to save $200 at checkout on our premier course, Product Management Foundations. Welcome, Quincy. It's great to have you on the show.
Quincy - 00:06:48: Thank you, Melissa. Happy to be here.
Melissa - 00:06:50: So you have a really interesting role. You are part of the global transformation at Amazon AWS. So that's Amazon Web Services for people who don't know what that is. And it's more of this advisory, consulting, coaching type role where you work with executives and help them through their transformations. Can you tell us a little bit about your product background and what made you want to get into more of the consulting and advisory world?
Quincy - 00:07:17: Yeah, so that's a good question. I've had a lot of experience working across a number of organizations throughout my 20 years of product management experience. And one of the things that I really enjoyed is just having the ability to work across different industries, working across different customers who have different problems, and being able to really dig deep and find out what's motivating some of the changes that they want to see across their organization and how they want to better serve customers. And, you know, when I came across this opportunity at Amazon, it really piqued my interest because it really allowed me to have the ability to speak to customers across a broad range of different domains, different industries, and really understand what are the differences between how these customers go through a transformation process for products. And just as importantly, like, what are the patterns? So what are the same kind of challenges they face? What's the same kind of value that they want to deliver to their customers? Or what is it? Same type of issues that they see internally in terms of their operations that they are trying to overcome. So, you know, I took the leap of coming on board to Amazon, and I currently work within what's called the Innovation and Transformation Function. And that's a function that essentially, if I boil it in a nutshell, is to help customers build better products on AWS. So you're not a cloud-aided organization, or sometimes you're in the cloud, but you don't know how to best leverage Amazon's or AWS's services. So you're not a cloud-aided organization, or sometimes you're in the cloud, but you don't know how to best leverage Amazon's or AWS's services. You would essentially use the services of the Innovation and Transformation team to help go through that process of helping build a better product. And that's not about just looking at the technology stack and the software code that you use to build a product, but it's looking at the business areas as well as the organization and operational areas that help support how you build that technology to support your customers. So my role is really focused around supporting and leading executives. So I work with executives as well as senior leaders. So I work with executives as well as senior leaders. They could understand how to set up their product teams, their product operations, and really try to leverage that whole product mindset and that product mental model thinking to deliver value to their customer, to be as what we say at Amazon, to be very customer obsessed and customer centric. And that's kind of what led me to the role is just having the ability to work across such a dynamic range of different areas and touch on the different abilities that organizations face today in terms of the challenges that they have with that transformation.
Melissa - 00:10:02: Now, I think a lot of people out there hear the word transformation and they start to think about agile transformations. So when you're working with these organizations, are you talking about agile transformations or are you talking about a different type of transformation?
Quincy - 00:10:15: Yeah, so Agile does get touched on, but it's not the core of our conversations. The biggest part of our conversations is really using the Amazonian ways. So looking at how Amazon does products and how Amazon operates and using that as a mechanism to help organizations better their operations. Now, what's important, Melissa, is that not every single thing that we do is going to work in an organization. So we're very careful about when we go in and we understand the context of how an organization is operating, what can potentially work versus what doesn't necessarily fit into their business as well as their environmental dynamics. So we look at things in areas such as the organizational structure and their practices, and that will cover things such as, you know, the size of their teams. So we are known for this thing about two pizza teams and, you know, having teams that are very Agile. But it's very different when you have a monolithic application and you need to deconstruct. And how do you go about that process? We look at things such as single-threaded leaders, leadership principles, team tenants. All these things are part of the organizational structure. Excuse me. The other part is about technology and infrastructure. So we look at how organizations have their technology set up and how does that essentially align with the business? So if we think about organizations who traditionally have this big software stack, how do you decompose that into microservices? And beyond that, once you have all that, how do you decompose that into microservices? How do you apply APIs in order for these microservices to speak to each other, to allow for your teams and your components to be a lot more autonomous and be decoupled and not have all these dependencies on each other? And then we talk about things such as the product management as well as the strategy. So how do we develop really good, crisp product management strategies that help really propel and accelerate the product teams to move fast, to deliver fast? Because one of the things that we highly index on over at Amazon is speed. And speed comes with having a very good operational construct in place that helps you accelerate decision making, helps you accelerate your experimentation, helps you have things such as your, you know, what we call our working backwards to understand the customer and accelerate how quickly you deliver value. And then last but not least, there's things such as the, you know, measurements and analysis. So how do we measure the goals that we're providing to the customers so that we can ensure that we're delivering the right type of value? So we speak to customers. We talk to customers about these goals. And then how do they look at their product data and how do they instrument and how do they have usage tracking and user engagement all in there so they can ensure that they understand the consumption patterns of their customers? And then all of that obviously needs to roll up into a proper reporting cadence as well as mechanisms to ensure that that's not just aligned with, you know, the senior executives of the company, but it's also aligned with the organizational objectives. So all of those are the things that we kind of touch on. Which is, you know, very much in parallel with product operations and product operation model and operating model. All of these things we touch on to essentially help a customer through that transformation as well as innovation journey.
Melissa - 00:13:21: One of the things I wanted to go a little deeper on that you just mentioned too is speed. Right. And I think in a lot of these organizations, they take too long for decision making. It's hard to get products out the door. I think, you know, even when it came to agile transformations, you know, when people started this around like what, 2013, everybody was so desperate to get more speed. Right. To be able to get things out to customers faster, develop software faster. When you're looking at that, not just from like a technology perspective, but also from a product perspective, where do you see the longest gaps in these companies for speed? Like where are the things that are taking too much time when it comes to that product decision making cycle?
Quincy - 00:14:01: Yeah, I think some of it is, you know, decision by consensus or not having clarity around who's the single leader that is to make the end decision to move things forward. So what I've seen in terms of patterns is that in organization, you have these teams and, you know, you want everybody to be involved in helping make the right decision sometimes and in most cases on behalf of the customer. But that mindset of having everybody involved in the decision sometimes adds a level of lag and slows down the complexity or slows it down when there's a very complex decision that has to be made. So I've seen that as, you know, as a very common pattern. You don't know when to agree on issues or challenges that are very contentious or, you know, different from what you traditionally do. So there's a lot of consensus that goes around. It goes up and down the executive team. The executive team is expecting. The teams or the product management teams to make the decision. The product management teams are saying, well, no, this is, you know, above our pay grade. We want the executives to make a decision. And it's that constant loop. So I think that's been a challenge. I think the other thing, too, that I see quite a bit in terms of a pattern is that, you know, people are afraid of making mistakes. People are afraid of making the wrong decision. So, you know, it creates an environment where no decision is made because nobody wants to make a mistake. Nobody wants to be penalized by it. And nobody. Nobody wants to be the one who is known for, you know, the product or service that didn't work or the capability that did not meet the customer expectations. So I see quite a bit of patterns with customers who are not making quick decisions because there's that whole level of let's try to do this by consensus to minimize the responsibility of or the onerous kind of condition that one person has to take in order to make that decision. To counter that, you know, what I see is kind of the way you deal with that is a few ways. So we have this whole. Think about one way and two way doors. I don't know if you're familiar with the concept, but essentially it's you need to think about your decisions on two levels. If it's a one way door decision, it means you go through that door. You can't turn around and you can't change that decision. And that's, for example, if I decide that I'm going to quit my job. If I tell my boss I quit my job, that's it. I can't wake up tomorrow and say, well, you know what? I changed my mind. It's not going to work out. That's a one-way door decision. And that's the same with technology decisions. Sometimes if you buy, you know, infrastructure or technology equipment, you can't really change that after you've made that decision and you deployed it or something that's very customer impacted. A two-way door decision is a decision that you can easily reverse on. So if I, you know, decide that I want to paint my room blue when I wake up in the morning, I decide, oh no, I don't want to like the color blue. I could just now change the color to red. It's a two-way door decision because I can know, I know I can make that decision and change it. And it's not going to have a big impact in terms of the outcome of what happens. And two-way door decisions are similar to, you know, if I want to, you know, change, you know, the buy button on one of my pages from left to right. If I want to change, you know, some of the search criteria decisions on my page. These are things that are two-way door decisions because you can reverse that decision without having really hard. Hard detrimental impact to your customers. So I think a big part of it is customers need to understand that there are levels in terms of how you segment, how your decisions are made. And those decisions that are two-way door decisions are decisions that should be made very quickly. It's not something that you should have to have a consensus on. You should have a leader who goes by that. The other thing that really helps is to have a, you know, what we call a single-threaded leader. And that is someone who essentially is a single person who is responsible, not necessarily for making the decision, but for moving things forward. So they would be responsible for gathering the feedback of the teams, understanding the various perspectives, being the voice of the customer, and using all the inputs and insights and information data to make a data-centric decision or a data-informed decision about the direction they go. And that stops it. And then the last thing I would say, you know, it's also a matter of mindset within the organization, culture. You have to also be able to embed a culture where it's okay. Okay. To make a mistake. It's okay to have an experiment that doesn't go the way you expect it. It is okay for your hypothesis to be not confirmed the way you thought it was going to be confirmed. And all these things lead up to help and accelerate decision-making because it takes away from the fear of someone feeling that they've made the bad or made a bad decision in terms of doing something that could be detrimental to a customer or to the business.
Melissa - 00:18:38: So one of the first ones that you were talking about too is this whole thing you know, concept of these leaders basically asking the product teams to make the decision, right? And the product teams coming back and be like, no, you make a decision, this up and down. And I've seen that kind of issue as well out there. For some reason, I feel like executives think that empowered product teams mean that they're going to make all the strategy decisions about what to build, right? And they're not giving them enough guidance on, hey, here's where we're going, right? And this is the path. This is a vision, right? Here's where we're going. This is how I think about prioritizing our top goals. And without that, I know product managers and product teams, they just get paralyzed, right? I think everybody in an organization gets paralyzed. So there's always this tension about how much direction do we give down? And then what should we expect coming back up? How do you guys teach that like in the Amazon way?
Quincy - 00:19:32: Yeah, so I think it's a symbiotic relationship, right, between the two. The expectation is that one party is not going to have all the answers, right? It needs to be coming from both ends. So the product teams need to help inform senior leadership based on data, based on insights, based on anecdotes in the absence of data. That really helps provide context and provides and paints a picture or paints a story of what is the customer challenge we're trying to solve. And beyond that, why do we think we should make a certain decision or go a certain direction in order to solve that, right? When the executive team or the senior leadership has that information, it's important for them to overlay that on top of what is the organizational strategy. And my personal belief is I don't think that senior leadership or executive leadership, should be involved in making the tactical decisions that the product teams are empowered to make. So what is important is for the executive team and the senior leadership team to understand the insights and information and the data, have that overlaid with the organizational strategy as well as the organization vision and goal, mission, et cetera, and ensure that they distill downwards to the team exactly how that needs to fit into the organizational goal. So what relates back to the organizational goal? So what relates back to the organizational goal? Down to what your product needs to deliver in terms of value for the end customer. And that should help drive that decision downwards to the product teams. Because what I think is always important is the decision for products should always be for the folks who are closest to the customer. So at the end points. And because product teams are traditionally closest to the customer, understands the customer, and should be ideally the voice of the customer, they should make the decisions and be empowered to make those decisions. And be single-threaded leaders to make those decisions that are aligned with that kind of directive from the organizational top line strategic view that's coming from the executive. So I don't think it's one or the other. I think it's a symbiotic relationship. And they both have to have a, not necessarily a say, but an involvement in terms of where that information comes or what information comes each way. And then how that influences the decisions that need to be made by the product teams. The other thing that I would say on top of that is, you know, based on your operational context, how you construct and how your product operations are set up, it's not wrong to have a governance structure or framework in place that supports when certain decisions should be escalated. Or when certain decisions should move up the chain to an executive level. And that could be based on impact to customer in terms of customer numbers. It can be based on revenue numbers. It could be based on cost criteria. So if you have a framework in place that supports that, it's very easy for the executive to be able to say, well, this is a decision that needs to come to our level at the executive level. Because it meets a specific threshold or criteria that says the product team cannot make this because it involves too much risk to the business or to our customers.
Melissa - 00:22:40: So one thing I see with a lot of leaders is they struggle to figure out how to give that information to the teams. Amazon's famous for like they're working backwards type work. What level does that happen at? And if it is on the product team level, like what's the executive version of what they hand down to the product teams or what they try to communicate for direction?
Quincy - 00:23:03: Yeah, so it goes back to that symbiotic relationship. So any kind of new initiative, and this is not secret information I'm sharing, everything here is public, so you can research this and find this out. But anything that is a new initiative, a new product, a new program that Amazon wants to implement starts internally with a person who has the idea or the thought, even if it's a new capability or a new feature, starts with this working backward from the customer, really understanding their pain points, their challenges, what they want to achieve. And that goes into what we call a PR FAQ process, which is basically a press release and FAQ. And I won't get into the details too much of that, but essentially it's a document that provides context of what do you want the future state of your customer that engages with this product to be like? What is their experience going to be like? What are they going to say? And what is going to be the story within the organization that supports that product? And that PR FAQ Document, which also has a set of FAQs that supports customer questions as well as internal stakeholder questions, is used to help different stakeholders and teams really dig into what this new proposition or decision is that we want to make if it's a new product innovation. And think about, you know, what are some of the things that can, you know, derail or what are some of the things that can create a challenge for this new product or service or proposition that we're building? And it gives people thinking because all that feedback goes into the document and then the owner of that document or the single-threaded leader of that document has the responsibility of addressing those concerns and continuously evolving the document to where it's a point where it says, okay, I can now bring this up to senior executives of the company. And that goes all way up to the senior the company executives of the who read that document and can give a final say on, yes, we can move forward with this idea or this innovative thought that we want. It's important to know that we can move forward with this idea of a new product or solution. So that's one aspect of it. Once that is done, it is also the responsibility of the teams to put in place what is going to be the key metrics, what are going to be the resources, what are going to be the financial investment needed to make this new product or innovation work, or even if it's a new That goes into a document that's part of an annual planning cycle process. And that goes to the executive level of the leadership team. And that leadership team will then work on creating, okay, we have all the insights and data and information. Let's roll that into our overall plan of what we want for the organization to execute as we go through our year or annual planning. So it's a two-way kind of relationship between the two. So we send up information or the product team will send up information to the product team in a very specific mechanism that's called, you know, or whatever document we used in terms of the narrative. And then the executive team would use that as part of their operational plan and as well as the annual planning process. And that would include all the things such as, you know, what it is that we want to achieve from an overall perspective for, you know, revenue contribution, customer numbers, and how that contributes to the overall strategy.
Melissa - 00:26:12: So it sounds like they're almost bringing these ideas up to be funded too, right? Is that kind of what it's like? It's like, hey, we did a bunch of research. We validated that this is a great way to go. Here's the idea. Here's some questions that people have been asking us on it. Here's what it's going to take to build it. Can we go do this new thing? Can we go do this like new piece of innovation? Will you fund it?
Quincy - 00:26:32: Yeah, it is part of that. It is a document. And a document is only a hypothetical piece of apparatus that you would send up, right? A big part that supports that is also experimentation. So there's this culture within the organization and kind of what we kind of tell our partners that they should do as well, that you have to have the ability to experiment and test and develop some sort of data points or insights in the absence of that anecdotes that will help support why you are recommending this. So it's not just, you know, a academic, you know, paper that's being put together that says, hey, we have a great idea. We want to do this. This is usually supported by some sort of tangible data points that was derived through a series of small experiments that support why we want to take a certain direction for a product or service. And it doesn't have to be, you know, a new product or services also can be a new capability. It could also be a new feature. It really depends on, you know. The scale and the size of what it is that we want to bring to market.
Melissa - 00:27:35: One thing I see companies struggle with, and I think Amazon is pretty good at this, so I'm curious how you advise your companies with it, is how to get people to embrace innovation and come up with wildly different ideas, right? Like Amazon Alexa is a great example at Amazon. Many companies, I think, that are going through transformation or starting off with these new ways of working with product management and software, they lack the capabilities or maybe their operating model or something. I don't know what it is, but they lack this way of trying to figure out how to incorporate innovation into it. And I've seen many different ways of people trying to solve that problem, right? It's like we make a little innovation hub outside the company in a really cool building, and we put a bunch of people over there, and we say, go build new products, right? I see a lot of desire from executives for regular team members to be able to innovate and come back to them with really radically cool new ideas. And yet I hear from those team members that they will do that, and then they never get funded, right? Or there's like, oh, we don't have a process for actually putting this into place. What have you seen work for baking innovation? What have you seen work for building innovation into an organization and giving people the space to go out and tackle it?
Quincy - 00:28:49: So I think all of that, you know, Melissa, really starts with, you know, that whole construct of working backwards from the customer. Really intimately understanding what the customer's problem and challenge is and empathizing with the customer. Putting yourself in that customer's shoes so you can really understand like, hey, where's the friction points that I'm trying to alleviate here? What is the value that I want to get out of, you know, adopting a specific product or service, et cetera? So I think that's the starting point, right? And I think that's one of the hardest things to do. You know, organizations, you know, have these nice, you know, hubs for innovation and all that sort of great stuff and product development. You know, it's very easy to go into your existing database of customers, your customer support folks and your sales folks and your marketing and get all these great, amazing data points and use that as justification to build up your story. But I think it's also one level harder to actually say, I'm going to interact with my customers firsthand. I'm going to put myself firsthand in their shoes to understand their challenges and be able to really come up with a good understanding of your customer in order to ensure that you're developing the right solution that is solving their issue. And I think, you know, where the challenge comes in is that executive leadership sees some of these things coming through and they may not be 100% convinced that it's solving the right problem or delivering the right level of value. So to do that, you really got to start by working backwards from the customer. So that's the first part. The second thing is, you know, I see innovation and funding for innovation as almost like a startup. You know, like when a startup goes through its A, B, C, D, et cetera series, right? So it's important for product teams and these innovation hubs to have, you know, we call it an MLP, most level product at Amazon, not really an MVP. But to have a product that they start at a small scale. And within that scale. Small scale and within the first phase or the first gate of delivering that product, they have to have established KPIs that says by this period, I want to be able to meet X, Y, Zed metrics. And this is how I'm going to do it. And this is the value that's going to be delivered to the customer. And if it does not happen, then I need to pivot. Then I need to iterate to change exactly what I see from the outcome of what my customer is going to realize from the product. Right. If my KPIs are met. And if I do meet the objectives, which are aligned with the executive teams, then I get a batch of funding. And it should be done in that sort of method or mechanism. So funding is done in batches versus saying, I've got this great innovation. It's going to cost, you know, a million dollars. I want a million dollars to fund this. That's not how it should work. It should really work with, I got this great innovation. We're going to start off, you know, in the first phase. It's going to have X, Y, Zed, you know, KPIs in place that we want to meet. And we're going to try to achieve this. And we're going to try to achieve this because this is the goal and the outcome. And this is how we're going to prove and validate the concept works. And if that's met, then the executive leadership team could say, okay, I will give you a batch of funding that will be supported until the next batch of funding. And that funding will then draw down as it draws down and they reach the next gate. They'll have to obviously prove the next set of KPIs. So it needs to be something that works in tandem with the executive team, as well as the product teams or the innovation hub to understand what are those KPIs you want to reach. And then more importantly, what is going to be the next step? And what are the next steps that you're going to be able to take to get to the next stage of the funding process?
Melissa - 00:32:29: You're working with teams like this too. How do you balance who can come up and ask for that funding and like, and, and having teams around products, let's say like, I could see people executing this wrong and doing it more like project-based funding, right. Where they're like, okay, this means everybody needs to come to me with their idea to improve a feature or to like make a new product. Right. And we will sign off on that project. Like we used to do in PMOs and, you know, fund it, but there's gotta be some kind of balance, right. With like funding stable product teams, but then also allowing for, for radically new ideas. How, how do you balance that? How do you advise people on that?
Quincy - 00:33:12: Yeah, I think that the important thing here is, you know, when you look at your data and your KPIs, it needs to be outcome based. And when I say outcome based, I don't necessarily just mean outcome for the organization. It needs to be outcome based for the customer. So you're not doing something that is driving a project mentality or project behavior where, okay, I need to achieve a certain set of KPIs in terms of, you know, my fast delivery or how quickly I can get this out or how much revenue I make and then I get funding. No, it needs to be based on I delivered a piece of customer value. We measure this by X, Y, Zed. If it's a new website, you may measure that by time to value, whatever it is that the product or service that you're creating. And those metrics that are outcome based should be something that directly impacts the level of value that the customer is getting. And that value that the customer is getting and proving that value should be tied to your funding cycles. So when we think about how that funding is released to. This innovation team, it needs to be based on, okay, innovation team, you prove that you've delivered value to the customer. You prove that the customer is is happy with the outcome of what you delivered. We are now releasing the next set of funding for you because you're showing that there's viability in this, not just for the business where it might not just be short term, but you're proving this viability for this for the organized for the customer where it adds a level of credibility for long term continuation of consumption of the product. So I would say the big part of that is that it needs to be outcome based. And I think a big part of that as well is that, you know, you have to have a mindset within the organization that when you are working on a new initiative or project. Yes, it's important for the best the business to benefit. But it's also just as important that if you create enough value for the customer and if you create something that's going to be sustaining in terms of delivering that value. You're going to get all the other. Benefits for the business that are important revenue generation, you know, acquisition of customers, market share, all that sort of stuff will come along once you are satisfying the customer. So that's a meant a mindset as well as a cultural change that needs to happen across the organization. It needs to be a focus on the customer and help pull the other KPIs that's important for the business versus I want to achieve these KPIs for the business. And that's just, you know, me focusing on my business outcome versus the customer.
Melissa - 00:35:40: Okay, so it sounds like there's always some kind of dual-sided outcome there where it's customer outcomes and business outcomes we're looking towards, but it's never just one in isolation.
Quincy - 00:35:51: Absolutely.
Melissa - 00:35:56: Are you eager to dive into the world of angel investing? I was too, but I wasn't sure how to get started. I knew I could evaluate the early stage companies from a product standpoint, but I didn't know much about the financial side. This is why I joined Hustle Fund Angel Squad. They don't just bring you opportunities to invest in early stage companies, they provide an entire education on how professional investors think about which companies to fund. Product leaders make fantastic angel investors. And if you're interested in joining me at Angel Squad, you can learn more at hustlefund.vc/mp. Find the link in our show notes. So one thing you kept mentioning too a little bit earlier is about like this concept of a single threaded leader. Is that a role? Like is that a product manager? Is it somebody else? Could it be any type of role? Who is that person?
Quincy - 00:36:43: Yeah, so typically the single threaded leader on product teams should be the product manager. So the product manager is the individual who really has and understands the voice of the customer. They understand the different elements of what is required to build that product from the technical side, the business side. It doesn't mean they need to go deep into the tech, but they understand the limitations, the parameters, the requirements. And they understand the business value, why it is this is important for the business or what it is we need to do in order to operationalize that. So the single threaded leader is not necessarily the person who has all the answers, but is the person who has a well-rounded understanding of the key elements and triggers that's going to support that product as it goes through the product life cycle. So when we talk about single threaded leader, it's really the person who takes the perspectives of the team. So if we're talking about, you know, we're talking about a product team, if it has an engineering manager, if it has a designer, if it has someone who's responsible for, you know, database creation, if it's somebody who's responsible for, who's a business analyst, all those elements, that person needs to have broad context on, not deep understanding, but broad context on. So when feedback and information comes to that individual or is being shared, that individual should be able to understand. And synthesize that information in order for them to make the right decision for behalf of the customer as well as the business. So they're a single threaded leader because they are taken and aggregated all that information. They're not necessarily a single threaded leader because they're a dictator. It's more of, okay, I'm in the middle and I have the responsibility of aggregating all this information that I get, all this domain experience that I have on the team. How do I bring this all together? To me, it's a very important part of the process. How do I make a decision that is best for the customer as well as the organization?
Melissa - 00:38:44: So I feel like since, I'm trying to think of when, but like I think like in the early scrum days, right? And when we were starting to think about how companies operate and make decisions too, I found that some people have conflicting views, and this is where it gets a little messy, about decision making and who makes the decisions, right? And you did mention early on in the podcast about how trying to make decisions by consensus is what really, you know, slows us down. I've always believed in this approach of like the product team helps to make the decisions, including the engineers and the designers being involved in it. But at the end of the day, the product manager has to be the one who makes a call if there's like not a consensus, right, about where we go. And I find that sometimes upsets people, right? When you say that this is the person who makes the call at the end of the day. How do you like balance making sure that everybody's voices are brought? And considered right as a product manager, what's your advice for them? Versus moving people along and for the sake of getting things out the door that are valuable. Like how do you balance that decision making and when, when's enough to stop as a product manager and make the decision? Let's put it that way.
Quincy - 00:39:59: There are two things, Melissa, that I think are very helpful and support that spaghetti of mess that I call it when there's the emotional elements that's involved in why can't I be heard or why can't my decision count, right? Two things that I think are super important. So the first is we have what's called tenants for product teams, right? And think about tenants as your, you know, the tablet that Moses had when he went to the top of the mountain with your Ten Commandments, right? Tenants are essentially the principles and rules by which the product teams are guided by. And each product teams has a set of tenants. And those tenants provide alignment and synchronization across the product teams in terms of, you know, what should they focus on? You know, how should they prioritize? What is important? Is it important to focus on the customer? Is it important to focus on operations? Is it important to focus on the business? So it really helps create a mental model of what needs to be taken into consideration as we make decisions, right? And what this does, it creates. It creates an element of a common understanding across the teams when we think about developing our products, right? So it, I would say, somewhat automatically gets rid of or stops to some degree the elements of people not understanding, you know, why certain decisions should be taken. Because, you know, you have your set of tenants or your set of commandments, whatever you want to call it, you know, my decisions should be guided by these set of tenants. So it sets that mental model. It sets that mental model in people's mind so they know that they should be guided by what's in that. So that takes away some of the fuzz and some of the gray area. It's not exactly perfect. It's not 100%, but at least it brings everybody on a common ground, right? The other thing that works really well at Amazon, and it works at other organizations once they do have it in place, we have a set of leadership principles. And we are very meticulous and work very hard to bring people into the business who share and have and can commit to the same type of leadership principles we have. And one of the leadership principles we have is to disagree and commit. So it means that you have the opportunity, even if you don't agree with something, to disagree with that decision, to state your position, And it is up to leadership. It is up to the product manager. It is up to people on the team to understand your perspective, to see your perspective, and also to give you enough insights into why we may have already thought about your perspective and addressed it or why we don't think it may be something that we need to consider as we make a decision. But once that is in place, it's also important for you as an individual, if you are disagreeing, to understand why this decision is being made and then commit to the way forward. And that doesn't mean you're doing it in a disgruntled fashion or I don't agree with this and I'm happy and I'll move forward. You're committing because you understand, you have context, you have a good foundation of why you're making or why the product team is making a decision. So I think the disagree and commit is a very strong leadership principle that helps support. I can voice my opinion. I could say I don't agree. I can say what I think about this decision, but I'm going to commit on behalf of the team and commit on behalf of the customer to do the right thing. And the product manager is usually the person who has that final say to say, well, this is the right thing to do because they are the voice of the customer. So I think those two elements, disagree and commit, as well as having a foundation of tenants that gives you the principles of guidance, really helps to provide that alignment for teams to get away from all that gray area of, you know, when should I listen to you? When should I not? When should I not listen to you? Or my feelings are hurt because you didn't really hear me. And I think that creates a better environment for that kind of decision-making.
Melissa - 00:44:08: I've always really loved that motto of disagree and commit. And I think it's so important too for leaders or anybody in a leadership position to kind of bring that to the forefront and make that part of their culture just so things can get done and they can keep things moving. But I've always thought that was such a strong thing. So that's great. So we talked a lot about like setting up good cultural tenants, good product tenants as well, how to like really start to communicate strategy. And another piece that you started talking about at the beginning was this concept of your product operating model and how you actually run your business to provide efficiencies and a better way of working here. When you think about the product operating model, what does that mean to you? What comprises of the operating model?
Quincy - 00:44:51: Yeah, so that's a good question. So what I see essentially is the product operating model. It's basically a construct or a framework that really helps the organization to better build, operate, and govern products. I see it almost like the strategic and operational backbone for how you lead impactful outcomes for both the business and the outcomes. If I'm going to give you a metaphor, Melissa, think about, you know, I'm going to ask you, what's your favorite restaurant?
Melissa - 00:45:21: Brunson in Sweden.
Quincy - 00:45:23: All right, great. So let's say you go to that restaurant, great restaurant. You know, Brunson represents the entire organization or it's a company, right? You go into the restaurant, you have your menu and the menu represents, you know, the product offerings. These are different dishes that you have that you're going to choose from and that you're going to eat. Then you have the chefs and the chefs are essentially like your product managers, essentially like your engineers and the folks who are cooking up your dishes that, you know, that's on the menu. So they're the ones who provide all the great tasty food. Then you have like your waiters and your services, your servers. And that's almost like your sales and marketing team. You know, they're taking the orders from the customers, they're ensuring that they're having a pleasant dining experience, ensuring that they're liking it. And then you have yourself, you know, this is your favorite restaurant, you come in and use it. And then you have the restaurant manager. So to me, the restaurant manager, just symbolizes product operations because it is the person who helps to orchestrate all this. They're not cooking the food, they're not serving the tables, but they're overseeing the entire operation to make sure that you have like a good experience. So when I think about operations or product operations, it's about how do you pull together the organization, not just the product team, but the organization as a whole, to orchestrate all the different moving parts that impact, that customer's experience, that impacts the efficiency, that impacts the outcomes of what you're trying to deliver. So product operations is almost like the, and I think you may have said this in your book, is almost like the glue that holds things together to make sure that everybody is synchronized and seeing and doing the same thing in the benefit of the customer.
Melissa - 00:47:06: So when you are advising people on how to set up product operations and looking at this, are there core components that you've seen be very helpful?
Quincy - 00:47:15: Yeah, so that spans across the different areas that I spoke about before about the operational structure or the organizational structure. There's the technology component I spoke about, the product management, and then there's the measurements and analysis. Those are the key areas that I kind of see are the areas that I focus on for customers. You know, when we talk about the organizational structure, the things that, you know, that come up the most is deconstructing and decomposing their product teams into smaller, more agile teams. And, you know, within Amazon, we call these two pizza teams. So these smaller teams that can be able to move quicker and respond to our customers and be able to experiment, iterate and move really fast. Right. It's also important as part of that team construct that you have, you know, your single threaded leaders, again, that really helps to accelerate your decision making. And we find, you know, what I've seen in organizations is that sometimes you don't have clarity around who's that single person who's making the decision. It's always, well, I'm not sure if I should make that decision because it may touch on, you know, Melissa's domain and I don't want to upset her or I think she should make the call or, you know, her technology areas can be impacted. If I make a call, so I think that's, you know, part of an important part that, you know, I see. The other thing I always tell some of my customers about that I think is super crucial and it sounds very simple is having those set of leadership principles as well as tenants. Because what it is providing is providing some sort of guideposts in terms of when I think about my organizational practices and the structure, like what am I being guided by? What is giving me a sense of, okay, this is the framework of what are the things that I need to do? Things that are important for the business? What's important for the customers? What's important for my team? So I think those are important things. And then the other part, which I think is super important, as I mentioned, is about the technology and as well as infrastructure. So those things such as, you know, how do I decompose my architecture or my infrastructure to be much more microservices based? And how do I leverage my APIs to ensure that, you know, I decouple all these systems that were hardcore? To allow for a lot more autonomy, to allow for a lot more flexibility and for us to be much more responsive. And then it's also important that, you know, when you're thinking about technology and your infrastructure, it's not just about the technology platform that's serving your external customer. It's also about your internal mechanisms that are serving your internal builders. So how do we, you know, mechanize things or tasks to automate them in a way that is taken away? From the work and the capacity that, you know, these product teams need in order to build. So really drive in automation of low value tasks to automate certain things. And then it's also important to be able to have systems in place that allows teams to self-serve. So, you know, when you think about your APIs, is there an API library? Is there a document repository where, you know, people can go in and find use cases around some of the experiments that you did and what were the outcomes of the experiments? And then also it's very important, which I think is key. And integral to, you know, when you think about technology and the business is ensuring you have that alignment between the business and the technology team. I cannot state how many times I walk into two organizations and there is complete disalignment. They have conversations on one side here with the business team. And then we have conversations on the technology side. And these two are not talking to each other. And they have different objectives. They have different goals. And they're just not syncing. So I think that's super important when we think about operations. Operational elements that help accelerate, you know, the speed of how we perform and build products. And I always tell, you know, the funny thing is, Melissa, when I go to the customers, I always say the funniest thing, the most value that we create is not necessarily all the great things we tell you in terms of how you transform. It's the value that we create. When we come in the room, that's probably the only time the technology and the business functions sit together. And that's the best value that we deliver. We're bringing these organizations together to actually speak to each other, which is an absolute insane thing. So in the absence of us being around, they're doing things in their own silos. When we come in, that's when they come in and speak to each other. And I think that's where we create a lot of value. And then obviously there's the product management areas that I spoke about, which talks about our working backwards, our narratives, our way we break up products into the different product taxonomy areas. So you can have a very strong product portfolio, the way we make decisions in terms of our decision mechanisms, one-way, two-way doors. And then last but not least, but I think it's also important, in order to have a clear idea of how your users, customers are consuming your products. So are you having very clear user engagement? Are you having very clear user engagement and usage tracking elements in place to understand your customers? Are you instrumenting your technology stack in terms of how you provide services or how your customers are using and adopting your services? And then on the other spectrum is those customers who are moving towards a SaaS model, which is a bit different flavor. They may be on the cloud, but they want to move towards a SaaS model. It's also important for them to start instrumenting their internal operations. And why I say that is because it's important for them to know exactly how their internal products are performing, not for the external customer, but internally. How long is their uptime? How long is the wait time in certain transactions? Are the APIs connecting fast enough? All those internal KPIs that were not before important to a product manager are now important, especially when you're in the SaaS world, because all those things impact the customer experience. So I think when we think about product operations, those are the kind of the key things that I kind of think about. Are there elements, you know, that I would discuss with the customer to help them evolve their current state?
Melissa - 00:53:13: I want to talk about that SaaS for a minute about how you've worked with organizations as well, who were more in a traditional software model. So not like non-software organizations, just for people out there listening, but ones who worked in this traditional software model, and now they want to transform to SaaS. For people who are not aware of what that shift actually looks like, what makes it different between just like a normal software model and a SaaS software model?
Quincy - 00:53:40: Yeah, so there are two things. So, well, I shouldn't say there's two things. There's a few things actually. So one big part of it is cost optimization. So you're able to optimize the cost of your technology stack because you're using a common infrastructure. You're also creating a set of use cases for similar cohorts of users. So you don't have to try to customize every single you know, deployment that you have for a customer because you have these, you know, what we call tenants, which is basically where the customers, you know, resides on your SaaS platform. So cost optimization is a big one. Responsiveness and agility is another huge part. So organizations now have the ability to be a lot more responsive because they don't have this big monolithic application or software stack that's now sitting in a customer's environment that has to be managed by the customer or themselves remotely. So they can now manage this for the customer through the cloud on the go. So all the customer really thinks about is the experience. They're not thinking about, oh, I need to manage servers. I need to manage software. I need to do security patch updates. I need to do new releases. All of that headache moves away from the customer. And that's a huge benefit for organizations in terms of deploying a software as a SaaS, but also for customers who use SaaS. I don't have to now take care of all these. Products and services. It's also a better way to understand your customers. So when you have a SaaS platform, one of the big things that is beneficial to the organization is having instrumentation in place that allows you to get real time as well as dynamic information on how your product and service is being consumed. So before when you deployed a customer, you know, you gave your customer your software, you had no clue about how they use it. You don't know if they used it once, twice, if they never used it, if they even installed it. So having that benefit of being able to understand the usage and the behavior around how your customers are using your platform and your software is a huge part. And then the other part about it as well is there's an opportunity, which is not immediate, but you don't have a recurring revenue. So you're changing your revenue model from, you know, a revenue model that would have been, you know, upfront, you get all your software that was essentially CapEx or CapEx costs for the customer who's buying it. That now changes to a new model. So you don't have to worry about the cost of the software. You don't have get the benefit of enhancements you make on behalf of a customer. So if Melissa says, you know what, I want to have, you know, a capability where I can add a red button on my screen. Well, guess what? All the customers now who are on my SaaS platform get to benefit from that red button on the screen. And I'm obviously simplifying it quite a bit. But that's essentially kind of the benefits for why customers are moving towards that SaaS model.
Melissa - 00:56:55: I heard this thing and I don't know how true it is. So I really want to hear your perspective. But I was talking to some developers a couple weeks ago and they said that now there's a push for companies who used to embrace the SaaS model, let's say buy SaaS products, not ones necessarily building SaaS products, but buying them, where some of them are actually moving back to on-prem because of the implications with AI and how people are using their data and the security and stuff around that. Is that a trend that you see at all? Being at AWS, I imagine that you would have some insights into that. Is that something that we should be worried about or any kind of trends that you see with companies doing that? Or is it, no, we're still migrating to SaaS?
Quincy - 00:57:34: Yeah, I haven't heard that as an issue, to be honest with you. There's still quite a bit of customers that are making that transition and making that evolution towards a SaaS business model. So I haven't seen that as a showstopper. You know, from my personal perspective, there are mechanisms that are available for customers to mitigate any kind of AI usage of their data. So you can actually have software products and software tools that stops, you know, different AI companies from scraping data off of your platforms, your websites or whatever it is. So there's mechanisms in place to have that. So I don't see that as necessarily a reason to stop moving to SaaS because SaaS, there are some inherent business benefits behind it. And then the other thing, you know, I think that organizations may be missing if they start reverting to on-prem is it takes away from that element of having very very strong and updated security. So one of the things that, you know, we are really good at that Amazon and AWS is our security, you know, protocols, our security stance, our security way of, you know, our way of securing the environment for our users. And because it's a model where we are always evolving and pushing security to our platform and to our services, or I should say, it takes away that burden of having somebody who has an on-premise deployment. So I think it's a good element to think about security and trying to figure out how they, you know, stop security, stop breaches into their platform. So I don't see that as a showstopper unless there's something else that I'm missing. But for me, I think AI should not be a reason to stop moving to the cloud. If they want to leverage, again, some of the AI capabilities that is out there, you only can do that in a cost-effective manner for now on the cloud. Because to do that on-premise, you have to... By very top-tier equipment that can handle the processing, the load, the storage, it's not an easy task. So I think organizations will be underestimating the amount of work and effort that's needed in order to stand up an environment that can accommodate an AI tool set. And in addition to that, as your AI grows and evolves, it means it's going to use a lot more memory. It's going to use a lot more storage. It's going to use a lot more storage. It's going to use a lot more processing. And it means that you need to invest in that. And when you invest in that, you're doing it based on sizing what you think the future outcome is going to be of that utilization of all those different services. Whereas if you're on the cloud or if you're moving in SaaS, you can scale that based on your consumption patterns. You don't have to scale something out too big for what you may need, and then you don't end up using all that capacity.
Melissa - 01:00:33: What are you excited about as you look at, you're looking at all these different companies embracing, you know, cloud cloud services and subscription models and great product management. What are you excited about for the future of product management and what you're seeing evolve at these companies?
Quincy - 01:01:41: Oh, that's a really good question, Melissa. So it's a tough one. And I say that because the product management space, if you think back, you know, I started in product management over 20 years ago, right? And you just can't see the grays because the hair doesn't really grow out much. But I started in product management over 20 years ago, right? And if you think about where product management was 20, 30 years ago, it was not as evolved as it is today. It was one of those things that kind of, yeah, we need to have product managers, somebody just to manage your products and put it together. But now product management has become almost the center point of creating value for the customer and ensuring that the customer's needs are fully embraced and fully adopted. And all that's great stuff that, you know, product management delivers, right? I think with that has come a lot of noise. So you have a lot of noise of product management theories and product management practices. And people are saying a whole bunch of things that are not exactly proven. And I think the challenge comes in, how do you know what's fact versus fiction? How do you know what's an academic pronouncement versus something that's actually been tried and tested? So I think the challenge is cutting through that noise and really understanding like, what are the clear signals within product management today that can work for my organization? So I think a lot of that is some of the challenges. When you think about product management, it's a mixture of science and art, right? And I like the ability to have some of the art in it. I know we are very now coming very data-centric. We're thinking about data all the time. We need to make all the decisions based on data. But I think the element of the artistic part of product management is slowly starting to erode as we're like focusing on all this data, data, data. So I would like to see more art involved in it. And when I say art, you know, I think about, you know, when we think about innovation and ideas, like what are things that can drive customers to adopt new ways of using a product or service? Like all these are kind of artsy kind of ways because you don't have any science behind it to prove it out. So I like that part of product management and I see it starting to disappear because everything is starting to be driven so much by data. And some of it, yes, needs to be supported by data. You can't make all your decisions off of intuition, but I like that balance between the arts and the science within product management that, you know, really helped drive the discipline from before.
Melissa - 01:04:10: Thank you so much, Quincy, for being here. This has been awesome. I have really learned a lot from you and it's been a wonderful dialogue. If people want to connect with you, where can they find you?
Quincy - 01:04:19: Best place to find me is on LinkedIn, always on LinkedIn. So, you know, Quincy Hunte. Ironically enough, there's no other Quincy Hunte on LinkedIn. And I did a Google search and there's no other Quincy Hunte. So unique. So, yeah. So if you need to find me, it's very easy to find me on LinkedIn, Quincy Hunte. Hunt with an E at the end. And always free to have a chat and, you know, talk some, you know, shop talk. Or even restaurants. Like I love food too as well. I'm a foodie as well. So feel free to reach out and happy to have a conversation.
Melissa - 01:04:50: Awesome. We're going to have to talk about restaurants next time we chat, because I'd love to go deep in that too. We'll link all those links for finding Quincy in our show notes. So if you go to productthinkingpodcast.com, you can find out how to reach out to Quincy. And for those of you who are listening, we want to thank you for being here for this episode of the Product Thinking Podcast. We'll be back next Wednesday with another episode. So make sure you hit that like and subscribe button so that you never miss one. And we'll see you next time.
Quincy - 01:05:15: Thank you. Bye-bye.