An aspect of a Product Manager’s job that’s often not discussed enough is their responsibility to own and manage risk. There are several stages in the product lifecycle where PMs are expected to assess and call out risks — whether it be in regards to scope, timeline, ability to meet KPIs, and just about anything that directly on indirectly impacts the product (including but not limited to current happenings, political climate, etc.). The downsides to failing to manage risk can be substantial — unhappy stakeholders, frustrated customers and likely a stinking reputation as a PM.

Product Risk can fall under two broad categories — strategic and executional. Strategic risk is ensuring that you’re building the right product/features at the right time while building confidence on the product or release’s ability to meet KPIs set by the business & customer (For example, what’s our confidence that this feature will meet the 10% DAU growth KPI set for our product in the next 3 months?). This risk often needs to be owned and accounted for in the formative stages of product/release planning and will likely need the inputs of stakeholders like the executive team, business development and user & market research. Executional risk is assessing potential roadblocks and issues to the operational aspects of product development — such as the design & development timeline, quality (i.e. no high impact bugs) and delivery (for example, releasing a new software version during off-peak hours).

As a PM, here are a few questions & following strategies one could use to identify, assess and potentially mitigate risk to ultimately ensure the launch of a successful product.

1. Have you prioritized the right thing?
   As PMs, prioritizing a roadmap can be particularly challenging and prone to risk because you’re often factoring several things into consideration while trying to gather enough supporting evidence to back your decisions. I’ve discussed ways to prioritize a roadmap in another story, but it’s crucial to make sure you’re prioritizing based on the metrics that align best with the goals of the product, business & executive expectations and what the customer needs the most right now.
2. How new/different is this product for your organization from other products or releases?
   Depending on whether you’re launching a new version of an existing product or a brand new product altogether, your risks could vary significantly. For example, if you’re launching a new feature on a stable, mature product, you probably already have some established baseline data on your users, the tech stack, prior product performance, etc. This is all rich data that you can leverage to make well-informed decisions on whether a brand new feature would work well for your audience and if the KPIs being targeted are realistic. However, if you’re launching a completely new product or say a brand new integration or extension to a product, the risk is definitely higher as existing data may not be a good proxy. If you find yourself in this scenario, consider investing in additional user & market research, looking into secondary data sources, analyzing competition and ultimately relying on your intuition and expertise. This might especially come in handy if you need to convince your executive team if this is new product is/is not a viable idea and why it should/shouldn’t be pursued.
3. How confident are you in the product design?
   It’s a no brainer as to why PMs and designers need to work hand-in-hand while designing new features or improvements. This is to ensure that the team is developing the right UX which tangibly addresses the goals of the product/feature while minimizing design risks. For example, does the choice of a conventional design treatment work against your product because the context is dramatically different? It’s always safer to do adequate user research & testing when there are areas in the design that spark uncertainty in terms of usability or ability to meet goals. As a PM, you want to make sure that you’re building as much confidence into your design before engineers develop & test the feature so as to reduce the likelihood of making changes to the feature once it’s fully developed (or worse, once it’s released)
4. Have you tested enough?
   Of course, quality assurance is a key part of every product development process, but what other testing would you anticipate being missed or additionally necessary to ensure successful delivery? Consider bugs that may be potentially missed or overlooked by your test teams because there hasn’t been enough field testing or longevity testing performed. Some bugs may only surface after continuous use of the product. Some ways to combat this as a PM is to build in adequate alpha & beta testing into your timeline prior to launch. This helps you get your product in front of “real” users and in environments that are very close to what your end-users will be in. Internal tests with employees in your team or organization are a great way to perform early testing because any potential issues remain contained within your organization (and not exposed to the customer) and these tests are relatively cost-effective to run and manage. This may also be a great way to catch any significant issues in the design based on user feedback from a fresh pair of eyes. The downsides to internal testing are that you may be subjected to bias, and your test users may not represent your end users very well. This is where Beta-testing comes in, and these can be administered either through A/B testing or through a limited rollout. PMs should seldom prefer to do a full-blown launch of any new feature or product directly to the customer as even the most well thought out products will have issues that were overlooked, and you definitely don’t want your customers to be the first ones finding them!
5. Am I tracking the right metrics?
   It’s important to identify and align on the right metrics to pursue and monitor early in the cycle. While in some cases these metrics may be obvious based on goals set by the business, more often than not, PMs should own and track metrics to best determine ROI on a release and check-in with key stakeholders to clarify concerns. On the technical side, in order to have data that you can trust, you need to spend time with your analytics team to understand where the data is coming from, how it’s aggregated and how it’s reported. There may be differences in interpretation of data and it’s important to get the teams aligned on what is being tracked and reported well ahead of the release. Moreover, if a new feature brings new metrics with it, you want to make sure you’re testing and verifying these new metrics at least on a sandbox environment before you launch so you know your data is not going to misinform you after launch.
6. Am I creating 2-way doors?
   With any product decision, it’s always best to create 2-way doors — essentially, a “fall back” plan. If you’re releasing a new version of a product, do you have a rollback plan for unforeseen circumstances? Are there any backwards compatibility considerations to make and have you tested them? If a software patch is the only way forward, how difficult and interruptive is it to administer? Even if you have high confidence in your product/features, it’s always good to create two-way doors to make sure in the event of an issue, you have a relatively painless way out.

With every decision a PM makes, there’s inherent risk involved. When in doubt, it’s always a good idea to ask the right questions, get the relevant stakeholders involved and leverage data and insights when you have it to make an informed decision while having a way to go back on something if you absolutely have to.