Ep. 5 - Balancing Risk & Innovation

[Music] Welcome to this episode of Product Bits, a sub-20 minute show about product management and building digital products because you don't have the time and I'm lazy. I'm your host, Jordan Wilkerson. In today's episode, we're going to be talking about balancing risk and innovation when building out products. But before we get into some of the more tactical stuff, I was reading some old stuff I had saved and I came across a really interesting article and it's basically a thought process around investment from Mark Anderson who, if you don't know, is one of the original inventors of Netscape and is an OG in the venture capital space in Silicon Valley. His firm A16Z has grown from 300 million in assets under management to over 25 billion since 2009. So keep in mind that when he's talking about risk here, he's talking about overall risk associated with investing in startups as a whole. But you'll hear something in these quotes that I'm going to read to you that should immediately say, "Hey, I have to think about that too in your mind." So here's what he says is his investment framework that he calls his "Union Theory of Risk" and there's 10 layers to this, so let's read through them. So he starts off by saying, "If you're an investor, you look at the risk around an investment as if it's an onion. Just like you peel an onion and remove each layer in turn, risk in a startup investment comes in layers that get reduced one by one. First is found to risk, does the startup have the right founding team? Second is market risk, is there a market for the product of service that the team is building? Third is completion risk. Are there too many other startups already doing this? And is this one differentiated from them and any potential large players in the space? And are there too few companies doing this and if so, why is that? Fourth is timing risk, is it too early or too late? Fifth is financing risk. After we invest in this round, how many additional rounds will be required for this company to become profitable and what will the dollar total be? Sixth is marketing risk. Will this startup be able to cut through the noise? Seventh is distribution risk. Does the startup need certain distribution partners to succeed? Will it be able to get them and if so, how? Eighth is technology risk. Can the product be built or are there fundamental breakters that need to happen in order for it to be built? Ninth product risk. Assuming the product can be built, can this particular team build it? And tenth and finally, hiring risk. What positions does the startup need to hire for in order to execute its plan? And he wraps all of this up by saying, "Take a hard-headed look at each of these risks and any others that are specific to your startup and its category and put yourself in the shoes of an investor. What could or can you do to minimize or eliminate enough of these risks and then do those things?" Now, while this podcast isn't around venture capital and investing and startups per se, it is very much important to know that at the end of the day, product positions typically are heavily aligned with or are they themselves driving the business objectives of a company. So even if you aren't in a startup looking to grow into a public company one day, it's still very much a good exercise to look at these kinds of risks that are laid out here to understand that your products can both have and mitigate a lot of the risks that are described. So the key takeaway here from this quote is that when it comes to outside investment and also internal business direction, risk plays a very heavy role. So regardless of how you think about it or manage it, risk for product managers puts us dead center in their arena of risk management, whether we know it or not. So as PMs, we're often tasked with creating products that are innovative, that push the boundaries, so to speak, and are exciting. But we have to do this while still ensuring that they are also somewhat practical, technically feasible to build and of course financially viable. AKA we have to tread the line between being risk averse for the sake of innovating and being risk conscious to ensure that we don't tank our business. Right. Because make no mistake, innovation and risk are tightly correlated. So in order to understand the relationship between innovation and risk, let's first define what we mean on this show by innovation and risk. So we just heard a few specific risks from the perspective of an outside investor, right. But let's go a little bit more general on on our definitions, much simpler. First innovation, when I reference this term, I mean very simply the introduction of new ideas, new products or new technology that brings value to a particular market that you as a product manager serve. Okay, super simple, probably too fluffy, but that's that's what it is to me. Now risk on the other hand refers to the uncertainty of outcomes and the potential negative consequences of a decision or action. Up to and including the introduction of new ideas, products or technology to the market that you serve. So set another way we as PMs must be aware that there are times where we have to swing for the fences and push something a little crazy. Maybe it's ill-defined, but always risky into our products in the pursuit of significant reward. But understand that that also carries the tremendous risk of failure and conversely playing it super safe and focusing solely on reduction of risk can limit the potential for innovation and therefore limit the potential for growth. So it's critical to know when to swing for the fences, when to just try to get on first base, when to bond and when to not step up to the plate at all. Hopefully that baseball metaphor made sense. So anyway, back to the point, how then do we actually achieve that balance between innovating and risk remediation when building products? Well, there's really two key approaches that are basically saying the same thing, just different ways of thinking about it and different needs within the business in order to make them happen that I would like to talk about. So before I do that, I'm not going to sit here and tell you that the way that I do this will work for you because it's going to be subjective. But I do think that the premise of how you go about getting something like this done can be universally applicable. So the first thing to acknowledge is that in order to effectively prioritize generally, not just talk about like what areas need to be pushed and what areas need to be cleaned up right innovation and risk risk remediation. You have to break your product down by core functions at least first. So you have to be asking like what are the big bedrock things that this particular product does right and that's where I start. So I start there and then I move on to smaller features that enable those core functions right these are the things within those big bedrock components or areas of the platform that you're working on or areas of the product that you're working on whatever. And I map all of these smaller functions to the larger core functions and these I call enablers right now this concept is like a it's called feature mapping it's not rocket science it's literally just spelling out hey if you want to do that. So I'm filling out hey if I were to divide up my product into these like little swim lanes how would I go about doing that and what are all the things that I can do within those swim lanes and those are your enablers. So there's a third level that it's kind of subjective of if it's useful or not. So I take those enabler functions and break those down further into micro functions or interactions like physically like what can you do how do you do it within the product. But this can be a tedious and troublesome approach depending on how many enablers you have in your product right you have a massive product that has thousands of enablers and micro functions and interactions and it's not worth a time all the time to go through those one by one. So at the end of the day once you have this mapped then it's time to start determining okay which of these core features need to be enhanced or what core functions don't I have yet right and need to be built for the first time. These are all typically larger efforts at least initially when you're when you're thinking about them these are those swing for the fence type items especially when you're talking about adding net new capabilities or features. So, when you look at this high level ideas, that to me is where typically you're looking to innovate, right? It's adding new capabilities, it's enhancing existing capabilities. In these specific areas, you start to prioritize innovative ideas. So the next step then is to look at the other areas and the other enablers that aren't impacted by those innovative ideas. And these are the areas in which I start to optimize and prioritize for reduction of risks. And that can be translated in a bunch of different ways, right? That could be just straight up remediation of tech debt as an example. It could be fixing known issues. It could be removal or merging of some troublesome features. It could be building in some smaller features to enable something like regulatory compliance or something, right? It really just depends. So as an oversimplified example of like these two categories of things, let's talk about just a super generic example. Maybe within a given release, I decide that I want to start rolling out an entirely new redesign to the overall user experience in a certain area of my product. But at the same time, I also want to be focusing on prioritizing work to ensure stability of my infrastructure or maybe adding a different deployment capability like being able to deploy this to the cloud or to virtual, let's say, if you're just like an on-prem product or something like that. Right? These are things that a user will notice, but it's not really moving the needle per say. It might open up some additional use cases, right? But it's not something that users are going to just throw money at you for. Right? These are things that need to be done to ensure the health stability of both your product and its contribution to the business. Right? Those kinds of things. Effectively, what we're talking about is you're doing this feature mapping exercise and you're deciding where out of all of these maps do I want to target innovation and where do I want to target risk remediation? And what that tactically translates to on your road map is getting a healthy mix of those big bedrock features or enhancements, smaller, enabler improvements and enhancements, you know, smattering of bug fixes, polish, you know, and non-user-facing work. That balance comes in targeting which of the areas need that heavy innovation versus risk reduction. And determining that balance is going to be based on where your risks and business strategy really start to collide. Right? The severity of which will then determine how much risk you need to address and where. And the counterpoint to that would then be well based on that amount and the severity of those risks that you need to address, how much innovation are you really able to push for within, let's say, a given release? So another way to kind of model this is to approach this problem by structuring your product, offerings themselves like an investment portfolio. Right? You know, the kind of investment portfolio that are totally going to be fine in this recession and definitely not taking large existential hits that you have no control over. Everything's going to be fine. But I digress. When you think about the general advice of how to structure an investment portfolio, the key word that you hear is diversification. And you can do the same for your product lines. So what I mean by this is literally building out your structures, your product specs, your requirements, et cetera, around some common shared criteria that is globally applied across your business. For example, some simple ones would be high risk, high reward efforts versus low risk steady state projects. So notice I didn't correlate any of those categories with time or size, okay, or say things like low hanging fruit. That because that isn't the business that we as pms are supposed to be in. Right? We're not the ones to determine that. So what I mean here is that you're literally qualifying the work that you're putting forward with a specific categorization. So you're literally acknowledging, hey, we can try this, but it might fail. And by doing that, it forces you to determine your success and failure criteria. And then the head you place on that kind of work is by qualifying other work as, hey, we know exactly what this is and how to solve these problems over here. So that if my high innovation that fails, my low risk low innovation project will offset some of that pain, at least in theory, okay? But in order to do something like that, that kind of level of thinking and categorization and structure has to be a part of your overall product strategy. And as we've talked about in past episodes, your product strategy has to be helping you achieve your overall business goals, which of course make up your overall business strategy. And what that means is that you need leadership to be on board and fully vested into balancing high innovation bets versus low risk items in order to determine, you know, what is the actual appetite for either category of work? Because after all, it isn't the sole responsibility of product managers to conduct this delicate dance between risk and innovation. Leadership plays a, it is your job to discover where the value lies in an environment like that. And in either approach we've talked about today, the way to do that is by breaking down your product into these segments for lack of a better term and figuring out how you get a good mix of all of these various categories of work into a cohesive set of features and enhancements that can be built within a given amount of time. Right? Your release should be a healthy blend of all of these things on a regular basis. That's how you deliver value. That's how you push the needle for your business. So you've got to step up as a PM and make that needle move in a direction. Right? And you have to convince others that it's the right thing to do for your customers and for your business, especially now in this insanely risking macro economic environment that we all find ourselves in. But faith favors the bold as they say. So to wrap up today's episode, let's recap the fact that risk taking your risk management is the name of the game when you distill down product development. Taking calculated risks can help you innovate in your space in new and exciting ways, but slow and steady work also can help build up your foundation over time to be able to take risks in the future or eliminate those that may be compounding in the present. It is your objective to help strike that balance in your planning, in your vision, and help influence your company's culture along side your leadership. So the best way to do this in my humble opinion, break down your products. Think about them in chunks that go from very large to medium to small to granular and identify what needs you have, what areas you need to light a fire underneath and which areas need some TLC. So that'll do it for today's episode. I hope you enjoyed it. And if you did, please do me a huge favor and share it with others. I'm looking to continue growing the podcast, but as I'm doing this for free, I could use all the grassroots effort I can get. So again, as always, I appreciate your time. Thank you very much for listening. And until next time, be good to one another. Bye. (upbeat music)