How have you managed risk in a project?

Before we dive deep into a sample answer for this question, let’s take a quick moment to understand certain key points below:

• What is the interviewer’s motive for asking this question? The interviewer is looking to see if you have demonstrated the art of taking calculated risks. You don’t want to come across as a person who is risk-averse or someone who takes risk recklessly.
• Every company and program will involve taking risks to various degrees, which is why this is a frequently asked TPM interview question. And it’s YOUR story based on your experience, so please do prepare and practice it well before your interview.
• For behavioral questions, it is recommended that the answer be in SAR format (Situation for the first couple of minutes, followed by Action for about four minutes, and finally the Result for a couple of minutes).

Example answer:

Situation: One of the biggest risks I have taken was in a recent program, where we developed a new feature based on beta feedback and released the feature externally without QA sign off. We had about ten days from the time we decided to include this new feature to external launch. Usually, the biggest chunk of time in each release cycle was the sign-off from an external QA team. We fast tracked the dev effort and completed the development of the feature in five days. Unfortunately, however, the QA team did not have the bandwidth to run a test pass on the new feature given other priorities within five days before external launch.

Action: Our options came down to launching the feature without external QA sign-off or delaying the P0 feature request from customer feedback. As the TPM of the team, I decided to launch the feature without QA sign off and planned for mitigating the risk:

• I worked with the developers and formulated a combined engineering test strategy and ensured they run all the unit, integration tests and build verification tests, and fix all the issues from these automated tests.
• I organized a bug-bash for all the people on the team for all the days leading up to launch and had the fixes deployed by the on-call developer the same day.
• I worked with the dev team to build a solution for acquiring customer feedback and logs to help debug any problems faced by the users once the feature went live and a roll-back plan for disabling the feature if we found blockers after the release.

Response: The feature was released on the external launch date, much to the delight of the users (and bloggers). We surpassed expectations in terms on how many users were on-boarding to the app due to this P0 feature we released by over 25%. The risk of going ahead with the launch without external QA sign off but with having some guardrails in place really paid off in this case.

Why is the above answer considered good?

1. It gives the interviewer a brief, but clear, background to help understand the context before talking about the risk.
2. Risk and mitigation go hand-in-hand. The answer seamlessly includes the mitigation plan as part of the narrative.
3. The mitigation plan clearly describes what the interviewee has done to mitigate the risk.
4. It includes concrete data to measure the outcome of taking the risk.

Helpful tips

1. Plan, Prepare and Practice: This is one of the best ways to deal with behavioral questions in an interview.
2. Reciting the answers in your head doesn't work - practice talking out aloud in front of a mirror or get your buddies to listen to your answers.
3. Don't get caught up too much in the details - be clear and concise in your answers. A good way to evaluate if you are giving too many details is by doing plenty of mock interviews and getting feedback from the interviewer. And remember, if the interviewer is interested in knowing more about what you are talking, they will probe deeper.
4. Finally, behavioral questions don't have a right or a wrong answer. They are your stories, your experiences - it's your job to convince the interview that you have done your best in the circumstance you experienced!