A Tale of Two Product Owners

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.

Introduction

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.

Scenario I

Business domain:

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 viewing for different mobile platforms (iPhone, Android and Blackberry Torch) and PC. This included the use of specialized authentication to integrate with different vendor services with IP based restrictions.

Narrative: In spite of the challenges, the team was able to go from concept to launch in less than 10 weeks.

Jeff calmly provided much needed direction to the frenzied team which was worried about the deadlines and integration challenges. His enthusiasm fostered a distinctive, value-based approach to software product development resulting in a high-performing team deeply involved in developing a differentiating, high business value product for the start-up organization concerned. Jeff followed a product management style that was enabling, engaging, empowering and encouraging leading to early risk mitigation and constant collaboration with multiple business partners. His adoption of startup-culture, where everyone in the team is considered as the "Reasonable Person"[ii] generated a sense of co-ownership of the product in the team. Jeff constantly motivated the team to take ownership of the product. His rationale was that if you give ownership to one person then the chances are nobody else will contribute to pushing it to the next level so why not distribute responsibility?

Few of the activities that Jeff did on a regular basis are the following

• Constant prioritization of features to identify Minimum Viable Product (MVP) at launch
• Negotiating business drivers and the feature set at launch with different stakeholders involved from the consortium
• Facilitating contracts and discussions with different integration partners whenever the team faced bottlenecks
• Allowed the team to choose the best tools and practices that they wanted to adapt ndash; letting the team build something which will be scalable and maintainable (no arcane technologies!)
• Review of any and all business risks ndash; early and often ndash; to all the partners and stakeholders and the team. This kept the team aware of the product scope and got them more vested in the success of the product than they initially were.

Scenario II

Business domain:

Online education (e-Learning and Assessment)

Strategic goals with the product: The product owner, Ryan was responsible to develop and launch a key product for a new venture incubated by a very large news and media company.ÿ The goal was to tap into the buzz generated by federal grants to the higher education market and introduce a new global assessment system to rank undergraduate students interested in a career in finance. This product was intended to be a part of a bigger (future) platform for offering other e-learning related products and services.

Challenges: Ryan had to deal with the following challenges

• The deadline was tight. The product had to go for a global pilot launch within 10 weeks followed by a commercial release in the consecutive quarter
• Lack of enough in-house domain expertise in assessment creation and delivery
• A strong product culture influence from the parent stakeholders to live up to
• Constant intervention from the internal IT (of the largest business sponsor in the incubator) of what is the right way of doing the product
• Lack of direction and budgets post the pilot launch of the product
• No prioritization of key features that would help to make the pilot product commercially viable

Narrative: The team was able to finish an initial build of the platform within a span of 8 weeks using available Open Source Software and enabled the stakeholders to run a pilot with universities across the world. The mantra to deliver product early and often and gather feedback from the actual users resulted in a successful pilot release. During the pilot phase the team was able to do two production releases every week.

Once the pilot was launched, the spirit changed. The PO lacked vision for next few releases which caused churn in the team and hence delayed commercialization. During the few weeks following the pilot launch the team got caught up in inertia of not delivering any new features to the product. There were constant discussions/arguments about technology choices, processes and methodologies without focus on building the product. This eventually delayed the product's commercial launch. ÿRyan failed to realize that a Role based culture, dependant on a central committee to determine the course of a start-up product (processes, technology etc) is not the best way to develop a new product. Role based cultures are always marred by procedures, descriptions and authority. Ryan ended up championing a product management style which was discouraging, disengaging and tarnished with mediocre choices of practices and technology leading to low team morale. His style of management was antithesis to agile principles.

Few of the common mistakes that Ryan committed during this phase are

• Inability to surface business and product scope risks early and often.
• Unable to support the partnering technical team in their choice of practices and technology best suited to solve the technological challenges (this is the very factor that gave him success during the pilot phase).
• Not being able to define a draft release map (post the pilot) and get buy in to the roadmap from internal stakeholders and external partners.
• Inability to clear the distrust between the internal technology team and external technology integrators about the measure of the productrs's success
• Unable to lead and protect the team from distractions and inordinate delays ndash; no facilitation of negotiations with partners etc

The Culture Connection!

If you do not change direction, you may end up where you are heading, Lao Tzu

In both the cases mentioned above, the relatively less prominent common pattern is this: larger corporations are forming or funding start-ups in financially trying times to build and launch new innovative product ideas.

Top management of large corporations is well aware of the cultural inertia that organizational growth (size) has brought in. Small but heavily financed incubators are their only alternatives to conceive, build and release new products. They staff these ventures with charismatic in-house leaders, new hires, and progressive-minded technology integrators, providing them with sufficient bandwidth to make the product a success. However, as narrated above, the results can be quite different. More often than not, the results are directly influenced by the organizational culture. Company culture is one of the most important things (other than the product and the market) that determine whether a startup succeeds or fails.

Contrasting Models and Product Ownership

Culture is about how an organization arranges itself (people, processes and values): the rules, procedures, beliefs and values make up the culture of the company. However culture is not something that is created artificially from outside but it happens from within[iii]. New companies usually do not have a set culture and it is determined by the consistent behavior of the people involved in the business. For new companies it's not ideal to borrow culture from outside ndash; borrowed culture ends up getting warped to fit the new principles and practices followed within the new business.

Agile Principles of trust, simplicity, respect, self organization, close collaboration (amongst others) are conducive to establishing a start-up business. With adoption of Agile, the POs and team should have leverage to build a cohesive, engaged, collaborative team dedicated to sustainable development of high business value software. The leadership (product managers) in new businesses has great opportunity to drive and shape the cultural innovation - organizational values and beliefs ndash; whether to value command and control over collaboration and active sharing, whether to promote trust over apprehension, whether to foster creativity and innovation over accepting the status quo (this is the way things are done around here) etc. Sadly, most agile adoptions are however short-sighted; the teams are eager to introduce the practices without complete understanding and appreciation of the principles behind them.

Traditionally, the Product Management division of any organization is responsible for defining the ldquo;what and whenrdquo; while the technology divisions takes care of the ldquo;howrdquo;. With the introduction of agile, product managers are now challenged to address the dual requirements of defining the strategic product road-map (what and when) and also simultaneously balancing the sprint level constraints of resources and budgets (how). So, product ownership in an agile environment demands a blend of diverse skill sets ndash; something which is unusual to find in one single person. Thus it's more critical for a product owner to constantly collaborate with the team to plug those holes and adopt agile practices to iteratively execute, inspect and adapt based on constant feedback. This replaces the conventional Power Culture[iv] and Role Culture[v] themes and hence traditional product owners run the risk of becoming the limiting factor to an agile team's collaboration and feedback culture.

As part of being in a start-up, Jeff took upon himself to be responsible for an Entrepreneurial Culture[vi] ndash; a culture which spawns value creation through innovation and provided enough freedom to everyone to grow and to fail. Jeff clearly understands that as part of nurturing a start-up, he is also growing a new business and a new corporation and hence he will need everyone's help to make it happen. He let the team choose technology and development practices and got him involved in providing guidance with constant business prioritization. This type of participation without controlling fosters trust and accountability in the team and hence more commitment to deliver success.[vii]

Contrast this with the behavioral patterns displayed by Ryan. Though he is also running a start-up, his actions are definitely not championing working together. Rather, his is more conformist approach to role based culture. While Role Culture definitely has its advantages in specific scenarios, it's not the best approach in start-up environments. Role based culture[viii] works best in military, baseball teams and other situations where specialized skills determines your position in the team and the person is limited by the skill set ndash; which is not true in a start-up situation where you are looking to have more generalists than specialists.

Agility Model

Agile fosters a collaborative, interactive development environment that believes in providing high value business solutions early and often with a group of motivated individuals. The goal of the leadership in such an environment is to remove all the obstacles that hinder the pace and quality of work and provide all the support the team needs. Obviously, this stems from a deep level of trust between the leadership and the team which in turn fosters more trust. However, both the business and IT in most organizations strongly suffer from ldquo;this is the way things get done around hererdquo; belief resulting in low levels of trust and slow pace - a significant trait of Process Culture.

Forrester Research is actually focusing a lot on building product-centric teams within organizations. A product-centric development team is a distinctive, value-based approach to software development; these teams support their company's value chain, partner with both their customers and business stakeholders, and own the business results that their software delivers. This is particularly true for regulated environments like finance, healthcare, telecom where products have to constantly adapt to changes in the marketplace. This is a lot more similar to the Entrepreneurial Culture.

Behavioral Anti-patterns

• Low or No engagement with development team (Power Culture)
• Spread too thin to commit to release level goals
• Not being able to define, prioritize and schedule the product backlog
• Inability to remove bottlenecks with other integration partners
• Hand-waving and bluster[ix]

• Low or No engagement with strategy team (Process Culture)
• Inability to define product roadmap ndash; all stakeholder inputs are not baked in
• Product feature set not aligned with market realities

• Un-empowered Product Owner (Role Culture)
• Decisions are overridden by other department or peers

Conclusion

Agile methods are intended to bring individuals working together in a more intimate environment than other methods. Agile also espouses self-empowered, self-starting teams controlling their own environment. It requires a different kind of skill and attitude to manage agile teams working in which is more often than all a contradiction (in terms of responsibility and authority) for traditional product managers to absorb. It is however the responsibility of the Product Managers, especially in start-up-like environments, to understand the underlying principles of agility and map them into effective practices that fosters a collaborative culture. As some people would say, ldquo;You can get the code right, you can get the products right, but you need to get the culture right first. If you don't get the culture right then your business won't scale.rdquo;[x]

References

[i] lWhere the jobs are; http://www.time.com/time/business/article/0,8599,2040964-2,00.html

[ii] {Link broken}

[iii] lDon't create a culturer; Page 249, Rework by Jason Fried David Hansson

[iv] www.learnmanagement2.com/culture.htm

[v] http://www.learnmanagement2.com/culture.htm

[vi] http://en.wikipedia.org/wiki/Organizational_culture

[vii] http://www.entrepreneurship.org/en/resource-center/creating-an-entrepreneurial-culture.aspx

[viii] http://managementhelp.org/org_thry/culture/culture.htm

[ix] Rich Mironov - The Agile Product Manager/Product Owner Dilemma 

[x] ThoughtWorkers who took time to review and provide constructive feedback for this article