We’re engineers. We build stuff. As for what we build, well, that’s a good question. Enter the product owner. This is the person who knows what we should build. They come in a few disguises: product manager, product owner, CEO, channel manager and VP customer relations are some aliases. No matter what their background, this is the person who translates between the customer, the market and the engineering team. That all sounds great. Having one person who can make product decisions will save on a lot of meeting time. There is a cost, though: That’s one person you’ll have to work with a lot. So how do you help the product owners – who usually aren’t engineers – understand the technical ramifications of various features, decisions and actions so they can do their job better? How do you as an engineer get the information you need? How do you get feedback from the product owner? How can you work effectively together? You need to train your product owner.

Goals of a Product Owner

Training your product owner starts with understanding their goals and needs. Their stated goal is pretty simple: Define and position a product that will meet the needs of the market and customers, and beat all of its competitors. You know, just predict the future and get it right. (OK, I’m being facetious, but only a little.) It’s a big job, and there’s a lot of pressure to get it right. Fortunately, the product owner has some help and a few tricks up her sleeve. She’s not making up the feature requests or the bugs in a vacuum. She’s analyzing competitive products, sitting through their demos and probably creating a large feature comparison spreadsheet. She’s talking to customers -- both existing customers and prospects -- and asking them about their needs, desires, processes and solutions. She’s looking at other markets and similar products in other industries to find the next big idea. She’s also listening to engineering and those flashes of inspiration you mention in passing. There are two main interface points between engineering and the product owner: feature definition and prioritization, and post-implementation validation. These are most easily expressed as two questions: “What should we build now?” and “Is that what you meant?” This is how the product owner gets her vision turned into software, and how engineers ensure that they are building something that’s useful.

Feature Definition and Prioritization

Feature definition and prioritization is the art of describing what a product should do. Over the years this has gone under many terms, such as requirements elicitation, feature definition, product requirements documentation and story creation. Ultimately, it's the distillation of all that vision and all that work, described in a way that lets engineering build it. This is frequently where things break down. The product owner comes to the engineering team with a feature that looks something like this: “It should calculate taxes based on the wholesale price.” To a product owner, that seems completely logical. To an engineer, it’s pretty vague. What taxes? Who is paying these taxes? When are they calculated? Do I need to show the wholesale price even to a retail customer so they can check the calculation themselves? Sometimes, the product owner comes in and says, “drop everything. This is the most important thing!” To many engineers, that’s also vague. Is it so important that they should miss this other deadline? What about yesterday’s “drop everything” that they haven’t quite finished yet? This is a moment to train your product owner. They don’t know how a feature is vague or confusing until you help them understand. After all, they have all the context of the feature, and you don’t. They don’t always know what you don’t know. So help them learn.

• Ask Questions: Take a story and start asking clarifying questions. “What is the wholesale price?” “Who should see this information?”
• Explain What You Need: Get on a whiteboard or open up the product and start pointing. “I have these three pieces of information. How do I combine them?”
• Explain What You See: Just like you don’t have the product owner’s context, they don’t have your context.
• Cover Edge Cases: Many times, the basic “happy path” function is pretty well defined. The tricky part -- and the questions -- are in the error conditions or the edge cases.

Most product owners aren’t engineers. It’s not your role to make them into engineers. Instead, it’s your role to help them understand what you need to develop software that meets their expectations as well as yours.

Acceptance

The opposite end of describing what should be built is validating the software after it’s built. In agile methodologies this is usually called “acceptance.” Other methodologies call it “validation and verification” or “business testing.” This is the point where the product owner looks at what was built and says, “Yes, this is what I meant.” Okay, let’s get rid of the elephant in the room: “No, that’s not what I meant” doesn’t mean engineering did it wrong. It doesn’t mean the product owner did it wrong. It means there was a breakdown in communication. Everyone did it wrong. Fortunately, it’s fixable. That’s why we have acceptance. Having a failure during acceptance is an opportunity to go back to the original feature request and talk about how it can be fixed to meet the product owner’s actual intent.

Tips for Training Your Product Owner

There are some simple things to remember about training a product owner.

• Repeat, Repeat, Repeat: No one is perfect after a single lesson. It takes reinforcement.  Be prepared to offer the same advice several times as your product owner develops helpful habits.
• Be Specific: Use specific features and specific stories to help the product owner learn what you need. Just like vagueness from the product owner isn’t useful, vagueness in your questions or requests isn’t useful, either.
• Mentor One on One: Group training is a useful introduction to concepts. One-on-one mentorship concretizes the lessons and makes them stick. This is a good time to ask questions, so don’t be afraid to ask as many as you can.
• Make Checklists: Over time you’ll notice a pattern to the gaps in the product owner’s requests. You’ll find yourself asking the same questions repeatedly, so put the questions in a checklist and give it to the product owner. Sometimes a simple prompt is all it takes to help them help you.
• Remember, They Know a Lot: They just know different things than you do. Product owners are almost never malicious or dumb. After all, they need your help to be successful. They just know different things than you do, and you need to help them understand your needs. This is about learning how to communicate.