Return to site

Step 9: The product owner as a value-discovery agent in DevOps environments

· 12 Steps

Many organisations have created huge confusion around those important roles that they live or die by. This is understandable. We are living through rapid change and what made sense last month might not make sense now. That’s particularly the case with people and their roles. The problem is you can define roles clearly and enthusiastically only to find they are becoming less relevant as your organisation finds out more about the challenges of continuous innovation

A role needs redefining, that’s for sure. But that might mean you have the wrong people in place. This to-and-fro between what you need in place and people’s capabilities is why we say that roles have to become fungible; people not teams have to be multidisciplinary. This is nowhere more true than those people who should be acting as catalysts for change, people like product owners. That’s what we’ll concentrate on in this article.

Plenty of organisations face this issue: they have people allocated to each important function that's been defined as essential to success.

But they have neither defined all functions well, nor understood the direction of change and its most important consequence - people need to perform a number of roles interchangeably because even clear role definitions will be subject to change.

On top of that the firm now needs people to become more value-seeking rather than role-fulfilling. Doing the job, as defined, is less important than breaking down role-barriers as you go in search of value. In short companies often face role rigidity, poor role definition and role mismatch when they should be seeking fungibility and value-seeking behaviour.

Even companies that appear to be performing well suffer these problems.

Performance is often a fiction created by the markets you are in. A very talented team can perform badly in a rapidly constricting market. Poor performance can be masked by growth. Senior leaders need to make a more abstract assessment of what they see in front of them. They should just pull the veil back a little and ask if people really come into work willing and able to seek out value for customers.

The chances are that leadership attention is focused elsewhere. The enterprise is going through various simultaneous changes. It’s leaders will be trying to figure out what digital transformation means, contemplating the rise of digital currency and cashless payments, looking at IoT, wondering if AI will disrupt them and so on. Most have been adapting to changing competitive conditions (will Google enter my market) and they will have been thinking about how to transform into new digital organisations.

You’d be surprised how many times that leaves them muddled. Nowhere is this more true that in the area of product management or ownership.


We’re going to argue, in this article, that unless you get this area right you will not transform and nor will you be efficient and productive in the sense we defined elsewhere (for our discussion on Pareto efficiency see Small Steps Big Change). Key to this is transforming the product owner into a catalyst for value.

The IT-Business Divide

The place of the IT department within an enterprise or public institution varies greatly. In some, perhaps many, there is a clear business-IT divide. The workflow creates that divide. Usually a product manager and his or her team, will create a set of requirements for a product and hand this over to the IT team who will place it into backlog until the resources are available to put it into development.

A business analyst will usually break that project down so that any development effort is shaped around business rules and business logic. These are quite simple rules that keep a project within the framework of a company’s prices, policies and terms and conditions while the logic is a description of the workflow: how the new feature will flow through the organisation’s processes.

At that point the requirements of people in marketing, say, are more or less transformed into an IT project.

In the next phase, developers will work away in different scrum sprint teams. When they are finished with their sprint, they will try to integrate disparate work units into something tangible and, hopefully, fault-free to pass on to the operations team.

Much of that work will be poorly integrated, because different teams may have taken a slightly different approach. It will then pass through a test-system that often is not capable of spotting problems.These will surface later in call-centre complaints or poor uptake of a product or feature online.

Problems arise here because the testing procedure will be designed weeks in advance and will assume no change to an original plan.

As you can see, this situation is fraught with the potential for conflict and division

The handover from business to IT, the work of the analyst, the integration of code from different scrum teams, the testing process, poor integration, all present technical issues but often overlooked is the fact that they also create the potential for human conflict.

You can add into this the probability that the IT team has been forced to follow the business plan rigidly, even when it becomes apparent that the business goals have been wrongly framed. This set of difficulties is the norm and as we already said, the potential harm that human conflict does to quality and value is an overlooked factor. That’s also why we have placed so much emphasis on culture in our book Flow.

We said in an earlier step that there are missing ingredients here that scrum agile framework doesn’t necessarily provide.

Conflict is a feature of the handover process, which is why, at the operations end of IT, DevOps emerged - to integrate development, testing and operations. But even in DevOps, the formal transformation of a requirement into a project creates all kinds of artificial boundaries that make high performance difficult to achieve.

What you really want in an enterprise is for business goals to be adaptive and for these to iterate as IT experience of delivering them grows.

Being adaptive means making “pivot” decisions at the last possible final point of commitment. This means the impact of the fail-fast concept which, to be frank, most enterprises only pay lip service to, can be minimised. We prefer to think of experimentation rather than failure anyway.

For example, you may have a requirement to undertake a survey through a website and this requirement can be baked into the workflow. But the business goal is to understand customer needs in a way that shapes product design and maybe this is done better and quicker by developing a set of interactions that would play out via Twitter.

Now, that might mean the business goal is not fully achievable in its original form. It may have been defined as “understanding customer needs in specific segments” and IT may have been tasked with designing that into a website form and landing page with some underlying analytics.

But, what if the pivot to a Twitter-based exercise gives us an opportunity to interact with customers and get the value of spontaneous commentary rather than formal responses to questionnaires? We can do it in 2 days not three months and unlock a piece of work that is stalled because of a lack of insight. Based on previous experience in IT a flow of insights is better than a formal report that ends up being a new point of friction and this pivot is cheap enough that we can repeat it several times.

Without that capacity to pivot the business requirement is met but without any value-seeking or interaction between the different experiences of the team.

The point is to deliver value with an adaptive business goal - products shaped by customers (not analysis of segments) - rather than to a product requirement or a fixed goal and to empower everybody to do that - empower everyone, in fact, to be value-seeking rather than role fulfilling.

Relationships between business goals and a unit of work in IT needs flexibility or we all revert to fulfilling the obligations of our set roles rather than setting out to find value.

Scrum agile doesn’t help in this because in Scrum, sprints are fixed and unchangeable and were designed as such in response to Waterfall’s tendency to introduce all kinds of project creep. In reality what we are talking about in Scrum right now is “Wagile” at best.

Scrum operates in relatively large units of work and arguably fails to incorporate enough variety in skills. It encourages multidisciplinary teams but our point is that the team needs multidisciplinary people, those who can set up a just-in-time acceptance test as well as contribute to work breakdown as well as being savvy about how value is emerging and what it takes to grow it.

It is also important to realise that very few organisations have created a role that champions that flexibility. In our view that champion is a different kind of product owner than exists today.

The Scrum product owner

The product owner is a relatively new role in business. It sits somewhere between marketing and development, though product owner and product manager roles vary across organisations. Sometimes the two are confused with each other; very often the role-holders maintain a distance from IT; in other cases they are IT people who try to liaise with marketing.

Often a product owner has more of a product manager role and see his job as curating the product rather than changing it, prolonging the status quo rather than taking a chance on something new. That person becomes a blocker. However, more often than not, the bocker is the lack of clarity and inappropriate role definition. There are product owners who are never really clear about the value they should be seeking and adding. The confusion over these roles needs clearing up.

Let’s look at a definition. In Scrum Agile the product owner plays a pivotal role in the relationship between IT and the business, or at least she should.

The Scrum product owner is typically a project's key stakeholder. Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is key to successfully starting any agile software development project.”

And further:

“The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed.“

There is nothing intrinsically wrong with that definition. But its effect is that somebody called a product owner is often plonked in the middle of a relationship that has been fractious for a long time. The product owner sits in the IT-Business divide.

In effect it is saying that the product owner represents the business in its relationship with IT and is a kind of junior product manager. In reality that product owner either ends up coming from a marketing background and therefore tends not to understand IT, does not know what it is capable of delivering, and can even be aloof from IT; or the product owner comes from an IT background and simply does not know enough about business.

In the past the lack of multidisciplinary teams seemed to hold IT back but now the lack of multidisciplinary people is the problem.

Having product owners from one side or the other does not solve a big relationship problem. It just means you now have somebody to carry the can.

It’s worth mentioning here too that a product owner can be responsible for agreeing the changes to a requirement prior to a team going into a new sprint. The product owner becomes the key to unblocking old Waterfall work methods. But we have pointed out elsewhere that many of the problems of Waterfall persist. The example we gave in Step 5 is that very often the use of Lean techniques like MVPs introduce more suspicion. Product managers think of the idea of a minimal viable product as the threat of a minimal commitment to delivery. As a consequence they overfill their requirements with features, sure (!) that IT will jettison essential development tasks in order to keep work to a minimum.

These definitions and roles arose out of an attempt to solve an old set of problems - change control and controlling requirement creep, the practice where new requirements creep into a project and throw planning and quality control out of kilter.

In the context of solving problems associated with monolithic projects they created a mechanism for managing conflicts where no mechanism existed before. They made somebody responsible for establishing some kind of order, truce, fixed point of stability, call it what you will.

But this was always a vague role, maybe doesn’t work as well as hoped and is arguably no longer so relevant when the whole system of creating value is open to change. We are moving to environments where multiple innovations occur every day and therefore we need roles, skills and relationships that fit with the tensions, and creativity, caused by a constant flow of innovation.

Most organisations need to work with a matrix of new features that they can regularly push to customers rather than one minimally viable product. That’s why we coined the term minimum sustainable delivery (MSD) or the optimal feature set for getting a sustainable degree of interaction with customers.

We need developers who understand more about the business and how it is changing into a matrix of shifting feature priorities, as well as knowing users and value creation.

If we are going to have product owners they need to be people who understand what capabilities IT now has, so they know how to get the most out of it for customers.

They need to understand the sources of feedback data and what it is telling the team about the performance of new features and functions; they need to be able to spot ecosystem activity that can be nurtured and microtrends that offer immediate opportunities. In short, we think this new product owner should be a value-discovery agent.

The new product owner

The new product owner needs to be a special kind of person.

In software-driven companies marketing is actually an IT-driven task. It is integral to the real-time assessment of a product or feature. That means the product owner has to master social data, analytics, call-centre data, trend insights, conversion performance, DevOps capabilities, application usage and so on.

Not many companies set themselves up to deal with these challenges or to get somebody to champion solutions to them. Real-time feedback loops are an important feature of the overall flow of value. What are those loops?

  1. Real-time analytics from call-centres (this is much easier now that companies are introducing call-centre bots).

  1. Real-time web analytics (assessments of where people come to when they arrive at your site, the pages they visit, the time they spend on a page, the actions they take).

  1. Real-time usage analytics (many products now have a data gathering function and can provide real-time usage data).

  1. Real time social media analytics (data from social media sources providing a real-time insight into what people are saying about you).

  1. Sharing behaviour (who shares your products or information with whom)

That last point reminds us that shareability has to be designed into everything.

These data sources should be the platform for new capabilities and new roles.

Often, however, companies will outsource social media and data collection tasks to an agency or will create artificial barriers that mean data needs a sign-off before it arrives at the product owner’s desk.

An additional problem is that development teams that are busy with sprints will be committed to a course of action over a 2-3 week period and won’t have any use for real-time data. Real-time is defined out of their work by the sprint (no changes to requirements shall be made during the sprint!!).

In the system we have described over the previous eight steps, however, you’ll note we have emphasised:

No projects - a move away from thinking about projects with a traditional beginning, middle, end milestone and deliverable.

Very small units of work - 1-2 day units of work that encourage people to bring work back to the Wall very often and therefore encourage social interaction.

Co-creating processes - highly visual work breakdown where as many people as necessary engage in defining priorities and how an objective should be reached (the process and tools).

Flexibility in goals and units of work - frequent interaction between developers and product owners and quick decision-making on whether a specification of work should change or a goal should change.

Informality - frequent informal acceptance agreements so that work can be kept moving.

Value-seeking behaviour - using multiple strategies to question if work has value and how value can be increased.

Experimentation - using hypothesis about what might add value and finding a way to test these, usually by pushing a matrix of features through to customers before committing to full development of any one of those features.

In this fast moving environment the product owner becomes the glue that holds a lot of this activity together. Given that there is much more interaction with daily deliveries, the team needs somebody whose main skills include:

  • Having a tangible, role-defined commitment to customer value, if not as a P&L owner then at least as somebody who is prepared to define customer-centric metrics into their role.

  • Understanding the major trends in IT and IT capability.

  • Engaging fully in work breakdown activities and understanding how to create units of work that stimulate daily interaction.

  • Knowing how to balance business goals, IT capabilities and user insights on the fly.

  • Knowing the data sources and interpreting data in real time.

  • Interpreting the thinking of marketers.

  • Knowing how to set up experiments to test new ideas.

  • Participating in just-in-time acceptance tests.

  • Being an advocate for value over being an advocate for IT or marketing.

This is a demanding set of skills for anybody to aspire to but here is the reality. Most organisations need marketing people that have a strong IT capability. Perhaps this is why the literature refers to these people as Digital Marketers. They may not need to code (but great if they can) but they do need to know how IT is growing its value-adding competency. At the same time both marketers and IT people need to grasp that innovation is a daily practice. When that happens firms need a mantra to help structure and focus work. The mantra that makes most sense is that we are here to seek value. The new product owner has to lead that charge.

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly