The Importance of Assessing Technical Risk for Product Manager
Being a Product Manager means you have to make sure that you are managing the risk in building a product. It could be business risk, user risk, market fit risk, or even a technical risk. Some product management books introduce technical feasibility testing to mitigate technical risk when the team is trying to use a new set of technology. This kind of testing is done by creating a simple prototype for proof of concept to make sure that the new technology can fulfill our use cases and to identify the obstacles in using the technology upfront before we go all out in the development process.
Not so long time ago, I made a mistake in one of my project. It was a volunteer project where I had a team of engineers from different backgrounds and companies. We want to create an app that could monitor and notify the user if they’ve ever contact Covid-19 patient in the past 14 days. At the beginning of the project, our engineer discussed how they will design the application. Because it was a non-profit project, we were trying to use as many free solution as possible to create our app. I joined the team after that discussion, so I didn’t know the details of the architecture. I thought that I can catch up later and trusted my engineers for the architecture design.
The nature of volunteer project is that you can decide when you want to contribute and when you want to stop. As time went by, the original volunteers who designed the architecture become inactive, leaving the new engineers to a confusion as there are nobody understand the original design of the software. Our team was unfortunate because we didn’t have an engineering lead PIC for the team. This condition pushed me to step up from just managing the product as a PM to also led the technical team, including making decision for the architecture.
I could understand the big picture of the original architecture and drove the team towards that. We broke the tasks and did the development by features. Then when the time came to integrate all the modules, we found a big problem. Turns out the initial design has an assumption that we didn’t prove first before starting the development. We couldn’t integrate the system unless we use the paid version of the library or we need to change the architecture completely. I was under impression that this design will work even though we use the free version of the service. However, nobody ever really look into it, so we realize it too late in the process and we couldn’t pay for the paid service as well since we don’t have any budget for it. I was speechless that our one month efforts were come to nothing.
From that experience, I learned that as a Product Manager, we have to consider all possible risks, even though it is not our direct responsibility. If only we had tested and confirmed it first, we could go with a better solution from the start. I agree that testing the technical stuff is not really our job as a Product Manager, but we are still responsible to assign someone to assess the risk. In my case, we only discuss the architecture in Slack and nobody actually assessing the risk and feasibility. I should have asked one of the engineer to be responsible for assessing the risk in the design. As the result, the project were failed because the technology actually cannot accommodate their needs and we were too late to realize it after spending a lot of resources for developing the wrong solution.
If I can go back in time, here are the things that I will do differently:
- First, I will ask one person as the PIC to lead the architecture design. All engineers are welcome to give input on the design, but this person will be responsible to decide the final decision.
- After we have the potential design, we will identify the risks that could arise if we use this design. Then we will assign a PIC to assess the risk or build the proof of concept to make sure everything will work.
- If the time and resources allow, we should also create a documentation about the architecture and why we choose this design.
That’s it. Hope you can learn something useful from my experience. 🙂