What do you do when things go south?

We were recently pitching a US based prospective customer. The client was looking for a long term technology partner to rebuild their entire web platform. The entire process of discussions itself took about 2-3 weeks and was one of the most thorough processes we as a company have been through. I personally loved every minute of it.

During one of the crucial discussions the Product leader from the client side asked us a question, a question that I feel we could have given a much better response to; a question that is a curveball unless you have answered it before. As some of you might have guessed it by now, the question is the title of this article.

The product leader asked something along the lines of (and I am para-phrasing here):

A reason why I/you i.e. product owners have a job is because things go wrong all the time, so what do you do when that happens?

This question is simple in formulation but a tough one to crack, a very defensive response would be to say we take care of things so that they don't go bad.

To answer a question like this one first needs to admit that things will go wrong (murphy's law) and then realize that a cookie cutter answer doesn't exist because every situation is different, has context, this question is a subtle invite to a case study where you talk about how things went wrong with a project and what did you to do bring it back on track.

That being said, there are always tactics that help when things go wrong. Not all are applicable in every situation of course but generally these are some principles - some learned, some borrowed and some inferred - that I and my team uses on a regular basis when things go south:

1. Admit there is a problem or you can feel one coming. Human intuition is not that bad, as a product owner it is part of your job role to anticipate problems to a certain degree.
2. Make an inventory list of all things that are wrong, leave nothing out, don't discuss solutions yet. Just must a list and then of course do the following to this list: a) Discover dependencies between the issues b) Prioritize. Make sure the key business stake owners are in sync with your list and the prioritization thereafter.
3. Pick 3-5 items at the top of the pile. Don't overwhelm yourself here. The intent is to do first-aid, let cooler tempers prevail and then re-asses.
4. Identify the root causes of the issues. Causes from my experience fall under two categories: a) People b) Process
5. If it is people problems, depersonalize the mistakes. It is difficult to way "You didn't think of this..." as compared to "Why didn't we do this in the first place...." . It is a common mistake that I have seen leaders make, in trying to be non-offensive or not put people on the spot but it doesn't work very well. My next point will illustrate why.
6. If it is a person related problem it could again fall into certain categories: a) One-time issue b) Frequent issue c) Process issue - wherein the person wasn't clear on the process/expectations.
7. If it is a frequent issue with no relation to process or communication you have to reconsider the role of the person in the team, either let them off the project or add buffer and reviews to their deliverables. Second option is only sustainable if you can expect improvement over a period of time - it doesn't work very well for certain behaviour changes such as timeliness as these behaviours are much harder to change.
8. Process issues can require extra man-power, increase dependencies between people or require setup upgrades. Do this with a balanced judgement, be in touch with your reality.

Of course there are a lot of particulars I can go into and come up with more nuances but the above principles are definitely key ones to start with. In the end, the client decided to go with somebody else but I'm glad that we were a part of the process and if nothing else it gave me the opportunity to formulate these unsaid principles for crisis management for my team :)

Do let me know if I missed something major in the comment or over DM!

#projectmanagement #product #startups #murphyslaw #scrum #agile