[ad_1]
Risk is not something to fear and avoid. Understand it and use it.
“What’s the risk?” I asked. Silence.
Then…. “errr, well, it could cause users to have to do these three things instead of these four things.” the engineer responded.
“Ok, how much more time-consuming would that be, if it were to occur?”.
“Maybe a couple of clicks”.
“Do we feel the value of the feature is outweighed by that risk or is the risk one worth taking?”….
“Walking it through I think it’s a risk we would want to take”.
Ever had this before? where a risk is presented as simple thing to avoid? but it turns out you should just accept it?
I’ve had variants of this conversation many times. Not just with engineers, with stakeholder groups, functional specialists, leadership members, the lot. The reason for that is many people don’t really think through risk with the right mindset.
Risk is presented as a simple binary thing; all risks must be avoided, none are worth taking.
Risk is a dangerous beast whose wicked maw we must escape.
But actually, Avoiding a risk is just one approach, and often not the best one.
Why? because avoiding a risk typically incurs greater effort in design, strategy, and build than either mitigating through some other approach which Reduces the risk’s likelihood/consequence, or, that rarely seen thing we should embrace: Accepting the risk (i.e. do nothing about it). Then there’s the even more rarely chosen option: Transferring the risk.
Avoidance of risk is legitimate, but too often it’s the go-to.
You’ve got to be alert to engineers and stakeholders defaulting to this approach.
Frequently the problem is that people overblow risks. They do this because rarely does anyone have complete visibility of the risk profile, in relation to the work being done, value being delivered, or outcome being strived for.
And in the absence of those things, risk is just conceptual, unbounded by reality.
Where the meaning is defined or understood, and carries a legitimate threat that would seriously hinder Usability, Viability or Feasibility, you may want to Avoid that risk.
For instance, say you have a third party system dependency on a product which is going to be retired in the next 4 weeks, and that dependency means your system can no longer send notification emails, which are going out at a rate of 100,000 per day, bringing in 5,000 users to interact with your system each day; that would be a threat to the continued Viability of at least part of your product, and would likely have a cash impact.
That’s where Avoidance is reasonable. So what could you do that truly Avoids that risk? you could find another vendor that offers a similar or the same product, or you could invest in building your own notification system using open source code, there’s a myriad of options, but in each case you’d be looking for one which takes the risk to zero impact. Taking it to zero likelihood will take time, because you will have to setup those other options before you can proceed, so by choosing one of those routes, it is not zero likelihood of the risk manifesting, until the alternative path is usable — i.e. vendor is up and running, tool setup done, code deployed etc.
In most instances, you will be Reducing risk. The important thing with this approach is a similar echoed learning from Avoidance; you must ensure proportionality to the risk being mitigated/reduced.
So if there’s a shortcoming in your design which could reduce conversion rate, is that shortcoming going to cost 10%, 1%, or 0.00001% ? there are ways to test for this (e.g. A/B testing or assumption testing), and getting a better picture may help to inform the decision about what to do with the risk.
Once you know the forecast impact, and the likelihood of that happening, you can determine more readily what level of investment in mitigating that risk is right. Is it worth an extra 3 weeks of design? an extra 5 days of build effort across 3 engineers? or just a few hours of someone’s time?
I’m on the high-risk appetite end of the spectrum, all organisations and individuals have their own level, which varies from time to time. I will frequently be in the space of encouraging people to accept a risk, if I’ve determined it is unlikely to cause significant harm if the risk materialises. (ps. try to be aware of your own and your org’s risk appetite).
This is an underused approach. Many risks are simply not worth trying to stop.
They may not ever occur. They may not be as impactful or consequential as feared. So a fair route to take is to reflect on those two things and simply Accept these risks and deal with the consequences.
Now, if the risk materialises, and the consequence is significant enough to cause harm, then you want to reflect on that and why the assessment of what to do with the risk was wrong; is there a consistent under-valuing bias slipping into your or the team’s forecasts? There’s a science to this, which is why in supply chains you will find Demand Planners who adjust for systemic forecast bias in their models, and have complex tools to support this.
A lot of people don’t like this kind of crystal ball predictive stuff in the product space, but the reality is — if you don’t do this for things like risk, you’re going to be expending a lot of effort on Avoiding and Reducing every risk you encounter. So you should get the crystal ball out and make a prediction, then use reflection to clear that ball of it’s fog.
A tool few people think of is to transfer risks, AKA passing the buck.
But it’s a valid method and common in some industries. For instance, say you’re in insurance — a place where risk understanding is a central tenet. Well, in this context, people Transfer or shift insurance risks all the time, for instance through hedging strategies and shared liabilities. Consider that companies in the insurance business that don’t do this would go out of business quickly; i.e. risk transference works.
Debtor and creditor situations are the same — if I have a heap of unpaid debt, and there’s a risk of not recouping it, I might transfer that risk at a cost to a debt collection agency. The cost to me? well I will only be paid a certain, reduced amount for that debt than it’s actual total value. That differential is proportionate to [their understanding of the risk profile] + some profit; they know they’ll recoup not 100% of the debt, maybe 60%. So they’ll pay to 60% value minus an amount which becomes profit.
In the product context, there are many places where this can crop up.
For instance, imagine you’re on a many-facted platform, representing one product team/tribe.
Perhaps the team have three results they’re considering for the coming quarter, one of which is Customer Acquisition, a repeating OKR for that area.
But you identify that in your team your ability to impact Customer Acquisition is low for the coming period, because of the recent loss of design expertise and a new starter in that space. So you have a risk, with a high chance of materialising.
Perhaps it’s legitimate in this model to reduce overall company and product risk by asking if another team can focus on that goal? the risk you have transferred might have a significantly lower likelihood in that new team than in yours, with their capacity. Capacity and resource are a common theme to consider in this model.
If you are a budding or current Product Manager, the place where you should apply this in practise is in your Roadmapping/Quarterly planning process, be that OKR driven or something else.
The Vision too may benefit from an analysis of risks in the market space in which you are operating.
Think carefully about risk options and approaches in managing large releases, e.g. the increments to a Product version from 1 to 2 to 3 etc. Point releases should be lower risk overall and may need this approach less.
As you move up the chain of product leadership, an awareness of these methods becomes all the more important. If you are blessed by Project support then these pieces are their bread-and-butter, but even if you aren’t, you can take and use the above methods yourself.
The best product leaders are capable project managers, capable business partners, powerful negotiators and communicators. Don’t underplay the role of the project discipline in the craft, and use risk as one of the tools to beat your market competition.
Stakeholder Management: https://productcoalition.com/how-to-manage-stakeholders-six-effective-tips-for-product-people-e33df2f1dd75
Dependencies: https://bootcamp.uxdesign.cc/project-skills-for-product-folk-killing-dependencies-9ae7513b36
Biases and jedi mind tricks for product: https://medium.com/@caspar.mahoney/biases-and-jedi-mind-tricks-for-product-people-406c5b36bd73
[ad_2]
Source link
