The Many Hats of a Technical Program Manager - The Product Owner

The second hat is the Product Owner. Product owners (PO), above all else, represent the voice of the customer and are responsible for ensuring that the customer’s needs are met. Sometimes those customers are nameless masses and sometimes they are a small, niche group of subject matter experts. Regardless, the product owner needs to get to the core of their pain and come up with a way to solve that pain for them. This means product owners need the ability to feel what their customers feel on a visceral level. Empathy is a critical attribute of successful product owners.

This is part 3 of a multi-part series based on the various hats a TPM will wear.

You can read part 1 here: The Many Hats of a Technical Program Manager - The Engineer (drjoeshepherd.com)

Part 2 can be found here: The Many Hats of a Technical Program Manager - The Researcher (drjoeshepherd.com)

The Hat

Where the engineer hat is focused on making sure we build things the right way, the product owner hat is all about making sure we build the right things, at the right time, for the right reasons. This role focuses on the what and the why and is ultimately responsible for uncovering and defining requirements and making sure the engineering team delivers value early and often. More than any other hat, the product owner is responsible for ensuring the customer receives a return for their investment.

I’ve controversially made the statement that if a product fails to deliver against customer needs, then it is ultimately the product owner’s fault. Right now, you are saying to yourself there are a ton of reasons a product may not deliver customer value. Things could change, engineering may not have built something correctly, the customer may not have been clear in their requirements. All of these things may be true but it's the product owner’s job to ensure they do not block value delivery. They are the single throat to choke (convince me otherwise).

Requirements

The core of any product owner’s job is about defining requirements. It’s about taking what’s in the client's head, removing all the complexity and fuzziness, shaping that into an actionable backlog of requirements that engineering can then transform into value. It's not just about capturing everything a customer says into a backlog, however. You need to be a bit skeptical here and dig into the gory stuff that lies just below the surface. I find myself asking “why” quite a bit. Actually, where requirements are concerned, it's good to ask who, what, when, why, and why now.

So, what makes a good requirement? There are many ways to define a good requirement, but I tend to fall back on the following attributes. To me, a good requirement is:

• Correct: The requirement must accurately reflect what is needed.

• Well-formed: It should be clear and have only one interpretation.

• Complete: All necessary aspects of the requirement should be included.

• Consistent: It should not conflict with other requirements.

• Verifiable: There must be a way to validate that the requirement has been met.

• Traceable: It should be easily tied back to a higher-level feature or stated need.

You may not check all these boxes right out of the gate but that just means you need to follow up and dig in a bit deeper with the customer. I don’t worry about doing that for every requirement in the beginning. It's often better to capture the high-level stuff and refine the details when it gets closer to implementing the requirement. Requirements change so don’t waste your time until you are sure it's needed. Following these six criteria, however, will go a long way to ensure your engineers understand what they are building and why.

Portfolio Planning

If the engineer lives in the complicated “how” then the Product Owner lives in the murky “why”. AS you advance in your career things only become murkier. It's one thing to manage a feature set or even a product. It's quite different to own and entire program or portfolio of products. I often talk about taking moving a product or a customer from a current state to a desired future state. To do that, often requires a TPM to manage multiple work streams across multiple initiatives. Consider a customer who wants to infuse I cross their organization. A seasons TPM may be called on to manage that portfolio of initiatives. This is something that is far more complex than a simple product backlog.

Impacting Forces

The question “What could possibly go wrong?” is far too often followed up with the phrase “well shit.” TPMs are often called upon to be the keeper of risks. Risks are just one aspect of a category I call impacting forces. These are anything that may have a material impact on the project and include things like risks, constraints, and dependencies. These may be related to budgets, resourcing, limitations in the technology or any number of factors. The important thing is that it is the TPM’s job to run headlong into these impacting forces to ensure they never see the light of day.

Road Map

I remember pouring over the Rand McNally Road maps during family vacations when I was a kid. There wants any cell phones or portable video games, so you had the choice of a book or the trusty road map. My father was an Army veteran, so he taught me to read topographical and road maps. I always found it fascinating to track my progress against the mile markers in the paper map. Customer road maps are similar. You start out with a current location and set a destination, but things may change along the drive. You may need to detour based on a road closure or to incorporate a stop along the way. TPMs need the ability to chart a path from point A to point B while remaining flexible to what life throws at them. Understanding when and why to make a change and convey that change adds value is an important part of the job.

Stakeholders

Stakeholder management is crucial for a product owner because it ensures that the product aligns with the needs and expectations of all involved parties. By effectively communicating with stakeholders, a product owner can gather valuable feedback, prioritize features, and make informed decisions that drive the product’s success. It also helps in building trust and fostering collaboration, which are essential for navigating challenges and achieving project goals. Additionally, managing stakeholder relationships can lead to better resource allocation and risk management, ultimately contributing to a more efficient and successful product development process. In essence, stakeholder management bridges the gap between technical teams and business objectives, ensuring a cohesive and well-rounded approach to product development. One thing I’d lie to call out here though. I’ve worked in environments where the executives in my team wanted to be the gatekeeper of other execs. I welcome them having the relationship, but I highly suggest the TPM have a similar relationship. Too often this model results in an ivory towner culture where executive leadership is aligned and the resources on the ground are aligned but both are stopped dead in their tracks by the frozen middle.

Conclusion

In conclusion, the role of the Product Owner is paramount in representing the voice of the customer and ensuring their needs are met. Whether addressing the concerns of a broad audience or a specialized group of experts, the Product Owner must deeply understand and address their pain points. This requires a profound ability to empathize with customers, feeling their challenges on a visceral level. Ultimately, empathy is a critical attribute that defines successful Product Owners, enabling them to create solutions that truly resonate with their customers.