Becoming a Product Manager - Part 1

— A theoretical approach

Writers note

While I was trying to know what Product Manager means and what’s his role in a company, I came across hundreds of articles. I read few of them, 6/7 of them to be exact or may be 7/8 of them. I am not sure. Whatever the number is, I made a short note for me out of those articles and here it is.

Behind every great product there is a person with great empathy for the customer, insight into what is possible and the ability to see what is essential and what is incidental. This person has a deep understanding of the customer as well as his own teams’ capabilities. He operates from a strong basis of knowledge and confidence. He thinks in terms of delivering superior value to the marketplace, and he defines good products that can be executed with a strong effort.

This person may have the title of product manager or may happen to be anyone on the product team from an engineer to a company founder – the key is that this role must exist and the responsibilities carried out by someone with the skills and talents the tasks demand.

[0] Source of product ideas

“Right product in the right time.”

[0.1] Customers
[0.2] Your competitor’s customers
[0.3] Industry analysts
[0.4] Your company’s executives
[0.5] The sales and marketing staff
[0.6] The product development team
[0.7] Your Company’s customer service representatives
[0.8] Your operations staff
[0.9] Your own experiences and knowledge of the market and technology

[1] CEO of the product

“Product focused, not business.”

[1.1] A good product manager acts like and is viewed as CEO of the product. Drive vision to success.
[1.2] Bad product managers think of themselves as marketing resources.

[1.3] Bad product managers have lots of excuses -

[1.3.1] Not enough funding
[1.3.2] Engineering manager is an idiot
[1.3.3] Microsoft has 10 times more engineers
[1.3.4] I’m overworked
[1.3.5] I don’t get enough direction
[1.3.6] When they fail, they point out that they predicted they would fail.

[2] Product strategy and roadmap

“PMs have to paint a clear and compelling picture of where the product is intended to go over the next few years and create a strategy for that. The product roadmap should chart the course to get there.”

[2.1] It helps to motivate and inspire product team
[2.2] It helps engineering team to architecture the product
[2.3] Helpful for the sales / marketing team to communicate the vision of the product to customers and industry analysts

[3] Manages Product Not People

“That responsibility is leading, but not managing, the extended product team. The best PMs do not want the product team to do things simply because he tells them to, he wants them to do them because they believe in him and they believe in the product.”

[4] Good product managers balance all important factors

“Good product managers don’t always know the answer to these questions, but they know enough to ask when they don’t.”

Primary factors are -

[4.1] Company goals & capabilities
[4.1.1] Goals, Capabilities, Limitations, Marketing resource etc.

[4.2] Customer demand
[4.2.1] Difference between what customers want and what they can & will pay for.
[4.2.2] Quantitive research
[4.2.3] If you build it right, people will use.

[4.3] Competition
[4.3.1] Know where the competitors can go easily
[4.3.2] Where they can’t go at all
[4.3.3] Be better and different [ product, integration, distribution ]

[4.4] Know what you know, why you know and what you don’t know

[4.5] Think ahead and monitor your assumptions

[4.6] Good PMs will confirm their understanding with other members

[4.7] Bad PMs miss the big picture or miss small but important factors
[4.7.1] Build a bad product
[4.7.2] Build a good product for the wrong market
[4.7.3] Build too complex product to sell
[4.7.4] Build a product what will take too long to pay off
[4.7.5] Reacts to the moves of their competitors and forget to develop their own product’s identity
[4.7.6] Don’t notice when things change and notice only when their product fails

[5] Clear, written communication with product development

“Good product managers are respected by their engineering teams. Engineering teams involve good product managers in difficult decisions.”

[5.1] Product Requirements Document (PRD)

[5.1.1] 10 steps to a good PRD

[5.1.1.1] Do your homework

[5.1.1.2] Define the product’s purpose

[5.1.1.3] Define the user profiles, goals and tasks

[5.1.1.4] Define your product principles

[5.1.1.5] Prototype and test the product concept

[5.1.1.5.1] Feasibility testing
[5.1.1.5.2] Usability testing
[5.1.1.5.3] Product concept testing

[5.1.1.6] Identify and question your assumptions

“Make sure you don’t specify a candle in the PRD and prevent yourself from getting a light bulb.”

Astronomy was originally defined as the study of how the sun and the planets revolve around the earth. Its very definition had an assumption that prevented anyone from getting the right answer.

[5.1.1.7] Write it down

PRD has 4 major areas

[5.1.1.7.1] Product purpose
[5.1.1.7.1.1] The problems you want to solve, not the solution
[5.1.1.7.1.2] Who is the product for? Companies, Customers, Users
[5.1.1.7.1.3] Details are great, but the big picture must be clear
[5.1.1.7.1.4] Describe scenarios

[5.1.1.7.2] Features

Describe each feature at the level of the interaction design and use cases. You must be very clear what each feature is and what the user experience should be, while leaving as much flexibility to the engineering team as possible.

[5.1.1.7.3] Release criteria

The true minimum requirements are, for each of the release criteria.

[5.1.1.7.3.1] Performance
[5.1.1.7.3.2] Scalability
[5.1.1.7.3.3] Reliability
[5.1.1.7.3.4] Usability
[5.1.1.7.3.5] Supportability
[5.1.1.7.3.6] Localizability

[5.1.1.7.4] Schedule

[5.1.1.8] Prioritize

[5.1.1.8.1] Must-have

This literally means that the product should not ship if even one of the “must-have” features is not ready.

[5.1.1.8.2] High-want

These features are important, and you do want all of these in the product before shipping if at all possible, but you are not willing to delay the product for these features.

[5.1.1.8.3] Nice-to-have

These features are useful for the product team to be aware of, even if most of them do not get built until a future release, at least the product can be architected to handle these features, where appropriate, in the future.

[5.1.1.9] Test completeness

[5.1.1.10] Managing the product

During the course of implementing the product, there will be countless questions identified, even with the best of PRD’s. Resolve all questions about requirements by pointing people to the PRD. If it’s not in the PRD, put it in the PRD. Your job is to quickly resolve all the questions and issues, and to record these decisions in the PRD.

Remember that the PRD is a living document, and you should track all features in the PRD through product launch.

[5.1.2] Common pitfalls

[5.1.2.1] Usability testing too little too late

[5.1.2.1.1] Plan on doing multiple rounds of testing.
[5.1.2.1.2] Do this testing during the product requirements stage and not when it is too late to make the necessary changes to address the issues.
[5.1.2.1.3] Be sure that the product manager and designer are present for most if not all of the testing.
[5.1.2.1.4] Pay more attention to what the people actually do versus what they say. If you’re not absolutely sure why a test subject did something, ask why, always trying to get them to think out loud.
[5.1.2.1.5] It can also be valuable to invite key architects, engineers or managers to observe some of the testing as well, as it can be sobering for them to see what the target customers are really like.
[5.1.2.1.6] Let usability engineering specialists or product designer perform the usability testing.

[5.1.2.2] You are not your customer
[5.1.2.3] What vs How
[5.1.2.4] Too little detail
[5.1.2.5] Too much detail
[5.1.2.6] Less is more
[5.1.2.7] Engineering-driven requirements
[5.1.2.8] Customer-driven requirements
[5.1.2.9] Emotion can be logical
[5.1.2.10] Standard is better than better
[5.1.2.11] Pay your taxes
[5.1.2.12] Requirements vs Design

[5.2] Good PMs clearly define PRD in writing
[5.2.1] Clear, detail
[5.2.2] Includes product, release criteria, platforms, QA, documentation
[5.2.3] Data over Opinion
[5.2.4] Make sure each team member understands it equally
[5.2.5] Gather information from engineering informally and verbally, but give direction in writing
[5.2.6] Attend product and engineering meeting regularly

[5.3] Good PMs think PRD is a big deal
[5.3.1] Update the PRD daily/weekly
[5.3.2] Communicate the PRD changes with the team

[5.4] Bad PMs cut corners on communication with engineering or misunderstand their role
[5.4.1] Ask for candle when they can build a light bulb
[5.4.2] Don’t make detail PRD
[5.4.3] Write a PRD and assume engineering understands it
[5.4.4] Don’t have time to update their PRD
[5.4.5] Update the PRD and don’t tell anyone, or don’t tell enough people, or don’t explain why
[5.4.6] Change engineering priorities based on the latest customer feedback or latest hot sales situation without going through the defined process (sounds familiar? ;-).
[5.4.7] Ignore engineering requests or calls