“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.”
What’s the difference between a cheetah and a gazelle?
One is the hunter; the other, the hunted. One stalks and sprints with total precision, unwavering focus and ultimate confidence. The other flees in uncontrolled panic.
When we’re exposed to pressure within an organisation, it is normally in the form of a risk or a threat: the risk of losing a big client; the chance we won’t get funding; the fear of losing our jobs.
The fact is that all mammals, including humans, are really good at panicking. In fact, we’re designed for it. Buried deep inside the oldest part of our brain is a brain region called the limbic system. In evolutionary terms, the limbic system existed long before we first picked up a rock and used it to hit something. It’s the part of our brain responsible for basic survival; it’s the part that takes over when we’re scared, angry, lusting for revenge or when we’re threatened.
When we feel threatened, our limbic brain sends some signals to a part of our central nervous system called the sympathetic nervous system, which activates the so-called “fight or flight response”. Our conscious brain (the cerebrum) more or less shuts down and the limbic brain takes the wheel. It will decide whether we flee or whether we fight.
This is the response that leads us to panic. But when we panic, we lose focus. All our effort goes into outrunning the cheetah… but a gazelle can’t eat, drink or make baby gazelles when it’s fleeing a chasing cheetah.
If we spend all our time running, we don’t focus on the important things. We might increase speed but we end up losing velocity.
We all have many reasons to panic… The market is moving quicker than ever. Markets and industries change and heave, companies rise to incredible heights or crash to the floor in a fraction of the time of 20 or even 10 years ago. We have to move with urgency if we want to keep up… but urgency isn’t panic.
Urgency is controlled. Urgency is precision, focus and confidence.
The Valley’s preeminent conference for Location-based services, Where (formerly Where 2.0), was on again at the start of April in San Francisco. The usual suspects were in attendance, with the likes of Google, ESRI, MapQuest and Foursquare holding prominent positions on the exhibition floor and presenting several keynotes. I was there of course with Nokia Location & Commerce, representing our Where Platform and location applications portfolio and our flagship product Nokia Maps.
Many of the themes of the presentations were covering similar material, I noticed a few main themes coming out of the presentations in general.
A common discussion was around the alternatives to the Google Maps API as a location platform for online and mobile applications. There has been lots of talk recently about Google’s decision to charge services for extensive usage of the location API, and many organisations are searching for an alternative. Open Street Maps, although not present at the conference themselves, were talked of often as “the” alternative to Google Maps. Although many other paid and free alternatives exist, including Nokia’s Nokia Maps API, OSM seemed to be by far the most talked about.
A trend is emerging around creating custom maps. Products like Mapbox are providing products that let you literally build your own map. Using Open Street Maps data, Mapbox lets you design/customise everything about the map design: labels, colours, catographic elements, zoom levels and everything else. They then not only provide the completed map, but even make it into tiles and host them.
The takeaway is that there is a trend emerging whereby people and organisations are placing much more value on the map design itself in terms of building or customising a product or service. Even as we see visual developments in the map design and style of the major map platform providers (like the recent visual updates on the Nokia Maps map style), we’ll see in the future countless different map styles and designs; customised both for differentiated visual appeal and also for the product or service’s specific use case.
After the very first Google Maps “mash-up” emerged location-based services focused heavily on placing data on a map. Whatever data you had, if it had a location, you could suddenly turn it into a layer on a map. Most experiences visualised all the location data as “pins” on the map layer. Other visual techniques emerged such as heatmaps or clusters, but essentially it was just like it’s real-world equivalent: a collection of pins on a map.
What is becoming clear now is that just a layer of data on a map is neither new nor innovative. Innovative location services will not just focus on collecting location-based objects, but will focus on utilising location as an object attribute to create smart and meaningful connections between these objects, and to use them to create compelling experiences. Further, when it comes to mobile, it is no longer enough to use the user’s current position to put the user in the middle of that layer of data that you’ve put on the map. Experiences need to use the current position to further contextualise a hyper-relevant experience based on the user’s location, friends, history and profile.
Serendipity has been the perennial favourite buzzword in the valley since the start of the Foursquare/checkin era. This year the talk was around how to use the wealth of location-aware activity data streams available via services such as Foursquare or Facebook Places to create meaningful online or mobile experiences that enhance real-world experiences. One such service, Meet Gatsby, is using Foursquare checkins to introduce people to each other who are nearby each other and share common connections or interests.
Everyone seemed vaguely aware of the obvious paradox in “engineering” serendipity: the deliberate, conscious attempt to spark or even force spontaneous events…
Everyone wants to feel like they’re a “true local”. That’s a promise we’ve been trying to fulfill with Nokia Maps for over three years. Now, the trend has hit the mainstream more than ever with tons of startups focussing on building experiences that combine user’s local knowledge with their location, profile and social graph to provide local place recommendations, directions and stories.
These services will build on the successes of products like foodspotting and Yelp to harness the power of the crowd to collect stories, photos and moments that allow people to see the world around them through the eyes of the locals. Review services like Qype, Yelp and so on have of course been around for ages… new services will combine reviews and photos with social connections and user profiles to provide better recommendations of places and things to do. We also see other services coming up that don’t focus specifically on place discovery: services like Lumatic, which focuses on providing contextual, natural pedestrian directions using photos, landmarks and stories as the essential wayfinding descriptions.
As mentioned above, the success of these products will be based on much more than building a huge database of content: content itself will not be enough. Successful services will augment various content types with social, location and activity information to provide more meaningful, immersive and contextual experiences.
As the available public and private datasets become ever-larger, crunching the data to find the meaning and connections is key. As such, a big focus has been on dealing with large datasets. Specifically, Hadoop and Pig were talked about a lot.
Factories must be awfully dull places. Factory workers working on a production line follow a strict process. Work is divided out into narrow and highly controlled portions. The guy working at machine #1 is an expert at machine #1, but not at machine #2 or #3. But that’s ok; if he stays focussed on his machine, the production line moves on and many widgets will roll off the end.
Factory workers take a given process or specification and assemble it. That the solution is provided is a given. There’s no room for initiative or individual innovation on the factory floor. If one machine doesn’t produce output of exactly the right type at exactly the right time, the system breaks down. Process improvement and innovation is for senior managers; observing the factory floor below from an air-conditioned room behind a wall
of glass.
In the early 1800s the factory revolutionised the production of goods and heralded the onset of the industrial era. It raised millions of people from poverty and created countless jobs (and millionaires). It brought about a new kind of competition: one fought along the bottom line. The problem with the factory is that the race to the bottom is over: we hit it long ago. When every factory can produce widgets as cheaply as you can (or cheaper), your ability to differentiate lies elsewhere – it’s not enough just to be able to sell widgets cheaper than anyone else.
Luckily in the software product business we’re not factory workers. We encourage individual initative. We challenge our teams to help us improve our processes. We believe that innovation can (and should) come from anywhere.
Right?
If that’s true, why do we keep treating our teams like factories, and our people like factory workers? Why do companies push solutions to teams and expect them to be just assembled, (where possible by yesterday), without asking too many questions or making a fuss? Why do organisations rebuff any innovation or ideas that don’t come from their own team? Why do we incentivise teams and individuals on the quantity of output, and not the quality or impact?
It’s not enough to talk about supporting innovation and encouraging initiative… our daily working process has to support it too; otherwise, we’re just another factory.
The creatures, great and small, that exist today exist because they, and countless generations before them, each underwent tiny, microscopic changes that made each generation just a little better, stronger and more durable than the last. Each generation was a measured experiment, and every change was measured against the context of its environment. Those that worked were carried through to the following generations. Those that weren’t died out.
The more generations you have, the more opportunities you have to experiment, change and measure.
A horsefly or a flying fox cannot easily control how many generations they can produce in a given time. As a software product designer, though, you can.
Release early, release often. Measure. Repeat.
No animal is alive today that developed all its characteristics within one, three or even 100 generations.
Human beings are naturally complicated creatures. We live complex lives and we interact daily with incredibly complex systems: office politics, personal relationships, government bureaucracy… we are surrounded by complexity. The reality is, though, that much of this complexity need not exist at all.
When humans look at problems, we have a tendency to look for the most complex solution to that problem. I think complex solutions to problems arise when:
(A more pessimistic or controversial reason might be that we sometimes develop complex solutions to problems, either consciously or subconsciously, as a defense mechanism: that is, we think that if we can show that our job is complex, we can become indispensable… in other words, we use it to justify our job/responsibility/existence.)
The problem with complexity is that it’s expensive:
As product creators we need to find the simple in the complex. Simplicity is so much easier: less code, fewer mistakes and a lighter learning curve.
Your value as a creator of meaningful things is in how simple you can make it; not how complex.
