PM Articles > Kent McDonald > User Illusions

User Illusions

by Kent McDonald

The daily standup was progressing as usual, until Vince's turn. "Well, yesterday I worked on the address screen for a while, and then I moved to the credit card entry screen, and then I messed around a little with the report request screen. Today I plan on working with the address screen, the credit card screen, and the report screens a little more. I don't have any obstacles."

Gina, looked at him quizzically and asked, "Why aren't you working on one thing at a time instead of jumping from one thing to another?"

"Oh," replied Vince a little irritated, "because I get so far on one thing, then I need to ask Todd a question about how the users want it, and he says he has an idea, but he wants to clear it by Mary, Joe, and Polly first. It seems like they always get back to him right away, but they always have different viewpoints and they can't come to a clear decision."

"Humph," chimed in Kim, "I wish Todd would just make a decision. It seemed so much easier when we just did what we knew was right. The customers never seem to know what they want anyway, or at least be able to agree."

"Yeah, no kidding," said Gina. "But when we started doing this, we insisted on having one customer to talk to and to have them with us all the time, and Todd is who they gave us. He's a good guy, but he has only been with that department for a couple of months. Where is Todd anyway?"

"He went home with a migraine," said Vince, looking at the Task Board wondering what other task he could get started on that wouldn't be a big deal if he didn't finish right away.

At least we know who to blame

Agile advocates like to brag that one of the advantages of agile methods is that they stress regular involvement of the "customer" throughout the life of the project. In fact most of the methods establish a clearly defined role and call it various things, including customer, product owner, and expert user. Although the terms are different, they generally expect the role to do the same thing—tell the developers what functionality to work on, and in what order, and provide timely feedback on functionality so that the developers can respond accordingly. These methods take things a step further and also stress the need for a single customer providing this information. Some people refer to the concept as the "single wringable neck."

This view on customers is rather shortsighted and ironic coming from a community so focused on collaboration. Very rarely will you find one person that has the necessary breadth of knowledge to address questions surrounding the business needs of the project and the detailed user needs, such as the best way to display the address fields or how fields should be laid out on a user interface.

In some cases, the manager of the area requesting the project is assigned to the team as product owner. In this case, the team may be able to get a good feel for the business need for the project, but chances are they will not get the best guidance on how the application should be designed for the actual user. Sure, the manager knows what they want, but chances are they are not working with the application on a day-to-day basis, so they provide guidance based on how they think the work happens, not how it actually does. The end result is product that provides the necessary functionality, but doesn't come close to doing it in a user-friendly manner. That is, assuming that the team is able to get an appropriate amount of the manager's time, which is often not the case.

Alternatively, an expert user may be assigned to your team. You would prefer someone who could do the job in their sleep, but those are the folks that are often tagged for every project, so you often get someone from the business that has a relatively good grasp of the process, but is not crucial to the operations. This also means that they may not be confident enough or have the authority to make critical decisions when it comes to prioritizing business functionality. They inevitably have to go back and ask their manager—you know, the one who did not have enough time to be involved with the team in the first place.

In both cases you get a single customer, but the advantages of their team interaction are diminished because they are not available, or they are not able to make the key decisions in a timely manner. And don't forget you haven't eliminated the frustration of dealing with multiple stakeholders with conflicting needs. You've just shifted it all to the "product owner," who may not have the skills, training, and experience necessary to cope with it. No wonder Todd has a migraine.

It Takes a Village

Instead of demanding that a single person represent the business point of view on the project, you will be much better off if you realize that requirements come at different levels of detail, and that different people are best suited to make decisions about each of those levels. Instead of thinking of a monolithic customer, I prefer to think of the business side of a project in four distinct roles: product owner, customer, stakeholder, and user. These roles aren't based on what they do on a project, but on what decisions they make. The following table shows these four roles, their description and the decisions for which they are responsible.

Product OwnerPeople responsible for the desired impact of the product on the business
  • Features included in product
CustomerPeople who will buy the product
  • Problems needed to be solved
StakeholderPeople impacted by the existence, use, or sale of the product
  • Product impacts to their organization
UserPeople who use their product on a regular basis
  • Detailed characteristics of the product, especially surrounding the interface with people using the product.

Keep in mind that "product" has different meanings depending on the context. In a product development project, the product is whatever is sold externally. For an internal IT project, the product might be a software application created to support a business process. In these internal projects, the customer and product owner are often the same role, in that the person "buying" the product is often also responsible for its impact on the organization.

This distinction is important when you consider that requirements can be classified into at least three different levels of detail: Business Requirements, or the features included in a product; User Requirements, which provide guidance around how someone uses the system; and System Requirements, which provide constraints around how the software is crafted to support user and business requirements. If we were to revisit the above table and include consideration of what requirements they provide, it would look something like this.

Product OwnerPeople responsible for the desired impact of the product on the business
  • Features included in product
  • Business Requirements
CustomerPeople who will buy the product
  • Problems needed to be solved
  • Business Requirements
StakeholderPeople impacted by the existence, use, or sale of the product
  • Product impacts to their organization
  • Business Requirements
UserPeople who use their product on a regular basis
  • Detailed characteristics of the product, especially surrounding the interface with people using the product.
  • User Requirements

What this tells us is that we have to chat with more than one person to get a complete picture of the product, and we have to realize that different people will provide different types of information.

So I am back where I started!

"But Kent," I suspect you are saying, "I could never possibly have all of those people involved with my project all the time. I can barely get one person dedicated."

Yep. But here's the trick: even though the product owner, customer, and stakeholder all identify business requirements, only the product owner is really responsible for deciding which business requirements—which features—are actually implemented, because they are on the hook for the success of the product. Additionally, when a team follows an iterative approach, decisions about which features to realize do not happen on a continuous basis. Rather, they occur at the beginning of each iteration when the team plans their work for the next couple of weeks.

The types of decisions that do occur on a regular basis are those related to how users interact with the system, so there is still an advantage to having a user work closely with the team on a day-to-day basis. The key is that the user working with the team has to have the appropriate knowledge of the product and business process, and must have the ability to make the appropriate decisions in a timely manner. In cases where the user working with the team faces a group of vocal peers, such as in Todd's situation, members of the development team need to help facilitate the discussions to reach an appropriate decision. The user also needs the appropriate authority to make decisions about user requirements so they do not constantly have to get in touch with the product owner.

Sometimes questions will come up during the iteration that require the product owner's input. In those cases the product owner needs to be available to provide a quick response. Depending on the availability of the product owner, this can be handled in a variety of ways. The team might contact the product owner when questions come up and have an agreement to get answers back within a certain time frame. The product owner might stop by a couple of stand up meetings per week, or have office hours so the team knows when the product owner will be available. The important thing to remember is that the team should not be constantly hitting up the product owner with questions, but rather only bringing up the ones that the product owner needs to answer—leaving the other, more detailed questions for the users who are working with the team on a regular basis.

Knowing who to ask is half the battle

While the concept of the single customer seems an ideal way to simplify the handling of requirements, it often leads to other challenges that could potentially slow the team down. It's important for development teams to realize that they have a responsibility to help the business make decisions by facilitating their discussions and providing them the appropriate information. Doing so may mean a little extra time, but in the long run, it will result in a more effective team, and potentially fewer headaches.

Related Items
Project Escalation Guidelines
Scope issues, major tradeoff decisions, and serious resource conflicts are all examples of situations that can require escalation to higher management.

Agile Technique Guideline: Stand-up Meetings
Agile project teams are all about collaboration and cooperation -- working with each other, not working for the project manager. This guideline explains how to use one common agile technique -- standup meetings -- to get team members into the habit of keeping each other in the loop without spending hours every week in endless, agonizing status meetings.

Agile: Overview and Core Methods
This paper by ProjectConnections Director of IT Content Kent McDonald provides an overview of the key historical statements created by members of the agile community to codify the value set and principles shared by agile software development and agile project leadership methods. It includes some of the history behind the creation of these statements and suggestions for applying these values and principles in a non-agile environment.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

Sounds to me like Kent needs some training and real life experience working in an Agile and/or Scrum environment. This perspective is very short-sided and defensive. No wonder PM's are getting a bad reputation for "not adapting multiple delivery frameworks." The PM capabilities still exist and are crucial to the success of delivery in Agile/Scrum projects. However, the responsible party changes who does what - not the fact that things don't get done.

Thanks for your feedback. I assume your comment about things not getting done was in reference to the opening story. The purpose of that story was not to advocate a lack of responsibility (which is far from the case where agile methods are appropriately applied), rather to point out some of the problems that having a single customer interface can introduce.

The agile focus on customer interaction is very important, however I think it is much more effective without rigid adherence to the single customer concept. For example, one of the agile teams I worked with recently pointed out that regular, if not continuous, customer interaction is probably the biggest benefit they see from adopting agile. One reason they are seeing so much benefit is that they rely on a product owner to provide feature level decisions, and also seek out feedback from expert users throughout the iteration, thus making sure they get as complete a picture about the business problem and constraints on the solution that they can.

I have to admit I’m not sure how that perspective is defensive, but I would certainly appreciate feedback as to how it may have come across that way.

I liked the story, as it related a very common and annoying scenario on any development team. In 1994, Microsoft started marketing MSF, the Microsoft Solutions Framework, which spoecifically called out the need for both perspectives, the business (product management) and the user (user experience). It included guidance on the skills, organizational positioning and risks of combining these two roles into one, depending on the size and complexity of the project. The MSF Team Model is a great framework for Agile Teams and would encourage readers to explore this framework. It was agile before Agile.
Thanks for your insights. Keep up the good work.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.