Hi, my name is Lucy Huang, and I'm a Product Manager at FullStory.

I've spent a lot of my career thinking about all the things that can go wrong. I currently work in the trust and privacy space.

I've also worked in an incubator, where I tested out new product ideas every single quarter, trying to find product market fit. And that's why I'm here today, to talk to you about de-risking your product ideas. And I'll also be sharing strategies and tactics to get to delivery faster.

The consequences of not addressing risk

First, let's define risk. Specifically today, I'm going to be talking about how you can de-risk that time spent to do discovery around a problem, and also how to do discovery around a solution so that you can get to delivery faster.

We're going to figure out how can we make sure that we’re addressing that problem, addressing the problem at the right time, at the right place, and for the right person.

But first off, what are the consequences of not addressing that risk?

Well, first off, it can be a cost to your business, including head counts and your budget. It can also be a cost to your competitors. Where are you going to be losing to them or lagging behind?

It's also important to take timeliness into account in this economy, and make sure that you're advocating for the time and resources to be able to do discovery properly. That way, you don't jump into the solution too fast.

But before you go looking for too much risk, it's important to understand that as humans we probably look for problems too much rather than preventing the problem in the first place.

Do you have trouble remembering what you did last week or last month and what your accomplishments were? That's because as humans, we’re naturally inclined to shift our focus to the next problem. And it's hard to pause and remember all the accomplishments that we've actually done because often our job as product people is to move forward and unblock or execute whatever our team needs to be done.

And that's why there's often this issue of a preventable problem paradox, where that problem prevention doesn't feel very visible and it feels boring.

In contrast, problem-solving's very visible. You're critical to your organization. You're the savior, you're the hero. But that's not sustainable in the long term, and that's why as an organization, you need to foster that culture of problem prevention.

It's really important to develop a consistent culture of problem prevention before you go looking for too much risk and all the things that can go wrong.

Top frameworks for risk

Next, I'll jump into frameworks for risk, understanding what types of risk need to be addressed and when, and who the directly responsible individuals are for owning the outcome of those risks.

The SVPG principles of risk

Silicon Valley Product Group’s/Marty Cagan’s principles of risks are classics for a reason. And to effectively execute on addressing these risks, you also need to address some of them early on, especially that business and value risk to make sure that you're setting your teams to work on the right items.

You'll also need to recognise owners and assign those directly responsible individuals to make sure that you're owning those outcomes.

It's also important that you work collaboratively. What I've seen a lot in my time is that you often have product and user experience folks owning that usability and value risk. And by the time it makes it down to engineering, you realize that this isn't actually possible. So that's why you should be working collaboratively as much as possible, rather than that waterfall mode.

So we'll go through each of these risks:

Value: Will your customers buy it or will people choose to use it? That's going to be something that's owned by you, the product manager.

Usability: Can your users figure out how to use it? Can they figure out how to navigate it? That's going to be owned by your design or user experience folks.

Feasibility: Is it possible to build this with the times, tools, and technologies? This is going to be owned by your engineering team.

Business viability: Is this going to work for the other various aspects of your business? Is it a compliant solution in the first place? Should you be focusing on this item to open one revenue stream, when you could actually be focusing on unlocking two to three revenue streams with one initiative? It's really important to make sure that you're addressing these.

How to prioritize risks

Now that you've figured out the different types of risk, it's also important to prioritize your risks. I have these 2x2 matrices below. I love these; they’re a really great way to frame things.

So we have two scales, your critical and non critical. So this is basically figuring out how important that risk is and how critical or non critical it is.

Then we also have known and unknown risks, figuring out how much information you have about the risk. So we'll walk through the quadrants here.

First, that evaluate portion. This is something that's important and unknown. So you're not ready to continue here without more information, and you probably need to consult some domain experts.

For your unknown and non critical portions, that's where you need to do generative research. This is something that I always advocate for as a consistent practice in product organizations.