The last key relationship product owners need to maintain is with the team. And although their relationships with stakeholders and the market are vital in determining what gets built next, it is in the context of the relationship between product owners and the team that the work actually gets done.

The responsibilites a product owner discharges through this relationship are:

1. Direct production to meet stakeholder expectations and user needs.
2. Share the product vision with the team.
3. Identify, aggregate and prioritise features and related benefits the product will deliver to users.
4. Prepare and maintain a prioritised list of summarised and detailed work items.
5. Describe product functionality by way of user stories.
6. Negotiate to prioritise work that mitigates technical and financial risk.
7. Prioritise work that accelerates team learning.
8. Validate the product for release, including use of user testing.
9. Decide whether to ship the product.

Lighting the path
Finding the right balance between documenting and doing is an art that still causes some anxiety in the team. And clearly not all documentation is bad. I encourage product owners to use the business case and vision to create a data sheet, which can be used to articulate the broad product vision to the team on a continuing basis.

This document distills out of the vision the principal features of the product, and their related benefits, in user language. If software was still sold off-the-shelf, this would be the promotional material printed on the outside of the box.

The overview is another document I encourage product owners to produce. This artifact contains as many of the product’s features and related benefits that have been conceived at this point, in more detail than the data sheet, but still in user language.

The overview, like the data sheet, still honors the product vision. Because it communicates how the product owner has interpreted the vision, when reading the overview team members often say, “Oh, I didn’t know you meant that. We’ll have to talk it through.” Then if proposed features and benefits need to be discounted for any reason, everyone is aware of the base off of which this is being done.

Obviously sprint planning sessions, sprints, and sprint reviews are opportunities to cement good working relationships with every member of the team. The strength of these relationships will shine through in the product. Keeping the team pointed in the correct direction is facilitated through strong product owner leadership in the product backlog.

With the previous documents in place the product backlog, which is a prioritised list of tasks described as user stories, becomes a doddle to produce.

Following on from the Doing the Business post, which discussed the relationship between product owners and stakeholders, what kind of responsibilities rest on product owners with regard to their product’s market?

1. Identify, aggregate, prioritise user needs.
2. Study and assess new markets, applications, products, and partners.
3. Perform gap analyses.
4. Follow commercial, technological, and legal trends.
5. Develop and maintain access to customer and industry evangelists.
6. Produce innovative, needs-based solutions.
7. Possess a strong understanding of customers’ issues and priorities.
8. Champion the product to internal and external audiences.
9. Study the product domain.

Do you know where you’re going to?
One of the benefits Agile offers is greater transparency, although too often this is only felt inwardly – inside the company.

I like to encourage product owners and their organizations to become comfortable publishing a product road map externally, to customers. This document creates an effective way for the market – as well as internal stakeholders – to view and interact with the product development pipeline.

On this basis, informed and unemotional discussion can be had about priority before inappropriate choices develop into crises.

In my experience, the benefits arising from your market being settled in the knowledge that you have a strategic direction for the product, for which they can plan, often result in customer loyalty.

Tom Peters was recently quoted as saying: “It’s always ‘the people’. It may be glib, but in this instance I don’t care. Network, keep your promises, behave decently. You are as good as your relationships. Period. Short term. Long term. Good times. Tough times. This is the time (though all times are, in fact, the time) to over invest in relationship building and maintenance.”

Although this is generally true in life, it is also particularly true of the relationships between product owners and stakeholders, users, and the team.

What kind of product owner responsibilities can be discharged through good working relationships between them and stakeholders?

1. Identify, aggregate and prioritise stakeholder commercial objectives and expectations.
2. Play a leadership role in determining product strategy and direction.
3. Influence or negotiate key strategy decision points and milestones.
4. Identify, establish and maintain, strategic relationships with key internal and external decision-makers and stakeholders.
5. Form and maintain the product vision.
6. Identify, contract, and maintain, business relationships that defend the product against strategic threats, create defensible competitive advantages, profitably grow existing business, and exploit or create new market opportunities.
7. Develop innovative product recommendations based on commercial, technical, and legal assessments.
8. Participate in developing business cases.
9. Identify and drive corporate themes through the product.

My view is that these responsibilities should themselves be treated with agility: In other words meet them in the context of the product, the business, and the other roles in the organization, like Product Managers for example.

A long one instead
How do product owners sense they are moving towards their objective of meeting stakeholder expectations?

Spend time with them. Apart from day-to-day interactions with stakeholders I usually encourage product owners to host regular sessions with them to in order to articulate key business risks and opportunities.

Having something sensible to say to busy executives who have committed their valuable time means that beforehand product owners should have mapped their products’ ‘DNA’ to provide a framework to discuss current and future product initiatives. It may prove handy to refer to a conceptual model, and a trading community model, during these sessions as well.

In my opinion nothing creates a visceral connection between product owners and their product like a business case and vision. Although products owners groan when I say they should write and maintain these artifacts, they are not the 100-page tomes of the past.

Mark Twain once apologized to his readers: “I didn’t have time to write a short letter, so I wrote a long one instead.” This shouldn’t be the approach product owners take with these documents: 3 pages for a business case and 4 for a vision. The outcome of the stakeholder sessions should be that the content of these documents is confirmed and updated.

Distilling out the product vision into a goal model is also a useful exercise, I’ve found.

When you’re faced with the ultimatum, “Do it or else,” what should your rational response be? “OK, sure,” or “Interesting idea; let’s look at it a little more closely before we take it any further.”

Being able to debate objectively with those who feel sentimental and passionate about their idea is a good way to help people see the pros and cons of what they’re suggesting. And, by applying a consistent rating method to each idea you’ll quickly build up a feel for which ones are winners, and which not.

Managing Agile’s New Product Rating template is a simple, yet effective way to confront the rationale behind new product ideas before the coding starts.

Please provide us with your contact details and we’ll send you a link to download your New Product Rating template.

One of the many unintended benefits, in my view, of applying Agile principles to your business thinking is culling a lot more initiatives before they even start. Common sense tells us this is a good thing, but in reality it’s often not perceived that way.

If you’ve set yourself up in business to develop software then that’s what you do, day in and day out, whether it’s a good idea or not. It is inconceivable to many managers that a Team can go through a period in which they are doing nothing commercially productive.

Warm and fuzzy
Perhaps this is a legacy of waterfall (wishful?) thinking, because when everything took so long to do it wasn’t a problem keeping the idea pipeline full. But as you reap Agile’s efficiency gains you may uncover a shortage of effectiveness and creativity within your company.

It’s usually then that you sense the presence of an age-old enemy: Sentimentality. It sounds sweet and is often said to “creep in,” whereas in my experience it is always a scoundrel that barges its way through the door, hand-in-hand with the CEO or another executive.

“We just have to do this,” the executive declares.

“Why?”

“Because we have to. Trust me on this, I’ve got a nice, warm feeling about it. And besides, what else will the Team do? We can’t have them sitting around doing nothing.”

Want a ‘Sentimentality-Buster’? Please provide us with your contact details to get your own Free! copy of a Managing Agile tool, which confronts the rationale behind new product ideas before they get started.

My superpower is listening, really listening, and when I filter out the political correctness, what I hear the executive actually saying is: “Listen sonny, this is my pet project. I’m the boss around here and if I say “Do it,” then you’ll just bloody-well do it.

“Oh yes! And when you make a mess out of this it’ll be your fault for implementing my good idea badly. I want to know now if you’re going to do this or not. If not, I’ll find someone else who will, and then what’s the point of having you around?

“Don’t you realize I get an ego (and bonus) boost by running the biggest dev shop in town. When everyone is always kept so busy I have to hire more people. That’s how it works around here.”

It takes guts and daring – leadership – from stakeholders, management, customers, and the Team to put initiatives to the sword, especially when the alternative is apparently doing nothing. Yet, for everyone’s sake, sanity, and back pocket, this is precisely what you must do. If Agile highlights that your company is not effective or creative enough, this is the problem to solve. Not how do I make everyone look busy.

I am often concerned during Executive reviews for example, that product visions are not well communicated to stakeholders. They are often not able to quote the vision for the products that make up their businesses. The visions don’t even make it onto the slides!

As Product Owners, you form and hold your product’s vision — but please don’t keep it a secret. Certainly every one in your team should be able to quote the vision verbatim, but I am disappointed if that’s as deep as it goes. In every presentation given about your product, your product vision should be the central theme. After all, your product is your business.

As a suggestion to get your product vision better known, why don’t you create an email signature that quotes it?

I know Product Owners know that forming a product vision is a key responsibility of theirs; what I don’t know is why it’s not used to unify and motivate the team and stakeholders alike.

Managing Agile will release its Business Case template soon. Be sure to keep a look out for it.

“The formulation of a problem is often more essential than its solution,” Albert Einstein once said. I’m sure he wasn’t talking about a business case at the time, but it’s equally apt to apply it to this essential product tool.

Many business cases I’ve read are framed in the solution domain, which should concern us because the business case may propose solving the wrong problem. As technology derives its value from the underlying business problem solved, solving the wrong problem will result in a sub-optimal ROI. And solving the wrong problem means the solution will fail because it’s implemented in the wrong context.

Solving the correct problem begins with asking questions. If you don’t know where to start perhaps it will help to remind you of a Rudyard Kipling poem in which he sets out a simple set of question framings:

Six Faithful Serving Men, by Rudyard Kipling
I have six faithful serving men
They taught me all I knew
Their names are What and Where and When
And Why and How and Who

I always suggest Product Owners write the business case for their product. It sometimes takes some convincing, but making the effort to argue for their product helps Product Owners tremendously when they need to make quick, consistent product calls.

Typing the first few words is often the most difficult, and maybe these fundamental questions may help them build their case:

Why should stakeholders invest in the product and how will it translate into increased shareholder wealth?

What is the problem or opportunity that needs to be solved?

and then:

When did the problem or opportunity start happening?

Who has the problem?

Why is the problem occurring?

These simple questions should give Product Owners a head start in producing compelling business cases for their products.

These days, when only remarkable counts, perhaps Kipling’s poem could be rephrased:
I have six faithful serving men
They taught me all I knew
Their names are What and Where and When
And Why and Wow and Who
How is not good enough anymore, it needs to be Wow! And Wow! begins its life in the business case.

The Agile Manifesto values working software over comprehensive documentation. In agile projects working software is the ultimate quantification of your project’s status. This may take some getting used to.

The signatories to the Agile Manifesto are not saying that technical documentation doesn’t have any value. Not at all; they’re simply emphasising the value of working software over comprehensive documentation. They’re saying that as working software should be the team’s goal, if producing detailed documentation for tradition’s sake is getting in its way, then it is time to adjust how much paperwork is produced.

“That is, whilst there is value in comprehensive documentation, we value working software more.”
-Signatories to the Manifesto for Agile Software Development

In addition, a number of the principles behind the Manifesto elaborate on this value:
- Working software is the primary measure of progress.
- [The team's] highest priority is to satisfy the customer through early and – continuous delivery of valuable software.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

How versus why
Finding the right balance between documenting and doing is an art that still causes much frustration in the lives of developers. And clearly not all documentation is bad. For example, sometimes end-user documentation is used as a criterion for ‘Done’. Sometimes it’s used to document decisions for team continuity. And documentation may even be needed for regulatory compliance. I’ve found it’s OK to leave the team to answer two simple questions: Is the documentation valuable? Is the team better off for writing it?

In my view this Manifesto value really addresses the project’s efficiency: The ‘how’ of the technicalities. The agile leader though, may be more interested in artifacts describing the project’s functional effectiveness: The ‘why’ of the business. This is because you are responsible for the software beyond its manufacture: Why you invested in it, and why it complements your broader business plan.

I’ve had great success using these documents to capture the business essence of an agile project. They convey stakeholder expectations of the project, the user needs the product will meet, and how the product will evolve once in the market. In my experience the benefit these artifacts bring to the team far outweighs the cost of producing them.

I strongly encourage Product Owners to produce these documents because they connect very deeply with the project through this process. Then, when the hard product calls need to be made, they’ll find the answers within them. And their confident, consistent decisions will earn Product Owners the respect of the other team members. Stakeholders will feel safe in their hands, too.

Business case
The purpose of the product business case is to set out: Stakeholder expectations; a mapping of the user needs to features to benefits; the proposed financial model; market opportunities identified; and, a product positioning statement. The product strategy outlined in this document should be consistent with the organisation’s business plan. (3 pages)

Vision
This is the chance to describe what the perfect product would look like—the outer bounds of market and functionality. The vision is derived from the business case and illustrates the problems that must be solved to reach the product’s goals, yet it should not be constrained by what is technically possible for the team. (3 pages)

Data sheet
This document distills out of the vision the principal features of the product, and their related benefits, in user language. If software was still sold off-the-shelf, this would be the promotional material printed on the outside of the box.(2 pages)

Overview
This artifact contains as many of the product’s features and related benefits that have been conceived at this point, in more detail than the data sheet, but still in user language. The overview, like the data sheet, still honours the product vision. Because it communicates how the Product Owner has interpreted the vision, when reading the overview team members often say, “Oh, I didn’t know you meant that. We’ll have to talk it through.” Then if proposed features and benefits need to be discounted for any reason, everyone is aware of the base off of which this is being done. (10+ pages)

Product backlog
With the previous documents in place the product backlog, which is a prioritised list of tasks described as user stories, becomes a doddle to produce.

Road map
So too with the road map: The release plan of future functionality is often a quarterly snapshot of the product backlog in a form that could be presented to internal and external stakeholders. Although some executives shy away from publishing the road map externally for fear of raising the market’s expectation of future functionality, I’ve found the benefits to outweigh the risks. The market appreciates that you have shared your plan for the product, and in turn it can participate more meaningfully in setting priorities.

I will elaborate on each of these documents in future posts, as well as provide templates of these documents for download. Be sure to look out for them.