Managing Digital: Concepts and Practices

Before work, before operations, there must be a vision of the product. You already established a preliminary vision in Chapter 1, but now as your organization grows, you need to consider further how you will sustain that vision and establish an ongoing capability for realizing it. Like many other topics in this book, product management is a significant field in and of itself. Historically, product management has not been a major theme in enterprise IT management. Digital changes this.

IT systems started by serving narrow purposes, often “back office” functions such as accounting or materials planning. Mostly, such systems were managed as projects assembled on a temporary basis, resulting in the creation of a system to be “thrown over the wall” to operations. Product management, on the other hand, is concerned with the entire lifecycle. The product manager (or owner, in Scrum terms) cares about the vision, its execution, the market reaction to the vision (even if an internal market), the health, care, and feeding of the product, and the product’s eventual sunset or replacement.

In the enterprise IT world, “third party” vendors (e.g.,IBM) providing the back-office systems had product management approaches, but these were external to the IT operations. Nor were IT-based product companies as numerous 40 years ago as they are today; as noted in Chapter 1, with digital transformation, the digital component of modern products continues to increase to the point where it’s often not clear whether a product is “IT” or not.

Reacting to market feedback and adapting product direction is an essential role of the product owner. In the older model, feedback was often unwelcome, as the project manager typically was committed to the open-loop dead reckoning of the project plan and changing scope or direction was seen as a failure, more often than not.

Now, it’s accepted that systems evolve, perhaps in unexpected directions. Rapidly testing, failing fast, learning, and pivoting direction are all part of the lexicon, at least for market-facing IT-based products. And even back-office IT systems with better understood scope are being managed more as systems (or products) with lifecycles, as opposed to transient projects. (See the Amazon discussion, below).

So, what is product management and what does it mean for your team? ^[1]

In order to define product management, we first need to define the product. In Chapter 1, we established that products are goods, services, or some combination, with some feature that provides value to some consumer. BusinessDictionary.com defines it thus:

Product management, according to the same source, is:

Product management in the general sense often reports to the Chief Marketing Officer (CMO). It represents the fundamental strategy of the firm, in terms of its value proposition and viability. The product needs to reflect the enterprise’s strategy for creating and maintaining customers.

Product strategy for internally-facing products is usually not defined by the enterprise CMO. If it is a back-office product, then “business within a business” thinking may be appropriate. (Even the payroll system run by IT for HR is a “product,” in this view). In such cases, there still is a need for someone to function as an “internal CMO” to the external “customers.”

With digital transformation, all kinds of products have increasing amounts of “IT” in them. This means that an understanding of IT, and ready access to any needed IT specialty skills, is increasingly important to the general field of product management. Product management includes research and development, which means that there is considerable uncertainty. This is of course also true of IT systems development.

Perhaps the most important aspect of product design is focusing on the user, and what they need. The concept of outcome is key. This is easier said than done. The general problem area is considered Marketing, a core business school topic. Entire books have been written about the various tools and techniques for doing this, from focus groups to ethnographic analysis.

However, Marty Cagan recommends distinguishing Product Management from Product Marketing. He defines the two as follows:

The product manager is responsible for defining—in detail—the product to be built and validating that product with real customers and users. The product marketing person is responsible for telling the world about that product, including positioning, messaging and pricing, managing the product launch, providing tools for the sales channel to market and sell the product, and for leading key programs such as online marketing and influencer marketing programs [50 pp. 10-11].

We discuss some criticisms of overly marketing-driven approaches below.

In the remainder of this book, we will continually encounter three major topics:

They have an important commonality: all of them are concepts for driving results across organizations. Here are some of the key differences between process, project, and product management in the context of digital services and systems:

The above distinctions are deliberately exaggerated, and there are of course exceptions (short projects, processes that take years). However, it is in the friction between these perspectives we see some of the major problems in modern IT management. For example, an activity which may be a one-time task or a repeatable process results in some work product—​perhaps an artifact (see Activities create work products).

The consumer or stakeholder of that work product might be a Project Manager.

Project management includes concern for both the activities and the resources (people, assets, software) required to produce some deliverable (see Projects create deliverables with resources and activities).

The consumer of that deliverable might be a product manager. Product management includes concern for projects and their deliverables, and their ultimate outcomes, either in the external market or internally (see Product management may use projects).

Notice that product management may directly access activities and resources. In fact, earlier-stage companies often do not formalize project management (see Product management sometimes does not use projects).

In our scenario, you are now on a tight-knit, collaborative team. You should think in terms of developing and sustaining a product. However, projects still exist, and sometimes you may find yourself on a team that is funded and operated on that basis. You also will encounter the concept of “process” even on a single team; more on that in Chapter 5. We will go further into projects and process management in Part III.

Amazon (the online retailer) is an important influence in the modern trend towards product-centric IT management. First, the founder Jeff Bezos mandated that all software development should be service-oriented. That means that some form of standard Application Programming Interface (API) was required for all applications to communicate with each other. By some accounts, Bezos threatened to fire anyone who did not do this. Second, all teams are to assume that the functionality being built might at some point be offered to external customers [165].

Third, a widely reported practice at Amazon.com is the limitation of product teams to between 5-7 people, the number that can be fed by “two pizzas” (depending on how hungry they are) [106] (see Two pizzas, one team ^[2]). It has long been recognized in software and IT management that larger teams do not necessarily result in higher productivity. The best known statement of this is "Brooks' Law” from The Mythical Man-Month, that “adding people to a late project will make it later” [36].

The reasons for “Brooks' Law” have been studied and analyzed (see e.g., [176, 59]) but in general, it is due to the increased communication overhead of expanded teams. Product design work (of which software development is one form) is creative and highly dependent on tacit knowledge, interpersonal interactions, organizational culture, and other “soft” factors. Products, especially those with a significant IT component, can be understood as socio-technical systems, often complex. This means that small changes to their components or interactions can have major effects on their overall behavior and value.

This, in turn, means that newcomers to a product development organization can have a profound impact on the product. Getting them “up to speed” with the culture, mental models, and tacit assumptions of the existing team can be challenging and rarely is simple. And the bigger the team, the bigger the problem. The net result of these two practices at Amazon (and now General Electric and many other companies) is the creation of multiple nimble services that are decoupled from each other, constructed and supported by teams appropriately sized for optimal high-value interactions.

Team collaboration is one of the key values of Agile. The Agile Alliance states that:

A “team” in the Agile sense is a small group of people, assigned to the same project or effort, nearly all of them on a full-time basis.

Teams are multi-skilled, share accountability, and individuals on the team may play multiple roles [7]:

Face to face interactions, usually enabled by giving the team its own space, are seen as essential for collaboration. While there are various approaches to Agile, all concur that tight-knit, collaborative teams deliver the highest value outcomes. However, collaboration does not happen just because people are fed pizzas and work in a room together. Google has established that the most significant predictor of team performance is a sense of psychological safety (see sidebar).

Research by Anita Woolley and colleagues suggests that three factors that drive team performance are [287]:

Other research shows that diverse teams and organizations are more innovative and deliver better results; such teams may tend to focus more on facts (as opposed to groupthink) [224]. Certainly, a sense of psychological safety (Psychological safety supports collaboration ^[3]) is critical to the success of diverse teams, who may come from different cultures and backgrounds that don’t inherently trust each other.

We turn to two current schools of thought with much to say about collaboration: Lean UX and Scrum.

Lean UX is a term coined by author and consultant Jeff Gothelf [111], which draws on three major influences:

We briefly discussed Lean Startup in Chapter 1, and the history and motivations for Agile software development in Chapter 3. We’ll look in more depth at product discovery techniques, and design and design thinking in the next chapter section. However, Lean UX has much to say about forming the product team, suggesting (among others) the following principles for forming and sustaining teams:

(Other Lean UX principles such as small batch sizes and visualizing work will be discussed elsewhere; there is significant overlap between Lean UX and other schools of thought covered in this book).

Lean UX is an influential work among digital firms and summarizes modern development practices well, especially for small, team-based organizations with minimal external dependencies. It is a broad and conceptual, principles-based framework open for interpretation in multiple ways. We continue with more “prescriptive” methods and techniques, such as Scrum.

One of the first prescriptive Agile methodologies you are likely to encounter as a practitioner is Scrum. There are many books, classes, and websites where you can learn more about this framework; [251] is a good brief introduction, and [232] is well suited for more in-depth study.

Scrum is appropriate to this chapter, as it is product-focused. It calls for the roles of:

and avoids further elaboration of roles.

The Scrum product owner is responsible for holding the product vision and seeing that the team executes the highest value work. As such, the potential features of the product are maintained in a “backlog” that can be re-prioritized as necessary (rather than a large, fixed-scope project). The product owner also defines acceptance criteria for the backlog items. The Scrum master, on the other hand, acts as a team coach, “guiding the team to ever-higher levels of cohesiveness, self-organization, and performance” [251]. To quote Roman Pichler:

The product owner and Scrum master roles complement each other: The product owner is primarily responsible for the “what"—creating the right product. The Scrum master is primarily responsible for the “how"—using Scrum the right way [210 p. 9].

Scrum uses specific practices and artifacts such as sprints, standups, reviews, the above-mentioned concept of backlog, burndown charts, and so forth. We will discuss some of these further in Chapter 5 (Work Management) and Chapter 7 (Coordination) along with Kanban, another popular approach for executing work.

In Scrum, there are three roles:

There are seven activities:

There are a number of artifacts:

Scrum is well grounded in various theories (process control, human factors), although Scrum team members do not need to understand theory to succeed with it. Like Lean UX, Scrum emphasizes high-bandwidth collaboration, dedicated multi-skilled teams, a product focus, and so forth.

The concept of having an empowered product owner readily available to the team is attractive, especially for digital professionals who may have worked on teams where the direction was unclear. Roman Pichler identifies a number of common mistakes, however, that diminish the value of this approach [210 pp. 17-20]:

Marty Cagan suggests that the product team has three primary concerns, requiring three critical roles [50]:

Jeff Patton represents these concepts as a Venn diagram (see The three views of the product team footnote:[similar to [208]).

Finally, a word on the product manager. Scrum is prescriptive around the product owner role, but does not identify a role for product manager. This can lead to two people performing product management: a marketing-aligned “manager” responsible for high-level requirements, with the Scrum “product owner” attempting to translate them for the team. Marty Cagan warns against this approach, recommending instead that the product manager and owner be the same person, separate from marketing [50 pp. 7-8].

In the next chapter, we will consider the challenge of product discovery -— at a product level, what practices do we follow to generate the creative insights that will result in customer value?

In Chapter 3, we needed to consider the means for describing system intent. Even as a bare-bones startup, some formalization of this starts to emerge, at the very least in the form of test-driven development (see Product discovery tacit).

But, the assumption in our emergence model is that more formalized product management emerges with the formation of a team. As a team, we now need to expand “upstream” of the core delivery pipeline, so that we can collaborate and discover more effectively. Notice the grey box in Product discovery explicit.

The most important foundation for your newly formalized product discovery capability is that it must be empirical and hypothesis-driven. Too often, product strategy is based on the Highest Paid Person’s Opinion (HiPPO). (Beware of HiPPO-based product discovery ^[4]).

The problem with relying on “gut feeling” or personal opinions is that people -— regardless of experience or seniority -— perform poorly in assessing the likely outcome of their product ideas. Some well known research on this topic was conducted by Microsoft’s Ronny Kohavi. In this research, Kohavi and team determined that “only about 1/3 of ideas improve the metrics they were designed to improve” [160]. As background, the same report cites that:

It is, therefore, critical to establish a strong practice of data-driven experimentation when forming a product team and avoid any cultural acceptance of “gut feel” or deferring to HiPPOs. This can be a difficult transition for the company founder, who has until now served as the de facto product manager.

A useful framework, similar to Lean Startup is proposed by Spotify, in the “DIBB” model:

Data leads to insight, which leads to a hypothesis that can be tested (i.e., “bet” on — testing hypotheses is not free). We discuss issues of prioritization further in Chapter 5, in the section on cost of delay.

Don Reinertsen (whom we will read more about in the next chapter) emphasizes that such experimentation is inherently variable. We can’t develop experiments with any sort of expectation that they will always succeed. We might run 50 experiments, and only have 2 succeed. But if the cost of each experiment is $10,000, and the two that succeeded earned us $1 million each, we gained:

Not a bad return on investment! (See [220], Chapter 4, for a detailed, mathematical discussion, based on options and information theory).

Roman Pichler, in Agile Product Management with Scrum, describes “old-school” versus “new-school” product management as in Old school versus new school product management (summarized from [210], p. xii).

There are a wide variety of techniques and even “schools” of product discovery and design; we will consider a few representatives in this chapter section. Of course, when you first started your journey in Chapter 1, you might also have used some of these techniques. But now that you are a team, you are formalizing and relying on these techniques. These techniques are not mutually exclusive; they may be complementary. But at the more detailed, digital product level, how do we develop hypotheses for testing, in terms of our products/services? We briefly mentioned User Story Mapping in our discussion of system intent. In product discovery terms, User Story Mapping is a form of persona analysis. But that is only one of many techniques. Roman Pichler mentions “Vision Box and Trade Journal Review” and the “Kano Model” [210 p. 39]. Here, let’s discuss:

Design thinking is a recent trend with various definitions, but in general, combines a design sensibility with problem solving at significant scale. It usually is understood to include a significant component of systems thinking. As Tom Fisher, author of Designing Our Way to a Better World [91], notes:

We’ve been doing a lot of work in this area of “design thinking,” which takes the thought process and the methods that have been developed for millennia around the design of physical things — products, buildings, cities — and applies that to the so-called invisible world of design, which is all of the systems and organizations that are designed, but we don’t think of them as being designed. And we’re seeing a lot of these systems not working very well. [209]

Design thinking is the logical evolution of disciplines such as user interface design when such designs encounter constraints and issues beyond their usual span of concern. Although it has been influential on Lean UX and related works, it is not an explicitly digital discipline.

There are many design failures in digital product delivery. What is often overlooked is that the entire customer experience of the product is a form of design.

Consider for example Apple. Their products are admired worldwide and cited as examples of “good design.” Often, however, this is only understood in terms of the physical product, for example, an iPhone or a MacBook Air. But there is more to the experience. Suppose you have technical difficulties with your iPhone, or you just want to get more value out of it. Apple created its popular Genius Bar support service (see Apple Genius Bar ^[6]), where you can get support and instruction in using the technology.

Notice that the product you are using is no longer just the phone or computer. It is the combination of the device PLUS your support experience. This is essential to understanding the modern practices of design thinking and Lean UX. As Jeff Sussna, author of Designing Delivery, notes, “In order to provide high-quality, digitally infused service, the entire delivery organization must function as an integrated whole.” [261 p. 18].

The concept of hypothesis testing is key to product discovery and design. The power of scalable cloud architectures and fast continuous delivery pipelines has made it possible to test product hypotheses against real-world customers at scale and in real time. Companies like Netflix and Facebook have pioneered techniques like "canary deployments” and "A/B testing.”

In these approaches, two different features are tried out simultaneously, and the business results are measured. For example, are customers more likely to click on a green button or a yellow one? Testing such questions in the era of packaged software would have required lab-based usability engineering approaches, which risked being invalid because of their small sample size. Testing against larger numbers is possible, now that software is increasingly delivered as a service.

At a lower level than the holistic concerns of design thinking, we have practices such as usability engineering. These take many forms. There are many systematic and well-researched approaches to usability, interaction design [71, 135, 267, 18], visualization [52, 270] and related topics. All such approaches, however, should be used in the overall Lean Startup/Lean UX framework of hypothesis generation and testing. If we subscribe to design thinking and take a whole-systems view, designing for ease of operations is also part of the design process. We will discuss this further in Chapter 6. Developing documentation of the product’s characteristics, from the perspective of those who will run it on a day-to-day basis, is also an aspect of product delivery.

THUNK!

Hello. Where did you come from?

I fell. From that machine.

Machine?

Yes, that big loud thing that just passed by. And is now stopped over there.

Why is it stopped?

Because I am no longer with it. The machine needs me to function. I am called a “cog.” Where did you come from?

I am a flower. I grew from a seed.

You …​ grew?

Yes.

You mean, no-one planned or designed you?

Not that I know of. What does it mean to be “designed” or “planned"?

I am part of a greater whole. The need for me was understood when that greater whole was conceived. I was designed to fit a very particular place.

They had to try making me out of different metals, and different ways to make me. This took some time and effort -— longer than was planned, in fact. But it was always understood that there would need to be a cog in a certain place in the machine.

Interesting. So you will never be more than you are?

No. I will always be a cog. They might make a different machine, with different cogs, but they will not be me. Are you part of a machine?

No. I grew here because it suited me. I have continued to grow for a couple years. Eventually, I may grow 20 feet tall if the conditions remain good. I can adapt to other plants, and find my way around them to the sunlight and the water I need. Or I may stay smaller if I can’t get the sunlight I need. Or I may die.

Aren’t you part of a system that defines your purpose?

I don’t know. Sometimes I think I am a system myself, made up of my roots, stem, leaves, and flower. There are insects living on me who rely on me for food and shelter. And I have the freedom to grow into one of the largest trees in this area. That is worth it to me.

Interesting. Well, it is good you are growing where you are, and not 20 feet further in that direction.

Why?

Because when they find me, or replace me and fix the machine, it will continue to clear all the land over there.

Oh.

VOICES: “Hey Joe, here’s that gear the tractor must have thrown.”

“Good, grab it, and I’ll see if I can’t get it back in place at least temporarily until we can figure out why it happened.”

Bye.

Goodbye. Nice talking to you. Good luck.

Thanks. You too.

Some of the most contentious discussions related to IT management and Agile come at the intersection of software and systems engineering, especially when large investments are at stake. We call this the “discovery versus design” problem.

Frequent criticisms of Lean Startup and its related digital practices are:

The parable in the previous section is meant to illustrate two very different product development worlds. Some product development is constrained by the overall system it takes place within. Other product development has more freedom to grow in different directions -— to “discover” the customer.

The cog represents the world of classic systems engineering -— a larger objective frames the effort, and the component occupies a certain defined place within it. And yet, it may still be challenging to design and build the component, which can be understood as a product in and of itself. Fast feedback is still required for the design and development process, even when the product is only a small component with a very specific set of requirements.

The flower represents the market-facing digital product that may “pivot,” grow and adapt according to conditions. It also is constrained, by available space and energy, but within certain boundaries has greater adaptability.

Neither is better than the other, but they do require different approaches. In general, we are coming from a world that viewed digital systems strictly as cogs. Subsequently, we are moving towards a world in which digital systems are more flexible, dynamic, and adaptable.

And, when digital components have very well understood requirements, usually we purchase them from specialist providers (increasingly “as a service”). This results in increasing attention to the “flowers” of digital product design since acquiring the “cogs” is relatively straightforward (more on this in the Chapter 8 section on sourcing).

Creating effective plans in complex situations is hard. Planning a new product is one of the most challenging endeavors, one in which failure is common. As the Don Reinertsen quote above reflects, the historically failed approach (call it the "planning fallacy”) is to develop overly detailed (sometimes called “rigorous”) plans and then assume that achieving them is simply a matter of “correct execution” (see Planning fallacy).

Contrast the planning fallacy with Lean Startup, which emphasizes ongoing confirmation of product direction through experimentation. In complex efforts, ongoing validation of assumptions and direction is essential, which is why overly plan-driven approaches are falling out of favor. However, some understanding of timeframes and mapping goals against the calendar is still important. Exactly how much effort to devote to such forecasting remains a controversial topic with digital product management professionals, one we will return to throughout this book.

Minimally, a high-level product roadmap is usually called for: without at least this, it may be difficult to secure the needed investment to start product work. Roman Pichler recommends the product roadmap contain:

More detailed understanding is left to the product backlog, which is subject to ongoing “grooming”, that is, re-evaluation in light of feedback.

The product discovery and roadmapping activity ultimately generates a more detailed view or list of the work to be done. As we previously mentioned, in Scrum and other Agile methods this is often termed a backlog. Both Mike Cohn and Roman Pichler use the DEEP acronym to describe backlog qualities [67 p. 243, 210 p. 48]:

The backlog should receive ongoing “grooming” to support these qualities, which means several things:

When “detailed appropriately,” items in the backlog are not all the same scale. Scrum and Agile thinkers generally agree on the core concept of "story,” but stories vary in size (see Backlog granularity and priority footnote:[similar to [210]), with the largest stories often termed “epics.” The backlog is ordered in terms of priority (what will be done next) but, critically, it is also understood that the lower-priority items, in general, can be larger grained. In other words, if we visualize the backlog as a stack, with the highest priority on the top, the size of the stories increases as we go down. (Reinertsen terms this progressive specification; see [219 pp. 176-177] for a detailed discussion).

Estimating user stories is a standard practice in Scrum and Agile methods more generally. Agile approaches are wary of false precision and accept the fact that estimation is an uncertain practice at best. However, without some overall estimate or roadmap for when a product might be ready for use, it is unlikely that the investment will be made to create it. It is difficult to establish the economic value of developing a product feature at a particular time if you have no idea of the cost and/or effort involved to bring it to market.

At a more detailed level, it is common practice for product teams to estimate detailed stories using “points.” Mike Cohn emphasizes, “Estimate size, derive duration” ([66], p. xxvii). Points are a relative form of estimation, valid within the boundary of one team. Story point estimating strives to avoid false precision, often restricting the team’s estimate of the effort to a modified Fibonacci sequence, or even T-shirt or dog sizes [66 p. 37] as shown in Agile estimating scales ^[7].

Mike Cohn emphasizes that estimates are best done by the teams performing the work [66 p. 51]. We’ll discuss the mechanics of maintaining backlogs in Chapter 5, Work Management.

Backlogs require prioritization. In order to prioritize, we must have some kind of common understanding of what we are prioritizing for. Mike Cohn, in Agile Estimating and Planning, proposes that there are four major factors in understanding product value:

In Chapter 5 we will discuss additional tools for managing and prioritizing work, and we will return to the topic of estimation in Chapter 8.

Books

Articles

Videos

Professional