Home > Articles

  • Print
  • + Share This
This chapter is from the book

Defining a Product

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.

    AND

  2. Every product has a customer who is a:

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

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

    3. Both

    AND

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

    1. Revenue increase

    2. Cost decrease or avoidance

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

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

Description

Buyer

Consumer

Producer Benefit

Microsoft

Professional office software for daily or occasional office work

Enterprise

–––––––

Individual user

Employee

–––––––

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)

Wikipedia

Nonprofit encyclopedia with volunteer contributors

Donors

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)

Amazon.com

Retail website

Individuals

Individuals

Revenue (sales)

Facebook

Social media

Advertisers

Individuals

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

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

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

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

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.

  • + Share This
  • 🔖 Save To Your Account