Product Management Skills - Articulating fitness risks
Fitness risk is the risk of making something that doesn't actually solve the problem effectively for the intended user.
As a product manager, you have to be able to articulate, separate, and define your risks - the potential negative effects of whatever you are trying to do. Articulating them helps you frame and compare them appropriately - ignoring low risks and mitigating higher ones.
These are the levers you use and the plates you balance as a product manager to create and deliver value.
If your solution doesn’t solve the problem, it’s not fit for purpose. You avoid fitness risk by performing validation early and often.
Fitness risk
Fitness risk is the risk that your solution will not actually solve the problem it was built to solve. That is, the solution is not fit for the purpose it was developed.
Suppose you had a problem: users are not referring their friends to the platform.
There’s a huge world of solutions that you could explore and implement. Many sound exciting and seem like they can solve the problem. You spend your time developing one of them, only to see zero effect - users still aren’t referring their friends. After addressing all of the other possible risks and causes, you realize you’ve built a dud that doesn’t actually solve the problem
That’s fitness risk.
An illustrative example
A while ago, a Product Manager, Emily, was working on a B2B enterprise insights dashboard with a bunch of cool reports. The primary users were executives that used the tool to gather rapid insights from a variety of data sources. The users loved the tool - it let them answer questions extremely quickly and present data to stakeholders that helped sell their ideas, secure funding, and reinforce narratives.
Pain heard and listened to
During Emily’s quarterly business reviews with her customers, there was a pain point that was heard over and over: the users wanted to be able to share access to the reports with others, but wanted to limit the visibility and lock down permissions to edit the reports.
Each of the users had a different set of permissions they want to give to govern who could do what on the reports. Some wanted the ability to only view, others wanted edit, but not the ability to share with others, and others wanted absolute full control to do anything they wanted. Nobody would be happy without their special rules.
Permissions, roles, security, data visibility, access control. Emily connected all the dots - this called for an customizable authorization product.
The product was simple on the surface but internally complex. It would give users the full ability and control by letting them create their own roles and define what permissions those roles have. The users could then have the full authority to grant those roles to any user account that was a member of their team. They would fully own the access configuration! It was genius - solving all of the competing desires in one fell swoop.
All that hard work and…
Emily and her team of 6 spent that summer building a dynamic role-permission management system into the reporting product. It was brilliant. It allowed for the creation of roles, the assignment of dozens of granular permissions, and even had an impersonation mode so the user could see what people in that role could see with their own eyes. On top of that, the UX was spotless.
At the launch party, she bought the entire team pizza.
The next week, after the marketing blast, Emily looked at the adoption rate, excited. She was disappointed by what she saw. Nobody was using it.
Strange.
She checked back a week later - still, nobody. A week after that - finally! Two customers had set up a new role and permission. She looked at who and got disappointed - one was just a demo account, and the other was an account manager who had set it up for his client.
A month later, with almost nearly no usage, Emily sunset the feature and called it a loss.
The pain was still there. The solution had allowed that need and pain to be solved. The UX was optimized. The awareness was high. The feature was free of defects. The documentation was clear. What went wrong?
What didn’t fit?
There were quite a few problems, actually.
The solution didn’t fit the mental model. Emily created a feature that was about configuring permissions, roles, and authorizations - concepts that were unrelated to the initial problem and pain of sharing a report. While they can be used to solve the problem, it certainly wasn’t the thing her executive-level users envisioned as they were describing their experience, and it certainly wasn’t in their wheelhouse of familiarity.
The solution didn’t fit the audience. Emily created a tool requiring intimate understanding of roles and permissions to achieve the result for an audience made up of executives. Most executives aren’t IT administrators who are familiar with clicking around in a SaaS configuration page to tailor suit the permission mechanism.
The solution didn’t fit the job being done. Emily’s product was for executives who were using it to rapidly obtain reports. When do executives need to rapidly obtain reports? When they’re in a rush. When are executives in a rush to get data? Stressful times when they’re being put on the spot, like during a board meeting, a presentation to a key client, or an investor call. A busy, stressed, rushed executive was not going to take the time to set up administrative permissions, even if they had full knowledge of how.
The solution didn’t fit the user adoption lifecycle. Emily accidentally created a chicken-and-egg problem. The users, executives, needed to give access to one of their IT members in order to set up access and reports. However, they couldn’t give anyone access unless they set up the permission and role system properly, which is what they wanted their IT person to do. It was a catch-22 - they would never set up those permissions. In fact, the only way that chicken and egg problem was fixed was when the account manager did the work.
While each of these was fixable and addressable over time, these challenges spoke to a fundamental issue with the solution: that it wasn’t fit for the purpose. This fitness risk could have ben addressed before development effort was wasted.
Addressing fitness risk
Emily could have addressed the fitness risk far before the build. She could have taken any number of approaches, all of which involved validating fitness with the smallest possible solution:
A research-based approach. Emily could have drawn some mocks, wireframes, or prototypes and shared it with her users for feedback through user interviews, or user testing tools. Their feedback could have given early signs of being on the wrong track.
A competitor-based approach. Emily could have taken a step back to better understand the problem space of sharing, seeing how competitors and other products solved that problem. She would have likely seen different patterns used and been able to take more into consideration.
An increment-based approach. Emily could have built and released a smaller scoped version of the product she built, such as something that only gave view access without the ability to configure it. Feedback and analytics from that increment could have quickly revealed fitness risk with limited development cost.
A sense-based approach. Emily could have thought through the problem more deeply, considering the needs of her audience, matching them with a deep understanding of her users and their jobs and context, thinking through how it would be used and set up from the ground up. This thinking could have afforded opportunities to realize the pitfalls of her solution before she had her team develop it.
The key to these is that they are minimal-to-low investments to get something in front of the user that helps get feedback early, before you invest significant effort from your development team in going down the wrong path. Whether that’s a paper prototype, a working increment, or a detailed thought experiment backed by deep thinking and understanding - all of these are cheaper than building the wrong thing.
To use the example above, an alternative solution with better fit might have been a report-specific link share option that allowed whoever had the link to view or edit the report for a specific amount of time. It likely would have required significantly less development, and fit the need of a rapid way to share reports on the fly.
Validation comes in many different forms and different approaches can give you different levels of confidence you’re headed in the right direction. What level of confidence is appropriate or not depends on the context. Early validation helps mitigate fitness risk by giving you confidence you’re building the right thing.