“Well, you know what they say… when you want something done right, you have do to it your bloody self.”
My dad used to say this all the time. In fact he still does. How often have you heard it said?
A key turning point for a new manager is, I think, the realisation that this is quite often not true. (Certainly less often than you probably suspect).
The product owner is possibly the most misunderstood, or at least the the least understood, role in agile software projects. Just about everyone you talk to, whether a current practitioner of the role or just someone who works in agile projects, will give you a slightly (or greatly) different description of the role, its scope and its value.
A colleague recently asked me to write down for him a brief description of everything I thought a Product Owner should be, in terms of role and responsibility as well as personality and competencies. As I started considering what this would be, a few things occurred to me:
I’ve now set out to produce a series of posts which will form my personal description of “the complete product owner”. I’ve chosen the word “owner” intentionally to relate specifically to the field of agile product management (as opposed to, let’s say, “traditional, waterfall” methodologies. More on product owners vs managers soon.) The word “complete” refers to the intention to provide a complete, end-to-end view of the scope and responsibilities of this role.
It is also important to mention at this point that what follows will be most relevant to the traditional home of agile methodologies: in software development. It is interesting to observe how agile techniques are being adopted by industries as diverse as medical research or construction, however the experiences, analogies and resources in this series will be exclusively focussed towards software product management.
The traditional industry title for those in the business of managing the product development life-cycle is the “Product Manager”. Agile methodologies, specifically Scrum, introduced the term “Product Owner” to refer to the member of the scrum team (ie, the product team) who is predominantly responsible for the product itself (predominantly, as in agile teams we strive to embed a feeling of product responsibility in everyone, throughout all levels of the product organisation).
Some people misinterpret the difference as a reflection of the scope of the role, assuming that the “Product Management” discipline is broader or more “senior” than an owner. I take a very different view, and argue that there is no difference. It could be perhaps said that within the Product Management discipline, a Product Owner is one who practices within an agile context; however there is certainly not, in my view, an assumption that the scope and responsibilities of a Product Owner are necessarily any different to that of a Product Manager.
In my writings I use the two terms interchangeably; however it is useful to remember that in certain circles the title “Product Manager” is often understood differently from an “Owner”. Specifically in non-software product industries (fast-moving consumer goods, among others) the term “owner” is less relevant.
In his famous 1955 work “Designing for People”, Henry Dreyfuss, considered my many as the father of modern industrial design, said the following about the role of the industrial designer:
“The successful performer in this new field is a man of many hats. He does more than merely design things. He is a businessman as well as a person who makes drawings and models. He is a keen observer of public taste and he has painstakingly cultivated his own taste. He has an understanding of merchandising, how things are made, packed, distributed, and displayed. He accepts the responsibility of his position as liaison linking management, engineering, and the consumer and co-operates with all three.”
Although he was talking specifically about the industrial design discipline, I think he has equally perfectly described the role of the modern product manager. (You’ll forgive his gender bias, but it was the 50’s after all). The complete product manager is a jack of all trades. It’s someone who can keep the big picture in mind while obsessing over the smallest details. It’s someone who can, on the same day, discuss or consider engineering process, marketing strategy or interface design – all in terms of how it relates to the core consumer value proposition.
A complete product owner:
The next time you meet a product manager, as an experiment, as them how they became a product manager. If you are a product manager, think about how you became one. If they attended university, ask them what they studied. The answers may surprise you.
Nobody will tell you that they studied “Product Management” at university. Some will have studied Computer Science, others design, still others psychology, business or even philosophy. Nearly nobody will tell you that they “always wanted to be a product manager”. Many of the product owners that I know say they kind of “fell into” the role. I sort of did, too.
Steven Haines calls it the “accidental profession”. The interesting mix of backgrounds and motivations does result in a healthy range of experience and perspectives in the product management world, but it has, I think, the side-effect of producing a problematic diversity in product management approaches and levels of training.
The Complete Product Owner series is broken into four acts. Each act is centered around a main theme: The Product, the Business, the Team, and you.
Some topics don’t fit neatly into a single act. In fact, most don’t. You can’t discuss product strategy without discussing design; you can’t think about market segmentation without thinking about the competitive landscape; and so on.
Within this series, I won’t be able to teach you everything you need to know. I can’t teach you how to do brand marketing or search engine optimisation, for example. The purpose of this series is to discuss the scope of areas, skills and knowledge a Product Owner should understand, what they are and why they’re important; and then potentially provide some links to resources for those who want to know more.
Much of the books or literature on product management tends to start with the process and definitions, and leave the actual product to the end, almost as an afterthought. To me, everything starts and ends with the product itself – so we start with the product here. We’ll look at defining what the product is, what it does and who it’s for.
The next aspect is the one that I see most often neglected by new and experienced product managers alike. The business is, if not the core element of a product team, the surrounding ecosystem that enables and supports the product development. Smaller teams and startups are intimately familiar with the importance of such business tasks as raising capital funding or developing a competitive business model, but these can go unseen or be neglected in larger teams.
This is where most product owners, particularly those new to the profession, spend a disproportionate part their time. The team is where things get done, or “where the rubber hits the road”. Having a functional, efficient and self-organising team is a critical focus for teams. For Product Owners, it’s critical to understand how the team supports you and how you support the team to ensure the greatest success.
Once you know what you need to do: the tasks, the responsibilities, the focus areas; how you actually do it is up to you. We’ll look at a number of key skills and competencies that you should focus on developing to be a complete product owner.
So let’s get started. In the first post in the series, we’ll look at defining the product: what it is, who it’s for, and why the heck you’re building it anyway.
I would love for this to be as interactive as possible. If you have questions or comments; if you agree or disagree with what we discuss here, please let me know in the comments.
In the 1970’s renowned German designer Dieter Rams defined ten design principles that embodied his view of design and product development.
He said:
Timeless.
(The translation is mine from the original German, but I’m sure there are countless others, including on wikipedia.)
Original German version:
You can download the image above as a desktop wallpaper in English or the orignal German.
Stop signs are always red. Exit signs are green. Play buttons are triangles. These are patterns and norms that, when appropriately leveraged in a design, can help communicate expectations and function. It doesn’t matter if you are an interface designer working on a software UI, a software engineer writing code or a manger preparing a powerpoint presentation: consistency is important.
What consistency is not, however, is copy + paste. As a great designer on the maps.nokia.com team said in a design review recently: “Consistency is not a rubber stamp.” It’s not a cookie cutter. It is a careful and thoughtful association between what you are doing and the user’s current knowledge. In other words, the question to ask is: “will this design allow my user understand what they need to do or what I am trying to communicate to them, given their experience, knowledge and understanding?” Two elements of a system can be consistent with each other without being the same.
Consistency for consistency’s sake (or, on other words, forcing total consistency at the expense of function) is a design crime of an similar magnitude.
Rather than asking the question: “is this consistent?” – ask the question: “will my user/reader/audience/etc easily understand, given their context and knowledge?”
As Emerson famously pointed out:
“A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do.”
