Another Way to Say “Building The Right Thing”
Successful software product development and IT Projects face a constant, and healthy tension – you want to build the right thing, you want to build the thing right, and you want to build the thing fast so you can get more feedback. (Thanks to Henrik Kniberg’s excellent video Agile Product Ownership in a Nutshell for putting words to that concept). All three are equally important so certain people on team find themselves naturally focusing on one of those three aims and then working together to make sure that healthy tension results in the best outcome.
My goal for kbp.media is to provide practical resources for those who are primarily focused on determining the right thing to build (and determining if building something is the right thing to do in the first place). A challenge I’ve run across is finding a concise term to call that set of activities, and I’m fairly certain I’m not the only one. For example over the history of the Agile Alliance’s North American conference there has always been a track that inherently been focused on building the right thing, but one program committee after another has struggled with what the heck to call that track. For Agile2015, it’s called Working With Customers. I’ve never found that name entirely satisfying.
I’m hesitant to lump it under an existing field (product management, business analysis, user experience) because I’ve found that activities from all those fields come together to effectively determine the right thing to build. I also don’t want to assign it to a specific role, specifically product owner, because of the implication that a single person can do all of those activities on a team. Not terribly realistic in most settings.
Others in the community have thought about this problem and have suggested the term product ownership. While not perfect, I think this term works good for my practices. It’s fairly recognizable, and it represents a group of activities more so than a role. So that’s what I’m going to go with. It’s also a name I’d suggest to the Agile2016 Program committee.
Product Ownership Defined
With that settled, I suppose it would be helpful to state what specifically I mean when I say product ownership. My brief description of product ownership is determining the right thing to deliver.
My bit longer description is:
- Understand stakeholder needs
- Determine if the need is worth satisfying
- Determine the best solution to satisfy it
- Build a shared understanding of the solution
- Validate the need was satisfied
For an even more fully fleshed out view of what product ownership is, take a look at the learning objectives included in the International Consortium of Agile (ICAgile) Value Management Track. Why don’t I use the term Value Management? I find that it is too conflated with concepts from other fields, (including the horribly misnamed Earned Value Management which has nothing to do with earning value.) In addition, the term as applied to determining the right thing to build is not as commonly known in the software product development and IT project communities. That said, I think the learning objectives grouped together under the ICAgile Value Management Track are a good collection of activities and techniques and I consider product ownership = value management.
Product Ownership is a combination of other fields
As I mentioned above, a primary reason I adopted the term product ownership is I see it as composed of activities from primarily three fields:
- Product management
- Business analysis
- User experience
You can think of it this way: (is there any sort of award for the gratuitous use of a venn diagram in a blog post?)
The extent to which you use the activities from each of this area depends on the context in which you are working. The simplest distinction I can make is between software product development and IT Projects. Software product development tends to use product management and user experience activities much more than business analysis. IT Projects tend to place a larger emphasis on business analysis, not nearly enough on user experience, and hardly any on product management. Chris Matts took a more thoughtful approach using the Cynefin model as a guide. He suggests that business analysis activities are helpful in complicated domains, whereas product management and user experience are the best tools for product ownership in the complex domains, with the difference heavily determined by the amount of choice the users have in what solution they use.
Unfortunately, these collections of activities are not as clear cut as someone who likes to group and characterize things would like to believe. There are activities that cross between these three groups (personas for example originated in user experience circles, but have been adopted by both product management and business analysis). So there are definitely some overlap between these areas, and there are some activities that these three fields include which are not included explicitly in product ownership.
Following is my attempt to identify a set of activities for each field that may be helpful to be aware of when talking about product ownership.
Product Management Activities
I tried to pick non commercial views of the activities in a given field, but given the extent of my knowledge of product management, the best collection of activities I can come up with is the Pragmatic Marketing Framework. The nice thing about this model is that it has several very discrete activities which provide a basis for determining what should be included in product ownership, and which fits outside. The downside is that there are several of those activities listed. All the same it is possible to clearly delineate which activities are relevant to product ownership as I think about it (activities such as User Personas, Requirements, Use Scenarios, Product Roadmap and Status Dashboard) and those which are important to a business but fall outside the realm of determining the right thing to build. (Everything else on the Pragmatic Marketing Framework, such as Market Definition, Sales Process, Channel Training and Support).
This graphic from a presentation that Rich Mironov gave at Agile2009 The Agile Product Manager/Product Owner Dilemma ( Slide 19) provides a nice view of which activities from the Pragmatic Marketing Framework could be considered part of Product Ownership:
Another view of the relationship between product management and product ownership, at least implied, is this one from Steve Johnson in his presentation titled Is Agile Breaking Product Management (See Slide 20: )
While it doesn’t indicate what activities fit in product ownership (all the stuff that would fit in the box labeled product) he calls out all the stuff that doesn’t fit in that box that are still important. Namely:
- Define Business
- Define Market
- Design and Deliver Promotion
- Design and Deliver Sales
- Design and Deliver Support
- Refine Business
- Refined Market
Business Analysis Activities
I’ll freely admit that of the three fields I’m discussing here, I’m the most familiar with business analysis. It’s the arena in which I have worked the most during my career.
The best description of activities associated with business analysis is the Business Analysis Body of Knowledge. That work is organized into a set of knowledge areas. These knowledge areas include:
- Business Analysis Planning & Monitoring
- Elicitation & Collaboration
- Requirements Life Cycle Management
- Strategy Analysis
- Requirements Analysis and Design Definition
- Solution Evaluation
As well as a set of underlying competencies.
These knowledge areas contain a set of tasks (you could also think of them as activities) some of which are relevant to product ownership, others of which are overhead activities used in phase based approaches. There is also a set of techniques that go along with the activities. Some of which are extremely useful for product ownership.
User Experience Activities
I had a hard time finding a commonly accepted set of activities for user experience, or at least I was immediately aware of one. I finally rested on referring to usability.gov which seems to have a fairly comprehensive view of the usability field. I have to admit that I was a little skeptical of using a resource from the US federal government as a resource on good practices on anything, so if you are a UX practitioner, please let me know if there is a better resource for information.
Usability.gov references a set of elements of user experience put together by Jesse James Garrett as the primary activities that make up user experience.
Those elements are:
- Project Management
- User Research
- Usability Evaluation
- Information Architecture (IA)
- User Interface Design
- Interaction Design (IxD)
- Visual Design
- Content Strategy
- Accessibility
- Web Analytics
I should note that these elements are intended primarily for the context of the web, and it is also 15 years old, so I’d love to know if this is widely accepted and it there is a broader, more updated view of user experience.
I can see where some of these elements are always applicable to product ownership and others are applicable in certain contexts, but some input from user experience practitioners would be very helpful to sort things out.
So What?
So why am I trying to categorize, sort and group a bunch of activities (the analytical part of me rearing it’s ugly head)? As I mentioned above a goal for BeyondRequirements.com is to serve people who are practicing Product Ownership. While I can certainly share my experiences, and plan to do so, I realize that I haven’t had the opportunity to experience every kind of software product development situation or every type of IT Project. I want to provide some suggestions about what activities and techniques are most appropriate for different situations, without regard to whether those techniques are product management, business analysis, or user experience. I thought I’d start the discussion on whether this categorization makes sense and is even worth while, and if it is mine the minds of experts to determine what some appropriate use of those techniques are.
Here’s Where You Can Help
So here’s where you come in. Let me know in the comments if you think this sort of categorization would be helpful. Also let me know if you think I have the right collections of activities to begin with. I’d especially love to hear from product management and user experience practitioners on any different frameworks that exist out there. And if you look at things with a business analysis frame of reference and think that the BCS or PMI view of things outweighs IIBA’s, feel free to chime in as well. (Note: My reference to these organizations and the content of their certification exams should in no way be construed as endorsement of their certification programs. For insight on my perspective on certifications, see here.)
I also plan to explore this idea during Open Jam at Agile2015, and would love to hear your thoughts about it there.