Risk Categories in Product Management

A checklist for assessing risk in B2B Saas discovery process.

When exploring the solution space as a product manager, there are multiple inputs to consider. Decisions are made while balancing confidence, risk, and impact. Let’s explore a few risks I’ve experienced in the B2B Saas world which might send your team scrambling or otherwise hinder adoption or usage of your next amazing app improvement.

Change Management

Change management is a unique challenge in the B2B world — you often have competing priorities among the people who give you money and the people who rely on or use your software. Those money-managing stakeholders’ interest can and do collide with the interests or day to day usage of those end-users who don’t have the autonomy of deciding which software to use.

When a change is introduced, often it’s essential to not only be optimizing for improving the end-user experience, but to also keep stakeholders happy, feeling empowered and in control. After all, it’s your stakeholders whose neck is on the line if your software falls short. Here’s some to think about:

How will your customers’ business processes change?

Business process can mean a lot of things — some organizations feel the need to update very detailed training documentation, others might need to get sign-off if new decision makers are introduced. If coordination or documentation within your customers’ organizations is required, you might consider a beta program, pre-release sign-up, early adopters, or sandbox environment. Using some version of feature flags (or environments) to control roll-out as your customers’ are ready is essential.

Will data changes affect existing reporting pipelines?

Data integrity is increasingly becoming an essential consideration. It’s super common to have business metrics be measured within or usage of a certain software. Every B2B company I’ve worked for has customer organizations with data pipelines into a local data warehouse feeding key business stakeholders. When software data structures change, these pipelines need to be updated — which means additional time and money for your customer. Baking this update into a feature release helps with adoption of key data-consuming or producing features.

Is set-up or configuration required to start using the feature?

Sometimes set-up or configuration is desirable —highly configurable software comes to mind. In these cases, having detailed documentation AND examples of why certain set-ups are desirable can help with adoption. Activities like webinars, recorded demos, or

Any training or documentation update needed?

As a product designer and researcher in a previous life, this question hurts me. We should be releasing software which is intuitive, discoverable, and usable, right? Right?!? Alas, there are certain industries that will always insist on the requirement to update their local documentation. Even if I disagree with the concept, I acknowledge that not taking this into account causes anxiety and strains customer relationships.

Engineering Complexity

How familiar is your teams’ knowledge of code base or language?

I came to my current role of leading a product line about 7 months ago. At that time, there was probably 50% of the code base which not a single person on our team was familiar with. That includes designer and product! More than once what we thought was an easy quick win turned into a can of worms. This isn’t anything new, though it is a risk we can mitigate. It might be a part of the code base your team’s unfamiliar with or a value prop or business processes you yourself are new to. Take the time to spike before diving in — and more importantly, uncover why previous, equally smart, team members didn’t do what you are about to do.

Do you have test cases in place?

It’s a thing — a lot of software wasn’t initially built with automated testing. If that’s the case, think about adding it before adding new features.

Business Direction

Will this feature cause an increase in your target market?

Competing in multiple markets before being established increases pressure across the organization. For product: designing for use cases which often compete. For sales: uncovering and refining sales pitches. For CS: discovering and documenting implementation best practices. Sometimes this is the right decision, but we should be deliberate about the impact and get buy-in across the board.

Does it undermine your value propositions?

Some feature requests coming from customers’ or sales will win you short-term sales, but can pull the rug from under your feet of existing or future sales. Let’s take a hypothetical Product Line C which is very often an up-sell to existing customers using Product A or B. One thing that makes C stand apart from competitors is the holistic, integrated suite with A and B— something not a single competitor offers. From time to time, a new feature requests comes in during a customer call or a request from sales asking if C could integrate with a competitor to Product Line A. While these integrations could win a few short-term sales, it would drastically reduce the possibility of selling the whole product suite.

Long Term Cost

Are scaling costs known and accounted for?

This might be performance as many more users start logging in or many more database entries are created, accessed, and updated. In any way, if you’re not considering growth that appears to be coming, you’re setting yourself up for refactoring. Quick and dirty code delivering a feature to gauge usage and adoption is great. Not stabilizing those features after learning will cause often cause pain in the future.

Are infrastructure costs increased (or decreased)?

Infrastructure costs can add up, especially if not being optimized. Again, this doesn’t mean don’t introduce that new file upload feature, but be aware of the financial implications for the business’ bottom line when weighing whether it’s something to invest in.

Are new library(s) fully supported with good community resources?

There’s a similar design risk described below. Good engineering managers will know when using new libraries will be introducing committed future work. Listen to them and plan for it.

Design Complexity

This might be the hardest risk category to wrap one’s head around. For any given outcome, there are at least 10 viable solutions with differing pros and cons — there is very rarely one. best. solution. Design complexity is often one of those overlooked pros/cons in teams which are feature-driven rather than outcome-driven. This makes sense — if what your team is delivering is a feature, there’s only one way to deliver it.

“Here’s this additional dropdown option, boss.”

As a PM, help re-orienting your team to outcomes. When you define are exploring all the different ways you can deliver a specific value, it’s quickly apparent that some solutions are more elegant than others. Trust your designers.

Are you adopting an existing design component for a new mental model?

An example: adding a simple plus icon at the top of a page. Ask one user and this icon means they can add it to a collection. Ask another user and they’ll guess that it’ll create a new object. Ask another user and they’ll say it’s modifying the current page they’re on. Not only is the icon ambiguous, this real life example was exasperated when the same icon was used for all these actions, just in different places, making the app hard to learn.

Easiest way to assess this risk? Take a static screenshot and simply ask someone who’s never seen the page,

“Can you describe what you can do here? What are we looking at?”

Sometimes using existing tech is the easiest way to test out ideas. This risk is mainly to highlight that it could introduce poorer usability for both parties when neither is optimized for.

One more example which is a bit more complex: I worked alongside a fabulous PM where we were given a customer feature request to create a WYSIWYG email campaign editor, think Mailchimp but as a feature instead of service. Long story short, link tracking is where we ended up through our discovery process. We already had a way to copy and send a link to a page, though through user testing we discovered the two audiences (end users and stakeholders) would be using this same feature in very different ways with different underlying assumptions. End users would often be sharing with their friends in a social context while stakeholders would be using the feature in promotional means. Sharing versus Promoting are two different mental models which might use the same underlying tech to accomplish, but are optimized with different verbiage, interaction, and feature sets.

Is this a new UI component which does the same thing as an existing component?

This is the quintessential design debt which we’ve all had — we’re updating design libraries and didn’t get through one update before we start the next. Now we have 5 different ‘plus’ icons being used throughout the app.

Wrap Up

Seeing risk isn’t a red flag to not test an idea out or deliver a new feature. Identifying what risks and unknowns you’re taking is a way to increase confidence you’ll be delivering more value than cost for your team and business and get ahead of those costs when they do arise.