The Art of Product Ownership (volume 1)
Table of Contents
I Meet the Product Owner
- 1. All about “What?”
- 2. Who is the Product Owner?
- 3. Requirements, Discover and Demand
- 4. Every Product Owner needs 4 things
- 5. Customers, Users and Stakeholders
II What do product owners do?
- 6. Scrum and the Product Owner
- 7. On-stage Product Owner
- 8. Off-stage Product Owner
- 9. The Busy Product Owner
- 10. Stop doing
- 11. The Product Owner Refactored
- 12. Specialist help
- About the author
- References & Further Reading
Xanpan: Team Centric Agile Software Development is available for free to all subscribers to Allan Kelly’s newsletter
This is an unfinished book. I don’t know when it will be finished, in part that will depend on you - your reaction.
If you like this book and let me know you like it - send me e-mail, send me corrections, suggest topics for inclusion and most of all pay money for it! - I’ll be more motivated and I’ll write more, sooner.
Please foregive all the spellings mistakes, poor grammar and so on. That can be fixed, I hope you like the ideas.
London, May 2018
In November 2018 “The Little Book of Product Ownership” was renamed “The Art of Product Ownership” and split into two volumes. This is volume one.
Some of the chapters originally in “Little” Book were moved to volume two. At the time of writing (December 2018) both volume volumes are on LeanPub and being actively worked on. Indeed, there may even be a volume three before I am done!
By way of thank you - and to allow you to read those essays - please use this link to obtain a free copy of volume one:
- Volume 1: Understanding your role as a Product Owner Draft
- Volume 2: Business Analysts, Product Managers and everyone else Draft - This book!
- Volume 3: Tools of the Trade Planned
The Art of Product Ownership series is designed as companions to A Little Book about Requirements and User Stories.
This book is a companion to Little Book of Requirements and User Stories.
Electronic (PDF, Mobi, ieub) version for LeanPub https://leanpub.com/userstories
Wednesday. George was the tactical product owner for the Cell Optimizer product. Project managers and operations staff regularly called him to discuss what Cell Optimizer could do and whether it would be useful for their work. As well as answering their questions he took notes on both ow the product would help their project and how it could help them even more - whether by adding new features, enhancing existing features, improving performance, accuracy, ease of use or one of a multitude of other attributes.
Most of George’s day was spent working with his technical team. Every second week they would hold a planning meeting. Today was the day before the planning meeting which meant George needed to comb through his product backlog and quarter plan to select the stories he wanted the team to tackle. Some of the stories he already knew could be broken down - these were Epics - but the team always surprised him in finding interesting ways to breakdown what he thought was a small story into several smaller stories.
Normally he would sit down with Diana for a few hours during the backlog review. Diana was the Strategic Product Owner and R&D Centre chief to look at the backlog but this week she was in Dubai with clients and operations staff. Although he called her a couple of times to discuss stories he made most of the decisions himself knowing she had delegated authority to him.
As he worked through his backlog and plans he occasionally wondered over to see Ahmed the technical lead. There had been a time when the whole team would be involved in reviewing the backlog but over time some of the team complained that it was a waste of time. So the team deputised Ahmed to attend the meeting, then Ahmed decided George could just ask him as needed. Tomorrows planning meeting offered plenty of time for technical conversations after all.
By the time he got on the tram to travel home he was confident he had enough stories and jobs selected to keep the team busy, and a few more incase the were ready to stretch.
The next day, Thursday, started with a 90 minute demonstration of the work which had been completed during the previous two weeks. George already knew what the demo would contain as he had previewed and approved everything during the sprint. He could have done the demo himself but he knew it was good to let programmers and testers show off their own work.
Most of the audience was project managers who wanted to use Cell Optimizer on their own projects. They were joined by some of the staff who would be hands-on with the product plus product owners and technical staff from other product streams which worked alongside Cell Optimizer.
Diana dialled in as did some operations project managers and other staff throughout the world. Occasionally one of the regional CxOs would too, especially if a high profile project was involved.
He was on hand to discuss questions from the audience and take more notes on how they would like the product to evolve - plus pick up whispers of new projects which might want to hire Cell Optimizer.
The demo went off without a hitch - which didn’t always happen - and the team was clear to deploy the new software. While the rest of the team grabbed a coffee Darren, the DevOps lead, would push the button to deploy Cell Optimizer to AWS. Later he would cut CDs to send to those needed on premise install. Not every user installed the latest version but the team would only support the latest version so the first thing anyone who had a problem needed to do was upgrade their software.
After coffee the team went into a retrospective for an hour and a half. The important thing was to find two or three things the team could improve. They didn’t need to be the best ideas - although that helped, they didn’t need to argue, they just needed a couple of things which had the potential to improve performance by 1%. And if they tried something and it didn’t help then they simply undid the change.
The planning meeting finally happened after lunch. The first task was to clear down the board of all the work done and update the tracking graphs. With that done the team lead stepped back and George stepped to forward. He quickly outlined what he was aiming for in the next sprint and then laid out the stories he was requesting.
The team moved through the stories in priority order. One by one the team looked at the story, discussed what was wanted with George, rewrote the story, added acceptance criteria and in many cases broke the story down into several smaller stories which George either kept in the sprint or pushed back to a later sprint. Often the team members broke stories down into technical tasks they needed to complete, this was more an act of collective design than work packaging.
It was only at this stage did the team add any effort estimates to the stories and tasks. Cell Optimizer was a little unusual here, most teams estimated three months worth of stories into the future. The Cell Optimizer team used to do this but they found that they spent a lot of time estimating work which never actually got scheduled so these calculated an average and told George to assume every story was four days work. Surprisingly this worked quite well, sometimes it was massively over and sometimes massively under but eight out of 10 times it worked well.
By the time the planning meeting was over it was time to go home. George put in a quick call to Diana to update her on outcomes but there was nothing unexpected so the call was short.
Right after the stand-up meeting on Friday George set about updating his quarter plan and backlog to reflect the outcome of the planning meeting. But he didn’t get very far.
First of all team members wanted to talk about the stories that were to be done. That was quite normal, stories are placeholders for a conversation after all and talking about them was a big part of George’s job. Some of these conversations happened right away but most of them were scheduled as 3-Amigo’s sessions to occur over the remainder of the week.
But, second, George was interrupted by a request from the field. Cell Optimizer wasn’t producing the expected result in Egypt and someone needed to investigate. George wrote out a yellow card - urgent but unplanned - and went to Sam the technical lead. They looked at the request together, rewrote the card and Sam set about doing it. As technical lead Sam was usually the one to pick up urgent but unplanned work. Not always though, others could be called on too.
All in all George hadn’t finished his own updates by the close of business. And he was due at a conference in town on Monday - inconvenient because the team had lots of questions but missing the conference would both deprive him of the latest thinking in the field and the chance to meet end-users.
So although he shouldn’t have, George ended up working through the backlog and plan changes over the weekend.
Most of Monday’s conference was boring, nothing new, but a few side conversations gave George new perspectives on customer needs. One of the presentations was from a direct competitor, while it didn’t contain any revelations it was reassuring to know what they were thinking along the same lines. But then again, when he thought about it: Diana always said she didn’t want to get into feature shoot-outs. She wanted Cell Optimizer to differentiate, perhaps tackle the same customer job but help the client achieve the same end differently, better.
It was Tuesday before he got to sit down properly with Diana and find out what had happened in Dubai. She had decided that the George should do the Dubai trip next month, she said this was because George would benefit from seeing Cell Optimizer in the wild and meeting with the project team but he suspected she was simply fed up of travelling.
Diana had come back with some more ideas and perspectives around Jobs to be Done by Cell Optimizer. (Diana and George had an ongoing debate as to whether Cell Optimizer provided several mechanisms to help with one job to be done or whether it helped with several jobs to be done which all centred around optimising the cell. Either way George had long ago given up on the idea that one day they would be “done”, no matter how many stories they delivered to improve the “one” job to be done they could always see more to do.)
Despite George needing to spend time with the technical team she thought they should take a couple of hours on Wednesday to revise the roadmap. The roadmap wasn’t due for a full review until next month - another day long session - but she wanted to review it in light of the Dubai trip. Diana couldn’t do it there and then because she had to see the COO later on Tuesday so Wednesday afternoon was marked for the roadmap review.
George could have ducked out but Diana and he were proud of their shared vision and the ability to deputise for one another. One or two of the other teams had Tactical Product Owners who didn’t work as closely with their Strategic Product Owner and there were occasional tensions when they wanted different things. Diana knew that George and the technical team could see things the technology could do that she had no idea about. In fact, Diana herself was SPO for three “Cell” teams at her centre and there was some tension with TPO for the Cell Monitor product.
Part of Diana’s urgently in reviewing the roadmap was because Thursday was capacity planning day. Since they introduced capacity planning a lot of the pressure had come off the roadmap. In his previous job George forced the roadmap to be part of the vision statement, a thinking tool, a capacity plan and a series of promises to projects and stakeholders. Now the roadmap was a what-if thinking tool to elaborate on the vision and imagine the future. While the capacity plan allowed medium term promises to be made to projects. One was vision, the other was delivery..
Although Diana was SPO for three products at her centre she didn’t have the final say on resourcing. So in capacity planning a couple of senior project managers and account managers joined to form a Centre Portfolio board which met quarterly.
Thursday found George and two other TPOs presenting their product lists to the Centre Portfolio board and make their bids for resources. The portfolio board had no time for effort estimates - occasionally new staff would present effort estimates as part of their bid only to be knocked back.
The portfolio board look at capacity - how many man-days the teams had over the next six months - and the value, or other priority, of the proposed Jobs to be Done for projects over that period. First off the portfolio board looked at all the jobs to be done and ranked them by value and priority. Immediately some fell of the end and some unlucky operations project managers would have to be told their request were not going to happen, they would have to use the product as they were.
Next the portfolio board allocated man days against each JBTD and determined the priority order. Some jobs were small but wold be done soon, others were large but would wait their turn. It hadn’t always been this way. For years teams, project managers and TPOs had argued over effort estimates. It took time to realise that business need and value should be the driver.
The second thing which changed the approach was when teams could reliably demo working, deliverable, software every second week. Once a team is potentially done every second week the game changes.
Each team is tasked with work and told: “You can give 20%” - or whatever - “of your time over the next six months to this job. It needs to be in the field by …” - some date - “how you achieve that is up to you and the TPO.” Giving the teams objectives rather than details, real deadlines instead of repeating their effort estimates back to them, and trusting them to deliver something was a game changer.
Although each of the three product teams would remain largely the same it was normal that a few people moved between teams. Sometimes this was a matter of expediency - Cell Optimizer was relatively well staffed while Cell Monitor was struggling - it also reflected individuals requests to move teams.
All in all that was Thursday. George was glad for a Friday where he got to spend time with the team, hold some 3-Amigos sessions to flesh out acceptance criteria, review some screen changes, do some tests, update his product backlog and quarter plan after the capacity planning session, reply to some user questions and more project manager enquires.
Mondays come around quickly and despite a busy Friday George hadn’t had a chance to catch up with himself - and team members had more questions and items for review. Monday morning provided some time but shortly after lunch he was on the way to the airport. Tuesday was a client site visit and a flight back.
All of a sudden it was Wednesday again and George had to review his backlog and get ready for Thursday’s planning meeting. Since Diana was in the office he wanted to spend some time with her talking about what the team would do next. And needless the end of the sprint mean the usual end-of-spring story reviews and sign-offs, a little more testing and suggesting some final modifications before the demon tomorrow.
Was it really two weeks since the last demo? retrospective? and planning? Well at least the next two weeks wouldn’t be so busy, no conference, no customer visit, no capacity planning, George would get to really get ahead of the game. Good thing too because the following sprint he’d be out in Dubai for a week. “Normal” weeks were not very common really.
|Wednesday||Get ready for planning||With team||Backlog review|
|Thursday||End/Start of print||Demo & retrospective||Sprint planning|
|Friday||With team||Team conversations, support||Quarter plan|
|Tuesday||Diana sync||Backlog review, plan review, JTBD, etc|
|Friday||With team||Team conversations, feature reviews||ACs, stories, etc.|
|Monday||With team||Team conversations||Flight to client|
|Tuesday||Client||Client meeting||Flight back|
… and repeat.
“Data beats opinions - If you don’t have any facts, we’ll just use my opinion.” Jim Barksdale, CEO Netscape Communications
Every Product Owner is Different.
Every Product Owner needs to work out what is right the right way for them to fill the product owner role. Every organization is different. Every team is different and every individual is different.
For a newly appointed Product Owner the first job is to sit down and decide what type of Product Owner will be. Both what the organization expects of them and what type of Product Owner they want to be.
- They may be a Backlog Administrator taking instructions from others. Structuring and filtering the backlog, working effectively with the team and burning down the backlog.
- They may be a Subject Matter Expert using expert knowledge of the domain to decide what the right product to build is. Then helping team members understand the details of what is being built.
- Some Product Owners will work like Business Analysts. They will analyse internal process and business lines, meet with stakeholders and balance competing internal requests. Frequently they will work as proxy customers.
- Others Product Owners will need to get out on the road. They will meet with customers - and potential customers. They will study their market and seek out opportunities using the skills of Product Management.
All Product Owners will need to call on skills from other fields too: Project Management, Consulting and Entrepreneurship to name a few.
Every organization will - rightly or wrongly - expect different things from the people it anoints Product Owner.
I cannot give you a flow chart for what a product owner does or should do. Nor can I give you a set of rules to say “When the customer says Foo the Product Owner should do Bar.” In the language of business schools: there is no contingent way of being a product owner. Every Product Owner and organization is different and they need to find their own path.
Product Owners do not work in isolation, they are first and foremost members of a team charged with creating and delivering products and/or services - typically software development teams. They will be members of other groups too. Product Owner groups, strategy groups and occasionally members of the management cadre.
As a member of the delivery team they have particular responsibility for “what is being delivered.” The responsibility is not exclusive, other team members have views and with encouragement should to share them. Still, Product Owners are first among equals when it comes to nominating what to build, and what to build next. Their skills, experience, time spent with customers (and users), research, analysis and more, means they are (or at least should be) the best informed people to make such decisions.
Importantly the Product Owner will need to say No to requests. Technology teams are usually fulll of good product enhancement ideas. Senior people, outside the team, will often make “suggestions” too. No team ‘Nocould implement every idea and someone needs to be able to say to be able to say “No.”
However every team is different and contains different skills and experience. As a result every team will differ in what it needs from the Product Owner and how the team members can support the Product Owner and share the work. For example, the skills and focus of User Experience Designers overlap with those of Product Owners, wise Product Owners make the most of those skills. Other teams members, especially Software Testers, bring skills and experience which can be leveraged.
Every Product Owner is themselves different and brings different skills, experience and insights to the role; and each Product Owner has different ambitions and aim for themselves.
But a Product Owner is not some other things:
- Product Owners who were a developer need to accept they will not be coding any more. There simply isn’t time and anyway, they need to trust the team.
- Product Owners who were Project Managers, Development or Line Managers should resist the urge to tell people what to do. Neither should they look too far into the future. Instead they need to recognise that their authority derives from their competence not from a position in a hierarchy. They need to re-focus on value not time.
- Product Owners coming from a Business Analysis background need to look beyond Business Analysis. Specifically they need to immerse themselves in the world of Product Management.
Every Product Owner, and those working with Product Owners, need to read and reflect on the role. There are really no hard and fast rules about what a Product Owner should or should not do.
Speak to any Project Manager and it isn’t long before they will talk about The Iron Triangle or The Triangle of Constraints.
Interestingly project success is usually measured by meeting to the same parameters: cost, time and scope. But, these parameters are best thought of as constraints, not success criteria. A solution to meet the scope requests needs to be build within a budget of money and time.
Since I am writing about software development I can refine this triangle a little. Consider budget, or cost. During software development where does the money go?
I moments thought should tell you that most money is spent on people. Salaries and wage costs usually dwarf everything else.
The more people who work on the endeavour and the longer they work, the more money gets spent. Many other costs are a function of people too: office space rental, machines, software licenses, etc.
Other costs do exist but they are insignificant in comparison. Especially now software runs in the cloud there is less and less need to buy hardware to run the end product, or data centres to set up. When considering the restraint it is reasonable to replace cost with people.
Hence I prefer to redraw the iron triangle to show people rather than money. One can easy work back to cost because:
Cost = People x Time
Some commenters would go further and replace “people” with “resources” to reflect the fact that some none human resources may be needed too. I prefer not to do this because people are the heart and soul of the work. People are more than just resources and deserved to be recognised as such. I’ll come back to people in a minute.
Some project managers try to reduce time, and therefore cost, by reducing quality. Specifically, they leave bugs unfixed and “technical debt” unpaid. Unfortunately, experience shows that such short run savings only really save money in the very very short run. Unpaid technical debt soon becomes a problem and costs increase as people battle weak code and fix bugs.
Those who have studied the economics of software development are pretty much uniform in saying that cutting quality increases costs and schedules:
The bottom line is that poor-quality software costs more to build and to maintain than high-quality software, and it can also degrade operational performance, increase user error rates, and reduce revenue by decreasing the ability handle customer transactions or attract additional clients’.
For the software industry, not only is quality free, as stated by Phil Crosby, but it benefits the entire economic situations of both developers and clients.* Jones, 20111.
Therefore, lets not consider cutting quality. Quality needs to be kept high if costs and time are to be minimised.
While traditional development aims for an end date it is more often an ongoing negotiation. As projects slip the end date is delayed - this in turn implies more costs as keeping the team staffed requires more money.
Traditional projects would postpone the end date again and again until one day it can no longer be postponed. Sooner or later - usually later - someone demands the work end.
Agile works differently. Firstly agile teams typically work in time boxes: two-week sprints. Every second week there is a negotiation about what will be build next.
There may be sprint followed by sprint followed by sprint but agile teams should know how long many sprints they have and when they need to be done. Provided they have a deliverable product at the end of each sprint then meeting a final deadline is trivial. (And any team not having a shippable product at least once a fortnight really shouldn’t call itself agile.)
Therefore, for an agile team, time is fixed. In the short run the sprint creates a deadline. In the long run the desired end date should be well known.
The number of people on a team is fixed in the short run simply because people cannot be added overnight. Hiring good people takes time. The best a team can hope to do is poach someone from another team in the same company.
But again, cost constraints may not allow people to be added.
And even if costs can be overcome and people can be found there is Brook’s Law:
“adding manpower to a late software project makes it later.” Fred Brooks2, 1975
Brooks’ can be generalised as:
“adding people to software development slows it down”
Therefore, on any software team the number of people is pretty much fixed in the short run and quite possibly the long run. (Of course people can always leave the team so team size is flexible in another direction at any time.)
So, people are fixed, costs are fixed, quality needs to be fixed at a high point, long-run deadlines have always been fixed and short-run deadlines are fixed in agile.
That leaves scope. Requirements. Stories. Use-case. The “thing we are building.” Call it what you like - I like to call it demand. Whatever we call it this is the only parameter which is flexible.
And someone has to make those decisions. Three guesses who that is.
The Product Owner.
When working agile the thing being built is in a constant state of flux both in the short term, and possibly to a lesser degree, the long term. Since the “what are we building?” question is the raison d’etre for the Product Owner role the role becomes very important.
Traditional project managers were trained to flex everything but scope. Traditional project management saw the “what are we building” question as determined before the work begins and fixed. The job of the project manager is to deliver everything asked for within the constrains.
Of course at the first sign of slippage the traditional project manager would ask for more time - which implies more money too.
Ignoring Brook’s Law such project managers would also look to increases resources - which also increase costs. At the same time they would lean on developers to cut quality - which would reduce quality and sap their morale and motivation.
Traditional project management held scope sacrosanct until every other option had been exhausted. (And in exhausting those other options often made the situation worse.)
If there is one different between agile working and traditional it is this: agile constantly flexes scope.
Hence, the Product Owner role comes to the fore and the project manager role steps back.
At the most basic level the Product Owner is the person who decides what gets in the next. The term originates in Scrum but it is not unusual to find the term being used in teams following other approaches, e.g. Kanban, or their own hybrid processes.
In the early descriptions of Scrum there was a tangible feel that the Product Owner really had the authority to make decisions. They were the OWNER. I still hope that is true, but more often than not the person playing Product Owner is more likely to be a proxy for an owner or multiple real customers or stakeholders.
There are two common problems in having a real owner, i.e. a real person who wants the product, in the role. Firstly they can lack the skills to be a product owner. Writing User Stories and adding them to a backlog might be easy but that is a small part of the role. Product Owners other abilities need to include:
- Interpersonal skills to work with a team.
- An understanding of technology and software development.
- An appreciation of the commercial pressures to deliver products and value.
- Skills to value stories and o create and execute product strategy.
- Focus to work in short iterations to deadline.
- Ability to say No and limit work.
The second problem real owners often face is time. By definition, real owners have real authority and real responsibilities. Being a Product Owner is almost a second job. Surrendering their “day job” jeopardises authority but keeping it can mean they lack the time to be an effective Product Owner.
It is possible to have others fill the PO role. Provided that is, they can satisfy the four attributes set out earlier: skills, authority, legitimacy and time. Indeed, having a qualified specialist fill the role has many advantages - especially when there are many customers.
As already noted, Scrum describes what Owners do within the Scrum setting but not how they know what they need to know to make those decisions. That knowledge comes because underneath they have real skills and experience.
For many years I have described the title Product Owner as an alias. The title Product Owner describes a specialist who, in the Scrum setting, undertakes the work defined for the Product Owner. As such the title Product Owner has often been a alias for someone who is employed in another role.
Product Owner is a Scrum defined role. In my experience the role is usually filled by a Product Manager, a BA, or SME. As others have put it “Product Owner is a role not a title.” In other words: nobody should have Product Owner on their business cards.
While this is still true for some Product Owners but the world is no longer so clear cut. Today’s Product Owners need skills from all these domains. A PO may well need product management skills, business analysis skills and subject matter expertise.
The Product Manager role and the Business Analyst role have a lot in common. Both roles seek an understanding of what the product needs to do, and to communicate that to the team building the product. While the roles need a similar aptitude and skill set they are are different. The roles are close cousins rather than siblings.
In general Product Managers work at companies that create software that sells in a market against other products. They are outward facing. They know they need to seek out customers and find out what they need to make their lives better. Product Managers need to consider competitor products and changes outside the company.
In contrast, Business Analysts work at companies which develop software for internal use. These are specific developments for companies which are only used internally. The natural home of a BA is the corporate IT departments - and external service providers (ESP), “outsourcers”.
Business Analysts look inwards, they look at the operations and needs inside a company. They know exactly who their users are - in some cases there may only be one user. When BAs look outside the company they may well be looking at suppliers as alternatives to development not as competitors in the market.
The similarities and differences between the Product Manager and the Business Analyst roles are often overlooked.
As if the confusion between BA, Product Manager and Product Owner were not enough there is a third role which is sometimes added to the mix: the Project Manager.
Like the Business Analyst the Project Manager role is somewhat ill-defined and quite elastic. The standard text for the PRINCE 2 method (a popular project management technique in the UK) does not define the role of Project Manager (Commerce 2005).
As a rule-of-thumb BAs and Product Managers are concerned with the “what” of a development while Project Managers are concerned with the “when”. Beyond this different organizations slice-and-dice responsibilities differently.
While PRINCE 2 contains processes to ensure the “what” and “why” are defined (in the business case) it is silent on who should create these documents. Neither is there any guidance on how to create a business case or what skills are required to write one. This is because writing a business case is not a project manager’s responsibility.
Project Managers are not Product Owners, neither are they Business Analysts or Product Managers. Project Managers have different training, different objectives and often different experiences.
The PO as an alias for Product Manager or Business Analyst is a nice model and helps explain the world. But it has always been a model and, as with all models, it simplifies the world to explain it. One problem with this model has always been that the different roles, Product Manager, Business Analysis and Subject Matter Expert have never been completely clear cut.
As business becomes increasingly digital things are changing. As companies use more software technology the role of software changes too. Software products are no longer an operational cost saving mechanism. Software today is a customer facing strategic route to competitive advantage. Consequently the roles of PO, BA and Product Manager are evolving too.
Once upon a time software companies sold software products. Today the same companies sell services enabled by that software. You can still by Microsoft Word but increasingly people use a word processing service such as Office 365 or Google Docs. The customer experience has expanded.
Once upon a time corporations used IT to improve efficiency in operations, software technology was back office. It was there to cut costs and help fewer people deliver more. But today customers are more likely to interact with the corporation online. Consequently the customer experience now includes a technology experience through the computer.
By focusing on stories, backlogs and sprints the Scrum Product Owner role simplified the “what shall we build?” question. Scrum was good because it highlighted the need for a Product Owner. But at the same time, by simplifying the role it overlooked important skills. Product Owner roles were a pale shadow of the Product Manager role, and the Business Analysis aspects often overlooked.
Today Business Analysts need to be able to think like Product Managers and Product Managers need to be able to think like Business Analysts. (A new variant of the BA has appeared in the job market reflecting these changes: the Digital Business Analyst.)
There is still some validity to those who proclaim “Product Managers are not Product Owners” or “Business Analysts are not Product Owners” but the world has advanced and got messier. The world needs a new model.
The employment market has decided: Product Owner is the role. The Product Owner role deals with the demand side, requirements and discovery. This is the role which considers needs and decides what gets built.
The collision between the world of Business Analysts and Product Managers is now complete. The Product Owner is now a superset of Product Manager and Business Analyst.
A Product Owner today may find they need to play the role of Business Analyst, Product Manager and Subject Matter Expert. Product Owners today may well need the skills of business analysis. They are even more likely to need the skills of Product Management. And they will need to know about the domain.
Today’s Product Owner may well come from a Subject Matter Expert background. In such cases they need to learn about Product Ownership, Product Management and Business Analysis.
Or they may have a Business Analysis background and need to absorb Product Management skills. Those who come from a Product Management background will need to learn some Business Analysis. In either case they will learn about the domain but they may want to bring in a Subject Matter Expert too.
To make things harder, exactly which skills they need, and which skills are most important is going to vary from team to team and position to position.
The modern Product Owner role is one of understanding what will make a product or service competitive in the market place. As such most of the role will closely resemble the Product Manager role. They will need to look outside the company to decide “what the right thing to build” is.
The modern Product Ownerneeds to be part Business Analyst. They need to consider how the product serves the company and how the company works with the product.
Some Product Owners will find they are primarily looking inside the organization in order to improve the organisation, and the services they deliver using technology. They will need to examine internal process and talk to internal stakeholders. Using business analysis skills they will determine “the right think to build” and communicate it to the team.
Increasingly roles overlap and the lines between them blur. Every Product Owner needs to consider where they lie on this spectrum from internal to external, from BA to Product Manager.
Product Owners will need other skills too: domain expertise, leadership and even technical skills. Every Product Owner needs to decide for themselves what their role calls for. The should ask themselves: what are the skills I need? and how can I best help this team and this organisation?
“The picture of the software designer deriving his design in a rational, error-free way from a statement of requirements is quite unrealistic. No system has ever been built that way, and probably none ever will. Even the small program developments shown in textbooks and papers are unreal. They have been revised and polished until the author has shown us what he wishes he had done, not what actually did happen.” Dave Parnas
Product Owners, Business Analysts and Product Managers are primarily concerned with the “what shall we build?” question. They may be considering this in the short term “what shall we build in this sprint?” or the long term “what shall we build in five years?”
Traditionally software development answered such questions with Requirements. The Requirements described - in writing - what needed building. Embodied in this concept was the assumptions that the thing to be built could be defined and that defining the thing would be beneficial.
In the classical model a requirements phase would precede development of the software product. Only once the requirements - and specifications - had been pinned down whould development commence (officially).
(The term specification is colloquially used as a synonym for requirements. Strictly speaking the terms mean different things. A specification is a constrained form of a requirement. A requirement described the desired result while a specification is far more, well, specific.)
Under the classical model software developers believed that provided requirements (and specifications) could be detailed and accurate enough then most - if not all - problems would be solved. Naturally, once decided requirements and specification should not be changed - they were “frozen”,
In the extreme this lead to the creation of formal mathematical proofs. At University I learned to write these detailed requirements and specifications using formal logic. While exact these requirements were unintelligible to most people - even experienced programmers. Such “specifications” were little different from program code.
For multiple reasons - not least the rise of Agile software development - the assumptions underlying the notion of requirements have been challenged.
To start with the idea of written requirements came into question. Some pointed out that the written word is not a great way to share knowledge. Others pointed out that large requirements documents take time to write, cost money to write and seldom get read in depth. When they do get read the reader seldom remembers much.
Software metrics expert Capers Jones has some interesting observations on requirements documents:
“the widely used concept that quality means ‘conformance to requirements’ is illogical as a serious quality definition. Requirements errors themselves constitute one of the major problem areas of the software industry (about 15 percent of defect totals).” Jones, 20083
Requirements documents form a significant proportion of all system documentation:
“What is astonishing about paperwork volumes for very large systems is that the specifications and technical documents can be large enough to go beyond the normal lifetime reading speed of a single analyst!” Jones, 2008
Assume for a moment that one could write down requirements in sufficient detail, free of errors, and communicate them perfectly to the development team. There is still a bigger problem.
The world changes.
Commercial needs drive most software creation. While software development is happening the commercial world continues to change and evolve. Much of this change is because technology itself evolves and changes. New technologies create new opportunities.
Some teams still try to pin requirements down before they start working. Some teams still resist changes to requirements once work has begun. Some people still believe defined, fixed, requirements are an essential foundation for successful software. If it works then fine, these people are free to continue, but many teams have abandoned this approach as they adopt Agile.
The basis of Agile software development is the belief that it is better for a team to be flexible and responsive to changing requirements rather than highly adapted to fixed requirements.
If a team assumes requirements are known and will not change then any changes will create significant problems.
If a team assumes requirements are vague and will change then if requirements do not change they will still succeed.
As a result of the rise of Agile software development teams take a more flexible approach to requirements. Teams assume the need is vague, they assume requirements will emerge as work progresses and they assume that value will become visible during the work.
Rather than talk about requirements - which are assumed to be known - they prefer to talk about discovery.
The aim of the team is to discover the customer needs and discover the value of those needs. A little discovery may occur before any code gets written but importantly discovery will continue while during products development.
The discovery model assumes rapid feedback both from users of the product and from the market reaction to the product. Feedback from the development team is incorporated even before customers see the a product.
Some have refer to this model as Dual-Track: a discovery track and a development track operating in parallel (see Jeff Patton4 and Marty Cagan[^Cagan]). Â Requests from the discovery track to the delivery track may still be called “requirements” but term is vestigial and does not come with the assumptions of perfect foresight.
The question “what shall we build?” is non-trivial. I like to apply economic thinking here: there is supply and demand.
The supply side is easy: Software supply is the activity of building and delivering software. It is programming, design, development, engineering, it is operations, DevOps and so on. Most of the thinking around Agile software development discusses software supply - and increasing software supply at that.
The demand side is somewhat more complex. In part this is because assumptions around supply model influence how requests are presented. And in part this is because much demand for software does not exist - or at least is not visible - until one understands what technology can do.
Who needed e-mail until they saw e-mail? Who knew they needed e-mail connectivity 24x7 in their pocket until they saw an iPhone?
The history of “texting” - the Short Message System (SMS) to give it the correct name - is illuminating here. SMS was originally devised as technical capability for the engineers designing GSM phone systems. No customer asked for SMS. Nobody requested a 160 character messaging system in their pocket.
Even after SMS texting exploded in Europe in the early 2000s American telcos failed marketed SMS or opened gateways between their networks. A PacBell subscriber could not text an AT&T subscriber. For some years American’s didn’t feel any need for something which had become essential in Europe.
Today cellphone users in the USA alone send over six billion message a day.
As upfront requirements documents have given way to dynamic dual track product discovery the nature of the work has changed. At the turn of the millennium it was common to find Product Managers writing BRDs (Business Requirements Documents) which begat MRDs (Market Requirements Document). Development teams would take the MRD and may create an FRD (Features Requirements Document.)
Business Analysts followed a similar process with different document names. A Business Case would begat a Functional Spec which might begat a Program Spec.
The emphasis was on up front definition. To do this Product Managers and Business Analysts would extensively research and analyse the need, the problem, the opportunity. They would conduct user interviews, examine market trends and similar systems, they would run focus groups and requirements workshops.
These models were born in the late 1960s and early 1970s. Even though the models evolved they still embodied the assumption that programming was expensive and slow. That was true in the 1970s because computers did have limited in resources.
In the 1970’s it made sense to do upfront analysis and documentation because CPU cycles were expensive relative to paper. The machines were a limited resources so moving activities away from machines was more efficient.
Now, in 2018, computers are an order of magnitude more powerful. Today it can be far faster, and cheaper, to program something - perhaps using quick prototyping and wire framing tools - put it in front of customers and see what the reaction is. Today’s programming tools make it far easier to discover needs by building something and observing the result. Testing in the market allows rapid analysis of commercial opportunities with real data.
One could argue that Agile software development has driven this trend. Agile lends itself to this style of working because teams work in short iterations to produce small product increments while responding to changing needs rather than adhering to plan.
But this confuses cause and effect. Agile is itself the result of the increases in CPU power. Massively more powerful machines have reduced the time and cost of creating viable products which can provide useful feedback.
Agile a process which allows utilisation of cheap Â available CPU cycles. When the relative prices changed the economics changed. Sticking with the traditional process would not utilise the cheap CPU cycles. Cheap CPU cycles make a more efficient process possible.
Today, CPU cycles are cheap. Therefore, in relative terms upfront activities - analysts and documentation - are expensive. Far better to exploit cheap CPU cycles.
The move from requirements to discovery is simply economics.
For Product specialist (Product Owners, Product Managers and Business Analysts) these changes mean their roles need to change too. Detailed research and analysis, captured in a document gives way to experimentation, face-to-face conversations, analysis of results, feedback and iteration.
Those on the demand side can still learn from research reports. They can - and should - still interview users and customers about their needs. Performing stakeholder analysis, observing customers and holding focus groups can still produce useful insights. And I still recommend all product specialists read The Economist to keep abreast of global and commercial changes.
But while these activities once constituted the bulk of the Product specialist work they are now a small part. The learning offered by these activities is still valuable but in market experiments offer rapid learning which is even more valuable.
Analysis today is more likely than not to be undertaken after customers see a product than before. Product specialists should now be working with teams to create products, then observing and analysing the results. Technology can help her too: the likes of Google Analytics and screen recording systems can provide data for analysis
Instead of creating defined requirements product specialists may create hypothesis and experiments. They create a small piece of product and oversee how customers react. Analysing the result determines the next action: refine the experiment, expand the experiment, or forget about it and try something different.
Sometimes this process gets call Build-Measure-Learn. Although this is itself a variation on the Shewhart cycle: Plan-Do-Check-Act.
There is nothing wrong with upfront planning and analysis. However it has rapidly diminishing returns. The first five minutes offer fantastic returns on investment. But after two hours of planning another five minutes will make little difference. And after four hours each extra minute probably has a negative return on investment.
Do a little planning. Then build something. See what happens. Analyse the result. Learning is rapid in these stages and th return on time spent is high. Now repeat.
I sincerely believe there are better Product Owners and not-so-good Product Owners. There are some organizations (teams, companies, enterprises) which offer a better environment for Product Ownership and equally there are those which are downright hostile to product ownership.
To be an effective a Product Owner needs at least four things.
There is more to being a Product Owner than simply writing user stories and prioritising a backlog. Yes, you need to know how to work with a development team and how to work in an Agile-style process. Yes you need to be able to write user stories and acceptance criteria. Perhaps BDD style cucumbers acceptance criteria too. Yes you need to be able to manage a backlog and prioritises and partake in planning meetings.
But how do you know what should be a priority?
How do you know what will deliver value? What will please customers? Satisfy stakeholders?
Importantly Product Owners need to be able to do the work behind the backlog. Prioritising and refining backlogs do not happen in isolation. To work effectively POs need a constant flow of current information.
Any idiot can pick random items form a backlog but it takes skills and experience to maximise value. Product Owners need to meet people, hold conversations and think about what they have learned. If necessary they need to do analysis and revisit the conversation to dig deeper.
Product Owners need to be able to identify users, segment customers, interview people, understand their needs and jobs to be done. They need to know when to run experiments and when to turn to research journals and market studies. And that might mean they need data analysis skills too.
If the product is going to sell as a commercial product you will need wider product management skills. Those creating products for internal use will find business analysis skills vital.
As a PO you may also need specialist domain knowledge - you might need to be a subject matter expert in your own right; or you might become an SME yourself given time.
Some understanding of business strategy, finance, marketing, process analysis and design, user experience design and more.
Don’t underestimate the skills and experience you need to be an effective Product Owner.
At the very least a Product Owner needs the authority to nominate the work the team will do during the next two weeks. They need the authority to choose items form a backlog and ask the team to do them. They need the authority not to have their decisions overridden on a regular basis. (OK, it happens occasionally.)
As a general rule the more authority the Product Owner has the more effective they are going to be in their role.
The organization may confer that authority but the team need to recognise and accept it too.
I’ve seen many Product Owners who while they have the authority to nominate work for a team don’t have the authority to throw things out of the backlog. When the only way for a story to leave the backlog is for it to get developed things get very expensive. This leads to constipated backlogs stuffed full of worthless rubbish and where one can’t see the wood for the trees.
If the Product Owner doesn’t have sufficient authority then either they need to borrow some or there is going to be trouble.
Legitimacy is different from authority. Legitimacy means one is recognised as the right person, the bonafide person to exercise authority and do the background work to find out what they need to find out in order to make those decisions.
Legitimacy means the Product Owner can go and meet customers if they want. And it means that they will get their expenses paid.
Legitimacy means that nobody else is trying to fill the Product Owner role or undermine them. In particular it means the team respect the Product Owner and trust them to make the right calls. Most of all they accept that once in a while - hopefully not too often - the Product Owner will say: “I accept technologically X is the right thing but commercially it must be Y; full ahead and damn the torpedoes.”
It can be hard for a Product Owner to fill their role if the team believe someone else should be managing the backlog and prioritising work to do. That doesn’t mean the Product Owner should freeze out willing helpers, if a developer - or anyone else - takes an interest in customers and prioritisation then the PO should seek to enlist their help. But balance is required and the first step may be to simply acknowledge someone is interested in helping.
Executives, managers and especially sales teams need to recognise the PO as legitimate. In many organizations the question of “what should be built next” has in the past been left to development and other managers. Managers accustomed to having such authority need to accept the PO as legitimate and not override their decisions.
Similarly, sales staff need to recognise the legitimacy of the Product Owner too. Sales people can can become accustomed to using the promise of a big sale to direct development to their own priorities. Product Owners will sometimes need to tell a sales person that a feature they claim is essential to a client will not get delivered soon - or perhaps at all.
Finally, and probably the most difficult: Product Owners need time to do their work.
They need time to meet customers and reflect on those encounters.
They need time to work-the-backlog, value stories, weed out expired or valueless stories, think about the product vision, talk to stakeholders and more senior people, and then ponder what happens next.
Time to evaluate what has been delivered and see if it is delivering the expected value. Time to understand whether delivered enhancement generate more or less value than expected. Time to feedback those findings into future work, then recalibrate expected values and priorities, generate more work or invalidate other work.
Product Owners need time to look at competitor products and consider alternatives - if only to steal ideas!
They need time to work with the technical team: have conversations about stories, expand on acceptance criteria, review work in progress, perhaps test completed features and socialise with the team.
Much of this work requires more than just time, it requires time at the right time. Deferring a conversation because of time pressure may mean that important information is unknown at the right time. Failure to work with the team at the right time might mean work needs repeating or fails to deliver the potential value.
They also need time to enhance their own skills and learn more about the domain.
And if they don’t have the time to do this?
Without time they will rush into planning meetings saying “I’ve been so busy, I haven’t looked at the backlog this week, just bear with me while I choose some stories…”
More often than not they will wing-it, and substitute opinion and guesswork instead of solid analysis, facts and data. They overlook competition and fail to listen to the team and other managers.
And O yes, they need time for their own lives and family.
I sometimes think that only Super Human’s need apply for a Product Owner role, or perhaps many Product Owners are set up to fail from day-1. Yet the role is so important.
In one of the earliest studies of the XP Customer role - which parallels the Scrum Product Owner role - Angela Martin found that “the customers [role] had the most pressured and stressful role in the project, requiring significantly more effort than the development team members.”
In part Martin suggested this was because “it is far too easy for anything that is not to do with programming, or that is not explicit covered by XP’s practices, to be defined as a ‘business’ requirement, and thus, to become the sole responsibility of the customer.” 5
This book sets out to explore the Product Owner role. A later volume will explore the tools available to those who rise to the challenge.
“There is only one valid definition of a business purpose: to create a customer.” Peter Drucker
Personally I dislike the term “user” because, as the old jokes highlight, it is not a term that commands respect. That said it is the term the IT industry has adopted. No other term is as widely known.
The term customer is a potential alternative to user and does command respect. However I think the two terms are used to describe different type of people.
Both customers and users - whether the terms describe the same people or different people - are both example of stakeholders. But there are potentially far more stakeholders of any product, system or service than there are customers, or users.
Because Product Managers traditionally focus on products for use outside the company they tend to think about customers - some of whom may be users. In contrast Business Analysts tend to consider stakeholders - who may or may not be users.
The dictionary on my Apple Mac defines customer as: “a person who buys goods or services from a shop or business”. The same dictionary defines user as “a person who uses or operates something.” There is a commercial aspect to customer which users lack.
When one considers a company like Facebook this becomes important. Facebook (currently) has over one billion users but few of these are customers, few of them pay any money. Facebook customers, the source of revenues, number a few thousand or tens of thousand.
The Financial Times once quoted an online executive as saying “You have a customers credit card number, users don’t pay.” This certainly passes the Facebook test.
While important the commercial aspect is not the only thing that marks a customer as different from a user. My own definition of a customer has been: “A customer has choice, they can choose to use your product, use an alternative, or even use nothing.”
My definition fails the Facebook test but highlights how users are often captive and have little choice but to use the software they are given to use.
“Requirements ultimately begin and end with people - stakeholders” Alexander and Beus-Dukic6, 2009
“A stakeholder is a person group or object, which has some direct or indirect interest in a system. Stakeholder can exercise control over both the immediate system operational characteristics, as well as oner long-term system lifecycle considerations.” Gilb[^Gilb 2005], 2005
The first challenge facing a Business Analyst is normally stakeholder identification: Who are the stakeholders? The second challenge is to understand their stake: why do the have an interest? is their interest legitimate? are they active or passive in holding their stake?
Traditional business analysis has positioned stakeholder identification as an upfront activity which is done in the early phases of work. In an agile setting it might be better seen as an ongoing exercise as new stakeholders become involved and others step back.
The third challenge with stakeholder is to keep them involved, at the most basic level this means communicating progress to them - and perhaps delivering bad news. Again, in an agile setting ongoing stakeholder management will involve far more: demonstrating evolving software to stakeholders, receiving their feedback, listening to their new ideas, evaluating new requests and, perhaps most importantly, evaluating the impact and value changes are having as they are delivered.
It is important to recognise that all stakeholders are not equal. Some will have more influence than others, some will think they (should) have more influence, some will be able to articulate their need and others will find it hard to see how technology impacts them. Most of all though, stakeholders will not have consistent views or demands:
“Stakeholders often have different views on what is important about a business system and the improvements that are needed. These views are often contradictory and can lead to hidden agenda, conflicts and inconsistent priorities.” Paul and Yeats7, 2006
All customers are stakeholders. All users are stakeholders too. But not all users are customers - some users have not choice but to use the product.
And not all customers will use the product - think of the CFO who agrees a purchase but never uses the product.
For example I am writing to on an Apple Mac computer. This makes me an Apple user and by implication an Apple stakeholder. Since I chose and paid for the Mac I am also an Apple customer. Where I writing this on a Dell laptop supplied by an employer then I would be a Dell user, and stakeholder, but not a Dell customer. In that case someone else, perhaps the head of IT would be the Dell customer (and stakeholder). They may also be a Dell user or they may use another brand of PC.
In many ways it is the stakeholders who are neither customers or users who are the most interesting - although not necessarily the most important. Such stakeholders will be overlooked if analysis only considers customers and/or users. But it is precisely because such stakeholders are unusual that they deserve attention.
Product Owners are primarily concerned with the “what”. They have specialist skills in determining what should be build. Any authority they hold comes from the recognition that they have such skills and are the legitimate person to decide what should be built.
As such almost all their work revolves around deciding what should be built, helping get that built and validating that the thing that was built satisfies the original need they set out to meet.
In this part of the book I’d like to turn my attention to what product owners actually do all day long. In my experience, most people answer this question with a long list of things like “write user stories” and “refine the backlog.” That is but the tip of the iceberg.
Yes product owners write user stories. Yes product owners refine the backlog. Yes product owners prioritise stores, work with the deliver team, set acceptance criteria and an awful lot more. One of the upcoming chapters talks about all that stuff.
But… you have to ask yourself:
- how does the product owner know what to write user stories about?
- how does the product owner know the things that allow them to refine the backlog?
- where does a product owner get the specialise knowledge that allows them to prioritise the backlog?
There is more to the Product Owner role than stories, backlogs and so on. There is an awful lot of iceberg which isn’t seen, work which the product owner needs to do in order to be able to do all those things that usually get talked about.
If you will allow me to change metaphors, I sometimes likened the work of the product owner to that of an actor. Everyone of us can see the work of the actor when thy are on stage. But in order to walk on stage and play their part there is a lot of preparation.
You don’t see the actor waiting in the wings watching for the moment they will come on stage.
You don’t see the actor before the performance, dressing in their costume, putting on makeup and perhaps double checking their lines.
Nor do you see the actor in learning their lines and rehearsing, again and again before the first night. There is so much more to acting in a play than the actual performance in front of the audience. And the same is true for the Product Owner.
When onstage in the team the Product Owner is seen writing user stories, prioritising the backlogs and such. In order to do that work effectively there is much off-stage work: visiting customers, observing or gently questioning the customers, analysing competitor offerings, taking the views of disparate stakeholders, reading market analysis, looking at market growth forecasts and more.
Product Owners needs to engage in all this off-stage work so that their work on stage is valuable and does not misdirect the team.
In the next few chapters I will look at what the Product Owner does on stage and some of the things they should be doing offstage in preparation. I will also look at what Product Owners should not be doing and how the role might be shared.
“Innovation has nothing to do with how many R&D dollars you have. When Apple came up with the Mac, IBM was spending at least 100 times more on R&D. It’s not about money. It’s about the people you have, how you’re led, and how much you get it.” Steve Jobs
The title Product Owner comes from Scrum so it makes sense to do to the source, the latest (2017) Scrum Guide1:
“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable. The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner. For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.” The Scrum Guide, 2017
In addition the Scrum Guide clearly states the Product Owner is a member of the delivery team:
“The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional.”
The Scrum guide is mostly silent on how the Product Owner fills this role and as such the role is open to massive interpretation. While this has the advantage of both keeping the description short and allowing variations as needed it still leaves open the question how the product owner knows what they need to know to do these things.
For example, in order for the Product Owner to optimize the value of the work they need to understand the value of each item. Unless this comes from an external source the the Product Owner needs skills to determine value. They also need to understand cost of delay, the competitive pressures in the market and longer term strategy.
If the PO is simply presented with this information from an external source then they are little more than a backlog administrator and they, indeed the whole team, lack autonomy and the motivation that comes from controlling ones own work.
It is clear therefore that Product Owners need skills above and beyond those described in the Scrum Guide - and taught on most Scrum training courses. If we are to understand both what the Product Owner does and what skills they need then examining related roles will shed some light. The following chapters will do just this.
It annoys me that Scrum Master get so much more attention in the software industry than the Product Owner role. This might be because the Scrum Master role has a more exciting title, it might be because Scrum Master certification has become the gateway qualification for working on an agile team, or it might be because the Product Owner role is so often misunderstood.
Whatever the reason it seems to me that a lot more is written about the Scrum Master role and how to work as a Scrum Master. Less attention is paid to the Product Owner role but to my mind the role is so much more important.
If a Scrum Master performs badly the team simply fail to perform well. If the Product Owner performs badly the whole product is in jeopardy.
Scrum Masters are fond of saying “My aim is to do myself out of a job.” The Scrum Master role is nominally a temporary role, once a team reaches a self-organizing state they don’t need their help anymore.
It is hard to imagine that ever being true of the Product Owner role. Teams which dispense with the Product Owner are quite likely to loose their understanding of business value and loose focus on customers.
The Scrum Master role can be - and often is - adequately filled on a part time basis on a team. A team with a part-time Product Owner may look busy but the value they deliver will be below that they could deliver.
As you read this list of things the Product Owner should be doing as part of the team to keep the agile/scrum process working effectively ask yourself:
What knowledge does the Product Owner need in order to do this effectively?
If I had asked you to write a list of the things you think a Product Owner should do I am sure most readers would have written down “writing user stories” first.
True, most Product Owners will write plenty of User Stories. But…
The thing normally called a “User Story” is more correctly called a product backlog item or simply a story. It is a token for work to be done.
“User Story” is actually a description of the format: “As a … I want … So that …”. Product Owners are free to use what ever format they like - free text, Use Case, Given When Then, IEEE 830 or whatever they find works best. That said, User Story format has two great features.
Firstly it provides Who, What, Why - who wants this thing, what do they want and why do they want it.
Second user stories are simple and easy for the uninitiated to understand. Techniques such as Use Cases are in many ways better at analysing user need and precisely capturing the need. But use cases form a barrier between experts - who are well versed in the technique - and the lay user who does not appreciate the subtleties of the approach.
Whatever format is used one can expect a Product Owner to spend a lot of time creating and working with such work items.
But, there is no reason why a Product Owner should be the only person allowed to write user stories. Indeed other team members can help a busy product owner, and other team members have insights and see opportunities which may well be captured in user stories.
Nor is it just team members who may write stories. Other stakeholders may suggest, or request, stories. In fact, stories can come from just about anyone, including the final customer.
In all likelihood the Product Owner is the backlog administrator. Indeed, too many Product Owner struggling to have the authority and legitimacy to be much more than a backlog administrator.
At its most basic level the Product Owner is the backlog gatekeeper. They get to decide what should be added to the backlog and what should not.
More importantly the Product Owners should get to decide what is taken out of the backlog, that is, what should not be developed into product.
Continuing on from backlog administration - but requiring a little more authority - the Product Owner is the one who gets to decide what priority is attached to backlog items. In particular, it is the Product Owner who decides what will be worked on next.
For Scrum and XP teams this means the Product Owner gets to decide in the planning meetings what items will be be loaded into the sprint for the next iteration. On Kanban teams this means the Product Owner decides what is scheduled next when a slot becomes available.
Many Product Owner will find it useful to keep their backlog in some kind of priority order most of the time. This will simplify their own work - because they know what needs the most attention - and serves as a form of communication with stakeholders.
However, holding rigid priorities, prioritising into the far future (e.g. more than 12 weeks out) and not being prepared to fast-track new valuable work are all behaviours which will cause problems. Such behaviours while appearing to offer certainty and predictability will reduce agility.
It shouldn’t need saying but the Product Owner is there to help the team and as such much of their work will involve working with the team. Again, the Product Owner is the specialist in understanding what is needed therefore they need to communicate their understanding to the team.
This communication isn’t a single event, it is an ongoing series of exchanges. Consider a user story, it is often said that a user story is a placeholder for a conversation. More likely or not that conversation is between a developer and a Product Owner. It is great when a developer can talk to a user/customer directly, potentially the Product Owner need not be part of the conversation, but they may want to be part of it anyway.
Nor is that conversation a single event either. The conversation is an ongoing dialogue which starts with the story and is only finished when the story is done and accepted. (Even then the conversation may continue via another story.)
Some of that conversations will occur during refinement and planning meeting, or in a the “3 Amigos” sessions.
At any point during development a Developer - or a Tester - may have reason to reopen the conversation and ask questions. It is impossible to know in advance every detail that will be involved even on simple changes.
As part of their administration duties Product Owners will regularly review the items in the backlog and change them. This is a process called refinement2. During refinement the words on a story may be tweaked to make it clearer, the story might be dropped or deprioritised, acceptance criteria may be enhanced, the story may be split into multiple stories or one of many other things.
Refinement may occur in an ad hoc fashion or it may be a regular planned event. Indeed the variations are endless.
Product Owners may undertake refinement by themselves or with the team. It may be a regular activity, say, once a week; or an ad hoc activity as they comb through the backlog.
Some teams schedule regular refinement sessions, say one each sprint. At these sessions the whole team, or just a few team members, will review and refine backlog items with the Product Owner. Refinement sessions might be meetings in their own right, or they may be part of a pre-planning meeting.
Some teams go even further than this. These team practice mob-programming.
In mob-programming the whole team - developers, testers and Product Owner - sit together and write the product together. The conversation continues until the end. This is perhaps the ultimate in story refinement because the final refinement is code and working software.
Ideally one would hope that every story that is scheduled is clear, concise, has plenty of acceptance criteria and requires little elaboration. However, there are few perfect stories and arguably crafting the perfect story is a waste of time - if only because not all stories will be scheduled for development.
As I never tire of repeating: a story is a placeholder for a conversation. No matter how imperfect a story is, when it comes to be developed a conversation needs to be had. Some teams formalise this as a “3-Amigos” meeting - alternatively this is sometimes called a “Power of Three.”
3-Amigos occurs immediately before a story is to be developed. The Product Owner, Programmer who will be developing the story and the Tester meet together to discuss the story, agree acceptance criteria and generally refine it there and then.
On teams without a professional Software Tester the Product Owner will inevitably be called on to perform some testing. But even on teams with a professional tester Product Owners should expect to get involved with testing. Ultimately the Tester is a proxy for the Product Owner: does this story reach the standard required? does it do the job it set out to do?
There are limits how much the Product Owner can delegate and how much a Tester can know. A quick visual check at a developers desk can be a very cheap way to get rapid feedback.
As the person responsible for meeting customer needs the Product Owner sometimes need to make the call on whether a story, and a product, is ready or not. (And since the Product Owner is often the originator of the story they are the person who really knows what they were looking for.)
In general Product Owners should not attach effort estimates to work items. Such estimates are the job of those who will do the estimates in future.
However, Product Owners may request others to provide estimates and they may assign statistical estimates to work items. For example, they may ask the team “How long do you think X will take?” or they may calculate that the average duration of a work item is 6 working days and assign that “estimate.”
Of course there are exceptions. One such exception arises when Product Owners assign all estimates and delivery teams are not expected to honour such estimates. For example, one version of capacity planning asks Product Owners to apportion seriously wild-arsed guesses (SWAG) numbers to work items. The “estimates” are not so much time estimates as capacity bids.
The last above is by no means exhaustive, there are more things a Product Owner might need to do. Nor is the list above compulsory, few Product Owners will do all the tasks above. However, for each item above the Product Owner should know either who is doing the task or why the task does not apply in their setting.
“Lies, damned lies, and statistics” Benjamin Disraeli, Prime Minister of Great Britain, 1874-1880
Hopefully as you were reading that last chapter you were asking yourself: how does the Product Owner know what to write on a user story? how does the Product Owner know the right acceptance criteria to specify? and how do they know that story X is more valuable then story Z and should therefore be done first?
Knowing the answers to these questions is the reason Product Owners exist. Product Owners are specialists in knowing what should be built, or rather, what customers value.
Descriptions of Scrum and agile focus on what the Product Owner does in the Scrum/agile process with the team. These sources say little about how the Product Owners find out what they need to know.
When not working directly with the team much of the Product Owners time - time the team cannot see - is spent in research (finding thing out) and analysis (making sense of what they find.) During this time the Product Owner is getting ready to work with the team and ensuring that the work the team will do adds as much value as possible.
Researching and analysis go hand in hand. I’m calling them out as separate activities to make things clearer. Research is finding things out, while analysis is making sense of what you learn. Thinking it through. Turning it over in ones mind. Arguing with oneself. Comparing notes and thinking with peers, triangulating ones own thoughts with those of others. Perhaps using financial models or specific “analysis tools” such as PEST or SWOT. And even, just sleeping on it and seeing if it looks different the next morning.
Some research and analysis will be conducted with the team or team members - and so will be visible. Team members will benefit from visiting and talking with customers, but only the Product Owner can justify doing this routinely. Programmers need to spend most of their time creating programs, observing customers helps inform this process but their focus is on creation. Similarly, Testers will find meeting customers adds value to their testing work but to spend more time with customers than tests is hard to justify.
Product Owners will undertake some analysis by themselves, hunched over a spreadsheet or sketching ideas on paper in pen. But some analysis is best shared with other team members, perhaps replacing the pencil and paper with a whiteboard and dry-wipe pen.
Broadly speaking there are three types of research a PO may undertake: Quantitative, Qualitative and Experimental.
Quantitive research uses, well, quantities, numbers, statistics, things that might be counted. How many customers does the company have? How many of those customers are under 25? How many have bought in the last 12 months?
Quantitive research may involve analysing existing data sets, e.g. sales transactions, or creating a new data set, e.g. running a survey. While numbers have their own authority - “70% of customers over 65 made a repeat purchase in the last 12 months” - they do not tell the full story and as can mislead.
Qualitative research describes the quality rather than the quantity. Qualitative tells a story: “our product sells to older customers, every year some die and some enter institutions where they are unlikely to need our product.”
Quantitive data needs qualitative research to both understand the numbers and to know what questions to ask in the first place. Without a qualitative understanding then quantitive measurements are meaningless. Numbers without meaning is like flying over mountains in an airplane and observing the peaks through cloud. Are they mountains 1000 meters tall? or 2,000? 5000?
Until recently most Business Analyst and Product Management research was qualitative3. There was little data available and it was expensive to conduct experiments. Modern technology has changed this.
Online commerce leaves a data trail the way dogs leave footprints in sand. Quantitive data are the exhaust fumes of modern business. While much of this data is useful and holds insights without a qualitative understanding such data can be highly misleading.
Hopefully I need not explain experimental research, I hope readers remember back to their school science lessons. I certainly learned to write hypothesis “Sodium dropped into water will burn” and then test the hypothesis myself - or at least watch a teacher conduct the experiment.
Until recently it was simply too expensive for most product owners to conduct experiments. Suppose you wanted to find out which shade of blue customers preferred for your product. On a traditional mainframe system you would be lucky to get to try two shades of blue a year.
On a desktop system you might be able to change the shade of blue more often but you still needed to change the shade, recompile the program, perhaps run it through QA, cut it to CD and ship it. And once you have exposed your customers to the different shades you need to (quantitively) find out which they preferred. Then you need a mechanism to get the data back, hopefully one that doesn’t take too long.
As a Google Product Manager Marissa Meyer (later Yahoo CEO) famously tested 50 shades of blue for Google to see which customers preferred. Or perhaps more accurately, which shade lead to the most customer interactions.
Modern technology has made it cheap to conduct experiments. Consequently experimentation has been added to the Product Owners toolkit.
Quantitive, qualitative and experimental approaches to research and analysis are not exclusive. They complement one another rather than compete. Different environments call for different approaches. An online retail may find experimental approaches work well, while an regulated financial service needs to make more use of qualitative techniques.
The promise of experimentation is that it tells you want people actually do, not what they say they will do (as with qualitative). However, experiments need to be conducted carefully and often at a large scale to be valid. Hence a quantitive techniques need to be used to examine the result. A true understanding of the data may only emerge with the additional of qualitative findings.
There is one form of qualitative research that deserves particular attention: meeting customers.
Or users. Or any other stakeholder.
Every Product Owners should be meeting with customers and understanding what they use the product for. There are few, if any, things more important than meeting customers.
It is also one of the simplest and cheapest techniques too implement. What is not to like?
Because a qualitative understanding of customers and users underpins almost all other forms of research it is worth looking at some qualitative practices in more detail4.
In theory, qualitative research is the easiest and cheapest form of research to conduct: a PO only need walk to a place where there are many potential customers or users and start asking questions.
- Walk into the staff canteen, walk up to a random person and ask “Excuse me, do you use the XYZ system?”
- Walk into the high street and stop a random stranger then ask “Excuse me, have you ever used the ABC website?”, or “Do you have the DEF app on your phone?”
So much for theory. Many Product Owners don’t want to talk to strangers. Organizations, particularly the sales department, don’t want POs talking to customers. Senior Executives fear that POs will divulge a state-secret, or promise action the company has not agreed.
And talking to customers can be expensive. Some years ago I was a Product Manager in London. I wanted to speak to a customer in Finland. Getting to Helsinki took half a day, and another day to get back, actually meeting the customer took up another half day and so an overnight stay was unavoidable.
Almost two days of my time for a two hour meeting. But what I learned was gold-dust. It almost lead me to understand that the original vision for my product was not one customers shared.
When I say meet, I don’t just mean meet, introduce yourself and share a coffee. Product Owners should be seeking to understand:
- Who are the customers? What are the different types of customer? What market segment do customers represent?
- What do the customers use the product for?
- What would customers do if the product did not exist?
- How does the product improve the customers life or work?
- How could the product be better?
And probably, right at the bottom of the list:
- What would the customers like the product to do that it does not?
For a planned, formal, customer meeting the Product Owner may well want to create structured interview to ensure they ask the important questions. Such a questionnaire can be used again and again. Although it is likely that at each asking new insights will reveal new avenues to explore and others to discard.
If a meeting cannot be actually arranged then a telephone conversation may suffice. Although such calls loose some contextual information they can still yield valuable insights. Other communication forms - such as e-mail and instant messenger - lack even more context and are not as free flowing as conversation.
While I would accept a telephone call when a physical meeting it not possible I hesitate to suggest written messages. Such messages can have their place but usually only as short, specific, follow up questions or for clarification.
Visiting 10 customers in a week might not be possible but phone call - or other remote working tools may well make it possible to gain a broader understanding. However, some contact should still be physical. Quantity is not always a perfect substitute for quality.
At a very minimum Product Owners should be meeting customers from time to time to validate that experiments, quantitive studies and telephone conversations are not missing important details.
POs should also be on the lookout for informal meetings. User groups and conferences can be provide lots of opportunities to meet with actual customers and ask questions. However such opportunities also present challenges.
You don’t want a customer to feel ambushed and you shouldn’t bank on having a long conversation. Note taking or recording will probably be difficult, although you may make some notes immediately after the meeting.
Informal meetings may be lubricated with alcohol. While this can make such meeting more enjoyable it also presents challenges, especially when trying to ask specific questions or recall what was said.
In general POs should be open to the idea of informal customer meetings at any time, you never know when you will fortuitously bump into a customer but that also means one has to know the right questions to ask and when to respect social boundaries.
Observing customers/users in their own environment is another powerful technique. Customers need not be using your product, indeed if your product is a completely new this may not be possible. Your interest may well be “how are things done without the product.”
Observing a customer presents more challenges than merely asking them a few questions. For starters it probably takes more time. It is also a more intrusive technique, you will at the very least be sitting in their workspace watching them. In some cases you may be sitting in their home overseeing them.
Installing cameras to record customer actions would remove the physical intrusion but may be more suspicions because of the events are recorded. Tools are available that use the customers machine to record the user in action. Such tools can record action, speech and even video. But, by their nature, they are limited to what happens on the machine and in the immediate vicinity.
Whether meeting, interviewing, watching or recording customers one need to be constantly trying to see the world as the customer does.
What is it they want to do?
Why do they want to do it?
What problem(s) do they encounter? - in general, with your product, with other products they must use?
What opportunities exist to make the help the customer undertake their task in some better way, whether that be faster, cheaper, easier or something else.
A Product Owner needs to build empathy with customers and users.
All too frequently Product Owners are so busy adding more stories to the backlog and getting the team to build new stories that they forget to look at what has been delivered and ask: did it meet our expectations? Did it please users?
Those undertaking experimentation know that an inherent part of the experimentation is to look at what happens and decide what to do next. But actually, the same is true of all work whether it is called an experiment or not.
If a new feature gets built for a specific customer request shouldn’t one ask the customer “did the feature do what you needed?”
If advertising is increased to bring in new customers surely one should look at customer numbers and ask “did the adverts work?”
If a set of changes don’t deliver the expected results is it worth doing further planned changes? Or is it with revisiting the changes?
It is vital that new work is evaluated to complete the analysis. Unfortunately this step is too often overlooked.
The above sources are by no means an exhaustive list. There are many more techniques available and each of those mentioned is worth of an entire book by itself. (I am sure entire books have been written about all of the techniques mentioned so far.) Still, it is worth mentioning a few more techniques.
One favourite source of ideas is calls to the support desk. After all, customers who are struggling deserve help and they call or e-mail the support desk everyday with problems which could be solved. However the support desk can be a very misleading place to look for product ideas.
In general requests which come through the support desk tend to be small incremental changes rather than grand leaps. For some products that is fine but for others it is a blind alley.
More problematic is the type of people who contact the support desk. In general callers fail into one of two groups.
The first group are those new to the product, those who lack experience and who may have been “thrown in the deep end” by an employer. Sometimes you may absolutely want to help people overcome their initial problems with the product and the right thing to do is to remove each and every obstacle to early use. But many times that is exactly what you do not want.
The second group who are most likely to contact the support desk are the exact opposite of the first group: the most experienced users. Those who have been using our product for some time and are pushing the boundaries. Consider them the most advanced users.
Again, you might actively want to help this group, you might be trying to make your product the most advanced widget-maker on the market and those people will help you advance the state of the art. But more often than not these people will lead you astray. By definition such advanced users constitute a small part of your user base and satisfying their every need means you will neglect the mass of your users.
For that is the main problem with relying on support desk calls to drive your product: you ignore the mass of customers who do not call the support desk. While you are busy adding features to support new or advanced customers you are detracting from the time and energy used to support far more customers.
If you are developing any kind of product for sale it is most likely your company employs dedicated sales people.
One of the great thing about sales people is that they are very focused on the next customer - for some this can be an obsession. Consequently when a sales person walks in and says:
“You know, customers want it orange. Orange is the colour of today. Everyone wants it orange. Making it orange is the most important thing we can do today.”
What they are actually saying is something like:
“The customer who I have just spoken to wants it orange. They really want it orange. I can sell it if it is orange. If you make it orange I have a sale. (And hence I have my commission.)”
Sale people are great because they are customer champions. But that also means they are blind to almost everything else. The next sale is their top priority. After all, that is why your company loves them and why they get sale commission.
The problem is, as a PO - and in particular if you are a Product Manager - your job is to look the market. Your job is not to consider what one customer wants but to consider what customers in aggregate want. And since resources are limited - and you cannot please all the people all the time - your job is to actively decide what is not being done (so that something else can be done.)
Saying yes is easy. If the company wants you to say yes to every request then you might as well resign today because you lack real authority.
Of course you need to listen to sales people. Of course you need to consider sales. But your job is more than that.
Another common way of coming up with feature ideas is to look at competitor products and copy. Even if you don’t start out with this strategy it is easy to fall into when customers start “feature-shoot-outs” and compare product feature by feature.
As a general rule you want to avoid feature-shoot-outs. If you are constantly trying to keep feature parity with competitors then you are constantly playing catch-up. Worse still, your product will become full of features that are seldom used but complicate the user interface, the code base and confuse users.
By all means look at competitors but look at them so you can differentiate your product from theirs. If your competitor genuinely has a similar product which is better - more features, easier to use, faster, etc. - then find a way to make yours different. Perhaps not through technology but perhaps through target market or price point.
In Crossing the Chasm Geoffrey Moore5 suggest you choose your own competitors. Be ready to say to a customer:
“Yes I know product Q is often seen as a competitor to ours but we have never considered it a competitor. They cater for a different type of customer….”
Then be ready with your reason: “they cater to advanced super user”, “theirs is an entry level product for small scale operations”, “they are a global player with global prices to match” or some other reason.
In academic circles there is a step before any experiment, before any case study interviews or survey: the literature review.
While customer interviews, data analysis and experiments in the market can all yield useful information one should always start from what is already known. There is no point running an experiment to prove that Liverpool FC fans buy more red shirts when it is a well known fact already.
When researching a market and a product there may well be specific market reports available which analyse the market. When launching a customer product there are many review sites which recommend - and forewarn - about existing products.
It can be worth reading the existing literature in a domain. Even if it doesn’t directly feed into your product you will have a better understanding of your customers.
Likewise keeping up with intelligent news and analysis sources can help too. I have lost count of the time I have read something in The Economist which has later come in useful with a client.
While all Product Owners play a key role in deciding what should get built - and communicating that to the delivery team - how they decide and communicate differs massively.
No two Product Owners will work in the same way. The Product Owner role inevitably differs from person to person and place to place. Why would two Product Owners, in different settings, with different teams, different users and customers, work in the same ways?
When not with the team the Product Owner is getting ready to be with the team. That means meeting customers - or users, or stakeholders - and finding out what they need. That information needs to be combined with other information - perhaps market growth reports, or sales figures, or company targets. Some of this will happen on paper, some on whiteboards or with other tools. But it will all happen inside the Product Owners mind.
The first thing every newly appointed Product Owner needs to do is to decide: how they will play the role and most importantly, how they will find out the things they need to know to write stories, prioritise the backlog, work with the team, etc.
Many of the research and analysis tools deployed by Product Owners come straight from existing Business Analysis and Product Management playbooks. Art of Product Ownership volume 2 will look more at the Product Owner role itself and what Product Owners can learn from Business Analysts and Product Managers.
And if I ever get around to writing a Art of Product Ownership volume 3 it is quite likely it will be subtitled: “Tools of the trade.”
> “Life is what happens to us while we are making other plans.” John Lennon
One aspect in particular of the Product Owner role really annoys me: they have so much work to do.
Or rather, a Product Owners who is doing their job properly - as opposed to simply administering the backlog - has so many things they should potentially be doing.
Consider the following responsibilities.
- Backlog administration: writing stories, reviewing and discussing suggested stories, splitting stories, weeding the backlog (throwing stories away), improving stories, putting value on stories, writing acceptance criteria
- Working with the team: talking to the stories, reviewing work in progress, reviewing “completed” work, potentially signing-off or formally accepting stories, participating in 3-Amigos meetings with testers and developers, helping to improve the development processes
- User Experience Design/Interface Design: working even more closely with an UXD specialists because the two roles overlap, and possibly substituting for UXD specialists where they are absent.
- Meetings: prioritisation pre-planning meeting, planning meeting themselves, stand-up meetings, retrospectives, show & tell demonstrations (potentially delivering them the show & tell themselves)
- Interfacing to the wider organization: reporting and listening to internal stakeholders in authority, attending Governance and/or Portfolio review meetings, aligning product strategy and plans with company strategy and plans, plus feeding back to company strategy about their own product strategy and plans.
- Planning: participating in Sprint planning with the team, planning for upcoming iterations (the rolling quarter plan as I like to call it), longer term planning which might take the form of a roadmap, a capacity plan, a scenario plan or all three
- Customers 1: identifying customers and potential customer, segmenting the customer base, creating customer profiles and personas.
- Customers 2: visiting customers, observing customers, talking to customers about stories and potential future work, reflecting on customer comments and feeding back to the team and other stakeholders.
- Customers 3: similar activities to #2 for people and organizations who are not currently customer but who are potential customers (because potential customers who have unmet needs represent growth.)
I’m sure some of you are saying: “But we don’t have external customers, we have internal (captive) users”. And your right, if you have such “customers” then you have a subset of these activities. But then again, shouldn’t you be thinking about how our product is used by internal users to service the needs of external customers? And how you could improve that experience (for the customers) and improve the process (for the users?)
- Marketing: inbound marketing the items just mentioned under customers plus market scanning (checking out the competitors) and potentially outbound marketing (advertising, PR, trade shows, etc.)
- Sharing expert knowledge: providing knowledge about the domain and subject of development to the development team, supporting sales calls, demonstrating the product at shows. (And when the company is small helping the training and support teams.)
- The offering: using the information gained in all these activities to refine the product/service offering to satisfy customers or improve business processes; Is it the right offering? Are you targeting the right customer segment? Should you be offering something else?
- Close the loop: evaluating the effect on customers and/or process: Are the features bing used? Are non-feature improvements making a difference? What shouldn’t have been done? What arises form the changes that have been made? More software changes? Process changes?
- Money: is all this making money? if the continued existence of the team positive to ROI?
This is not to say that all Product Owners should be doing all of these things. Asking one person to take all this on is probably setting them up to fail. Every product owner should recognise every item on this list. If they aren’t doing any of these items themselves then I expect they can either cross it off (doesn’t need doing where they work), or name the person who is doing it.
And I also expect every product owner can add some things to this list which I have overlooked.
Even a quick look at that list of potential actives in the last chapter will tell you the Product Owner is going to be a busy person. Fortunately there are some things that Product Owners can stop doing - something they might be able to stop immediately and some others they should work towards dropping.
It is worth repeating what I said earlier about time: If Product Owners do not have time to do their jobs properly, specifically, if they do not have enough time to visit customers, question and listen to customers, and do not have time to analyse the results of those meetings and reflect those learning in their backlogs and prioritisation then, in time, the work they prioritise will reduce in value. Opinion will substitute for well researched facts, quick knee-jerk prioritisation decisions will be made over well considered choices and over time the work being done will decline in value.
Product Owners Cutting code should NOT be cutting code.
Having a former coder in the Product Owner role can be a great boom. Not only do they know how to talk with the technical team and (hopefully) can command their respect but they can also see how technology can apply.
But to be an effective Product Owner they need to step away from the keyboard and stop writing code.
Product Owners add value by ensuring that the code which is written addresses the most valuable opportunities with the smallest, most elegant, delightful way possible.
Every minute spent coding is a minute not doing that.
Second: Product Owners need to empathise with the customer, with the business users, they need to eat-sleep-and-breath customers.
Being a good coder - let alone someone called an architect - is to empathise with code, the system, the mechanics of how a system works.
Importantly both requirements and code need to be able to come together and discuss what they see and find a way to bring the two - sometimes opposing - views together. It is a lot easier to have that discussion if the two sides are represented by different people.
Asking one person to divide their brain in two and discuss opposing views with themselves is unlikely to bring about the best result and is probably a recipe for confusion and stress.
Thats not to say both sides shouldn’t appreciate the other. I said before, former coders have a great advantage in being a Product Owner. And I want the technical team to meet customers. But I want discussions to be between two (or more) people.
(I might allow an exception here for Minimally Viable Teams but once the team moves beyond the MVT stage the PO should stop coding.)
Product Owners should NOT be line managers.
OK, senior Product Owners should might line manage junior product owners but they certainly should not be line managing anyone else. Most certainly they should not be line managing the technical team.
Product Owner authority comes not from a line on an organization chart, or the ability to award (or deny) a pay rise or bonus. Product Owner authority stems from their specialist knowledge of what customers want from a product and what the organization considers valuable.
If the Product Owner cannot demonstrate their specialist knowledge in this way then either they should learn fast or they should consider if they are in the right role.
Product Owners need to trust the technical team and the technical team need to trust the Product Owner. Authority complicates this relationship because one side is allowed to issue orders when trust is absent and the other side has to obey.
And again, Product Owner simply don’t have the time to line manage anyone.
Being a good line manager requires empathy with employees and time to spend observing and talking to employees, helping them develop themselves, helping them with problems and so on.
Product Owners should not Make Promises for Other People to keep.
Specifically that means they should not issue “Roadmaps” which list features with delivery dates based on effort estimates. The whole issue of estimation is a minefield, very few teams are in a position to estimate accurately and most humans are atrocious at time estimation anyway. So any plans based on effort estimation are a fantasy anyway. But even putting that to one side…
Issuing such plans commits other people to keep promises. That is just unfair.
Product Owners can create and share scenario plans about how the product - and world - might unfold in the future.
Product Owners can co-create and share capacity plans which should how an organization intends (strategically) to allocate resources. And Product Owners can work with teams in executing against those capacity plans in order to deliver functionality the Product Owner thinks should be delivered by a date the Product Owner thinks is necessary.
In other words: provided a Product Owner is making the promise that they intend to keep themselves (i.e. they have skin in the game) then they might issue some kind of forward plan.
Product Owners should dump outbound marketing at the first opportunity.
Outbound marketing, e.g. advertising, press releases, public relations and product evangelism, often ends up on the Product Owner plate - particularly when the Product Owner is a Product Manager. And in a small company (think early stage start-up) this just needs to be accepted.
However, in a larger organization, or a growing start-up, Product Owners should seek to pass this work to a dedicated Product Marketing specialist as soon as possible. Both roles deserve enough time to do the job properly.
The Marketing Specialist and Product Owner will work closely together - they are after all two sides of the same coin, the Marketing coin. The Marketing Specialist handles outbound marketing (telling people about the product) and the Product Owner handles inbound marketing (what do people want from the product?). (Again, in organizations with established Product Management this is usually easier to see.)
Product Owners should dump pre-sales at the first opportunity.
As with outbound marketing Product Owners often get dragged in as pre-sales support to account managers. And again this is more common in small companies and early stage start-ups.
There are some advantages to playing second fiddle to a sales person. The Product Owner will get actual customer contact (sales people too often block Product people from meeting customers.) And Product Owners should be exposed to some of the commercial pressures that sales people - and customers - encounter.
But doing pre-sales is very time consuming. And being wheeled in to help deliver a sales will distort the Product Owner’s view of the market - just ‘cos this customer wants the product in Orange doesn’t mean other customers want Orange.
Once infant of a customer the Product Owner will come under pressure to commit to particular requests and make promises against dates. These pressures arise both from the customer and sales person but also from themselves because they want to please people. Unfortunately once a customer (or sales person’s) expectations have been set it is hard to backtrack even if other work is more valuable.
And again, pre-sales is more effectively done by specialist staff as soon as the company can afford them.
Product Owners are often tempted to add more detail to their stories. In fact, they are often asked by Programmers and Testers to provide more detail. However, this is a trap best avoided. Rather than more writing Product Owners should provide more conversation.
An old agile maxim says:
“Write slightly less than you think is needed.”
If a PO writes less than is needed then someone can ask a question and a conversation can follow. The written word seldom adds as much as a conversation because writing is one way, from the writer to the reader. And the message is decided not by the writer but by the reader.
In contrast, a conversation allows both parties to ask questions and iterate until a shared understanding is reached.
The pressures to write more can be intense: outsourced delivery teams, remote teams, regulators, audit trails and governance all add to the pressure. But remember: writing is very expensive for both the writer and the reader. Well actually, it is only expensive for the reader if there is a reader, if nobody ever reads the written words then it is complete waste.
In many ways, in the ideal world, the Product Owner would not exist. The team would contain a mix of business and customer facing skills together with technology knowledge and would work together to product the right thing.
Indeed this model sometimes exists in teams of one - which really isn’t a team. From time to time individuals both posses the skills to create a software product and because of their domain expertise, or simply being in the right place at the right time, can create a great product. But this model is difficult to scale.
So we introduce a Product Owner. Having a designated, and skilled, Product Owner can be a great step forward for many teams. In many cases where a team has to decide between many requests from different customers having someone in the middle can be a major step forward.
…. diagram of middle man …
A team can get a lot of mile from this Product Owner - especially when, as described in other chapters here, the Product Owner is supported by the team and other specialists. However as a team grows, and as more products are added to a portfolio this model too has scaling problems.
One solution is to split the role in two with one Product Owner taking a Strategic view and another a Tactical view.
The Product Owner lacks the time - and sometimes skill - to fill the role fully therefore split the role in two.
One person, the SPO (Strategic Product Owner), looks long term, they focus on customers and strategy.
The other, the TPO (Tactical Product Owner), focuses on the near term (this sprint, the next sprint, the next quarter). The TPO spends most of their time with the delivery team while the SPO spends most of their time with customers and senior stakeholders.
Sometimes the Product Owner lacks time simply because there is so much work the Product Owner should be doing they simply don’t have time.
Sometimes they lack time because the team is large, or the team lack domain knowledge (and therefore need to ask the PO lots of questions). Sometimes POs need to travel a lot to meet customers and even the most talented PO can’t be in two places at once.
… table of contracts …
The key thing about the SPO/TPO model is that the two people who hold the role need to speak with one voice. If they do not then the model will fail. Ideally the SPO will stand in when the TPO is unavailable and vice verse.
They may also lack time because they have another job to do. While I think the Product Owner role is a full time job sometimes the person who is the right person to hold the role - usually because they command authority - needs to combine the work with another role.
For example, on a trading desk the Product Owner should probably be a senior trader who both knows the domain and has the authority to say Yes and No to features. But by definition such a person lacks time. Normally I’d want a dedicated Product Owner in place but sometimes the only way to have the necessary authority is to have another job.
And sometimes the person who is should be Product Owner - think our trader again - lacks the skills and experience to do the role. So again they need help.
There is another occasion when the SPO/TPO model can be useful: big teams.
Ideally there is one product owner, one team and one stream of work. But sometimes there are several products, teams and streams. Here you might have an SPO who looks at the long term and several TPOs each of whom works with one team on one stream.
Now, like all good patterns this one is not without its downsides…
I’ve heard Scrum-advocates argue against this model: One True Product Owner they say. And they have a point… putting more people between the delivery team and the customer does detract from communication.
One of the problems software development faces is when multiple people think they have the right to say what is built next. Another problem occurs when the customer is remote from the development team and multiple people mediate what is asked for.
Ideally developers can talk to customers directly but that is often not possible or desirable - I won’t go into the reasons right now. So a good solution is One True Product Owner.
But then the One True Product Owner becomes a bottleneck so we split the role SPO/TPO. Yet every-time we introduce another link - another person - between the coders and the customer the greater the propensity to introduce problems. So it becomes a balancing act.
At the start of this chapter I wrote: “Having a designated, and skilled, Product Owner can be a great step forward for many teams.”
Then I explained how having two Product Owners - an SPO and a TPO - can be even better! So the natural questions is: could three product owners be even better? or four? or five?
Maybe, but probably not.
When there is one person there is no communication problem because everything is in one persons head. This is great but creates other problems (adding more staff, individual time to do the work, alternatives views, etc.).
So we introduce a Product Owner which solves some of other problems but introduces communication overheads and the risk of miscommunication. Sometimes adding a second person can help with bigger teams and time pressures but it also introduces magnifies communication problems and increase the risk of absent or mis-communication.
Going from none to one is a trade-off which often - but not always - makes sense. Going from one to two frequently makes sense but not always. Going from two to three… maybe, I’d need convincing.
Every time another person is placed in the chain between customer(s) and programmer communication is impeded, slowed, facts can be lost or misunderstandings and false beliefs added. Anyone who has ever played the party game “Chinese whispers” should recognise the situation.
Indeed, in the pre-agile days it was not uncommon to find long chains fo business analysts talking to business analysts talking to business analysts. Actually it is worse than this because many of the “conversations” are actually paper hand-offs. This still exists in some companies, especially those engaged in offshore outsourcing.
… diagram …
So it comes down to a balance. When do the the forces pushing towards having another intermediary outweigh those pushing to keep the chain short?
When does adding another person to the chain improve matter more than the cost of adding another person?
For me the default answer is: there should be one Product Owner.
In the right circumstances I can see a good case for having two: one Strategic and one Tactical, and perhaps multiple tactical Product Owners if the structure is right.
But having three people in the chain… I’m not saying never but I do need convincing.
Four people in the chain… I’m find it hard to imagine ever being convinced here.
If there really are so many people who need to have a say perhaps the answer is not a chain but a committee. Perhaps all these people are really just stake holders. Perhaps what is needed here is one Product Owner with the legitimacy to take ideas and requests of multiple stakeholder and decide what is the right thing.
I find lots of companies who have a version of this model in place, they have created the model to deal with their own situation. But few of these companies realise that this is a reoccurring solution and is quite legitimate. (I should write it up as a Pattern but I haven’t written any patterns for a while.)
More importantly I find that many companies and individuals faced with problems around Product Owners benefit from adopting this model. Specifically, as I’ve already mentioned there is a lot of work for a Product Owner to do and one way of doing this is to share the load.
“Alone we can do so little; together we can do so much.” Helen Keller
I explained that there was an awful lot of work for a Product Owner to do, then I suggested some things a Product Owner should NOT be doing, next I suggested how the role can be refactored to reduce the workload. Now I’d like to suggest some more ways a Product Owner can reduce their workload.
More importantly what follow is not just advice for reducing the workload this advice can help product owners do a better job by involving more people, getting more views and more expertise involved.
In the old days it was not uncommon to see a “us” and “them” relationship between the those charged with understanding business and customer (“us”) and those tasked with building the product (“them.”).
This was made worse when there were multiple people in each role, for example, a team of Business Analysts working together to product requirements for a team of developers. It is also made worse when these teams - or just individuals in roles work in physically different places (and maybe never meet) or work for different organizations, say the Client and the Supplier.
One way “Us and Them” manifested itself was a battle of the documentation.
Needless to say in the perfect world of Agile this never happens: teams are co-located, friendly, work to the same goal and don’t write anything down.
Well, yes, it does happen in some places.
But simply waving the Agile-wand doesn’t make it so. There are plenty of teams out there who are nominally Agile but where the “Us and Them” business v. technical divide still exists.
Unfortunately this makes more work or the business/requirements people - energy to maintain the divide, the extra formality, documentation and arguments required.
Product Owners should see the technical delivery team not as their enemy but as their partner - there should after all be one team. The delivery team are clever people who know technology, may well have built similar things before and may have some understanding of the business domain.
Even if they don’t they are another pair of eyes (usually many pairs of eyes).
When Product Owner trust the members of the delivery team they reduce their own workload and that of the team. They need to give them last detail less their requests (they trust the team to ask questions), the practice less management (they ask for less reports and listen to fewer), they agonise, question and gossip about the team less.
Product Owners need to enrol the team, take them to meet customers, have them talk to stakeholders, hold joint backlog weeding sessions, have them review stories and comment on them, delegate work to team members.
Unless delivery members are involved in discussions and conversations with customer then they are unlikely to ever properly understand “the business.”
Following directly from that last point, as Product Owners find more and more of their time devoted reviewing work and testing the greater the value in adding a specialist tester to help. Of course the Product Owner must be prepared to delegate authority to the specialist tester to accept work. If they are not prepared to delegate that authority then they need to keep testing themselves.
This also elevates the Professional Testers role: they are less concerned with “pressing return 50 times to see if it crashes” and more concerned with “ensuring it delivers benefit to the users/customers.”
In many ways Professional Testers start to look more like Product Owners: they too try to understand what the customer is trying to achieve and are tasked with ensuring the customers world really is a better place with the new tools; and whether product enhancements deliver the expected benefits. When enhancements don’t deliver the expected benefits it is time to ask: what else can be done? how can that value be unlocked? or perhaps, was the expectation misplaced? - there is no point in doing more work to unlock an expected benefit when the benefit doesn’t exists or is far smaller than anticipated.
In some cases a Professional Tester may well be the first to see new opportunities which arise. Naturally they should feedback such insights to the Product Owner. One can expect the roles of Product Owner and Professional Tester to increasingly overlap.
In many, probably most, teams little or no attention is paid to the user interface design. The programmers “throw” together something. Some programmers are good at this and sometimes - frankly - a crude programmer designed interface is good enough.
In many environments the interface design skills of programmers will be quite adequate. That is not to say the result will be impressive let alone intuitive, rather it is to recognise that in many places impressive and intuitive interfaces are simply not required or justified.
Consider an internal application for managing supplier invoices. Such system may only be used by a handful of people for a dozen invoices a week. It might be painful for an accountant to use, and their might be benefits to creating an Apple quality interface but, would system an enhancement add value? Would it add enough value to justify the cost of the work? Or would the same effort be better directed to work with greater benefit?
But sometimes quality user interfaces are entirely justified. Indeed too many companies settle for a “good enough” programmer designed interface when well considered professionally designed experience would unlock significant value. This is particularly true of products which will be marketed and sold to external customers.
When the needs for user interface and interaction move beyond the skills the programming team it usually lands on the Product Owners desk. (And this happens a lot sooner when the Product Owner doesn’t trust the delivery team.)
So many Product Owners end up, for better or worse, “designing” (or simply mandating) the look and feel of the Product. While some are good at this - they have an eye for design and might have done this before - most of them are little better than the programmers who throw things together.
Unfortunately when Product Owners are also interface designers discussions about user interface can obscure the problem or opportunity the Product Owner is trying to address. Rather than talking about what the user is trying to achieve discussion centres on how the user will accomplish the task. Such debates - particularly when conducted in writing - can get acrimonious and time consuming.
Sometimes the User Interface, the Interaction Experience, the Design, the Look and Feel, the… whatever you call it… makes A VERY BIG DIFFERENCE.
Sometimes it is the way a product works which is the thing that differentiates the product and makes it a winner. Consider Apple.
Exhibit A: Apple Inc. [[link]] picture.
At the time of writing Apple is the worlds most valuable company. One of the major reasons for Apple success is their respect for the user and their efforts to product systems and interfaces which not only look good but are (relatively) easier to use than their competitors.
Apple does not get it right every time - this writer constantly find iTunes frustrating to use. And Apple does not always get it right first time or produce killer products every time (consider Apple TV). But Apple does engage in significant customer research and user observation - frequently hidden from view.
While few companies have the financial resources to devote to design that Apple do, in my experience, almost every company would benefit in spending more money on user experience design even if it means reducing expenditure on programming.
Obviously, when the interface makes a big difference, or when the Product Owner is spending a lot of time on interface design - or when the Product Owner lacks the skills to take on the work then it is time to add an UXD specialist.
And there is another lesson from UXD…
In many ways a UXD specialist is one of “Us” - they will have insights into customers needs, they will work closely with the Product Owner in deciding what needs to be done and how to satisfy the need. But a UXD specialist is also one of “Them” - they are part of the delivery process, they are technical specialist, they are there to be instructed in what to do next.
Even more than the Professional Tester the UXD role highlights the absurdity of Product Owners seeing a “Us and Them” relationship with those creating the product. The very difficulty in pigeon-holing UXD demonstrates why pigeon-holing is a stupid idea.
(When I say UXD I mean User Experience Design but these comments apply equally if you prefer the term UX, Interface Design and other variations on this term. When I mean is: the activity of, and professionals who, consider how user work with the system. Both analysis of the way people work with the machine/system and the synthesis of products to improve interaction. I am taking a liberty by using these terms almost interchangeably here.)
As always, there is a lot of work the Product Owner could, even should, be doing. Frequently when there is no specialist available the Product Owner becomes the default dogsbody to pick up the work nobody else wants to do - or lacks the time to do.
Sometimes this is necessary, in a start-up company to minimally viable team. But this is self inflicted. Product Owners who don’t trust their team members may feel they need to take on responsibilities - like UXD - themselves.
With success and additional resources Product Owners should seek to offload some of their work to specialists. Not only will these specialists free up the Product Owner time but they will do a better job than a time pressed Product Owner who has never worked as a user experienced designer or software tester.
When additional resources are available the tyranny of the backlog can lead Product Owners - and the organization as a whole - to prioritise more coders rather than specialists. Yet frequently the right specialists can add more value than another programmer. This is especially true in the case of user experience/interface design. Just ask Apple.
Allan inspires digital teams to effectively deliver better products through Agile technologies. These approaches shorten lead times, improve predictability, increase value, improve quality and reduce risk. He believes that improving development requires broad view of interconnected activities. Most of his work is with innovative teams, smaller companies - including scale-ups; he specialises in product development and engineering. He uses a mix of experiential training and ongoing consulting. When he is not with clients he writes far too much.
He is the originator of Retrospective Dialogue Sheets, the author of several books including: “Xanpan - team centric Agile Software Development” and “Business Patterns for Software Developers”, and a regular conference speaker.
When he is not writing books Allan:
- Delivers Agile training courses to teams.
- Provides coaching and advice on agile, software development and digital strategy to teams and executives.
- Speaks at public conferences and internal company events.
Currently only available on LeanPub as eBook https://leanpub.com/cdigital/
Available from your local Amazon
Ebook and print version available on Amazon
Published by John Wiley & Sons
Available in all good bookshops and at Amazon
Available in all good bookshops and at Amazon
Knowledge sharing and analysis with patterns in Business Analysis and Leadership, Pullan and Archer, 2013, Kogan Page
Check your code first before looking to blame others and Two wrongs can make a right (and are difficult to fix) in 97 Things Every Programmer Should Know, Henney, 2010, O’Reilly
Encapsulated Context pattern in Pattern Languages of Program Design volume 5, Manolescu, Voelter & Noble, 2006, Addison Wesley
Blank, Steve: 2013, The Four Steps to the Epiphany
Cagan, Marty, 2008, Inspired: How To Create Products Customers Love SVPG Press.
Cagan, Marty. Inspired: How To Create Products Customers Love (Kindle Location 3). SVPG Press. Kindle Edition. Christensen, Clayton M. 1997. The Innovator’s Dilemma: Harvard Business School Press.
Christensen, Clayton M. and Michael E. Ray-nor. 2003. The Innovator’s Solution: Harvard Business School Press.
Christensen, Clayton M., Taddy Hall, Karen Dillon, David S. Duncan, 2016, Competing against Luck: Harvard Business School Press.
Cooper, A. 2004. The Inmates Are Running the Asylum: Que.
Hohmann, Luke. 2003. Beyond software architecture: creating and sustaining winning solutions. Boston: Addison-Wesley.
Kelly, A. 2007. More patterns for Technology Companies In EuroPLoP, eds. L. Hvatum and T. Sch端mmer. Irsee, Germany: UVK Universitassverlag Konstanz GmbH.
Kelly, A. 2008. Business Strategy Patterns for Product Development In EuroPLoP (European conference on Pattern Languages of Program design). Iresee, Germany.
Kelly, Allan, 2008 *Business Patterns for Software Developers: John Wiley & Sons.
Moore, G.A. 1999. Crossing the Chasm. Capstone publishing.
Moore, G.A. 2005. Inside the Tornado: Collins.
Paul, Debra and Donald Yates. 2006. Business Analysis. Swindon: British Computer Society.
Ries, Eric, 2011, The Lean Start-up: Crown Publishing
Stull, Craig, Phil Myers and David Meerman Scott. 2008. Tuned in : uncover the extraordinary opportunities that lead to business breakthroughs. Hoboken, N.J.: J. Wiley & Sons.
December 2019: Lots of edits and a few additions
November 2018: Split into volume 1 and volume 2
October 2018: Lots of edits and additions - no publication update
June 2018 (second): Added Changes to Product Management chapter
June 2018 (first): - Major refactoring to early chapters - Added chapters on Product Manager - Made space for Business Analysts chapters
May 2018: First release - prologue and boilerplate
Meet the Product Owner
1The Economics of Software Quality, Jones, C., Bonsignour, B. and Subramanyam, J., 2011↩
2Brooks, F. 1975. The Mythical Man Month: Essays on Software Engineering. Addison-Wesley.↩
3Jones, Capers. Applied Software Measurement: Global Analysis of Productivity and Quality, 2008, McGraw-Hill Education.↩
4Jeff Patton, “Dual Track Development is not Duel Track”, https://jpattonassociates.com/dual-track-development/ [^Cagan]:Marty Cagan, Dual-Track Agile, https://svpg.com/dual-track-agile/↩
5The XP Customer Role in Practice: Three Studies, Angela Martin, Robert Biddle and James Noble, Agile Development Conference, 2004, Salt Lake City.↩
6Discovering Requirements, Ian Alexander and Ljerka Beus-Dukic, 2009.↩
7Business Analysis, Debra Paul and Donald Yeates, 2006↩
What do product owners do?
1Schwaber & Sutherland, https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf↩
2In some circles this exercise has been called grooming. However, in England, this term has taken on negative connotations with the general public in recent years and is better avoided.↩
3I’ll give them the benefit of the doubt and assume that none of them ever devised business cases based on technology solutions or pure desk based dreaming.↩
4I also fear that with the current popularity of experimental research techniques some Product Owners are negating first hand customer contact.↩
5Crossing the Chasm, Geoffrey A. Moore, 1991.↩