Every company is different which creates nuances for the role and the responsibilities of product management within that company. Even though the core skills expected from a PM do not change, one company's PM expectations may not fit another company. For example, the planning process and expectations at Amazon is very specific to that company - with OP1 and OP2 approaches, written culture, P&L ownership etc. It would be neither practical nor successful to try to directly adopt that to a startup, where the product managers are expected to be Swiss Army knives.
"At Lyft, we had a lot of senior people who joined the company from companies like Amazon, Google, Tesla and Facebook, and we had to create 'Lyft-way-of-doing' things, sometimes with trial and error based on what these senior leaders brought with them," Kamil added. After each planning cycle, you can receive feedback from product managers (and the broader tech team) and discuss this feedback openly through post-mortems.
"I can give an example of what we have adopted from Amazon. When I first joined Lyft, everything was based on slide decks. In general, I have not been a fan of decks as I always felt people spend a disproportionate amount of time on the flow and the cosmetics, rather than the content. Unless you’re a master of decks, they almost always require a voice over - by design as they are for presentations not necessarily for discussion of topics. Long story short, we gradually adopted the written culture of Amazon, retired most of the deck creation and moved to documents - the key is to acknowledge that this has to go through change management as it’s a cultural and operational change even though it looks like a tactical one.
At Amazon, the company has an annual planning process—they refer to it as Operating Plan 1 (OP1) and Operating Plan 2 (OP2). Their finance team plans the budget, informs the teams, and asks them to modify their OP1 into an OP2 based on the budget constraints. At Lyft, during my time, we stopped at OP1 and started creating annual plans that provided the company a one-year vision for each area of investment. Back then, we could not adopt the OP2 part of the Amazon way, because our headcount and budget planning processes did not exactly fit how Amazon does their planning. Still, having annual plans was a big step forward in forcing teams to think beyond the next quarter, being more strategic in their plans and having an early read and visibility into the problems the team intends to solve for the customers and the company.”
Kamil also shared an interesting question from people with whom he has worked in the past. “You keep mentioning longer-term planning, but isn’t this contradictory with the agile approach?”
The teams sometimes confuse the agile development methodology with being unplanned for their product area. The agile approach does not mean that you start working towards a direction you feel is right and figure out your product strategy as you progress. Quite the contrary: Agile helps being flexible in your decisions and the progression of product development within a strategy that you already have. Based on what you learn from the users/customers and even due to changing priorities for the company, agile allows teams to learn, adjust and adapt their development in alignment with the team goals.
Kamil also shared one of his favorite quotes when it comes to planning, from Dwight D. Eisenhower, the 34th President of the United States: "Plans are nothing; planning is everything."
Product metrics have to be directly or indirectly related to the company's business metrics - in case they are not already the same. Product teams define and track a ton of metrics without answering the question of why the metric matters in the grand scheme of things. The role of the product manager is to be able to provide that linkage and able to explain why improving certain KPIs matters for the business results.
Another related topic is that companies should know the difference between an OKR and a KPI. KPIs are essential metrics that the company always tracks independently of the immediate strategy and initiatives. KPIs are the core metrics that are most of the time evergreen and represent the health of the business/product. OKRs, on the other hand, are the metrics that measure the success of an investment. OKRs might change depending on the company's strategy, goals and initiatives.
"This distinction was a problem at Forto. We saw teams defining KPIs and OKRs as if they are the same set of metrics. As an example, we always need to track core metrics such as the number of shipments and gross profit (GP) per shipment and be able to understand the changes. So these are KPIs. But, if we have a specific product initiative that aims to reduce the cost per shipment, we should define OKRs around that initiative for the duration of the initiative, and be able to measure ourselves against the set goals - and in parallel tie the impact of the initiative to the GP per shipment, which is an evergreen KPI."
Product managers are expected to make decisions or facilitate decision-making in their respective product areas. In most cases, these decisions come in the form of a trade-off or a position that best generates value for the customer or the user. The more insights and data the product manager gathers, the higher the chances of the decision being the right one. The primary source of those insights and data are customers or users. Building customer/user empathy reduces the guesswork and improves the alignment between the product decision and the customer value generated.
When the product managers lack the customer perspective, there is anxiety in decision-making, especially given each product decision, big or small, is a resource investment decision for the company. If the product manager has talked to every valuable source possible (customers, sales, customer success teams, UX research), and gathered all the information accessible, it is likely that the decision is the best one under the circumstances. If there is doubt in the decision or data supporting it, the product manager needs to have a plan on validating the major assumptions leading the decision, so if some core assumption does not hold true, the direction can be modified. This validation could be in the form of early customer feedback, through early access programs or user research, as the product starts taking shape or, depending on the domain especially in consumer businesses, through experimentation designed around testing the core assumptions. No one always makes the right decision, but it’s important to have a plan and procedures to detect the mistake and course-correct fast.
In research, B2B founders are divided into two groups. While they are B2B founders, you can think of them as product managers because they will create their products. They give the same training to both, but they provide scientific thinking training to one group. What does that mean? These people learn how the hypothesis is created with as much information as possible, then tested in the market. Next, data is collected, and so on. Thus, the second group, the scientific group, sheds their egos and focuses on getting data and information. They perform better and have better psychology.
Two schools of thought influence leadership. First, Adam Grant, an organizational psychologist at the top-ranked Wharton School at the University of Pennsylvania, developed his 4 decision-making criteria for evaluating leadership and making the right decisions based on a series of studies. He developed 4 antidotes to reduce escalation of bad decision-making:
(1) Separate the initial decision-maker from the decision evaluator.
(2) Create accountability for the decision process, not only outcomes.
(3) Shift attention away from the self.
(4) Be careful about compliments.
In an experiment out of London Business School, people who had been praised for their decision-making skills were 40% more likely to escalate their commitment to a bad decision than those who hadn't been praised. On the other hand, those people who’d been praised for their creativity were 40% less likely to escalate their commitment to those who hadn’t been praised. The conclusion—any time a person is given positive feedback for their skill or trait, in turn that person is at risk of becoming overconfident.
Patrick Lencioni offers his own school of thought with his 6 types of working genius. They are:
(1) Wonder - you see potential and greater opportunities in any given situation.
(2) Invention - you see novel and original ideas and solutions.
(3) Discernment - you intuitively and instinctively assess ideas and situations.
(4) Galvanizing - you rally others to act on ideas and inspire, and organize others to take action.
(5) Enablement - you help bring ideas to life through encouragement and assistance.
(6) Tenacity - you naturally push ideas or tasks to completion to get results.
He promotes his theory that a healthy work culture promotes employees to feel valued. Yet, their happiness is also determined by whether they are naturally talented and good at doing their assigned tasks. So by tapping into their “working genius” and engaging in areas of weakness less, team members can find joy in energy in their tasks and skill sets.
This research created such enlightenment because everyone is good at something, so it is incredible to understand how to work together. Some people in the group are constantly generating ideas. Then, someone decides on that idea and moves forward. Yet, there needs to be due diligence to see if it is a good or unwise decision. Another employee will galvanize and gather people to bring this idea to life. A team member enables it and outputs its roadmap. Someone else checks if we are doing well. So now, to do an excellent job, this whole skill set needs to be present in the team, and there is usually no person in a group who is exceptionally good at all of it. The team members need to create a little bit of this structure. When we sat down and organized, we saw that some skills were missing, so we should hire some people who have those skills. The same approach can be beneficial in terms of product management.
