Being a product owner and having responsibility for a product's development using agile methods can be a bit overwhelming. Creating any product can be challenge. With a product being developed at the speed of agility, these challenges increase. Nothing is more frightening than feeling out of control while going at a high rate of speed. Let me reassure you, though, that it does get better. The first time you drive down that agile highway (even if you aren't yet going fast enough), it's scary. But with practice and a good understanding of what to watch for, driving an agile project becomes easier.
Because training and certification for product owners is fairly new, I've included some wisdom I've gained from my time on the agile road, which includes guiding four different teams over the past several years.
Priorities Are Priority One.
What teams need most is a product owner who is able to prioritize the product backlog. This includes adjusting priority based on new information and juggling the team's needs for work against customer features. A product owner must understand and be willing to have the critical conversations with team members regarding stories (work) that are not direct customer features, yet will develop an architecture that will enable the team to achieve more work (higher velocity) in the future. Balancing all of these competing stories, and the emerging importance and changing priorities that come with them, is a constant struggle.
I have seen product owners use multiple backlogs to hold work for features, anomalies, and other technical debt. I discourage this practice. A single backlog not only is the best way to force all work into priority order but it also provides a single visible place to know what is coming in the next sprint. Separate, multiple backlogs tend to distract the team. Technical leads and product owners become content to maintain their own personal backlogs, which prevents communication and preparation of a single point of priority focus for the team. It's just as easy to categorize stories on a single backlog and it's much easier to have the conversation about whether this architecture or that refactor is more important than this feature.
Patience Rarely Comes When It's Called.
Product owners should be available for the team. A group that is self-organizing does not need to have its work managed minute-to-minute, but when the group has a question, it might block several people. Being always available and ready to answer these questions isn't easy. Here are some tips to help you choose a course of action quickly and decisively.
Know the product vision
“‘Would you tell me, please, [asked Alice of the Cheshire Cat] which way I ought to go from here?’
‘That depends a good deal on where you want to get to,’ said the Cat.
‘I don't much care where—’ said Alice.
‘Then it doesn't matter which way you go,’ said the Cat.
‘—so long as I get SOMEWHERE,’ Alice added as an explanation.
‘Oh, you're sure to do that,’ said the Cat, ‘if you only walk long enough.’” —Lewis Carroll, Alice’s Adventures in Wonderland
When creating a product, you need to have enough of an idea of where you want to go to make sure you’re headed the right way. It's the product owner's responsibility to know and communicate a product vision for the team. Knowing where you want to go enables you to reach your destination; the details of getting there we all discover along the way. It is far easier to arbitrate the expected functional details then the minutia of the implementation. Technical individuals tend to lose themselves down a rabbit hole every now and again. It's the product owner's job to pull them back just a bit to the overall vision.
Stop scope creep. Little slips can have longer impact than first imagined. This costs the project both in terms of when the product will have the features it requires and also in opportunities for higher priority work.
Know your customers. The next iteration of work—whatever the team thinks it can deliver working at a sustainable pace—comes from the top of the backlog. Choosing the work that is the highest priority comes directly from knowing the customers. Understand who they are, what their needs are, and how they will interact with the product. By relating the specific uses of the product to team and giving them real examples, product owners can help the team provide some creative solutions.
Communicate. It can be easy to get lost in the technical detail when several functional disciplines (development, marketing, quality, test, and information developers) are all working together. Strive to talk to these stakeholders every single day. Ask questions. Not only will you learn something, you will also come up to speed more quickly. Part of the product vision is fixing the target: release date, cost, or criteria. When a team begins to veer from this vision, it's the product owner's job to perform course corrections. Occasionally, any group will go into the weeds for a while. They're so close to the work they can't see that working on one particular feature for many sprints is delaying the implementation of basic features. No one has a map on how to get there, just a field guide on the type of terrain. Communicate. Communicate. Communicate.
Inside Every Question Is a Quest.
The character of an individual is as unique as the identity of a team. A stage actor can tell you that every audience has its own personality. Teams are no different. Product owners must be able to earn the respect of the team, resolve conflicts through conversations, and adjust priorities accordingly. There are whole books dedicated to managing conflicts. Learning when to take a stand and when to give is important. It is more important, though, that everyone has a voice.
Though often perceived as oppositional, I have always tried to view differing conclusions as collaborative. Viewpoints and concerns from all disciplines, as well as how personalities present them, is the core of what a team does. The product owner takes some time to compare the premises and sorts them into priority order for the product. A good product owner always questions the importance and priority. What is the team likely to complete in this sprint? The team will let you know. The team will use your backlog and schedule what it is likely to complete.
Release planning is different; the plan to deliver a product through series or versions should be reviewed by the product owner so that the vision of the product ties directly to the goals and expectations. If the team is developing a car, for instance, then everything that makes the product drive-able is important; however, there is only so much time to spend on one aspect. The customer would not be pleased at the delivery of just the engine. There is a notion of right-sizing the work to fit into the time granted. Release planning at least every quarter helps the product owner and team focus on what is most important. It can afford a chance to step away from a particular feature and ask yourself, "Is this worth holding up the release?" As a primary reference on the product backlog, you will find you have requests from what seems to be a million people. Try to seek out the wisdom and futility in each request. The corollary to keeping the team focused is to filter out the noise and distractions for the team. This can sometimes mean learning how to balance and manage personalities. Have answers as quickly as possible. If you don't know the answers, get to know the subject matter experts. Go to them and get an answer for the team as quickly as possible.
Working with the Team Helps the Team Work.
When using Scrum, you should look for certain patterns of team behavior in order to encourage some and guard against others. The product owner, the ScrumMaster, and the team members themselves should all do this.
- Encourage swarming on tasks that need to be completed, even if it means stepping out of functional roles to do so.
- Make tasks a visible focus, not only to reinforce what needs to be done to complete the work, but also to train people that may be new to the team.
- Cultivate a sense of ownership by team members. The more ownership they feel, the more motivated they will be to finish the work
- Look for key signs of Scrum's intended interruptive innovation: features, requirements, and functions that emerge from a better understanding of customer needs and wants.
- Strive for linked project artifacts and loosely coupled processes.
- Decentralize control and empower team members to change processes and tools when it makes sense to do so.
- Expect geographically distributed teams to have culturally diverse preferences and contributions.
Show Your Work and Seek Feedback. Be able to tap every functional discipline/role for feedback. This speaks loudly to communication. As a product owner, try to make actions and decisions visible to the team. After all, the product owner often asks the team to “show me” what work was done; humans are hard-wired to process visual information. Doing your own work in front of the entire team is a great way to visibly reinforce best practices. Many eyes will usually make better “eye-deas.” I have always encouraged peer reviews on specifications, code, test plans, user documentation, marketing materials, prototypes, and websites… just about everything. When I asked that some technically gifted testers be placed as observers on developer code reviews, the testers thanked me for the heads up on where changes were occurring. They could see for themselves a few of the impacted functions. This made for better test cases and automated testing.
The Devil Is in the Details. User Stories define the work to be done. Capturing this work requires special consideration. Treat the story as a beginning of a conversation until the team is ready to estimate how big it is. By then, when the team is closer to actually performing the work, the scope should be fairly well defined and you should know what is unknown and left to investigate. A product owner who is specific in what needs to be done will be better than one who speaks in broad generalizations.
When the team is about to work on a story, the task breakdown of everything which needs to be done should be clear to everyone on the team. It saves a lot of time when the team has fewer questions and less to debate. Make those tasks visible. You can elicit most of the details you need to estimate and plan through a few quick conversations. Having these conversations in advance of the sprint is usually a big time saver for the entire team. Groom the backlog of stories for 1 - 2 sprints ahead, keeping the right level of detail for what you need to know right now. An analogy comes to mind with caterpillars. I have seen caterpillars chew leaves; they can eat quite a few. However they eat in little swipes on a single leaf at a time. They only consume a little with each chewing arc. They never get distracted by all the leaves and possibilities that a tree has; they focus only on the leaf that they are trying to eat, one tiny bite at a time. Going too deep into detail too soon leads to the proverbial analysis paralysis.
Mockup without Bogging Down. The use of mockups and prototypes enables you to get feedback earlier, without much development effort. At the same time, however, there are two dangers to be mindful of with prototypes.
- Don’t limit the creativity of your customer interaction. The prototype shouldn’t limit them; merely help everyone have a conversation on how to proceed.
- Prototypes should be cast off once vision and product development have grown. There is never a need for the butterfly to keep the cocoon. The prototype is not a sellable product. Efforts to sustain the prototype to keep it "current" are often unnecessary.
Define Success. Think long term and find ways to measure the improvement and success of a release. This might again speak to some of a products’ vision. If the end is not somehow defined, processes and people could keep going long past the desired endpoint. The product owner should be vocal in what is done and acceptable. Teams shouldn't try to surprise the product owner with extras. The focus should be on completing stories, listening to the feedback, and adjusting accordingly.
Peer Pressure Doesn't Create Diamonds.
As a product owner, you should be able to clearly represent the product across the business on a moment’s notice. Part of your role includes adjusting the organizations’ expectations as needed. Be clear about what the business is willing to pay for. Be even clearer about what the customer is willing to pay for. If you do this part of your job right, it will help enable and empower the team.
One way to ensure that you understand the true return on investment of a feature is to search out the technical support personnel (phone, e-mail, on-line, etc.) and learn what the pain points have been. Technical support is a cost to the company that is not always directly tied to the product, but is nonetheless tangible. Learn the painful parts and help to eliminate them in the product, anyway you can.
Be concerned about creating a stable environment for the team members to learn and contribute. It's imperative that you keep the team from being distracted. There can be so many competing priorities for an individual team member’s time: pet projects, process changes, side initiatives for a functional role. Stop work that isn't accounted for. Additionally, functional managers might feel compelled to fill free time with activity not listed on the product backlog. Work along these lines should be scrubbed, if not exorcised. At its best, this pull is only diagonal to where the team wishes to go. Any pulls on the team's time slow how quickly the product is developed.
When the environment is constantly changing, tools and processes must change rapidly as well. Expect the team to adopt and discard tools as needed. Understand that certain processes will become questionable or may be fleeting. It is your investment in the right people that will pay dividends over time. This leads into the first of the tenants of the Manifesto for Agile Software Development:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The Only Thing Between You and Your Customer Should Be a Conversation.
Working software is something your company can sell or that helps the organization leverage other products it can sell. Though we need to document this software to learn, extend, and teach, our focus is always on getting the product in the customer’s hands.
Treat the customer as a person, not as a legal adversary. Never envision your customer as some captive to talk through some confining legalese or technical limitation like a prisoner through bars. Nothing should separate a product owner from knowing what customers really feel and think. It would prevent leveraging their creativity and innovation. Anyone involved in helping to design a product is very likely to purchase it.
When bringing customers on to the team seems unlikely, create personas. A persona is a profile of a person who will be using your product. The more specific these are the better. Even if it only helps a single person on the team, the wall space used to keep these visible is worth it. Product owners can use a persona to describe a pattern of behavior with the product, help assess a use case, or bring some clarity to the product vision. Personas are analogous to design patterns in software, only now several behaviors are abstracted into, Mary the graphic artist. Personas can be an effective way to test and imagine product interaction. Personas should never be used to replace; but only to augment the presentation of real customer visibly to the team.
Do No Harm.
The product owner is not a dictated hierarchy, but a service role. The customer, the team, and the company are all tuned around the product by the product owner. As new information is discovered, the ability to change priority is one of the most important aspects to getting that product right. The highest priorities are for the greatest good. It will be rare that the difficulties and obstacles experienced by the team will be remembered. These things do not augment the accomplishment; they serve instead to strengthen and temper the achievers. If we build the right thing, there is usually a need for the right thing 2.0. Our experience and role as product owners can help determine how fast we get there.