The product owner role on agile projects is critical to the team and the project. The product owner's influence, performance, and behavior can set the stage for smooth sailing—or sink a project. In this article, Anupam Kundu shares two different product owner experiences to drive home the argument how their behaviors and practices can shape organizational culture—specifically for new product development and start-ups.
Have you ever felt impacted—either negatively or positively—by the Product Owner (PO) on your team? Does product owner have enough clout to change the ways things are done and make them better? All of us at some point in time are affected by the behaviors and decisions of our product managers and product owners. Experience how two different POs handled situations to learn how they can shape organizational culture, especially for new product development and start-ups.
Culture is a by-product of individual (and group) behaviors and practices in an organization. Product owners, being a part of the leadership, can definitely play a strong role in driving collaboration within and outside the products teams and thereby influence the organizational culture. Courageous, confident product owners can positively lead change even in hi-strung environments and motivate agile teams to success. On the other hand, traditional, command-control focused product owners fail to fully comprehend team dynamics and struggle with steering agile teams in the right direction. Pragmatic POs can successfully align teams with business goals even with limited resources and political constraints just by fostering the right attitude ndash; positively affecting the culture of the team and organization in the process. On the flip side, non-collaborative, unilateral decision taking POs end up alienating the team leading to a negative, weak culture.
Circa 2011. It is the best of times and it is the worst of times.
Post the financial meltdown and the much debated stimulus plan, senior level product managers across multiple business verticals are eager to prove their mettle ndash; there has lead to a significant increase in the spend on software and computer services[i]. This means that technology integrators and organizational change consultancies (like the company I'm employed by) are called in by product teams to assist and enable build new, cutting-edge innovative products and share our experience.
During 2010-11, I was closely involved in development phase of two such innovative consumer-facing web products and got a chance to closely observe two different and distinct styles of product management. Both these product owners (and their sponsors) eagerly embraced the Agile practices for the development of their respective products. However, only one of them was successful in launching the product on time and within budget ndash; in alignment with the business goals while the other product owner suffered considerable setback with procrastinated go-live dates.
First let me start by providing an overview of both the businesses and projects involved. I will follow up the scenarios with the culture connection in each of the situations.
Digital Media (e-Books)
Strategic goals with the product: The product owner, Jeff was responsible for developing and launching a product for a start-up sponsored by a consortium of multiple trade-paper publishers. The start-up partnered with a digital media platform provided by another alliance to provide a premium location-sensitive, online reading offering for the customers of this alliance. This platform was destined to be a revenue-sharing and marketing opportunity for multiple partners (like Jeff's start-up) by selling music, magazines, and other premium online content.
Challenges: No sooner than he started, Jeff faced the following challenges
- The deadline was tight. The product needed to go from concept to literally millions of users in the USA within 10 weeks.
- Critical components of the product needed integration with external product vendors. Their release timelines were not aligned to the launch date.
- The product involved multiple integration partners and hence multiple dependencies. Contracts - both business and technical ndash; were to be negotiated in that limited timeframe while continuing the product development exercise.
- The software was intended to support custom