The just-in-time Product Owner
By: Elijah Calhoon
Tags: Software Development, Product Management, Product Owner, Programming, Agile

Photo by Drew Coffman on Unsplash

The just-in-time Product Owner doesn’t have to worry. Their work is never outdated. They are never endlessly piling requirements into the backlog while their product and their customer’s needs change around them. They deliver just enough, just in time. They are the masters of Now.

The Problem

Product requirements age. This is at the foundation of the Agile methodology. Customers change their minds, or the industry advances in some new way, and requirements which were tediously gathered 3 months ago become irrelevant. If you have ever rearranged your office, worked in it for a few weeks and realized that you wanted it arranged some other way, you have lived a perfect example of this. Customers are human; they change their minds and what they want or need today does not have much bearing on what they will want or need tomorrow.

The three common responses to this problem

Do nothing : Product Owners will gather detailed requirements for each feature request, as they come in. Then, when the feature is finally prioritized, they will go back to the customer and find that they’ve changed their mind, forcing the Product Owner to re-write requirements and redo mock-ups, causing double work.

: Product Owners will gather detailed requirements for each feature request, as they come in. Then, when the feature is finally prioritized, they will go back to the customer and find that they’ve changed their mind, forcing the Product Owner to re-write requirements and redo mock-ups, causing double work. Freeze requirements : The Product Owner will tell the customer that they aren’t allowed to change their mind. They still gather requirements early on, but when the feature is finally prioritized and it is discovered that the customer has changed their mind, the Product Owner says “sorry, these requirements are locked”. This method almost guarantees frustration all around, along with less value being delivered to the customer.

: The Product Owner will tell the customer that they aren’t allowed to change their mind. They still gather requirements early on, but when the feature is finally prioritized and it is discovered that the customer has changed their mind, the Product Owner says “sorry, these requirements are locked”. This method almost guarantees frustration all around, along with less value being delivered to the customer. Just-in-time requirements gathering: Being a just-in-time Product Owner combats this propensity for change with fierce adaptability. Product requirements are delivered to developers just in time for development, and with just enough detail to develop. Feature requests are kept at the bare minimum of detail until they are coming up on the development schedule one to two iterations in the future. Until that point, the detail which is maintained is just enough to estimate and prioritize. Once they are prioritized and scheduled one to two iterations in the future, the Product Owner creates mock-ups and gathers the requirements needed for development.

Scott W. Ambler’s diagram shows this ramp-up of detail well, illustrating that low priority, unscheduled items are loosely modeled, but as they become more highly prioritized, they become modeled in greater detail.

The risk of just-in-time

The one risk of practicing just-in-time is that a Product Owner will miss their deadline for having mock-ups completed, requirements gathered, and everything customer-approved. This is a real concern, but is less common than you might think. It is often mitigated tremendously by having developers who participate actively in the discovery process and are willing to accept a small level of uncertainty while late requirement are polished up.

So why not try it? Be a just-in-time Product Owner. Never worry again that your work will be outdated or that your customers will change their minds. You don’t need to worry. When a feature request comes in, you gather only what is needed to estimate and prioritize it. When features are one iteration out, that’s when you strike. You gather just enough, just in time. You are the master of Now.

Sources

by Scott W. Ambler

by Bob Hartman

by Aby Yohannan

by Alan O’Callaghan