In the past, I have written what a new software product manager should plan do in the first 30 days on a new job to be successful. If you are planning to start on the right foot at a new job, a key thing you need to understand is constraints. Especially in a startup, during early days when things are move lightening fast, shortcuts are the norm because of constraints. There is not enough money, people and most importantly time. You are trying to put your MVP (minimum viable product) out there, get early success to build upon that there are not enough hours in the day to do things better than you are doing now. 
So if you are a new product manager who walks into such an environment, the last thing you want to do is to start by criticizing how bad things are, how best practices are not being followed etc. Instead, spend the time to understand the reasons why things are the way they are. 9 times out of 10, the folks that have been there are not stupid to have done what they have done. The team will be very appreciative if someone takes the time to appreciate what they have done under the constraints they had. This will help you build the relationships you need to build to be successful in the long run. I am not suggesting that you be disingenuous and praise something when everyone around you knows it is a pile of shiitake.
You have been hired for a reason. It is probably because things have not been rosy and the company needs a direction. But before you start to rock the cart, first find the reason for the current madness.
Another occasion where understanding constraints becomes valuable is when you are making a business case for something. Sell the idea first (before you ask for resources), make sure there is buy-in and then outline the constraints that will need to be resolved if the idea needs to succeed. This could be asking for more people or funding.
Thoughts? Do you agree? What can you share from your experiences?
Image: Courtesy of scmep.org
Software Product Manager by Gopal Shenoy 
The PM has to put forth the effort to understand the constraints and then balance them as needed. In a new environment, the first point is critical – instead of coming into a new team with the “know-it-all” attitude, prescribing a solution right away, a good leader must first understand why things are the way they are. There is always a reason, and in most cases “incompetency” of the team should not be the default assumption; the first step has to be an effort to understand WHY! The new team will appreciate the effort, and be more cooperative as well.
Agree completely, if you want to bring a change you need to be first part of the system. And good way to do is understand and appreciate it. In all practicalilty, you would need the team around to bring about a change, so you first build a good rapport with them.
Their is a lot of truth in this word. As a new product manager in a small company, you will learn, that the road is long and everyday is a day of doubt, is this the right way to do it.
I learnt this right in the first week of joining a new job as a Prdouct Manager. Prior to this occupation I was a core technical architect for a long time and had little to do with Product Management. I applied the principles of the previous organisation & my job role in the new position. Good for me, I realised my mistakes quickly enough and saw the big picture from a different perspective.
Sure there are a few holes in the processes, people and the system as a whole but I am now tryign to solve them gradually and at the same time am able to appreciate the “good things”. I would have lost a lot if I had persisted with finding only the holes. It was not easy to do, especially for a person with many tears of industry experience, but then it has to be done. Very good thought Gopal, and nice of you to have thought of sharing with others. Thanx.
Embracing constraints is one of the best tips I’ve encountered in PM. The problem over time is that it takes incredible, proactive discipline to revisit those regularly and upgrade to the new reality. Failing to do so seems (inevitably?) to lead to debt – technical or otherwise – pain, and reduced velocity.
Agreed and good post on the inherently political nature of PM. It is one thing to know a relative best practice, it is another to understand the reasons why it is not already in place. Simply pointing out problems that may or may not be obvious to people who have been living with them undermines the consensus building that will be needed to make things better. It implies the people who have been working there are less competent or interested in making things better than someone who just walked in and hasn’t yet helped the team solve a problem.