This chapter is from the book
This chapter is from the book
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:
There is always a product. It may not always be obvious, but it is there and it needs to be identified.
AND
Every product has a customer who is a:
Consumer: Anyone who gets value from your product, whether or not they pay for it
Buyer: Anyone who pays for your product, whether or not they use it
Both
AND
Every product has a producer who receives a core benefit through:
Revenue increase
Cost decrease or avoidance
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 |
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) |
Retail website |
Individuals |
Individuals |
Revenue (sales) |
|
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 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
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.
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.
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.
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.
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.
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.
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.
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.