Take Charge Product Management
Collect information and work with your cross-functional partners to be an effective product manager. Your company will rely on you to be the most knowledgeable about your product so never take your eye off the market and establish an objective framework to guide your decisions.
Take Charge Product Management by Greg Geracie
You won’t find these two sentences in any books on product management: “It was 6:45am. The sharp sound of the alarm clock buzzer cut through my thoughts”, “The candy bars on Alex’s desk were vanishing quickly”, or “My first shot sprang off the rim of the basked and bounced to the other end of the court.” But you will find them in Take Charge Product Management . Geracie uses the story of a fictitious product manager to illustrate the skills, processes, and deliverables that he presents in the book. The vignettes at the beginning of each chapter tell the story of Sean who begins the book on the sales team and is recruited by the CEO to be the company’s first product manager. The knowledge and he learns is illustrated and elaborated in each chapter. For example, when Sean sets off to conduct competitive analysis, the remainder of the chapter describes how competitive analysis should be structured and what specific information should be included. The story concludes with Sean finishing his first year by giving a presentation to the board of directors.
Every one of our early sales had come with a different set of promises about what the product would do for the client. It was not the sales team’s fault as we were lacking a definitive value proposition. To make matters worse, the engineering team was having difficulty prioritizing because each sales person had a different request from their respective clients.
The book starts with Sean agreeing to be the first product manager at Alpha Technology Ventures. He is initially overwhelmed but quickly falls back on his product and customer knowledge along with building relationships with his new peers in Engineering and Project Management. Geracie describes how product managers are “minted” in various size companies and describes the role and its context. It’s a great chapter for anyone who is new to product management or needs to explain to organizational peers why the role exists. Geracie says that product managers are the “field generals for their product, coordinating activities across the diverse functional areas of a business to ensure a maximum return on product investment.” He highlights the role of product manager as knowledge repository about the product, customer, and market. Like Sean, many product managers are overwhelmed with the scope of the role, but Geracie points out that product managers are supported by all other business functions.
Your role as product manager is to see the forest, not the trees
Once Sean gets out of bed in a cold sweat at the outset of Chapter 2, he begins to dive into the role and understand what’s expected. Geracie traces the product manager’s role from developing the product vision, through business planning, to leading cross-functional collaboration to build the product, and finally establishing and reporting on metrics. Challenges along the way are time constraints, being more reactive than proactive, lack of formal reporting relationships and control, conflicting opinions about the direction of your product, and changing market landscape. In addition to functional skills, Geracie provides a long and intimidating list of behavioral competencies for product managers including strategic, entrepreneurial, conceptual, creative, leadership, customer, political, influence, and calm under pressure. It’s a tall order and no product manager will have all of these skills or even an equal weighting across all skills they do possess, but he clearly illustrates all the areas a great product manager is expected to cover. For product managers who are primarily used to working with development and QA teams, Geracie has a hub-and-spoke model with the product manager at the center and all other areas arrayed around the hub. To make product decisions Geracie recommends asking two questions: 1) will this request directly help attain the product’s goals?; 2) will this request help make the product manager more efficient by reducing this type of request in the future?
In the third chapter, it’s the CEO who is in the hot seat as he attempts to explain to his board why he is establishing a product management function in the company. As Sean is embarking on his first steps as a product manager, he starts off by immersing himself in the company’s business plan and understanding the market, customers, and vision. Geracie discusses how the product management skills in the previous chapter map to phases of company growth (i.e., different skills are needed in startups than in mature companies). This is a great profile for product managers as they seek new career opportunities–what is valuable and works well in one environment may not translate to another. Geracie describes three methods for understanding the customer: voice of the customer, workflow analysis, and outcome driven innovation. Voice of customer analysis takes internal and external data sources to understand the customer’s needs, context, and problems. Workflow analysis requires direct observation of the customer performing their work to understand each step along the way to achieving an objective and completing a job. Outcome driven innovation attempts to go as far upstream as possible to understand and identify customer metrics and objectives in their role and business.
[Process] options exist that allow you to examine what customers are telling you, how they accomplish their work, and what they are trying to achieve.
As Sean begins working with his CEO and peers, he begins gathering all the information he needs to do his new job and his board presentation. Geracie lists various sources of internal and external information that a product manager should collect. These sources include market research, customer lists, sales presentations, marketing collateral, win/loss data, and customer contracts. This list is particularly useful for a product manager who came to the role from a technical team and may not have previously reviewed this type of information.
Geracie advises synthesizing all the data you collect into a hypothesis (product strategy) that will be reviewed and discussed with internal leaders and key customers. Sean’s story is largely about the creation of this document and Geracie focuses on it as well.
Your preliminary product strategy will reside on presentation slide. Start by selecting a point on the horizon, say three years. Now settle on starting point, say the end of this year. If your horizon point is three years and your starting point is year-end, you’ll need to show customers what happens at the mid-point of this journey.
It’s hard to imagine anyone putting together a three year product plan, but Geracie’s template can be taken as a product vision. He says “if you get hung up, reach out to a friendly thought leader in your organization and ask them to help you round out what you’ve already accomplished.”
Like many management book writers before him, Geracie invokes the infamous Wayne Gretzky quote about skating to where the puck is going to be. Geracie says “to create an effective product strategy you must be able to anticipate shifts in your marketplace before they happen” which is easier said than done. He doesn’t provide any advice on how to prognosticate in such a manner but implies that synthesizing available information and conversations with other thought leaders will result in this view. Geracie places a premium on the product manager being the most knowledgeable about their product so presumably the deep learning process creates the ability to map out the future vision with sufficient accuracy. In relation to this approach, Geracie writes “you want to draw together the sharpest minds available in one room to help you forecast the direction of the market and challenge existing assumptions about your product. Make sure to schedule at least two to three hours for the meeting.” Geracie maps out the meeting which will result in a three to five year product strategy. He then suggests getting feedback from customers on your strategy and plan. He advises backing up the plan with a business case (which is outlined in the book).
When Sean completes his product strategy document and business case, he moves into execution mode, beginning with requirements gathering. Geracie lays out a standard product lifecyle with seven stages (and iterations within each): strategy, requirements, analysis/design, development, deployment, operation, and retirement. To gather requirements, Geracie says you must first decide which requirements methodology you will use: voice of customer, workflow analysis, or outcome driven innovation. Once you’ve gathered your requirements, Geracie recommends using a decision matrix to ensure objectivity when prioritizing and selecting requirements to implement. It’s equally important to have cross-functional representation throughout the process, especially as requirements are evaluated.
Geracie’s view on product roadmaps is that they are an “operational plan that highlights your products quarterly development activity over a rolling 12 months.” He advises having an internal and external roadmap: one for customers and one for internal teams.
The book doesn’t depict Sean gathering requirements, going through the development process, or releasing his product, but Geracie provides recommendations for all the later phases of the product lifecycle. He describes a requirements document along with a launch activities checklist. He does discuss Agile but not in depth. Staying with the business focus of the book, Geracie does give some detailed guidance on customer advisory boards, which seem straightforward, but have many complexities.
One of the main themes in the book is information gathering because Geracie says that for product managers knowledge is power. He dedicates an entire chapter (with a Sean vignette at the start) to the specifics of ongoing competitive analysis.
Geracie concludes with a chapter on documentation and success metrics. He writes: “leave documentation behind for those who follow you.” For those of us who have inherited products without any documentation whatsoever, this is advice I wish everyone followed.
Take Charge Product Management has a lot to offer all levels of product managers. For those who are new to the role or for anyone who has never worked with a product manager, the first few chapters are an excellent introduction to why companies need the role and what product managers do. For experienced product managers there are some good details around concepts like customer advisory boards and competitive analysis.
The focus of the book is on the business side of product management so you won’t find any advice on writing user stories or working with the UX team. Geracie focuses on cross-functional collaboration, information gathering, and planning. This is great for product managers who are coming to the role from technical areas since it gives a lot of details about the specific type of business information that is relevant and should be collected for product planning.
Geracie is heavy on documentation and portrays the planning process as seemingly simple set of meetings, but if you view his advice from the perspective of developing a product vision, rather than a three to five year plan with milestones, it becomes more applicable. The book’s protagonist Sean deals primarily with the CEO and peers in sales and marketing; the development of the product itself doesn’t figure prominently. This is good because there are so many books dealing with execution that having one which focuses on the business and negotiation is valuable. As we see Sean learning about being a product manager, there’s a lot of great material for anyone who needs to educate their organization about the role.
