Product quality has several aspects:

  1. How well does it meet the needs of the stakeholders of the business who are funding the product?
  2. How well does it meet the needs of the customers?
  3. How well the product is built?

The third one has several aspects to it. These will impact how easy the product is to maintain as well as change. These aspects include:

  • Technical architecture
  • Business architecture
  • Implementation quality

While building the right thing is critical, building it well is also essential.  This is especially true when the company has long-term relationships with its customers. In this case, the quality of the product is of value to the customer since updates will be expected.

The four capabilities in this chapter are:

  • Ensure you’re creating the greatest value
  • Have high quality from the customer’s perspective
  • Validate the requirements with examples
  • Create value in small steps to enable getting quick feedback

3.1 Capability: Ensure you’re creating the greatest value

There is nothing so useless as doing efficiently that which should not be done at all. Peter Drucker


While we are always looking to increase our ability to build more in less time by eliminating wasted effort, at any one point we have a limited capacity. To maximize our value-adding capability we need to work on the most important items.

Value, however, is often in the eyes of the beholder. The question of value must include who the beholder is. We must break from the bias that the user of our system is the main stakeholder in our system. This bias is rooted in the roots of Agile which is more than 2 decades old. Instead, we must look at all stakeholders. This includes those in our company as well as the company using our services. For example, a restaurant management system will have stakeholders in the restaurant (management, legal, food services) as well as in the company building it (marketing, sales, executives, legal). All of these stakeholders will be competing for the constrained capabilities available.

Why this is important

The most significant cost/waste is building the wrong thing. Don’t be misled into listening to only some of the stakeholders involved.

How to implement when using either timeboxing or flow

High-value items can be used to align work to business value. If this is not present people will not coordinate what they are working on to get value out the door quickly. Whether you are using timeboxing or flow is not particularly significant except that flow will likely get you quicker feedback.

One method for discovering what is of value is to identify the value of those stakeholders. Joy, Inc, presents the idea of a persona target. It is used to identify the users of a system and how their importance relates to each other. But this can be used to identify stakeholder values as well. This doesn’t need to be done for small items, but should be done for significant items of work.







Use the target by placing the role of the stakeholder and what they consider to be of value on the target in the appropriate position. The more important the stakeholder the closer to the center it is on the target.


If you aren’t building from the stakeholders’ perspectives your product will likely not be the most important thing that can be built.

3.2 Capability: Have high product quality from the customers’ perspective

“Software is notoriously difficult to use. I’ve often said ‘if a person acted the way most software systems do they’d be punched out within 5 minutes.’” Al Shalloway


Figuring out what customers want and need is considered to be notoriously difficult. But much of this is because most people pay attention to the system they are building and not the customer’s journey. Focusing on the customer’s value streams via the customer journeys is how we determine what to build.

Let’s face it. A lot of software is difficult to use and built poorly. It’s awkward, inconsistent, hard to learn, and hard to use. If a person responded to people the way most software responds to people they’d be punched out in five minutes. This happens because most developers come from the perspective of what they are building instead of how the customer is going to use it. Or assumptions are made that don’t need to be made. For example, many products work best for right-handed people when with just a little thought they could have been designed for either left or right-handed people.

What’s needed is software that functions the way people want it to. Even better, when it opens possibilities or people that they hadn’t considered. We want the software to improve how people work and live.

Most products, especially software systems, are created from the perspective of the product or the software system being built. But this is the wrong perspective to use. It creates a need for the customer to understand the way the product is designed or how the system behaves. Unfortunately, the way designers think and the way customers think is often not in synch.

What’s needed is to focus on what would be a good value stream for the customer. From this we can ask “what would the customer journey have to be to enable the good customer journey?” When that is understood we can build the product or system from the customers’ perspective, not the developers.

A software product example.

In the 80s, I was building software for people who worked at the front desks of hair salons. Not the small ones you often see, but ones with 20-40 stylists. The front desks at these places were insanely busy. The standard way of using menuing systems design to navigate the system, were two slow and difficult to use. I remember trying to figure out a better way. Instead of thinking how the system could be better, however, I put myself in the position of a front desk manager. I wanted to go from client to the appointment book to ticket …. And it needed to be contextual. If I went from a client to the appointment book I wanted to see the client’s appointments I was looking at. Imagining what a user meant by asking to go from one place of the system to another was pretty easy if you knew how people worked in the salon.

Using these insights I came up with the idea of function keys to navigate. While obvious now, these were not in use back then. F3 was appointments, F4 was tickets, F5 was clients, …. The meaning of these never changed, which also allowed us to put a paper strip above them.  People who had never used a computer before learned how to navigate around one in a minute or two. Trying to find a faster way to navigate around the system would have been a lot harder than just seeing how people wanted to navigate in the first place.

A physical product example.

I once was an avid photographer. I was using an Olympus camera that had through the lens light metering. This meant that I could use two strobes at once and the camera would automatically set the shutter speed. In looking for hand-held camera mounts that would hold the camera and an additional strobe (one strobe would be mounted on the camera itself) I noticed that many mounts would only allow for the handle to be mounted on the left side of the camera. Left-handers, like I was, were left out. In looking at these holders, it was clear they could have been just as well designed to be held by either hand. That users would want to do it differently was clearly not considered. Instead, it appears the thought process was based on the components of the camera mount.

Why this is important

If people have difficulty using your products they won’t appreciate the value that might be in them.

How to implement when using either timeboxing or flow

This section includes the same directives as the previous implementation section on how to implement and ensure you’re creating the correct value. However, it has one more – use the customer journey to design the system.

As mentioned earlier in the book, the customer journey can be used to improve the innovation of products and services. We can do this by taking these steps:

  1. Get familiar with the customers’ goals and commitments
  2. Look at their commitments to see if there are better ways to achieve them
  3. Design a customer value stream based on these better ways
  4. Look to see what the customer journey would be to enable this customer value stream
  5. Design the system to enable that customer journey


If you aren’t building from the stakeholders’ perspectives your product be awkward, even difficult to use. It won’t garner the support your organization would like to get from its customers. You won’t get viral selling from your customers that you’d like to get.

3.3 Capability: Validate the requirements with examples

“You Cannot Learn What You Think You Already Know.” Epictetus

“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” Mark Twain

 “The single biggest problem in communication is the illusion that it has taken place.” George Bernard Shaw

Reflecting on the quotes above provides insights into why we often have such bad requirements. People hearing the requirement think they understand it. But they don’t.


Consider this – does it make sense to build something if you aren’t sure what the requirement is? What’s the best way to find out? Build it and then see if it meets it? Or ask the person who is going to validate what you create what their criteria for accepting it is? This acceptance criterion is already in their head, or will soon be. They may just not have told you it. The idea of “test-first” is really getting what the person making the requirement is going to use to see if the right thing was built before you start creating it.

Why this is important

Without this, the creators of the functionality will mostly be guessing, while thinking they know, what is needed. This will waste time and create a lot of handbacks.

How to implement when using either timeboxing or flow

This approach can be followed when using either timeboxing or flow. The only difference is the number of examples gathered.

A simple practice to always follow is for people being given a requirement to ask “how will I know I’ve done that?” whenever they are asked to create something. This requires the requester to stop and think about it, gaining clarity on the request. It also provides the person about to create the requested functionality with an opportunity to start their process by having the end in mind. When combined, these two create a mutual understanding of what is required.

How to do requirements by example – an example

Consider a situation where developers are tasked with writing a payroll system. They are given these initial requirements:

  • People are paid a set wage when they work Monday to Friday for up to 40 hours a week.
  • They are paid time and a half after the first 40 hours
  • They are paid twice their salary when they work on holidays or Sundays.

The product owner tells the devs they have to leave for a week but are happy to answer any questions. So the devs ask:

  • Where do we find the employee wages?
  • What day of the week does a week end?
  • Where do we find the hours worked by employees?
  • What are the holidays of the company?

Possibly some others. Basically, the devs look at what they know, and what they don’t know. They then ask questions about what they don’t know. While often considered trite, there is an important truism that we know some things, we don’t know some things, and there are some things we don’t know, but we don’t know we don’t know them. This is the territory for missed requirements. The way to avoid this problem is to include with requirements examples of what it means to satisfy them.

Let’s say the product owner gives these three cases:

  1. Pay with no overtime
  2. Pay with overtime but no holiday or Sundays
  3. Pay with overtime and some hours on a holiday.

Let’s look at these in tabular form:

Standard hours Holiday / Sunday hours Wage Pay()
40 0 $20.00
45 0 $20.00
48 8 $20.00


It is very important not to proceed until you fill in the rightmost column.

The first two cases are pretty easy and most people get them right.

Standard hours Holiday / Sunday hours Wage Pay()
40 0 $20.00 $800
45 0 $20.00 $950
48 8 $20.00 ???


Now really, take the time to calculate the third. In running this example most people respond with $1360 or $1120. Actually, there are usually one or two other solutions given, but they are usually the result of math errors. That we get two different answers is interesting on its own. After a brief discussion, it is discovered that the discrepancy is due to whether the “Standard hours” is the total hours worked or just the non-holiday/Sunday hours. If it’s the total number of hours worked, then the answer would be:

  • 40 * 20 = $800 —- this is our wages for our first 40 hours
  • 8 * 20 * 2 = $320 — this is our time for working on holidays or Sundays
  • TOTAL = $1120

In the other case we’d have

  • 40 * 20 = $800 —- this is our wages for our first 40 hours
  • 8 * 20 * 1.5 = $240 — this is our time for working overtime
  • 8 * 20 * 2 = $320 — this is our time for working on holidays or Sundays
  • TOTAL= $1360

But, in fact, the correct answer is $1520. Huh? That’s because there’s something else afoot. Something else we didn’t know, but we didn’t know we didn’t know it.

Can you figure out why this is? Notice that that’s not really important. Now that you know you don’t know you can just ask.

Before giving you the answer, let’s see if we can make it clear why this problem occurs. Consider a metal-cased pen, a plastic-cased pen, pencil, and a whiteboard marker. Would you consider them the same? Or different? Most people would say they are different. But now consider if you can think of them as the same. Most people say “yes, they are all writing instruments.”

People can consider these items the same or consider them different. The question then is how you are thinking of them differently when you consider them the same and how you’re thinking of them when they are different? The difference, of course, is the level of abstraction. They are the same conceptually, but have different implementations.

Now, consider the requirement “twice their wage.” What is their wage? Is it their standard wage or their overtime wage? How would you know? You wouldn’t. And you almost certainly didn’t know you didn’t know. You just figured it was their standard wage because that’s how people talk.

If you asked the product owner they’d have told you “twice the wage they are being paid.”  Notice that while you think of the standard wage and overtime wage as different, as with pen and pencils we could think of them as the same.

Now we can see that the answer to the third case is:

40 * $20 + 8 * $20 *1.5 + 8* $20 * 1.5 * 2 =  $800 + $240 + $480= $1520

But also notice that given the answer of $1520 and a little Algebra, we can calulcate what the rate we should be using in the 3rd example:

40 * $20 + 8 * $20 *1.5 + 8* x = $1520 OR

$800 + $240 + 8* x = $1520   8 * x = $1520- $1040    8 * x = $480 which makes x = $60

Wage = $60, which is the overtime wage of $20 times 1.5 times 2.

The bottom line is never accept a requirement without asking the question (and getting an answer) “how will I know I’ve done that?” Notice this takes no extra work since the person asking for the requirement is going to have to figure this out eventually. You’re just asking for it up-front.

How to take this further

This is what I call “baseline Behavior Driven Development (or BDD)”. BDD was created by Dan North as a way to create clear requirements. BDD suggests using the format “<given> <when> <then>.” The then is the output, not the action which is left to the developer. Each line in the tables above include the “given” and “then”. The “when” is when you the event that triggers the calulation happens.


You are not doing this effectively if after building something the customer says it was the wrong thing.

3.4 Capability: Create value in small steps to enable getting quick feedback


Mistakes happen. While we should try to avoid them, it is imperative that we catch them quickly. Otherwise, more time will be spent on the effect of the mistake.

Using Feedback to Manage Unexpected Events

Unexpected events are a way of life in product development. Learning what will make a difference to customers usually has to be discovered through creating a series of small features, showing them to customers, and getting feedback on their actual value. This underscores the importance of short feedback cycles. Having them enables the process mentioned above to go more quickly.

As we will see later in the book, much of the unpredictability in knowledge work comes more from people not following good practices. However, external events are unforeseen. To deal with them, we must be in a state that allows effective pivoting.

See the chapter Dealing with Complexity in Knowledge Work for more.

Why this is important

Quick feedback is critical to avoid building the wrong product. In some situations, it is difficult for teams to be in contact with the product owner so it is important to set up a cadence for conversations as needed.

How to implement when using either timeboxing or flow

This is one of the key factors in deciding whether to use timeboxing or flow. If the product being built is not well known continuous demonstration, validation and pivoting may be necessary. If we’re creating a new product with MVPs, then it is likely that flow should be used. When the speed of feedback needs to be high, recognize that planning an entire timebox will likely be a waste because we will change what we want to work on as we get feedback.

The biggest cost/waste is building the wrong thing. That is often hard to prevent but you at least want to notice when you’ve done it as soon as you can.


If you’re not getting quick feedback from your customer you are likely going to do a combination of the following:

  • build the wrong functionality
  • build more functionality than you need
  • miss opportunities to build and create functionality

Go to Amplio@Teams: The Path to Effective Lean-Agile Teams

Go to Being a Professional Coach

New Workshop

More Info >>

Upcoming Events