(thanks to http://www.usfbap.org/ for the image)

Recently, I came to know about someone who wanted to move to a Product Management role. She had been wanting to do that for years, but not been able to. She got in touch with an experience product manager and asked him for guidance. They worked together to create a five month plan.  She followed the plan and the fifth month – “magic happens” – she gets a Product Manager role in an organization which she wanted to join.

This, I think, is no big deal if you have got a good set of mentors and are willing to go an extra mile whenever needed

Easiest is to reach out to senior folks in your Organization, College Alumni, ex-colleagues / family etc. to find mentors.  But do keep in mind that you need to respect their time as well.

All the best, Happy mentee-ing :) !

Its tough.

But there are quite a few things which can help you sail through:

1. Build Trust  - this is the MOST IMPORTANT thing.
2. Make yourself available as much as you can – over IM / email / Phone.  Let your colleagues know that they can call you anytime, so that they get a feeling that you are just a phone call / ping away.
3. Visit frequently and utilize it in relationship building, making folks comfortable.  Go for coffees, lunches, dinners with key people  every single day when you are at the office site. 
4. Manage your emotions – phone audio and emails do not convey the body language / tone of the conversation very well.  You can easily upset your counterparts and vice-versa. Learn to manage that – be extra cautious.
5. Find a way to whiteboard remotely - 
   1. My method was to have lots of re-usable diagrams already prepared which I could use while talking to different people. This became easy with the help of google docs – drawings. All my drawings were on Google docs and I could just send across a link for the other person to open and see. AND you could actually edit the diagram  / highlight  / color it in real-time while explaining it over phone.
   2. A whiteboard type setup – Wacom tablet for drawing on Microsoft OneNote with a screen share. This is the one I have.  It worked wonders. I could always open up OneNote and start drawing what I am thinking in the middle of a discussion.
6. Faster turnaround on emails  - make folks comfortable. Decide your own turnaround. Mine was max 1 day. In special cases – 2 days.

Would love to hear your thoughts too , share them in the comments section below.

And later regretted that!  I don’t want the same to happen to you.

Few instances where I screwed up: 1) Publishing the notes / minutes of a meeting where a wireframe was discussed and approved by the consumers. 2) Discussed a small requirement with the engg team but did not put that into the  PRD. 3) Discussed, a success / release criteria but did not put that in the plan.

When you put things down on paper / email -

1. The communication/ message gets a date to it.
2. The written message becomes an evidence of a communication that happened.

This :

1. Drives clarity and forces people to come onto the same page if they are not w.r.t a decision / process.
2. Clearly calls out the people responsible  for any action items and the expected timelines. (at least a good note does that)
3. Also, clearly admits any open items.

This is a BIG DEAL  for organizations / people who deal with a lot of people./ or with people who tend to forget things.

I think more than knowing when you should speak up and how you should articulate, whats important is to understand when you should NOT say anything.  When you should just be a listener, observer.

There are plenty of instances where I thought, I had something I could share. A piece of advice, some feedback, my personal opinion / comment etc. But I stayed quiet and that was much better for all the parties involved.

Few Examples

These are only a few examples, but in general – I have realized that staying quiet is more important a skill than many other rock star competencies one may have.

For the rest of the article, I am just going to express some of my thoughts on this subject which may or may not be coherent.

Lets first understand why email ? 

So that we can communicate. When we don’t need the addressee to respond immediately. When we don’t want to (or  not in a situation to ) give the addressee a phone call or use instant messaging or talk face to face.  Also, when we want a communication recorded in writing. Or save a bit of time so that you don’t have to walk up  / call a person ?

Is that it ? Dear reader, please help me get more. If you have other thoughts in mind – jump to the comments section right away and share your thoughts.

Ok, now lets look at the limitations of an email - 

1. Emails cant carry your facial and voice expressions.
2. Emails do not give the other person a chance to clarify immediately and fix the confusion / mis-conception / doubt right away.  Once sent, the damage is done.
3. Emails get recorded. You ll be shown your stinker email at the time of your appraisal.
4. Human mind tends to read a slightly positive and slightly negative message as only negative (or worse highly negative)

Thats all I had. Also, here is an interesting perspective.

Please do help me out with your comments.

This is the first book which focuses on new and aspiring managers in India in the knowledge industry.  I was one of the reviewers and thoroughly enjoyed reading and reviewing the book.

Highly Recommend -

Packt Publishing:
http://www.packtpub.com/information-technology-management-in-india/book

Amazon link:

http://www.amazon.com/Management-India-Accidental-successful-knowledge/dp/1849682623/ref=sr_1_1?ie=UTF8&qid=1341554743&sr=8-1&keywords=management+in+india

In the world of IT, engineers usually grow into either 1) Technical managers with people management responsibilities OR  2) Technical Advisors / Architects working as  individual contributors.

Here the first set of roles do not necessarily need you to have a great technical prowess compared to an architect. Similarly, in an architect role, you need not have great people management / planning, delivery skills compared to a Technical Manager.

We must keep these distinctions in mind when looking at entry level / junior developers. Also, keep in mind the need for utilizing the strengths of your employees and making the weaknesses irrelevant.

Given the above, lets look at various scenarios that usually happen with developers:

1. Core Technical Strength  of an individual sometimes is not good enough for a more senior role.  You may want to ignore this weak-ness for a while and look at the strengths of the individual.  Like ownership, planning delivery, people skills etc.
2. Ownership and passion may be great. In this case, let this person  be the driving force for solving a critical problem, may not be solving them problem himself.
3. Delivery and execution skills may be awesome. In this case, let this person use these skills to drive the planning and execution for a team of individuals. See how this plays.
4. Some people are just good at their clarity of thought, their inclination towards customers, business etc. You may want to let these people work closely with Product Mgmt in understanding requirements and helping provide a Product Manager view  / proxy to the team and help in documentation for the features being built.

I personally did not use to like this approach, but it actually works like a charm !! If you as a manager show folks that you care a lot about their strengths, then they tend to pay a lot more of attention to their own weaknesses to make you / the company happy. Try this out !

(thanks to http://www.pictures13.com for the pic)

1. Your “things to do” list would be overflowing ALL the time. Even if you take no more things to do and just work on the current task list, it may take you a month to just wrap up those. This would lead to a constant prioritization loop. You would always be prioritizing on whats important for you to do right now, today and this week.
2. No “Right” / “Correct” way of doing things.  You will need to figure out what works in your role, your product and your organization with your customers, your engineering team etc. This is very different from Engineering where you need to usually solve a mathematical looking problem and come up with the best suitable solution. Incase of Engineering generally the influencing factors (for your choice of solution) would be well understood so you can make a “well-informed” judgements.  This is very hard in a Product Mgmt role, the ‘influencing factors’ in your decision-making would be generally fuzzy. Many pieces of information would not be available.  Many data points would be un-verified. Many data points can be made available, but it would take a huge effort to gather those, and you would not have all the time for that  investment.
3. Poor understanding  / standardization of the  role. Different organizations, different teams have very different understanding of what the Product Manager should do.  This leads to a lot of confusion, mis-understanding and the going gets tough. For example, I have seen orgs where PM defines what problems we need to solve, the use cases, business scenarios, HTML mocks ( if they are relevant), then leaves it to the engg team to build a system which can accomplish those goals.  I have also seen teams, where the Product Manager provides a requirements document which already defines an engineering approach for the problems to be solved and the engineering team is responsible for building that engineering approach( and does not care about the business use cases, scenarios). 2 extremes. Be careful about this clarity before you sign up as a Product Manager for a particular org (be it an org within the same company or a different company).
4. Limited learning re-sources. There are a LOT of senior engineers to learn from. The knowledge and the wisdom has been gathering in this area for a long time and thus getting induced into this role and growing in terms of learing and executing best practices is rather easier because of the abundance of patterns. Product Management being a new role, has limited resources to learn from.

(Thanks to http://weheartit.com for the image)

A normal engineer needs to think top down. The data layer is the foundation of the system.  Go to the foundation in the very end.

You start with a requirements and start defining functional blocks of your product. Think of it like different parts of machine, say if I were to design a car, i would think of the engine, the AC, the body, the seating etc as the “functional blocks” which are directly derived from the requirements.

These components need to be able to interact with each other to make the software you need.  You can call this a  “High Level Functional Components Diagram”.

Once you have this diagram ready, ONLY then you should get into the design of each of these components.

Take a look at this nice article on a structured design thinking and different perspectives which are important in a design process - http://bit.ly/aXGVAd

Is it really so hard to understand this 1 simple thing ?