Four things I’ve learned in my role as a Product Manager.

Alex Schneidman, Product Associate
13 April 2022

At the beginning of 2022, I completed the Product Manager Headquarters (PMHQ) Product Management course to build my knowledge of Agile and hone important skills in Scrum/Kanban. In addition to the development I’ve made in the beginning of my product career at Somo, PMHQ’s training has provided several new insights and informed my perspective on the best practices when developing quality products. 

Here are some of the things I’ve learnt: 

Push vs. Pull

One very important and key difference between Scrum and Kanban methodologies is what PMHQ’s training calls “push vs. pull.” Scrum determines what goes into a sprint based on the needs of the product. Therefore, “pushing” stories/tech debt/etc into a sprint and into production. In an ideal world, the team is then built around these needs and can deliver on them. Kanban, alternatively, “pulls” stories into work based on the capacity of the people delivering them, never overloading the system beyond its capabilities.

Personally, I see the value of both methodologies when it comes to delivering products. However, I am more aligned with the idea of  “pulling” stories based on resources involved in Kanban. I admire the attention this process gives to the actual human beings executing the work and its flexibility. Whilst Scrum also encourages the input of all team members in planning, the “pull” model gives team members a different kind of autonomy. Concerns may arise about complacency in the Kanban model, with people becoming less inclined to give that extra push when the capacity is so discreetly decided. But in my opinion, teams that feel autonomy and self-direction are generally stronger than teams that do not.

The importance of empiricism to the Agile methodology

One philosophical angle that my training explained was the practices of empiricism when decision-making and road mapping within the Agile methodology. Empiricism, a philosophical offshoot of western ideas popularised around the same time as the scientific method, prioritises observed experience over tradition or customs. I.e. ‘We’ve just always done it that way’. In decision-making and assessing risk, empiricism places a heavy emphasis on the use of empirical evidence. This can be thought of as evidence found from the hypothesis-data collection-conclusion model within the scientific method. In the world of product and its management, obtaining your own data and research is the most common method used to inform what path to take within the building process. 

Obviously, there is a lot of value in this method, which I have seen in the work I do at Somo. But there are some shortcomings to being so ardently aligned with this philosophy. Product teams looking for direction in ways to innovate may not have access to the resources, or the time needed to test for data on new efforts. So it can be incredibly valuable to hear out the past experiences of team members, especially new ones, even if they contradict the norm. If we want teams to create innovative products, we must also be willing to accept that past experiences may not always align with future endeavours. Nevertheless, we should always look for ways to validate our aspirations and direction.

Different validation frameworks

The most valuable facet of my training was the explanation of various validation frameworks that can be used in making business decisions. Four different frameworks were discussed in this course: the Four Steps of Epiphany, Lean Customer Development, The MOM test, and the Validation Checklist.

Each of these frameworks essentially follows a model informed by empiricism, seeking outlived experiences and accruing data to validate the product-based decisions, teams and businesses make. The framework that initially jumped out to me was the Validation Checklist. 

I was drawn to its interrogative approach, using a list of questions that must be answered before the process can go any further. Some of the questions focus on the effort and opportunity aligning with the ‘vision’. Ultimately, these are incredibly important questions to answer in the affirmative, because if your team is not unified to work in the same direction, issues that arise that may knock the project off track. There’s also a question that posts whether ‘we’ can do it. Meaning whether or not a specific team can execute the idea in the desired way. This idea aligns with the Kanban methodology’s emphasis on respecting the capacity of your particular team's skills.

Estimation and the “base story”

Working with teams in the past, I have found that it can be difficult to predict the timings of certain tasks and the level of effort that is required. This is where PMHQ’s training is helpful, the course encourages the idea of finding a ‘base story’ with your team, to establish norms for the level of effort and timing. 

On previous projects, I have been involved with, not every team member has always had a hand in deciding the timings for tasks, which tasks might introduce external variables and dependencies, and which tasks have the potential for increased difficulty. By finding a solution that involves all team members in some capacity, that can be used as a reference point for relative scaling of effort, teams can be more confident in their ability to deliver. I have seen this practice in action within the myAudi team at Somo. Regular planning sessions help to get the whole team together to discuss and agree on estimations for different user stories and tech debt. Especially when working on a complex product with a big team, I see how valuable it is to find a common ground on estimation.

There is so much to gain from joining an active product team. I am thrilled that I’ve had the opportunity to sit with these ideas in a more formalised setting with PMHQ. At Somo, having the ability to take time to better understand the industry and the teams with which I work has allowed me to build my confidence. I can’t wait to see how this new knowledge will help me bring my best self to work.