Featured » Product Managers | Practitioners » Confronting (and Embracing) Risk Aversion

Confronting (and Embracing) Risk Aversion

May 3, 2019 Amanda White
“I love what your company is doing, but it would never fly where I work. Our leadership is very risk-averse.” 
 
This is a common concern I hear from visitors, potential clients, and friends who I bombard with lean product management theory over beers on the weekend. There’s something about light documentation, moving fast, and having a flexible roadmap that seems risky to those who are accustomed to more fixed planning and definition in their products. And in dealing with particularly risk-averse stakeholders, you can be met with a wall of resistance when introducing a change of any size. Fortunately, our methods are optimized for high-risk situations! It’s just a matter of how you approach the question of risk. If you are a Product Manager, Client Liaison, or in another stakeholder-facing position, it’s a good idea to strategize about how to address these common concerns. Here are some approaches that I’ve seen work well for getting buy-in from people who are particularly risk-averse.

Embrace Risk Aversion

When somebody says “Our leadership is risk-averse,” I respond, “Good!” Because risk reduction is exactly what our practices (Extreme Programming, User-Centric Design, and Lean Product Management) do. This catching nasty bugs before they escape into the wild, validating that people will actually use what we build, and releasing early and often to test our assumptions and to avoid one common but devastating product risk: software that never gets shipped and just becomes a money hole until it gets axed. Any stakeholder who has faced these issues in the past knows how risky they are and will be thrilled to learn we are here precisely to help with those things.

Listen To Their Concerns

When hearing concerns that come up in the face of agile methods, our natural inclination might be to think, “Same old story… I’ve heard this before… they all say the same thing…” But that’s an assumption that is not serving you or your stakeholder. Yes, there are some common themes around the hesitation to adopt lean practices. But you’re also talking to someone with a wealth of context on the situation, who knows things that you don’t know. They know some nuance of the market, the board of directors, the budget, that isn’t on your radar. That doesn’t mean it’ll ultimately change your approach, but the information might be valuable. Get these risks out in the open so you can mitigate them!
 
Even if their concerns are all things you’ve heard before, it’s critical that you hear them and acknowledge them. Empathy for your stakeholders is as vital as empathy for your users and clients. Listen to their thoughts, explore the reasons behind them, confirm that you’ve understood them correctly, and capture them somewhere before jumping into how you’re going to solve for them.

Call Out the Risk of NOT Doing

Finally and most powerfully, talk about how there are risks on both sides of the decision: the risk of doing the thing, and the risk of not doing the thing. Whatever that thing is— releasing early, trying pair programming, replacing a legacy system— your stakeholder might be weighing the risk of taking action without considering the risk of inaction. Staying where you are seems safe and reliable until you remember that the world around you isn’t staying still itself. Get them brainstorming about what could go wrong if they don’t take the leap and then have an honest conversation about the severity and likelihood of those risks compared to the reverse.
Sometimes you can even quantify what inertia is sacrificing in dollar amounts, which always gets attention. For example: if you’re trying to release a feature that will save a user one hour a week, to 100 users, and each make $50 an hour, you’re leaving $5000 on the table every week you defer. This is your “cost of delay” and it’s a powerful tool for calling attention to risks flying below the radar.
 
Don’t forget that carefully considering risks is a good thing. In fact, when you’re dealing with successful, established enterprises, keep in mind that this quality is probably why the company is still around today. Overcoming resistance to change starts with reframing the risk discussion: getting the risks out in the open so we can mitigate them, showing how our methods are optimized for risk reduction, and discussing how risk cuts both ways. These are conversations you’ll have again and again in your career, so take each opportunity to listen, empathize, and work together with your stakeholders to help them sort through where the biggest risks lie. So that the next time somebody tells you they are risk-averse, you’ll smile and respond, “Good!”

About the Author

Amanda White

Amanda White is a product manager at Pivotal Labs Boston. Her tech career was born out of the need for a website for her Paris-based band in the early aughts, which was realized as a Geocities site that Amanda coded by hand in Microsoft Notepad. (It had frames.) She went on to write a long-lived tech column for Classical Singer Magazine and eventually transitioned out of the music business via a Master’s degree in technical writing from Utah State University. Upon returning to the Boston area (where she had previously lived while earning her Bachelor’s degree in Opera from The Boston Conservatory), Amanda threw herself into the software industry through business analysis and personnel management in the medical, library information science, and hospitality industries. A resident of “Witch City” Salem, Mass., Amanda fronts a rock band, travels obsessively, and still sings the occasional opera in her spare time.

More Content by Amanda White
Previous
Principles of Designing & Developing an API Product [Part 1 of 4]
Principles of Designing & Developing an API Product [Part 1 of 4]

Resourcing & Designing Your API: For product managers, designers, engineers

Next
Practical Advice Regarding Roadmaps
Practical Advice Regarding Roadmaps

Aloka Penmetcha, Director of Product Management, answers frequently asked questions in regards to Roadmaps.

Return to Home