this talk is brought to you by user pilot the all-in-one tool for product ux customer success and marketing teams with analytics inapp user onboarding and [Music] engagement and inapp surveys hey folks this is Amelia from user pilot and our next product Drive speaker doesn't really need introductions he is the author of three very popular books in product management namely inspired empowered and most recently transformed he's also the founder of Silicon Valley product group at training and coaching organizations for product teams to enable them and Empower them to build better products and he also held vpu of product roles at companies like Netscape and eBay so welcome to the stage Marty Kagan Marty is going to talk to us today about moving to the product operating model so without any further Ado I'm giving over the virtual mic to Mary hello everyone thanks for joining this talk um joining the product Drive conference I've um looking forward to talking to you I have been talking quite a bit actually for the last several months about moving to to the product model um of course in truth I've kind of been talking about this for 20 years um really the first 20 years of my career was all about learning the product model and the next 20 years were really about sharing the product model now of course uh you would not believe me really if I told you just how different it looked all those years ago and I was learning in terms of the techniques the methods the tools we had were dramatically different but interestingly the principles were remarkably consistent with what they are today I actually think that's what makes them principles uh and that's really the heart of the product model we'll talk about that but uh because I have been sharing especially the truth is I came out with a new book transformed uh in March and so it's been out a few months and several I mean the goal was a lot more Executives would get into this and learn about it and see is this right for their company and the good news is a lot of them have and uh I do at least one or two executive briefings a week I I do them in person whenever I'm out uh traveling and uh of course A lot of them virtual and I've been getting a lot of questions now the good news is objections were I've been getting the objections for years and we included a large section in the book of the objections but what's been interesting is not really the objections to me but the uh just the confusions there are always confusions of course with anything non-trivial and I've been tracking those confusions uh we've been adding to a live Q&A we have on the website called transformed FAQ you can see it's constantly getting more questions and answers put in there but what I wanted to do today was to give you a high level overview of really the product model what the key Concepts are but also really for the first time what I wanted to do was address a lot of the common confusions that we see there's a lot of stuff out there especially of course on social media the funny thing is of course and you can't stop this this is just human nature most of the people that do make claims or comments have probably never read the book probably never visited even a company working this way but you know everybody's entitled to Ain so they share them so what I wanted to do is address the ones uh the main ones that I hear they're there's always there's always new ones there always will be but try to address the main ones so that you uh can understand sort of the different perspectives and not assume that something you read say on social media is is H the intent or the reality so anyway let me uh start by telling you um svpg Silicon Valley product group we were created to share the principles and practices and techniques of the world's top Tech powered companies that's it we uh in fact it's this is where I'll start addressing some of the confusions uh we didn't invent the product model um we just are describing the product model we did well we didn't name the product model either really what we did is we needed a term for it and we started looking around what were the terms out there some people used product Le company or stuff like that and we didn't like the sort of connotations of product in the driver's seat uh and some companies were using this term product operating model and we thought all right that's good that's it's not a process it's conceptual so we ended up using that um but we did not invent that just to be very clear um in fact we didn't invent any of the things we write about if you read any of the books inspired empowered transformed we didn't invent those things we're just sharing uh what we see in practice in the best companies that's really what we do now we don't share everything we share the things that we see work and also we try to share those things that that are common across companies not just the vagaries and you know the sort of things about a founder like some every company has founders with these personalities and some of those things we think are unimportant they're just part of the character uh but what really matters are the principles and the practices and so that's what we share so that's important so you know where we're coming from okay so what I wanted to get into the heart of this is what is the product model you can already tell we is the term product model is short for product operating model and really it's a set of a few things it's a set of Concepts it's a set of competencies and most importantly it's a set of principles product model first principles in fact the heart of the book is the principles there are 20 product model principles that we've identified and it's interesting because they're the same principles we see whether it's a device company uh an Enterprise SAS company a consumer internet services company whether it's a startup or whe it's a huge Enterprise these principles are not specific to those things there are things you know I don't want to play koi they're things like um do you need to experiment if you want to innovate across all of those examples we argue you do and every single good product company we know consistently experiments and and that is the key to their Innovation yet in so many companies out there they don't do experimentation if they do anything it's some very lowrisk optimization like using optimizely or something not a real experiment and so um that's an important principle and there are 20 like that by our sort of taxonomy of principles okay so um let's talk about the product model first of all the highest order idea what is really about is is achieving outcomes everything we talk about is all about delivering outcomes which is as you probably know it's a whole lot harder than delivering output in fact when I first learned product it was really all about output there was some talk about uh outcomes because I was uh I was at um a company hulet Packard the HP Labs where we had a culture which included something called management by objection by objectives and the idea is you give a person or a team a problem to solve and outcomes to achieve so there was that but there were still a lot of road maps and there was still a lot of waterfall going on and even when you have the best of intentions was a lot of it was output so as teams companies got better at product they get better at achieving outcomes so the the overarching principle of the product model is to achieve outcomes it's to help your company and your teams get better at delivering business results so that's the highest order Point second a product model is a conceptual model and this is so important it is not a process it is not a framework I've been a student of processes and Frameworks for years um uh honestly for my whole career I've been interested in that and I still love to learn them but my view is there is no one process there's no one framework you want to choose the right tool for the job yet the product model is a conceptual model so there are many ways of doing things like product Discovery there are many ways of engineering products but what matters is uh this conceptual model and so that's what we're focused on that's why the first principles are so important is like I said is not a process it's not a framework it's not a methodology there are any number of them so what is it really it captures a set of principles which reflect what we see in the top product companies that they believe to be true about creating great products okay so let's talk about some of the misunderstandings about the product operating model that already have sort of surfaced and this is normal I'm not I don't want to sound you know bitter or anything or frustrated just because this is human nature it always happens I think this is kind of the funniest one um that there are some people out there that have come up with some really random definitions of what product operating model is I mean uh accounting firms have weighed in people who have never done product before clearly have weighed in and said oh yeah you need to be on the product operating model and here's what that means and I read it and I just can't help but burst out laughing so so of course people can Define things any way they want right I mean look at how I was some people Define the Earth as flat doesn't make it right but you know if you want to believe the Earth is flat you can look look at how many people say safe scaled agile framework is agile and that is hilarious to me um of course safe is anything but agile but doesn't mean that you know a lot of marketing people in the safe world will say of course it's agile unless you know better but the point is really that you have to look deeper so don't just trust some random definition if you wanna if you're reading our work then you can look at the definition that we're talking about here and the main thing i' encourage you to do is just be very uh take it with a big grain of salt there's a lot of stuff as you know in anybody can go out there and Define anything they want and so it's buyer beware you have to be careful another really common misconception now this is not the most harmful one in the world but it is politically damaging in the sense that a lot of people think when we talk about product model we're talking about a model of product management now don't get me wrong it includes product management but that is like one of about 30 things that are really important that it includes and to equate the product model with a product management model sort of puts it it elevates product management Way Beyond what it deserves it's just one of the critical competencies and it also sends a very different message if you go if the CEO perceives what we're talking about here as product management model it doesn't even make it to their to-do list you know it's not even relevant that is way too low a level product model is a much higher level concept about how you deliver outcomes for your customers and ways that work for your business so that's important to understand just like we don't consider any of our books like inspired is not on product management it's on product teams it's on how product teams do product Discovery uh Howard is not just product man it's on product leaders how engineering leaders design leaders product management leaders do their job and of course transformed refers to moving an organization all of these people to the product model this is another one that's kind of funny it's just an accidental one but it's amazing to me how many people don't realize they they just sort of assume because the string that when uh when people say product opts it's short for product operating model but actually it's it's just a coincidence product Ops is a role it's uh it's a supporting role I think it's an important role it can mean different things in different places but for most people it includes user research and data an data analyst and as you know hopefully you know those are really important roles they help product teams make decisions they make them help them make qualitative decisions and quantitative decisions but that is just to be very clear you can have product Ops people in companies that are not in the product model in fact most of them are not just like most people with a title product manager are not in the product model they're in feature team companies the majority of companies in the world out there are feature team companies they can have people called Product Ops they can have people called Product managers that have nothing to do with the product model so don't just don't conf fuse the two it's understandable if the string kind of tripped you up but um but they're different things product Ops is a role it's short for product operations as in devops as in design Ops product Ops it's that side that that's what it comes from this is another one that's really uh important for people to understand because I have definitely met I just actually just yesterday had a call and this is something the CEO is confused about product Le growth first of all I should say I love product Le growth I I try to convince a lot of companies to go that direction but it's similar to product Ops you can do product L Le growth with any model of working you don't have to use the product model it's orthogonal to the product model product leg growth is how do you build and design and build your product to spread just like we have sales Le growth where basically sales people that sell your product you can have marketing Le growth and you can have product Le growth some of the greatest success stories of the last several years have really pursued product-led growth where the product designs in the capabilities to spread slack is just sort of an obvious great example of product L growth but um I just want to be clear those there's a lot of words out there in our industry with the string product in it don't confuse use them product Le growth is great it's not just to be clear it's not appropriate for every company uh there are a lot of products where product Le growth is not right sometimes for example a direct sales organization is the better approach that's a whole different conversation that's really not about the product model at all uh you can do product Le growth you can do sales Le growth you can do whatever you want in the product model that way that product model doesn't tell you the nature of the product you build and I hinted at this before but this is like super important uh don't assume that just because you have people called Product managers or Worse product owners that you're running the product model uh the chances are you're not I I just I just say that because the majority of companies out there nobody knows I've never been able to find anybody that's done any real statistical analysis of what the percentage is but I wager anything we're talking a minority of companies maybe 10 15 20% are running the product model the vast majority are running what we call the feature team model or or even worse there's delivery teams we don't that's the sort of safe thing that's not really in the product world the last thing I want to point out is there is no one right way to create product there's many right ways I mean look at Apple doing a device and you compare or contrast that to Amazon doing a new service or Netflix doing a new capability these are very different things that they're doing but I would argue what matters is those principles are still consistent and that's what the product model is about so there's no one right way I try to coach product teams every day to to consider this the problem in front of you consider the scenario the risk and choose the right tools for the job there are lots of good ways to do things we're finding new ways all the time and there's also lots of bad ways to do things so uh that's important all right hopefully these are common confusions about the product model in general overall so you don't have to like read this but this is an overview of the product model there's really uh Dimensions I'm going to double click on that so I won't spend much time here I'm going to talk about that in a few minutes but um there at the highest level when we talk about the product model we talk about how do you decide which problems to solve how do you solve those problems and how do you build test and deploy those Solutions uh then we'll get back into that in a bit um in order to do that there are five critical Concepts in the product model your product culture your product strategy which is actually how you decide which problems to solve your product teams which are the ones doing the work of solving those problems and delivering the solution how they solve those problems that's product Discovery how they deliver those Solutions that's product delivery so those five major concepts are critical they're the really the building blocks and then the people which is really at the heart of all this the people there are a set of competencies in fact one of the hardest things we've found is to convince people that when you move to the product model you need to take a very fresh and honest look at the competencies and that's mostly because people already have employees in their company companies already have people with these titles and just because you have that title though doesn't mean the job is defined the same way as you know there are many different different definitions of product manager out there I'm going to talk about that next there are also several kinds of product designers there are different levels of Engineers but in general engineering is engineering there Tech lead we're talking about there as the senior most engineer uh on the team and then uh they we have the managers of all of those people those those are the managers of product managers the managers of designers and the managers of Engineers and those we refer to as the product leaders turns out they have a very big job in the product model it's another really common misconception is that oh all you need are these empowered teams but that's just not true okay so let's double click on the first one the most common and deep confusion about the product model is the role of the product manager now some of you know I've been talking about that forever um and and I understand why it's so hard these are very deeply in things there is no one answer there are different schools of thought out there but what we can say is that if you move to the product model from the feature team model it is a very different job with very different responsibilities now you can debate if your company wants that role or not which definition it wants but if you're going to move to the model it's a very different job now what I'm showing here I I've tried so many different ways I've written uh one of my most popular articles is called Product teams versus feature teams and it caused quite a Ruckus when it first came out because it shined a light on this difference a lot of people were really disturbed by uh kind of seeing their job painted in a way that they weren't crazy about but they kind of knew was true uh and that was really what I'm trying to do here with this image is now I'm I'm try I recently tried sharing this drawn and on a whiteboard for people and you know some people visuals re you know resonate better than a narrative and you've probably seen this this image has been around for for so long uh I've always considered it absolutely wrong uh but I understand it and I understand where it comes from but what it's showing um there are if you just look look online you'll find like 50 variations they all are the same exact image the same vend diagram they'll just sometimes name instead of user they'll say ux or something like that but it's the same thing and most importantly they show design they show engineering and then they show the product manager kind of not really in product manager doesn't really have a place of their own in this model they as you see they they kind of say well we're in the middle and you'll hear all these different um I'm trying not to be uh derogatory here but you'll hear lots of sort of uh apologetic descriptions like oh well we're the facilitator you'll see that word facilitator all over uh uh we're the cat hurter I hear that a lot because in in the feature team where you're given a road map you're given some dates you've gotta get something designed you've got to get it built you got to get it shipped and you're given output on a road map so you're trying to ship output and the product manager is kind of there to H the cats that's why so many people describe it that way of course what I'm really describing is project management that's really what it is project management who's deciding that thing is even there that was on whoever decided it went on the road map It's usually the stakeholders and and so the product manage I don't want to make this sound trivial it's not it's a hard job project management is a hard job it's also a lot of times a thankless job so I is not a judgment about that all I'm saying is if you want to go to the product model erasing from your mind this definition because this is all off uh because in this model in the feature team model the decisions about value the decisions around viability are really coming from the business from the stakeholder ERS so the product manager is really the enabler of that so okay now if that's a feature team product manager now let's talk about what an empowered team product manager looks like and I'm drawing it the same kind of way it's the same vend diagram but there's a pretty big difference here first of all this is all about outcomes and that means that implies that the product manager needs to be the expert and the representative on the business this isn't the stakeholders anymore the product manager is no longer a facilitator the product manager is a Creator you hopefully know product is about satisfying for the customer the user it's about satisfying the business constraints the viability and it's satisfying the Techni technology the engineering constraints and that's what the engineers do uh One More Level here you look at this now by the risk the product designers got usability and they do in the feature team model too the engineer tech leads have feasibility and they do in the feature team model too but what's different in the product model is the business risks viability is this viable for our business can we afford to build it can we monetize it can we Market it can we sell it is it legal is it uh ethical is it support the Privacy constraints so that is squarely on the product manager and all three of these are contributing you can just intuitively you hopefully understand all of these things have to be there the usability the feasibility and the viability to have a product and furthermore the value of the product is how is a really a measure of how good you do these things so if it's just okay okay and it's not as good as the Alternatives out there good luck selling that product what we're looking for is where the value is high enough that customers will choose you that's what's hard about product so this is um I hope you know I'm trying this approach with the visual but hopefully you can see okay yeah there's still those three constituencies but in the product model the product manager is a Creator they are responsible for viability and they are overall responsible for the outcome and they collaborate with the engineers and with the designers to satisfy for the customer and satisfy for the technology so hopefully you can see that that is not a miner difference so much because if you want to empower a team what does it really mean to empower a team it means you give that team a problem to solve and the team comes up with the best solution to that problem that might have been something that would have been on a road map probably a different approach because usually the people that put items on a road map don't understand the enabling technology that's why Innovation almost never happens in the road map model but what or in the feature team model but in this model because the engineers are working with the enabling technology every day we often come up with much more innovative better Solutions that's the premise of a empowered product team but if and a product empowered product team is able to solve the problem and be accountable to the outcome but in order to do that they need to be able to address all four of these risks hopefully that makes sense that's a big deal what we're talking about here all right another big Concept in the product model is this idea of strategic context of course the premise here is to push decisions down to the product teams this image is just showing four product teams and they're each getting they're each given some objectives we usually use okrs for this but you don't have to uh there some objectives in other words problems to solve they're given problems to solve and they're given a measure of success and team has to figure out best way to do that however in order for that to happen it sounds logical hopefully in intuitive but in order for that to happen in you need the product teams to be able to make good decisions now part of that comes from working with the engineers every day and talking to the customers every day but part of it comes a big part of it comes from understanding the big picture and that's what the Strategic context is that's sort of what that triangle is uh um at the top it starts with the mission of the company which everybody knows and the business objectives which are using usually annual and then where you get interesting the product Vision the team topology you know product vision is the future you're trying to create several years from now the team topology is how are you going to structure your product teams what are because we need to know not hopefully we know what our team is responsible for but we also need to know what other teams are responsible for because a lot of times we're going to need to work with other teams to get stuff done so we need that big picture on the team to ology and most important of all we need the product strategy the product strategy is what identifies so the product Vision says where where we're going over the next several years the product strategy says what are the most important problems we have to solve now right now this quarter and so we all need to understand that product strategy because that's what really shows how our work ties in with everybody else work the product Vision will show how it all contributes to the greater whole over time but the product strategy is a big deal now hopefully you can already start to see that some of what I'm describing here is very different from what like a lot of agile coaches will teach you if they've never worked in product companies before so let's talk about what some of those things are so I mentioned already though that the Strategic context gives you that context necessary for product teams to make good decisions but it's got to be at the holistic level it's in other words what we're looking at is the whole not the parts and because of that and this is the big thing I wanted to highlight it's the the Strategic context is the responsibility of the product leaders a really common misunderstanding standing out there there are all kinds of goofy definitions in my opinion of the product manager in some senses they're they're project managers like I said when they're feature teams yet in other senses people say oh and they're responsible for product strategy no they're not how could they how can that make sense just think about that let's say you've got 25 product teams in your medium-sized company and those 25 product teams are all contributing to some product Vision do you really want 25 product strategies do you really want 25 product Visions so people that tell you any coach that tells you that every product team or every product manager is responsible for the vision and the strategy they're just spouting words without having any idea what they mean so I just want you to realize what's critical here is that you have a strategic context it includes the vision the team topology and the product strategy and that is the responsibility of the product leaders similarly I just started talking about this more because I've met more companies that are confused about this go to market strategy hopefully everybody on this call knows what we mean by go to market is a really important concept it's one thing to build to get the product Market fit and have a great product for that market but a big part of the equation is how does your product get to Market I was sort of alluding to this before too when I talked about product Le growth but what are the channels that are used to get your product to Market what is uh uh do you use a direct sales channel do you use uh directed consumer um do you have uh reseller channels all of these things and then what is the value at each stage you have to provide value say to sales reps or to a channel in order to get them to sell your products so you need to understand go to market strategy but just just like product strategy that needs to be at the holistic level imagine if you had oh imagine you're working on the iPhone do you really want each team and by the way there are hundreds of teams working on the iPhone but do you really want each team worried about their own go to market strategy that would just be uh you know beyond ridiculous so that has to be done at the holistic level as well now that we do need to make sure that whatever we build and deploy is consistent with that go to market strategy so just like we have to be consistent with our design there's a lot of things we have to be consistent with all right so those are some uh you know the at the highest level the product model Dimensions the product model Concepts and the product model competencies now what I wanted to do was double click on what does it really mean to transform and we're going to talk about those three dimensions here and then we'll talk about the areas that people find confusing so the first one and to be honest there are three but there's no real order here uh in fact in the book transformed I described them in the opposite order that I'm describing them to you now uh sometimes I like to go from the bottom up kind of when I describe it and sometimes I like to kind of describe it from the higher level Concepts down and uh what I'm doing here is starting with the highest level concept um that said the reason I did it in the book and honestly is probably the better way to explain it is um even though I'm describing this Dimension First It's usually the last of the three to do when you transform because you don't really want to do this until you've got the other two nailed so we can talk about that later so let's talk about this though whatever order doesn't matter there are are three highlevel concepts when it talks about uh the three dimensions so how do you decide which problems you're going to solve that's the first big Dimension I wanted to talk about here now just to be very clear every single company in the world I've ever met has some way of deciding what they're going to invest in that most of them are remarkably consistent they have some sort of quarterly or annual product planning process some of you actually have been emailing me lately because you're in the midst of that process right now and you're working on your business cases and budgeting and stuff like that that's fine um but uh there some way companies figure out what they're going to do now the truth is most of them it's not very complicated at all what happens is the the SE Suite CEO and the CFO and the CMO the senior leaders of the company they decide how much of the engineering capacity is going to be allocated to each business unit I mean we're talking a big company here it's an easier exercise if it's small like a startup or even a midsize company but in a large company which is where this process is the most painful um you know they're trying to decide and the easiest way they do that is they say okay we're going to allocate 20% to the international business unit because International is very important and then they say we're going to you know allocate you know 10% to our warehousing operation because that's very important we're e-commerce and we fulfill that's important and they just make some allocation and then they lean then they basically delegate to the stakeholders for those business units and say you've got 10% but that maybe that turns into you know 25 Engineers they don't really some allocation and they say okay you got 25 Engineers worth and your job is to make sure they're doing what you need them to do so that's why that's where this concept of a stakeholder driven road map comes from it's not it's not evil or anything that's just normal they're spreading that out now most of the time the language they're using is not the problems to be solved they're more like we need this feature and we need it yesterday because a competitor has a feature or because we want to do this kind of shipping or because of whatever and that's fine a lot of times just they just want to knock it out but they typically have a solution in mind and they prioritize those Solutions and that goes on the road map and that eventually gets to the product team that's assigned to do those things for that business unit if you move to the product model the idea is this changes and this is also I'll be honest this is the most impactful of the changes in my experience it's also the most difficult politically of those changes because now we're talking about a change in the power dynamics of the company you can hear the way it works in most companies the stakeholders are very much in the driver's seat and the feature teams are very subservient to those stakeholders and now we're talking about not flipping that Dynamic but now they're true collaborators and that's a different Dynamic but the reason it's important and the reason the best companies are so good at this is because the job of course is to make sure you're pursuing the most valuable opportunities and that you're pursuing the most serious threats not that you know you have 15 stakeholders and they're all getting their fair share what you're trying to do is make sure you're getting the most bang for your buck and the way we do that is to look holistically and that's that's what product strategy is that's what product vision is this is where the product leaders really earn their salary and it's interesting to observe in a feature team company the product leaders don't do this at all it's not like they don't do it well they just don't do it because it's really something being done by the stakeholders but if you move to the product model the product leaders now have a very large responsibility that's why I do recommend this is done after we get the other two Dimensions working well part of it honestly is building and earning the trust from the organization that you should be allowed to do this all right so that's the First Dimension continuous product strategy what are some of the problems it's really important to understand that the responsibility to identify these problems to solve is your product leaders if your product leaders are not up to that maybe not yet or you don't think they ever will be then honestly your stakeholders will continue to do this now that's not so bad it's not the end of the world usually almost always I want to be clear the stakeholders do know very important problem s to solve they don't necessarily know the most important problem solve because they have to look across the whole company to see that but within their area they are they're in it every day they have very good understanding we just need to coach them it's not hard to instead of framing everything is build this feature or build this project to now solve this problem identify the problem to be solved that's not hard if we we can do that little bit of a negotiation with the stakeholders and say can we just frame this what problem are you trying to get us to solve and how would we know if we succeed that's a very easy discussion honestly you can typically do it in a few minutes and then of course the win for the stakeholders is yeah and now the team is signing up to deliver on an outcome that's a much better real progress but um if your product leaders can't do the product strategy then you'll need to continue with your stakeholders this way but you can still make progress all right let's talk about the second dimension the second dimension is how do you solve problems how do you solve them if you're handed a road map again this is not something product teams feature teams sometimes they say they do product Discovery but they really I mean it's a it's a stretch uh what they're really doing is they're designing en coding solutions that have been given to them on the road map because almost all road maps there are some exceptions I wish there were a lot more but um they're output they're prioritized lists of features and projects so when you move to the product model the second biggest second large Dimension is changing how you solve problems for most companies that mean introducing empowered product teams and product Discovery that's what it means uh having real product managers like we were talking about earlier uh that are responsible for the value and the viability of the solution collaborating with real product designers and real Engineers to solve hard problems in ways customers love but work for the business that's what product Discovery is now there's a lot of confusion out there there's a lot of noise out there about product Discovery now I want to be clear from the be beginning of our industry literally my father was uh was literally the first PhD in computer science uh and then so I grew up kind of hearing this stuff it's been the same thing forever in technology we've always had two two things we needed to do we need to figure out a solution and we need to build that solution now most teams just sort of Squish those together and they say well we hope we're right we think we're right we're just gonna build this and cross our fingers of course we know that doesn't have a very good track record realistically it's like 10 to 15% of the time it's right the rest of the time we have to iterate and iterate and that's why it takes years so often to achieve time to money versus time to Market so we uh we need the techniques of Discovery T Discovery is just the term we use for how do we figure out a solution worth building and delivery is just the term we use for developing coding testing QA testing deploying the solution all right lot of common confusions around Discovery let me tackle the biggest ones the first one is like I said before with the the Strategic context the product leaders are responsible for identifying the problems to solve and assigning those to the product teams but it is the responsibility of the product team the empowered product team to come up with the solution to that that's their job the idea is you know it's not a prize the idea is that they have the engineers they have the designers they're working with the enabling technology every day they're talking to customers every week who better to figure out the best solution to that problem but this is where there's a lot of confusion because of that product Discovery is mostly solution Discovery it needs to be mostly solution Discovery now if you don't know what I mean there there's two side two parts to product Discovery discovering the problem understanding the problem and then coming up with the solution hopefully it's obvious to everybody that if you don't understand the problem you are you're in trouble good luck coming up with a good solution if you don't even understand the problem now when we talk about understanding the problem there's even two parts to that there's identifying a problem worth chasing worth solving and then there's really understanding that problem identifying the problem worth solving that is the product strategy that is the product leaders now they are usually don't get me wrong we have these wonderful people that I love called user researchers that are discovering unmet needs all the time but we they they feed their learnings to the product leaders so that they can decide if that's so valuable that it will be included in the next iteration of the product strategy so there is that sort of oh we've identified a new opportunity but realize the context here in the product model is the product strategy identifies this quarter we need to solve this problem and then that problem is assigned to a product team so that product team needs to make sure they understand the problem and then they need to design the solution and build that solution now the reason I say Discovery needs to be mostly solution Discovery is because yes you need to understand the problem but that doesn't get you anything you customers buy solutions they buy Solutions and the part that you really need to hear is that because this gets to the essence of product what's hard about product is solving a problem better than the competition dramatically better some Ben horist likes to argue on the order of T times better I don't know if it's hard to even quantify what's a 10 times better solution I could tell you slack was a 10 times better solution Zoom was a 10 times better solution when these things came out um lots of examples of that but the point is they're clearly better demonstrably better because that's value and that's why people choose to use our products to buy or to use the new capability so you need to make sure that most of your time is on solution Discovery now a little bit of politics here if the CEO if the stakeholders if they think you're spending three months understanding the problem and doing nothing to come up with a solution my guess is they will revert to their old model and they'll say look you're not able to do this we're just going to tell you what to build so you have to be smart you have to be smart now the other thing that sort of saves a lot of teams because there sort of a NeverEnding process of understanding problem you can always spend more time the nice thing is when you're doing solution Discovery what is that really it's prototyping and testing in those prototypes with customers if you didn't understand understand something about the problem you were going to have that you know kind of slap you in the face when you test your approaches to solving it so it's self-correcting and as far as the Optics especially I mean I'm trying to coach you on successfully transforming here you want to make sure that the organization sees you trying out Solutions and coming up with winning Solutions so make sure you budget most of your time for solution Discovery I hope that makes sense to you another thing that's worth pointing out because some people again just get confused not everything we work on has to be a problem to solve normally a product team is assigned one or two problems to solve for a quarter and then they have a whole bunch of little things we called keep the lights on especially if your products in production already these are smaller things that you know a stakeholder needs because they can't even they don't have the reporting they need to run their business so they need us to add something or it could be anything could be a privacy thing we have to do the government's got a new regulation whatever this is called keep the lights on stuff so not everything has to be a problem to solve now if keep lights on stuff takes the majority of the time for the team you're not going to be able to solve the hard problems so we that's something we're looking at do we have the right number of developers on a team for example but remember not everything needs to be a problem to solve and also be you know realize not everything is risky product we like to start by assessing the risk because if you don't really have a good understanding of the risk you're probably going to fail but it's also true not everything is risky some things are literally just sort of no-brainers they're like the the engineer says this is not a problem we do stuff like this every single day the designer is going users aren't even going to see this product manager going there's no viability issue here you just build the damn thing you don't have to prototype it you don't have to go test it you just put it on the backlog and knock it out so and that's important that you do because if you don't do that you won't have time for the real problems which is the where the real Innovation comes from all right yeah I mean I wish I could just find the root of this problem and stamp it out but it's just this has existed forever there are some people out there that like to argue that it's all about the user and all you have to do is make your users happy and everything's going to be wonderful and I wish honestly I wish because that's you know our favorite part about product is coming up with things that customers genuinely love however the hard part about product is usually not that it's coming up with something the customers love and works for your business it's viable it doesn't have to necessarily be profitable in some businesses it does but it usually doesn't but it does have to be viable it has to have a path to profitability it has to uh be reasonable the unit economics have to be reasonable you have to be able to show this is in the right direction there are a lot of great businesses that are not profitable right away so it's not about profitability but it is about viability all right so anybody that tries to tell you just focus on the user and let me just say I can excuse designers that say that because honestly in a lot of the design schools that's kind of the indoctrination going on I can excuse it from a designer their heart is in the right place when I hear a product manager saying that I know if the CEO hears that product manager it's game over usually for that product manager that is that is just a product manager saying Oh Mr Miss CEO I'm clueless about business that's what it's saying don't be that person all right the last one is there's oh there's I actually think this is increasing because of generative AI um and I'll sort of tell you why some people conflate the concept of research with product Discovery Now product Discovery is not research in fact some people like to call it R&D it's not uh R&D by the way is wonderful uh and that's where geni a number of companies I work with they're struggling with Gen because really because the data is not there the data that Powers their models are not there and at that point they're not ready to productize this product they're not ready for product Discovery or product delivery in fact one of the companies it's been going over a year where they're still not ready and I don't even know if that company will solve the research the real research which is in this case data science to get what they need in time if there'll be enough of a company left that's why a lot of times it's the big places that afford the true research and most companies focus on productization which is product Discovery and delivery but I I sort of jumped ahead a little bit there are two forms of research that people confused with product Discovery they're separate but they're both used the term research I've been talking about R&D research in other words the is the engineering ready to be productized now for a lot of things we do the engineering is is definitely ready to be productized uh but there are some things and generative AI is an example where we might be a year out we might be two years out we might we don't know but we want to make we don't want to really we don't want to have a whole product team going until we have something for them to discover and deliver if it's just not there yet it's not ready now the other kind of research is user research uh and there the people people are usually referring to what I described earlier where user researchers are identifying unmet needs and identifying new problems to solve that is first of all that's also awesome we love that love to do that but that is not product Discovery that's an input to the product strategy which is then gives us the problems to solve and product Discovery is not identifying the problem it's identifying the solution so that's big difference so don't confuse Discovery and research uh either form of research and and I know that most of you won't care about this but in a lot of big companies this is actually a very important accounting topic because if product Discovery is actually confused with research it's treated differently than if it's treated which is what it is product development all right and then the last point the last Dimension is product delivery which honestly I can't believe I'm still talking about this should have been nailed 20 years ago it was nailed 20 years ago with good companies but something sort of happened um what this is is small frequent reliable delivery vehicles this is what agile was supposed to be of course many companies this is what agile is uh but if you don't have uncoupled consistent release Vehicles every single week ideally many times a day that's continuous delivery then uh you're not gonna be able to take care of your customers well let me be clear because I want you to get to cicd but realistically I'm talking to those teams that are still releasing quarterly or even monthly you you do not want to try to take care of customers today when you release monthly that is a recipe for unhappy customers and unsuccessful businesses you need to have small frequent reliable release Vehicles so what does that really mean no more fake agile so what happened was the early agile was very I mean they they taught you you release no less than once every two weeks that was basic scrum kban even better more frequently but uh but you know process people kind of took over that and the desire for predictability went out and so you had these crazy complex processes all about predictability quarterly releases that is uh if you're doing that and you want to move to the product model you got to go back to you need to get serious about this and what does that really mean releases no less than every two once every two weeks for each product team and the goal of course is continuous delivery uh and that is each basically each change is its own Atomic release that means we're probably releasing many times a day all right all right we're almost there I just wanted to kind of wrap up I I actually threw a lot at you the high level concepts of changing how you decide which problems to solve changing how you solve those problems and changing how you build test and deploy those Solutions how you deliver those Solutions the main thing I wanted to talk about as we close is that it is not easy but it is also not impossible uh in the new book uh I've got these these logos are basically case studies that are in the book that talk about and and none of them are Silicon Valley companies they are all companies that had to that worked the old way and had to change in order to get the benefits of the product model and they did amazing things and as you well you if you read the book you'll see there's Enterprise SAS there there's medical there's uh one of the companies is from Sai Arabia there there uh lots of one's a 200y old company I mean if you know if you think it's not possible these and these are the real you'll see real names you can look them up on LinkedIn a lot of people have and they have told me they've heard from several people so that is um it is not impossible there are a lot of people that will tell you they don't think it's possible um and you know the truth is it is hard it is hard but I really um the people I know and the people that I spend my time with they want to work they want to do something meaningful they want to really solve problems in a in a way their customers love and work for their business and so and really every good engineer I know wants to do that every good designer I know and definitely this is why people go into product management so that's what um if you do want to work this way I do hope you will at least uh read the book um I actually think it's best now to start with transformed um if you haven't read any of these books I would suggest starting with transformed because it goes through the the fundamentals of the product model and it's written from anyone from an individual contributor engineer all the way to the CEO so it's written for a much broader audience um and uh if you're an engineer or a designer a product manager I hope you like it enough to read inspired which goes into the techniques that we're talking about if you're a product leader I hope you'll read empowered it goes into the techniques for product leaders uh my partner Martina luchenko wrote the book loved which is on product marketing uh especially if you are involved in product marketing um hopefully that will help but um I hope and and if you can't afford the books a lot of the contents is for free on our website and that's the last thing I'll really mention to you svpg domcom we have uh honestly 20 years of content out there help yourself um and uh we hope you know definitely hope you'll read it the other thing I'll mention is um my partner Christian has been doing a podcast which is really aimed at product leaders and product coaches called Product therapy um you might want to check that out and the most important thing the last thing I'll leave you with is if um if you get qu if you have questions or either from my talk here or from next week next month if you start getting interested in this and you don't see where it's talked about um email me and I genuinely appreciate that that's where I get so many of the questions that you saw me or heard me just address uh and you'll also find articles if I find lots of people with a confusion I write an article about it but so I genuinely welcome those questions a lot of times honestly most of the time my reply is a link to an article that that talks about it because you're probably not the first one to ask that question but sometimes you are and I love those actually those are my favorite because then I'm like should I talk about this more generally or should I just answer this for this person and if I don't know the answer those are my really favorite and I have an amazing network of friends uh that I can usually find some pretty good answers to so I realized that was a bit of a long talk uh I hope you found this interesting I hope it addressed some confusions you may have had um and uh yeah I hope you find the time useful and I hope you enjoy the rest of the conference thanks very much this talk was brought to you by user pilot the all-in-one tool for product ux customer success in marketing teams [Music]