Return to site

Step 9: The road to value

Product owners and marketers, developers and testers, business analysts and you

· 12 Steps

In Flow, we believe in interdisciplinary people. Interdisciplinary teams are great but life is better when people step up and fill different roles. Partly that's because of how novel many areas of work life have become, a point we don't need to iterate too much on here other than to say not much can get done if people insist on doing just what they were hired for. But the fungible player is also a key to speed and bridging the IT-Business divide.

In this chapter we are going to talk about roles and how to encourage multidisciplinary people. Another point we make in Flow is that you cannot buy it as a solution. Digital transformation in general requires people to transform how they see themselves in work, why they show up and how they perform. To get people into these new mindsets requires a relationship skill or a set of relationship skills. There isn't a piece of software for it. But people can catch quickly.

The problem, often, is that many organisations create huge confusion around significant roles. 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.

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

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.

An example of that from software is the tester.

Software test suites are usually written by inexperienced developers. Because testing is undervalued, the work is given to people who are generally new and need projects to cut their teeth on. The result is that quality is often seriously compromised because developers cannot meet the test requirements and the software has to be pushed through anyway or the project risks becoming an overrun. In effect, the firm allows itself to be held captive to inexperience.

Similarly in marketing the arrival of social media created a lot of menial work. Tweeting on behalf of a client can be a career entry path in an agency but let's face it, the work is empty.

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 or Amazon 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 product 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 to Big Change). Key to this is transforming the product owner into a catalyst for value.

Pivotal roles

Product owner and product management roles come in various guises. They are kind of critical to the business but it is a difficult role to define so always difficult to hold it up as a reason for success or failure. The responsibilities vary depending on where you work.

The role came to prominence because of agile methodology, which assigns responsibilities like product definition and vision, backlog grooming and stakeholder relationships to the product owner. But it is a problem when your role is defined by IT culture. A good product owner should understand the coding environment but should also be very cognisant of marketing requirements - after all an increasing amount of marketing goes through the IT shop to a website.

A good product owner would also be able to support the work breakdown process because they and business analysts are critical to translation of business goals into units of work. In fact the role is summarised below and you can see straight away that it is a role for more than one person or a role for one person with tremendous variety in their background.

Very often a good product owner will be an excellent business analyst and by excellent we mean capable of changing business goals when necessary. The most overlooked skill of all is knowing when business goals have to change or when a project can be unblocked by flexibility in business goals.

Many of these skills, however, as missing from people that are given the product owner role. Let's look at that.

A typical workflow

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.

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. What you really need is something like this:

A simple modern for the relationship between goals and work

The pivotal role of the product owner is to mediate between the experiences of trying to develop a product or feature and the goals that are driving it. Traditionally, if there is such a thing in agile, the product owner would create the requirement that would then be handed on to the developer team, with some conversation about the vision alongside it. However, when you operate with small units of work this changes. The priority becomes the iteration cycle above. Breaking the work down to small units, getting some experience with coding them, maybe running some rough tests on their acceptability, gathering customer feedback where possible, and then seeing how those impact the business goals. This is the only way to create value as distinct from delivering a project.

And being adaptive means making “pivot” decisions at the last possible final point of commitment. We prefer to think of this as iterative experimentation rather than fail-fast, fail-cheap by the way.

An example

You may have a requirement to undertake a survey through a website and this requirement can be baked into the workflow. The survey is specifically the product owner's job.

The business goal is to understand customer needs in a way that shapes product design in the short term, as a particularly interesting product is getting too little traction.

Here you have the nub of what the product owner is about. She has to understand what customers want know how to get to that understanding in a timely way, and negotiate some adaptation to the IT backlog to get the survey work done quickly.

But maybe this is done better and quicker by developing a set of interactions that would play out via Twitter, a Twitter survey (a favourite example of ours you may have noticed).

Now the product owner has a choice. In Flow we want to get work done in small units and two-day cycles. So the survey idea in a traditional form could just take too long. She decides the twitter option gives her a way to stimulate the web team with a challenging project (always gamify when you can) and gives her a chance to get hold of the additional data she needs if she is going to persuade her market4ing colleagues and IT colleagues that a pivot is needed.

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 page and a landing page with some underlying analytics.

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. This pivot is cheap enough that we can repeat it several times. The key to it though is pivoting the business goal. it will no longer be "understanding customer needs in specific segments". It will be "a snapshot of customer commentary"

Weighing the benefits of speed and completion against comprehensiveness and depth is important. Projects that take months often get forgotten or buried in the frenetic clamour for resources.

Without that capacity to pivot the business requirement is met but without any real questioning of the goal itself. That means true value-seeking behaviour is minimised. The pivot also arises from real interaction between the different experiences of the overall team, which is way better for morale and might produce a result that people buy into more easily. Social interaction is a key component of it.

The point is that the product owner's job is to deliver value within the context of an adaptive business goal. Products are shaped by customers (not analysis of trends). The product owner moves away from a rigid product requirement or a fixed goal to something far more adaptive. To empower everybody to do that is to empower everyone, in fact, to become value-seeking rather than role fulfilling.

The Scrum product owner

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 of 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.

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.

The new product owner needs those skills we drew out at the top of this chapter. Here too is a way to manage this. We talk later about personal learning goals nd one way to curate your own goals is to develop learning management system. Haydn uses sheets of A3 paper to set out a whole project and all the things he has to manage in any given project. Take an A3 and sketch out your knowledge and objectives in these areas:"

Relationship management - Where was that two-day course when you need it! Knowing how to manage the expectations of disparate groups is a key art but very little in the way of training is around. Our advice - authenticity. Don't go out there trying to please people. Get the focus on value and be mildly relentless about it. We're all here to create value so keep that in front of people without berating them.

Market analysis - Good customer segmentation can often be achieved with social listening tools which is a key to developing better customer segmentation but market insights is more. It also includes competitors but of critical importance is understanding how and why people share. Sharing needs to be built into product design. It's a new skill and rarely developed to its full extent.

Customer segmentation - companies pay too little attention to segments and their needs. In the long tail economy this is disastrous, so product owners need to get onto it.

Developer process insight - Understanding how IT processes are changing is critical to raising the ambition levels of the business. Listen in as IT shifts over to DevOps and micro services or pulls in some low code skills.

Requirements setting and goal management - It is a traditional area but how good at it are you? In Flow we tend to think of requirements setting as iterative with the developer team as we break work down into those small units we keep talking about, and we see goal management as critical to getting work done.

Workload management - A product owner has to get products into the development process so having an eye for workload makes a whole lot of sense. Fin prefers his product owners embedded with the developer team so that they intuitively know where the pressures are and when an opportunity to introduce new work will crop up.

Real time customer feedback management - Pulling data from the call centres, social listening tools, customer labs, surveys and conversations all tell you what you are doing right and wrong.

Acceptance testing - Be prepared to play a role in activities like acceptance tests.

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 and the role of the product owner/business analyst. What are those loops?

  1. Real-time analytics from call-centres (this is much easier now that companies are introducing call-centre bots).
  2. 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).
  3. Real-time usage analytics (many products now have a data gathering function and can provide real-time usage data).
  4. Real time social media analytics (data from social media sources providing a real-time insight into what people are saying about you).
  5. Sharing behaviour (who shares your products or information with whom?)

In the system we have described over the previous eight steps, however, you’ll note we have also 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:

They need a demanding set of skills 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