Jobs of a PM
Thanks a lot for the suggestions and comments on the last post. Have been stuck with some personal work and bad health and hence the delay in posting. Also have been reading a lot of posts on Steve (including Fake Steve Jobs) while recuperating.
I personally LOVE the mac (having had the chance to work on one for about a fortnight) and have decided my next machine would be one. The title (as you can see) is an intentional take on the i of Apple inc.
There are several aspects to the PM function which are not clearly laid out. One learns it “on the job”. I am addressing a few of those below
- Responsibility without authority
An essential attribute of a PM is leadership. In most cases, PMs deal with teams which do not directly report to them. He has to –
a) Convince the team of the product idea
b) Get a buy in and commitment from the team for its implementation
c) Work with the team to set deadlines and adhere to the overall timelines
d) Do the overall monitoring and check on quality
Most of the above steps require lots of interaction, brainstorming & feedback from development and testing. They however report into their own structures and interact with PM only as a part of the project. Hence the PM needs to convince the team and not delegate / order. He does this by –
- customer need
- knowledge of competition – to name only a few
Development and Testing usually hate nothing more than decisions that are not well thought out. The points above compel a good PM to structure his thoughts and build consensus on his decisions.
- The customer is always correct – really?
I had once heard Steve Jobs say that he doesn’t talk to users before and during the development of a product. But does he design good products? – Hell yeah!. Here’s what he said about the case when there are too many stakeholders to hear to –
“Here’s what you see at a lot of companies; you know how you see a show car and it’s really cool, and then four years later you see the production car, and it sucks? And you go, What happened? They had it! They had it in the palm of their hands! They grabbed defeat from the jaws of victory!
“What happened was, the designers came up with this really great idea. Then they take it to the engineers, and the engineers go, ‘Nah, we can’t do that. That’s impossible,’ And so it gets a lot worse. Then they take it to the manufacturing people, and they go, ‘We can’t build that!’ And it gets a lot worse”
In most cases, user studies are helpful – to know the pulse – but taking whatever one hears at face value is a very dangerous thing to do. A user only should give an idea of what is needed – not tell you what to do. People dont necessarily know what they are asking for before its even designed. You are the smart guy who is there to design. Listen to the user – but don’t *obey* all he says (use your brains – thats what you are paid for :)).
- Are more features better?
One of my presumptions regarding PM was that PMs design features. That’s correct (partly). Designing features, thinking through scenarios, fleshing to the tiniest details are all parts of a good PM’s job. However, like the proverbial too many cooks, too many features DO manage to spoil the product.
- There aint no thing as a perfect PM mate
To quote an article about Steve Jobs (again) – “But Jobs doesn’t care just about winning. He’s willing to lose. He has done it often enough. He’s just not willing to be lame, and that may, increasingly, be the winning approach”. All PMs make mistakes – thats assured. I am sure Steve threw hundreds of designs for the iPod before he even started thinking seriously about one. Everyone in other teams works with their own constraints (“I dont have another developer – this would be late”. “Dude we cant release this without testing this for 2 years – Vista Test Manager”). The PM therefore has the opportunity (good or bad) to think from scratch (Blue Sky thinking as they call it at MS). You don’t need to be perfect – just smart.
- The buck stops here
PMs are (literally) hammered on all sides. On the one side, there is the pressure of designing products within timelines and resources available. On the other are the functions of upper management and marketing. Good PMs I have seen, usually balance the two. And in most cases they do it by “The buck stops here” rule.
I own this product and I will decide what goes into it. If I take in a feature, I will explain why this was needed. If I don’t take in a feature, I will explain why it wasn’t a good idea. In short, I make the decisions.
You can see how many “I”s were there in the last segment. That was deliberate. Owning a product literally means full and total ownership. I realise this may not be possible in some cases like –
a) Seniority (or the lack of it)
b) Meddlesome and Micromanaging bosses
c) Hyperactive marketing teams
d) Highly “customer focussed” management
Be the owner and the single point of contact. Own it. Don’t be this
Some more stuff on Apple – here
My next post would be on –
Challenges Product Managers in India face
Do let me know how to make posts better and your feedback in case you do not agree to any of the above.