How Product Managers Influence Organization Culture

Image courtesy Technical.ly
Image courtesy Technical.ly

Among many others, maximizing value and ensuring ROI are primary responsibilities associated with a Product Manager role. These include activities around market research, customer interaction and much more. All Product Management activities are split across 2 broad categories; strategic and tactical. These activities take away the majority of the Product Manager’s time with limited or no time in hand for the team solving the problem.

A Product Manager’s engagement with their stakeholders highlights a very distinct gap. This gap is caused by the approach driven by local optimization where customer’s priority is about market expectation and their need for new features, management which is concerned about timelines and cost and teams that are about stress and impact of changing business landscape. In a nutshell, each interaction deals with local problems without much attention paid to common business goals and objectives and the missing alignment.

When it comes to development teams, the kind of engagement a Product Manager is able to develop impacts how the team performs. Here are some Product Manager attributes that impact team culture:

Shared Product Vision – Developing a good Product Vision can be difficult. A lot of market data and research goes into understanding what you need to build and why. Knowing the vision of the product can greatly impact the behavior of the team. It is imperative that the people involved in building the product buy into it. A lack of it can cause the team member to be demotivated or follow their own goals which make it harder to achieve product success. An inspiring vision that is able to articulate the positive change it will bring can go a long way in how teams think, engage and innovate.

A vision also helps in guiding the decisions of the team. A team member who will be able to challenge a Product Manager on a decision that deviates from the vision is typically a motivated team member.

A Product Manager should bring in the team together every once in a while and have them articulate the product vision to ensure shared understanding.

Product Strategy – The next step is to have a product strategy. A strategy is developed taking into consideration market and customer needs, key product differentiators and focused outcomes. While Product Managers own the strategy, an inclusive approach where the team gets to influence strategic decisions based on their understanding of business and product helps builds a culture of trust.

Focus on the problem – It is commonly said and understood that while Product Managers focus on the “WHAT” and “WHY” of the problem, they should trust the team to come up with the “HOW”. Many Product Managers indulge in influencing decisions about the “HOW” suggesting lack of ability in the team to solve problems.

While organizations invest heavily in hiring people with the right skills and talent, Product Manager trying to force solutions may suggest their lack of faith in team’s ability and skills. Product Managers and other team members must have mutual respect for each others knowledge and contributions to the team. A Product Manager who shares a problem and trusts the team to find a solution build a culture of collective ownership.

Acknowledge unknowns and need for experimentation – Just like all business solutions may not be successful, technical solutions can fail too. Expecting development teams to be first time right can kill the creative capabilities and limit the team from taking risks.

Product Managers should encourage the team to experiment and take risks towards building next generation solutions while staying aligned with the latest technology and industry trends. Technology teams understand market and business constraints and should be trusted to provide solutions that work around the constraints and provide business value. This will also lead to building a culture of celebrating failure.

Allow technology to drive value – We live in the era of technology innovation where the biggest businesses have been successful by leveraging technology to solve the most common problems. Most successful enterprises are creating a “playground” for exploration to explore new technologies cause disruption.

Driving business value is crucial for Product Managers but the most innovative outcomes are produced by allowing technology to remain on the forefront of problem-solving. This needs to have a mindset and culture of collaborative ideation and problem solving to use to best of both worlds to create competitive advantage and create a culture of innovation.

Wrap Up: The most successful enterprises are using joint business and technology portfolio to innovate and create the most innovative product offering. Product Managers can play a critical role in practicing this at the team level by putting the above-mentioned behaviors in practice.

If you are a Product Manager and you have other ideas that can help transform organization cultures, please leave a comment.

When to size Product Backlog Items?

When is a good time to size product backlog items? I have come across varied opinions on this topic. While for some it makes sense to size stories during a backlog grooming session, others suggest that PBIs should be sized in the initial part of sprint planning. Additionally, I have seen teams size PBIs multiple times, 1) during Product Backlog grooming to help Product Owner with predictability and 2) during sprint planning as the team gets to the next level of details for the PBI. So what is the right approach?

Image

The key objective of sizing stories during backlog grooming it to provide relevant data to the Product Owner to prioritize the product backlog and provide an opportunity to the stakeholders/customers to make long term predictions.

While I have had teams size stories multiple time, this approach feels redundant. Following are some ways to size your product backlog items:

1. Periodical grooming (monthly/quarterly) – This can be a scheduled periodical meeting where the team can size stories for the next 2 to 4 sprints.  This can be done on a day between sprints to allow the Product Owner to plan for a larger goal and write additional stories to achieve the goal as needed. Deliverables at the end of each iteration will help the PO to re-plan and re-prioratize the product backlog.

2. Once every sprint – Some teams like to get into a backlog grooming session once every sprint. This is typically done when the team wants visibility into what is coming up in the immediate next sprint. The team collectively spends one hour to go through the highest priority stories in the backlog.

3. As needed after Scrum – With some teams a Product Owner’s presence during the daily Scrum is an indication of the fact that there are stories to be sized. This typically works well as the number of stories to be sized are generally lesser in number.

Teams having to size PBIs directly during sprint planning generally result in issues. Having the team to size the stories during the grooming session works best. This also presents an opportunity for the teams to identify dependencies on other teams and notify them, identify spike candidates as needed and brings about an overall visibility into what is coming next.

So if you have a un-sized product backlog, go ahead and get it sized by the team and make it an ongoing activity to deliver value continuously.

%d bloggers like this: