Owning the Problem and the Decision you didn’t make- as a Product Manager

This post is mostly relevant for larger big tech companies with products that spawn years / decades and have a rich legacy. Eg: Think Apple App store, think Amazon cart

Whenever you join one of these larger companies you end up owning a piece of product that has been owned by many PMs in the past and has undergone many iterations, decisions, and designs that have either not been documented or were documented but are kind of lost.

One issue that happens with a lot of New PMs is that they get overwhelmed and start “defending” themselves and “deflecting” the blame to their predecessors whenever asked about certain specific decisions. This would happen typically when another team wants to do some changes and wants your opinion on your part the product, or when a customer escalates and you are looped in .

Some statements you would hear:
-I have no clue why this was done, I would not have done that.
-This is ridiculous and makes no sense. Lets remove it
-Whats my take on this? I have none, this was before my time and i dont care if you want to remove it

The problem with this approach is that , for good or for worse , you now OWN THAT DECISION .
But how do you OWN a decision you didnt make , and that my friend is a great question . Here is the strategy

1. You did not make that decision and thats ok: This is something that is clear to everyone. You do not need to know the answer for everything. You also need to internalize this, if someone thinks this design makes no sense its not a comment on you, its just a comment. Your job is what now
2. Figure out : Take a pause and figure out WHY that decision was taken and what are the repercussions. Seems pretty commonsensicle but a lot of new PMs attempt to jump straight to having a POV.
   Some things to check
   
   Legal / policy concerns?: Maybe there was a specific legal ask at that point in time? Maybe its still there. A lot of decisions are sometimes reactionary to the guidelines by various government agencies
   
   Eng concerns : Maybe the systems at that point were not sophisticated enough? Eg: It makes sense to show your scheduled uber rides on the home page, but when it was built it was not big enough use case to make that additional API call to a different system?
   
   Just the best idea at that time : Sometimes the team at that time did the best that was possible. It was a judgement call
   
   Specific market conditions? You would be surprised at how many features get built to address specific market needs which end up being temporary but the feature never get deprecated.
   Maybe your predecessor built this in reaction to a very big partner and that specific design eventually became the generic standard?
   
   USAGE USAGE USAGE : How many users really use it? It has surprised me multiple times at how many tiny features here and there are not being actively looked at. They are being monitored ie if it goes down some eng team will know and fix it , but no ones really checking much.
   
   Tangentially its also possible that the internal analytics systems have been updated and that specific feature is not even being measured . Large companies also have strict data retention policies which mean a lot of historical data is just not there . I have built new features basing my hypothesis on as little as 30 days of data , sometimes no data at all. Gut based calls
3. Your POV
   Now the FUN part . Have answers to these
   – Do you agree with what you saw?
   – What happens if you remove it
   – Has something else been built that can replace this older functionality ( It very frequently is)
   -If it was to address a need, is that still true?
   – What next: I have deprecated features, and sometimes doubled down because we found a gem due to these explorations. In the end you need to finally have a POV.

If you want to be seen as the owner of that product area, it comes with taking ownership of all the decisions of the past, good, bad and the stupid