Be more than a product owner — Start product thinking

By the end of this article, which is based on a corresponding talk at DevOpsDays Amsterdam 2022, you will better understand that:

• Many software projects and teams are hindered by dark patterns in product ownership, such as a lack of product thinking;
• Product thinking involves consistently making many tough decisions while maintaining good relationships with a multitude of stakeholders from business, development, and operations;
• Three principles are fundamental to sound product thinking.

Product thinking principles

Virtually each mature framework for agile software development, such as Scrum or SAFe, recognizes the need for product ownership and/or product management. Both entail having product features described, prioritized, and mapped in time on a continuous basis — aspects of software production that are broadly embraced as essential input for successful delivery of valuable software.

The role played by the average product owner or product manager leaves a lot to be desired. Some consider themselves outside — or worse, above — their team and, in their self-sequestering, form lonely bottlenecks. Some actually lack mandate so merely act like spokespeople for the business. Others lack a consistent, long-term product vision, or they act as glorified scrum masters or agile coaches, fixating on process while forgetting product. And finally, most exert so much focus on new features that they virtually ignore the importance of non-functionals. In short, product thinking is missing. Three principles are fundamental to sound product thinking:

1. Product leadership over process and personal prestige

Part of product thinking is product leadership. So, what is product leadership? It’s a capacity that helps you understand and talk tech, business, and user experience. It enables you to put yourself in your end user’s shoes, knowing and feeling all that they will experience, and use that as input for product improvement.

Product leadership entails more than the software planning and production process. Too many product owners focus on work methods, feature descriptions, or project progress far more than on the product itself. Product leadership also requires undivided attention. Don’t do it as a side job, as this would imply too much delegation of core responsibilities — product ownership — and too little consideration of the why behind the product strategy, roadmap, or feature.

Product leadership means identifying the relevant and mandated stakeholders from business, development, and IT operations as well as representing the product for and to them. It emphasizes maintaining collaborative relationships rather than maintaining your reputation. Saying ‘no’ to feature requests should not destroy your relationship with stakeholders.

At the end of the day, product leadership is a job in the service of others. Yes, we’re expected to be a jack of all trade and serve as a mini-CEO, involved in everything. But ultimately, it’s about being a wholehearted member on the team, not outside or above it. So: prioritize product leadership over process and personal prestige.

2. Useful functionality over feature quantity

What exactly is this product that we should be leading anyway? Based on a composite of other definitions, I offer the following description to cover both the what and the why:

software product
a functional software system that satisfies user requirements and contributes to business goals by providing solutions to a domain-specific problem

As this definition illustrates, a product doesn’t really have a right to exist in and of itself; it should serve the goals of users, teams, or organizations. It should be useful. But adding more features to a product doesn’t necessarily make it more useful. I’ve met many product owners who seriously doubted the utility of a feature, couldn’t come to a clear conclusion, and therefore decided to ‘just’ create a setting for it. Often this indicates a lack of understanding the end-user and reflects a flawed product vision.

For example, consider these settings panes of Microsoft Word for Mac.

There are a lot of checkboxes. But let’s not confuse abundance with choice. Adding a feature setting implies adding debt, be it functional or non-functional. Besides the functional build costs, running and maintaining a feature has costs in terms of quality, security, and privacy.

Delivering a product successfully involves saying ‘no’ again and again. This is difficult: a ‘no’ is a rejection of one thing; a ‘yes’ is a rejection of a lot of things. Building and maintaining a clear, coherent vision helps because it clarifies why a particular feature should or should not be part of a release. So: pursue useful functionality over feature quantity.

3. Staying on course over satisfying singular milestones

Most project roadmaps plot an overly optimistic timeline that goes from the foot of the mountain straight to its peak. But often we need to descend into dark valleys before reaching the top. For example, the team needs more time to build a feature; a fundamental component requires rewriting to deliver acceptable performance; or end users turn out unhappy with what we have built.

In essence, staying on course with our roadmap is about dealing with uncertainty — and communicating effectively about it. And missing a single, or even singular, milestone might not be so bad as long as you’re staying on course.

The cone of uncertainty, a project management conceptualization brought into software by Barry Boehm, helps us visualize this uncertainty. The takeaway is not to make promises to stakeholders when our team finds itself on the left side of the figure — thick in the No Promise Plane — and estimates may vary by a factor 16. The farther to the right our team is — reaching the Paradise of Predictability — the better.

In his book Shape Up, Ryan Singer uses another helpful metaphor. With any project, there are basically two work phases: figuring out what to do — going uphill — and getting it done — going downhill. Only from the hilltop can we create a more precise timeline. Before we get there, the team still is figuring out what needs to be done. Let them. Only if we really, really need to communicate timelines before reaching the hilltop, do so in broad terms.

Staying on course means acknowledging that every project or feature build probably will come with a significant period during which many things remain unknown. One strategy to cope is to reduce scope, for instance, by leveraging the concept of a minimal viable product (MVP): the slimmest initial feature scope that end users would consider valuable. In determining this scope, realize that valuable doesn’t only mean functional; it means functional and reliable and easy to use. In short, make it nice.

And once MVP scope is established, something pushes us all the more to keep course: the MVP go-live. New usage patterns pop up, typically resulting in unforeseen bugs that need fixing. End users submit feedback that may require the team to redesign or rebuild a particular feature. Or user demand turns out to be significantly higher than anticipated, forcing the team to spend more time establishing the designed non-functional requirements. Staying on course means incorporating time for impactful events like these. So: privilege staying on course over satisfying singular milestones.

Boost the team. Boost the business. Start product thinking.

Product thinking is hard but achievable. The challenge is to translate the product vision and roadmap clearly and consistently into smaller, distinct features that are valued by end users and, at the same time, to guide the team along the way without getting in their way.

Taking these three principles onboard can help us build a better, more valuable product in a more predictable and thus reliable way. And it will boost team and business satisfaction as a result.