We didn’t do anything wrong, but somehow, we lost.

—Nokia CEO, Stephen Elop


To set the stage for this chapter, try answering each of the following statements with Agree or Disagree. Answers appear at the end of the chapter.




Schedule, budget, and scope are the best ways to measure project success.

Product management is an essential practice for Product Owners.

A Product Owner should act as a proxy between the business and technology.

A Product Owner establishes a vision for a product.

Scrum provides all the tools necessary for successful product management.

Every development effort has a product.


A project starts with an idea. If the idea sounds promising, a project can be initiated to make it a reality.

Important projects require organization and accountability. This is where a project manager comes in. A project manager is someone skilled in managing tasks and people, but not necessarily knowledgeable or passionate about the domain.

This project manager gathers enough information to create a plan. The plan will outline in detail the scope of the initiative over several project milestones and estimate how much time and money will be needed to complete it all. That manager then asks for resources (including people), forms a team around the project, and keeps each team member on task to ensure a successful outcome. Success is ultimately measured by how closely the project manager sticks to the initial plan—scope, time, budget.

This seems perfectly reasonable—at first.

But what about projects that remain on time, on budget, and within scope, and yet still do not succeed? For years, Nokia led the market in producing mobile phones. It delivered phone after phone on tight schedules. It knew how to run a project, and each individual project likely succeeded. But what about the company’s phones? Is Nokia still around? Yes, as a department of Microsoft. What is interesting is that Microsoft paid more for Skype ($8.6 billion), a few hundred person services company, than it did for Nokia ($7.2 billion), a company that at one point had vast infrastructure, millions in hardware assets, and 100,000 employees.

If you or your company think in terms of projects and less in terms of products and value, the tide of fortune can turn rather quickly.

Interestingly, the word “project” used to mean to do something before (pro-) acting (-ject). In the 1950s, project management became more mainstream with the introduction of several techniques within the engineering and defense industries. This expanded the definition of “project” to include both planning and execution and has since expanded to hundreds of techniques across many other industries.

Don’t worry, this is not a project management book. However, an understanding of the current state of project management should provide some context for why we wrote it.

This project mindset (see Figure 1-1) defines success from the “inside out,” using internal measurements that are more about task management and about how accurately the initial plan was followed.

Figure 1-1 Visual representation of a project mindset

What is the alternative?

What do your customers value? Projects or products? The objective is not to deliver projects but to deliver value through products—products that ultimately lead to higher revenue and lower costs for your organization. Products that are so great that your customer base will grow and existing customers will stick around.

So forget about projects. Approach your idea and its business case as a product. Give your product idea to a capable team and introduce them to meaningful business targets such as user adoption, sales, and stakeholder satisfaction. Impress on the team that the only way to influence targets like these is to release something of value as soon as possible and validate your business assumption.

Now that the team has the proper mindset, the next question should be: “What can we ship first that will have the biggest impact on our targets?”

Suddenly, delivery and business start to align and bridge their communication gap.

This product mindset (see Figure 1-2) is an “outside in” approach that uses external measurements to actively guide the development of the product to maximize value.

Figure 1-2 Product versus project mindset

A product mindset:

encourages more frequent releases, which results in earlier feedback from the marketplace;

communicates objectives instead of tasks; teams get more creative with their solutions and take more ownership over their plans; and

eliminates waste by depending less on task assignment, reporting, and management decisions.

Contrast this with the project mindset, which leads to:

less business involvement;

more handoffs;

more task management; and

more people management.

But what if there isn’t a product?

Read on. Later in this chapter, we make the case that software development always involves a product.


Figure 1-3 shows the different layers of planning within an organization that develops products of any kind. At the core of any Scrum-based approach is a daily plan within a Sprint plan. (Sprints and Sprint Planning are described in Chapters 5 and 6.) Both these plans belong to the Development Team that is doing the work. They have autonomy in developing a plan on how to best meet the Sprint Goal and inspect and adapt that plan every day.

Figure 1-3 The different layers of planning

The two outside planning layers are the overall company vision and business strategy. Both are typically owned by an executive team or CEO, who establishes and communicates a company-wide vision and promotes an overall strategy under that vision.

In between the larger organizational goals and the work that Development Teams do day-to-day is a gap (see Figure 1-4).

Figure 1-4 The Product Management Vacuum

We call this the Product Management Vacuum, and it is a major motivation for writing this book.


The thing about any vacuum is that it has an innate need to be filled.

If you are not careful, the Product Management Vacuum will get filled with meaningless busy work and extensive task management, often guided by project metrics as described earlier. All the layers of budgeting, project charters, handoffs, and tasks breakdown mask the true intention of the initiative. You run the risk of being busy without a clear direction.

The bigger the vacuum:

the more disconnected the technology groups are from the business;

the less engaged the people on the ground become;

the more reliance there is on project and task management;

the more hierarchies and handoffs emerge;

the more complexity is introduced;

the harder it is to shift directions when the business climate changes;

the more “busy work” is created;

the more waste and rework occurs; and

the less value is delivered to customers.

True product management is about embodying agility throughout the whole organization from the top down to the bottom and thereby filling the Product Management Vacuum. Done right, this creates a true competitive advantage.

To fill the vacuum the right way, use the three Vs shown in Figure 1-5. Figure 1-6 represents how the three Vs fill the vacuum.

Figure 1-5 The three Vs

Figure 1-6 How Vision, Value, and Validation fill the Product Management Vacuum

Let’s take a brief look at each of the Vs.


Vision creates Transparency.

The successful Product Owner establishes a clear product vision for her team, much like a military commander establishes clear intent for his subordinates. Doing so allows subordinates to act without direct orders if necessary to carry out the commander’s intent.

From the book Auftragstaktik: The Basis for Modern Military Command? by Major Michael J. Gunther:

The use of mission tactics [Auftragstaktik] allow[s] subordinate commanders . . . to interpret how best to achieve the commander’s intent based upon their understanding of the tactical situation. . . . The success of the doctrine rests upon the recipient of orders understanding the intent of the issuer and acting to achieve the goal even if their actions violate other guidance or orders they have received.1

Self-organization does not just happen. Much like in the military, the two main ingredients are shared vision and clear boundaries.

In the context of product development, the boundaries are provided by Scrum and the vision is provided through the Product Owner’s strong leadership and communication.

The product vision anchors everything in the process. This vision creates transparency because it forms the basis for all following conversations, leading to a common understanding for why you are building the product and what your customers’ needs are. According to Richard Hackman, 30 percent of a team’s success depends on how it was launched.2 A great and well-communicated vision is paramount for a successful launch.

You need to communicate the product vision again and again to keep everyone on board and honest. Never forget that this vision represents the voice of the customer. If you stop listening to your customers, the resulting product will be of less value or even alienate them.

I too often see the term “resources” used for human beings. These resources are given a catalog of requirements to implement and rarely have any idea about why. They lack the context of the vision and therefore are deprived of situational awareness. They fulfill exactly what was specified but often still miss the goal.

Making the connection to the product’s (or even the organization’s) vision helps team members make goal-driven commitments and feel like they are a part of something bigger than themselves. So how do you create a clear vision? Techniques are explored in Chapter 2, “Vision.”


Defining value provides you with something to Inspect.

Imagine the vision as a long thread. Value is the individual pearls you attach as you progress. Vision provides a foundation and direction, but without the pearls attached to it, there is no value. A Scrum Team’s job is to identify and then attach pearls (value) to the thread (vision).

The first pearl could be either a large business initiative or a smaller distinct feature. Aim for the most valuable item first and attach it completely before moving on to the next one. In other words, always be in a position to deliver value.

“If you could have only one thing, what would it be?” is often a good opening question when identifying the most valuable.

If everything is important, then nothing is.

—Patrick Lencioni3

Once you get this answer, often after persistent digging, try to truly understand the other person’s view; try to grasp the underlying why. You might even go so far as to question the product’s utility. Eventually, when you have narrowed it down and are convinced, go ahead and define how the value will manifest. Would a process take fewer clicks? How many? Will the behavior of a user change? How? Will a transaction be faster? How much faster? You need to provide more leadership than simply saying “let’s do this!” If you are not able to quantify success or to prove the realization of value, then the chances of being on the wrong track are rather high. Do not forget that the only real proof, though, is through the customer. Everything before is nothing but a hypothesis.

I like the idea that through the functionality we develop, we actually improve the world. It might not be world peace we reach, but we make a positive impact on someone’s life—even if it is just one click less in a process.

So how do you measure value? Techniques are explored in Chapter 3, “Value.”


Validation causes Adaptation.

Most business assumptions are plainly wrong.4 They look good on paper but do not hold up in the real world. Each valuable idea has to be validated as soon as possible. One place this is done in Scrum is the Sprint Review. The Sprint Review is the chance for all stakeholders to review the current state of the product and to get an insight into next steps. The closer the reviewers are to actual customers and the closer the Increment is to being released, the more realistic the feedback and subsequent adaptations.

Even if the Sprint Reviews go well and everyone seems happy, you still do not have true validation until the product or feature is in production and used. In Scrum, “Done” means the Increment is potentially releasable. However, to have ultimate validation and reduce the overall product risk, you need to establish a feedback loop with the marketplace. For this you need to release as frequently as the business can support.

The two core feedback loops in Scrum are on the process side and the product side:

Process validation is about inspecting and adapting how the Scrum Team is working.

Product validation is about inspecting and adapting what the Scrum Team is building.

Validation in the context of product management and the three Vs is about the latter: product validation.

Chapter 4, “Validation,” describes this in more detail.


Building products requires that you consider a series of strategic activities. Consider the following list:

Analyzing the industry and competition

Maximizing ROI

Forecasting and assessing feasibility

Developing product strategy

Planning releases

Identifying customers and their needs

Roadmapping the product

Auditing results

Creating outbound messaging

Sustaining the product

Executing the release

Creating the business case

Identifying product requirements

Launching the product

Developing customer retention strategy

Defining product features and initiatives

Retiring the product

Marketing and branding

How many of these fit squarely in the realm of Scrum? Maybe three or four, but not many.

The world of product management is a lot bigger than Scrum, as suggested in Figure 1-7, which quite possibly explains why there is such a large Product Management Vacuum in the software industry.

Figure 1-7 Scrum is augmented by many, many practices. (Figure © 1993-2016 Scrum.org. All rights reserved.)

This is where the Product Owner comes in. A Product Owner is one of the three Scrum roles. Although most product management activities are not part of the Scrum framework, as shown in Figure 1-8, a good Product Owner will take them on to fill the Product Management Vacuum.

Figure 1-8 Product Ownership is agile product management leveraging Scrum.

In other words, a good Product Owner is an agile Product Manager.

When I work with an organization to identify ideal candidates for the Product Owner role, I first ask about the strategic activities above and who does them. If the organization already has a Product Manager who does many of these activities, then I consider them an ideal candidate for Product Owner. If nobody is doing these activities or that person is not willing or able to commit to a Product Owner role, then I insist on empowering our Product Owner to own these activities as a way of elevating the role beyond the tactical to the strategic.

An empowered and entrepreneurial Product Owner fills the Product Management Vacuum, as shown in Figure 1-9.

Figure 1-9 The Product Owner and the Product Management Vacuum


Who should play the role of Product Owner?

Later in this book, more time is spent on the specific tasks and responsibilities of a Product Owner. This chapter stays at a more strategic level.

In Scrum, you need a Product Owner. But it obviously takes more than just filling the role. The effectiveness of that role, and of the overall Scrum implementation, depends a lot on the type of person in that role (see Figure 1-10).

Figure 1-10 Product Owner role types by expected benefits

A scribe is likely someone on the technology side who has been tasked with capturing requirements for the Development Team. This person is often seen as the team’s secretary and is asked to write everything down during meetings with the business. He has little to no decision-making ability, which severely impacts his effectiveness as a Product Owner and causes delays.

A proxy is still likely to come from the technology side but is seen as a representative of the business, maybe even for a particular product manager on the business side. She often has a business analyst or system analyst title. The problem is that a proxy creates an unnecessary indirection between the Development Team and the real influencers.

What is a likely response from the proxy whenever the team has a question for her? “Let me go ask,” resulting in more delays.

Could the proxy get protective of her role and shut down any direct communication between the team and the business? Very likely. You surely see it all the time.

Both the scribe and proxy are on the receiving side of what goes into the product. They get told what to do. At best, they work out the details.

A business representative is someone from the business side rather than the technology side. This role is a clear improvement over the proxy role, as it demonstrates a commitment from the business toward the product. In contrast to the proxy Product Owner, this role provides more direct access to domain knowledge and stakeholder expectations. However, there may still be decision-making delays, as the business representative often has limited autonomy over product management.

A business sponsor is a big improvement on the Product Owner role. A sponsor is someone who spearheaded the initial business case and acquired the budget. Consequently, he has the trust and the mandate to make financial and product decisions on the spot. This creates fewer hiccups, less context switching, and largely improved flow. The Development Team can then focus more and get more things done sooner.

The ultimate Product Owner is an entrepreneur. This is someone who is spending her own money to fund the development of the product. This gives her complete responsibility over all product management decisions for both business and IT strategy. Now while this may not be a realistic situation for many organizations, an entrepreneurial mindset is still something that Product Owners should assume. They should expect to see a return on investment (ROI) as though their own money was at stake.

The business representative, sponsor, and entrepreneur are more on the initiating side of the product. Because of their deeper business understanding and their two-way communication, they develop a stronger customer empathy. This empathy allows them to initiate rather than simply receive the right requirements.{20}

Keep in mind that the closer a Product Owner is to a sponsor the further he may disengage from the Development Team. Finding ways to maintain that sense of connection with the product vision becomes even more important and is what is expected of an entrepreneurial Product Owner.

Figure 1-11 provides a summary of this discussion of Product Owner roles types.

Figure 1-11 Summary of Product Owner role types

I often find myself writing these five Product Owner role types down when talking to organizations. I like to ask them where they see their Product Owners. Not surprisingly, they are more often than not closer to the scribe and proxy roles. This then turns into a discussion of more practical actions a Product Owner could do to move up the list. Could a scribe start to be more representative of the business people? Could a proxy start learning more about the business side? Could a business representative ask to be more involved with budgeting and strategic direction? If the answer is no to any of these questions, then we should ask ourselves if we have the right person in the Product Owner role.


What is a product? On the surface, this question seems simple. But it’s not.

A product is anything that can be offered to a market that might satisfy a want or need.5

Companies sell many products—retail, financial products, seats on planes, cars.

In the world of software development, you make products too:

Some are straight commodities—word processors, games, operating systems.

Others are channels to other products—online retail, travel booking websites, mobile banking apps, search engines.

When this book refers to products, generally it means software products. However, many of the concepts discussed apply well beyond the realm of software.

To start, here are some assertions:

1. There is always a product. It may not always be obvious, but it is there and it needs to be identified.


2. Every product has a customer who is a:

a. Consumer: Anyone who gets value from your product, whether or not they pay for it

b. Buyer: Anyone who pays for your product, whether or not they use it

c. Both


3. Every product has a producer who receives a core benefit through:

a. Revenue increase

b. Cost decrease or avoidance

c. Societal benefit

What happens far too often is that smaller areas of functionality or even smaller technical components are considered products, with no clear customer or value proposition.

I had in one of my Product Owner trainings a participant who introduced himself as “My name is . . . and I am the Product Owner for testing.” Normally I am known for being swift with my words, but in this case I was speechless.

Another common pattern is Conway’s Law:

Organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.6

The result of Conway’s Law is a series of interconnected “systems” built by different departments (or hierarchies) within an organization with little focus on the actual product or on who the customer even is.

This is the reason Scrum names the role Product Owner and not System, Feature, or Component Owner.

The best approach is to think about the product from a customer’s perspective. Which customer needs are you addressing? What do customers expect? What product improvements will make customers’ lives easier?

When we work with companies to define their products, we emphasize that this is ultimately a business decision. Let’s align our technology groups based on the products our business wants the end-customers to see.

For example, Company A may have a strategic direction of presenting their customers with a series of products to fulfill their needs, while Company B decides it would rather present its customers with one larger product. Both are valid options, and neither should be constrained by the technical software delivery structure. This needs to remain a strategic business choice, and technology should be able to adapt as seamlessly as possible.

This bridges the chasm between business and technology.

When you think of a car, what is the product? The engine, the entertainment system, the steering, the air conditioning, the car itself? What exactly is the product?

As stated above, start with the customer. Who is the consumer and who is the buyer?

If you are buying the car for yourself, then you are both the buyer and the customer. If you are a parent buying a car for your child, you are the buyer but the child is the consumer.

Car companies must design products with both in mind. Cars must include airbags and safety ratings for the parent and fun colors and multimedia systems for the teen.

But you can look at it from a different angle: The car company is the buyer as well as the consumer for components within the car. The products are the engines, entertainment systems, air bags, and so on that are produced by vendors or even internal groups.

So, to know your product, you need to know the consumer and buyer—your product’s customers.

Getting back to software, Table 1-1 presents some realistic examples. See whether these assertions still hold true.

Table 1-1 Product Examples





Producer Benefit


Professional office software for daily or occasional office work



Individual user



Individual user

Revenue (licensing)

Technology Department within an organization

Replace legacy backend system with updated web service API

Technology Department

Individual programmers

Cost savings (lower maintenance costs)


Nonprofit encyclopedia with volunteer contributors


Information seekers

Social benefit

(free information)

Call Center

A system for customer service agents to log calls

Call Center

Customer service agents in Call Center

Cost savings (shorter call times)

QA Department

Creating automated tests for development teams

QA Department

Internal Development Teams

Cost savings (better quality)

Business Analyst Group

Creating documents to hand over to IT for implementation

Business Department

IT Development Department

Revenue (salary)


Retail website



Revenue (sales)


Social media



Revenue (advertising sales)

After you have identified your product, the next question is, “Is it a viable product?”

A viable product is one where the stated producer benefit comes to fruition. This means that you should have ways to measure the benefit along the way. Chapter 3, “Value,” explains more about how to do this. For now, consider this a major responsibility of a Product Owner for maximizing ROI.

The preceding examples of the separate automated testing and business analysis groups rarely produce a viable ROI.

Admittedly, you will see examples of initiatives that have failed, time and time again. Is the automated testing group developing a product? Sure. But is the stated benefit of better quality even viable? Will the other Development Teams embrace testing environments that they did not develop themselves? Who will maintain this testing system after its implementation? The ROI is rarely there unless these efforts live with the Development Teams themselves. Regardless, it is important to understand the cost and perceived benefit and set up a feedback mechanism to ensure that the product is still viable.

An important takeaway when defining your product is to go as high as possible without losing sight of your core objectives. You have to find the right value area from the customer’s point of view. What does the customer need, and what is the customer willing to pay for? What provides value?

Coming back to the car example, would you buy a steering wheel or a seat? You most likely want a usable product, a complete car in this case. This product provides a benefit to you as a consumer.

If you structure your teams below the value areas, you will see too many Product Owners, with all the resulting coordination overhead. Imagine having a separate Product Owner for each car component with no real centralized vision for the whole car as one product (see Figure 1-12).

Figure 1-12 A Product Owner for each car component

Now when you add a new feature or large initiative for a value area, it needs to be broken down into units of work for each of the affected components. This creates enormous overhead, with many dependencies to be managed and resulting in skill shortage, timing, quality and integration issues. To handle all these dependencies, you will likely need to find a “feature” owner to take care of all the coordination and to be accountable for the feature. Some call this role a project manager (see Figure 1-13).

Figure 1-13 Project managers are feature owners.

The problems mentioned above can lead to the following:7

1. Sequential life cycle

The dependencies from the various components need to be aligned, which requires a plan taking handoffs into account. Once Component B is completed, it is handed over to Component F, and so on.

2. Unnecessary dependency management, coordination, and overhead management complexity

In a plan-driven approach, all the coordination of the dependencies is left to managers, many of whom are nontechnical. By instead providing a clear goal and leaving the implementation details to feature teams, you get commitment and working functionality more quickly for review.

3. Working on low-value features

The feature is composed of functionality of various degrees of value, from very low to very high. Since the whole feature is being decomposed and top-down managed and coordinated in the components, there is no feedback to identify high- or low-value functionality.

4. Handoffs, information scatter, and high inventory

Individual feature activities need to be completed before the next activity can start. Communication and knowledge transfer at those handoffs is done by documents and specification. All those interim activities lead to high inventory, spread-out information, and too many handoffs.

5. Loss of customer and whole-product focus

When work is organized by activities to be completed by all those component teams, naturally the customer becomes secondary. There are enough dependencies, challenges, and other obstacles to manage that a customer, especially a customer providing feedback, can quickly become a nuisance.

6. Opaque measure of progress

The sequential approach means you lose the feedback, which then means you are stuck measuring progress toward your plan instead of toward your value goals.

7. Inventing work

What do you do when your component team runs out of work? You need to justify its existence. So you come up with “important stuff” that needs to be done so that you can justify your team’s payroll.

8. Bad quality

Since you focus on each component’s quality, you lose sight of the final overall feature quality. Those local optimizations are known to cause problems for the real goal. Also, technical problems between those components are often not addressed correctly for lack of time. Remember the plan to be followed? This leads to technical quality issues in the long run.

Instead of thinking in components, you need to think in terms of one (larger) product. This can go a long way. A Product Owner should be able to handle a fairly large number of Development Teams for a single product.

Remember, the ideal Product Owner is an entrepreneur—a single voice for the vision of the product, regardless of its size. A company has just one CEO, whether it has 100 or 100,000 employees.

This is referred to as the Santa Claus rule. No matter how busy Santa gets, he does not bring on other Santas. How does he cope? Elves.

As products scale, Product Owners should find themselves less involved with the day-to-day tactics of product development and more involved with strategy and direction. They can get help (elves) from teams, stakeholders, assistants, and so on for the more tactical work. As Santa, you can delegate responsibility, but you still remain accountable for the success of Christmas.

If this is not sufficient, then split the product into value domains on the right level of abstraction (see Figure 1-14). This also requires that you set up cross-functional feature teams underneath your product accordingly. The resulting intercommunication is essentially the steering committee, Project Management Office (PMO), and governance in one body. This addresses the problems mentioned previously.

Figure 1-14 Independent customer-focused value domains, sharing common services

I had a client who had several Product Owners for a large product. The client’s solution was to allow each one to select something from his list for the next Sprint, round-robin style. While this may seem fair at first, is it the right strategic solution for the organization? Are the Development Teams truly working on the most valuable features? Who ultimately decides which features are best, regardless of how many voices there are? That person is the real Product Owner.

The shared services between the value domains represent dependency management and integration on a technical level. With today’s continuous integration, infrastructure as code, and test automation, this area is well understood. Coordination on a technical level is far more predictable. You either have a working product or you do not.


Compare your answers from the beginning of the chapter to the ones below. Now that you have read the chapter, would you change any of your answers? Do you agree with the answers below?




Schedule, budget, and scope are the best ways to measure project success.

Product management is an essential practice for Product Owners.

A Product Owner should act as a proxy between the business and technology.

A Product Owner establishes a vision for a product.

Scrum provides all the tools necessary for successful product management.

Every development effort has a product.


1. Michael J. Gunther, Auftragstaktik: The Basis for Modern Military Command? (Fort Leavenworth, KS: School of Advanced Military Studies, U.S. Army Command and General Staff College, 2012), 3 (emphasis added).

2. J. Richard Hackman, Leading Teams: Setting the Stage for Great Performances (Boston, MA: Harvard University Press, 2002).

3. Silos, Politics, and Turf Wars: A Leadership Fable about Destroying the Barriers That Turn Colleagues into Competitors (San Francisco: Jossey-Bass, 2002).

4. Ronny Kohavi et al., “Online Experimentation at Microsoft” (ThinkWeek paper, Microsoft Corp., Seattle, WA, 2009).

5. Philip Kotler, Linden Brown, Stewart Adam, Suzan Burton, and Gary Armstrong, Marketing, 7th ed. (Frenchs Forest, New South Wales: Pearson Education Australia/Prentice Hall, 2007).

6. Melvin E. Conway, “How Do Committees Invent?” Datamation 14, no. 5 (1968): 28–31.

7. Cesário Ramos, “Scale Your Product NOT Your Scrum,” Scrum.org (February 2016).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.