What is Product Management?
Originally coined in 1995 by Agile Manifesto founder Ken Schwaber, product management is a concept which formally acknowledges that key software systems should be treated as ongoing and evolving endeavours with a focus on value (products) rather than one-off deliveries with a focus on delivering against an unchanging plan (projects).
Product managers facilitate this process by maximising the value delivered by their product and they do this by prioritising and pursuing the items that are likely to yield the most value when balanced against the effort to implement.
Product managers and product owners work closely with a variety of stakeholders, both internally (employees) and externally (end-users and third parties) in order to understand not only what they say they want (requirements), but to form theories and hypotheses about what they might need and not yet know (experimental test and learn).
Table of Contents
Capturing Requirements
Part of being a product manager is speaking to stakeholders to understand what behaviours they want the system to exhibit and how they want it to function. This is where we get the term “functional requirements”.
Functional Requirements
Functional requirements are so-called because they are functions required by someone, usually stakeholders, and the requirement is related to the system being built. An example would be “I want to be able to log in to the system”.
Product managers are often subject matter experts regarding the product they are managing, so they may often write their own requirements. In such circumstances, they need to be careful that their requirements are validated with research otherwise there is the danger that the product becomes built to their own subjective requirements rather than externally validated ones.
Agile software development approaches recommend that rather than building the full stated requirement, that just enough is built to allow the customer or stakeholder to interact with the system so that they can review the work completed and reconsider the next steps. This is called iteration.
Non-Functional Requirements (NFRs)
When requirements relate to technical requests, these are called “non-functional requirements”, which are specifications for the system that do not directly affect the user-facing behaviour. An example of this would be “User passwords should be encrypted to the AES 256 standard”.
Non-functional requirements are very important as they relate to the security, performance, scalability and integration of the system being built, but it is easy to forget non-functional requirements until it is too late and that’s why it’s common to see large I.T. projects fail; it’s not that the user-facing design was wrong, it’s that insufficient rigour was invested into specifying the bits that you don’t see.
It is also common to see the reverse of the above issue where systems are over-engineered in regard to the NFRs. This usually happens because either people have taken an overly risk averse approach to the NFRs (e.g. stating that a system must be available 99.999% of the time when it’s only required during working hours) or they’ve used an example set of NFRs from a different project.
With the above points in mind it’s important to ensure that NFRs are “right-sized” and appropriate for the product being built to prevent failures which might impact business continuity, but also prevent overspend and overengineering, which can carry a burdensome resource load.
Product Requirements Document
When requirements are being gathered they are often captured in a product requirements document (PRD), which is a list of the stated requirements along with explanations of what they are and why they are required.
This list of requirements can then be used to write a series of actionable backlog items for the development team to start implementing. Such backlog items are often written as “user stories”.
User Story Mapping
From the PRD we can then begin to start writing our list of user stories, and a useful approach to take is a user story mapping approach as follows:
Vision → Goals → Activities → Tasks → User Stories
It often helps to use the separate steps of the customer journey as an aide memoire to writing the user story map as it ensures no element is left out.
User Stories
User stories, introduced by the eXtreme Programming (XP) movement, are a way of representing requirements in a series of simple statements. The structure is as per their name in that firstly, the requirement must be linked to an end-user and secondly, they must be written as a story, rather than a solution.
An example of a good user story:
As a shopper
I want to search for cheap items
So that I can save money on my shopping
This is a good example because it lets a person reading the story understand who the user is, what they want to achieve and why they want to achieve it. Further discussions can now occur as to how this story could be delivered. For instance, you could allow sorting of search results from lowest to highest, or you could have a quick link which displays a page containing items priced under $5.
The point of this is, there are multiple solutions to a problem and if you jump to a solution too early then there is the risk that you choose the wrong solution,
An example of a bad user story:
As a Product Owner
I want to optimise the DB by changing select queries to limit queries
So that it performs faster
This is a bad example because firstly, a product owner is not a user, so we don’t understand which user persona we are directly benefiting by completing this task (unless you happen to be building a system for Product Owners!).
Secondly, the approach to resolution has been pre-solutioned without any room for negotiation and thirdly, the outcome doesn’t really state how the task adds any business value, as a faster database in itself does not create value.
User Stories: A reminder to have a conversation
A good user story is a reminder to have a conversation with your users, stakeholders and development team about how to solve the stated problem (not a reminder that a conversation has already occurred!). In fact, the process of implementing user stories is stated to be “The three Cs” as follows:
- Card – The writing of the user story
- Conversation – The discussion about how to achieve the desired outcome
- Confirmation – The process of confirming that the outcome has been achieved
It is common, however, to see user stories written with full solutions attached before the development team has seen the item and this tends to be reflective of organisations who have moved towards agile from a more top-down waterfall approach. This isn’t necessarily a catastrophic problem, but certainly better resolutions are achieved when the people implementing them are correctly engaged.
Workflow tools and Agile
Originally, agile software development teams managed their workload using whiteboards known as “information radiators” which were separated into columns with sticky post-it notes to represent user stories and indeed some teams still operate like this today.
The purpose of the information radiator is to provide transparency, both within the team and outside the team so that the status of progress on an item can easily be known. Whether it is in progress, done or not yet started; it is important that people with a vested interest can make themselves aware of this progress and preferably without having to disturb the developer by asking “is this done yet?”.
With the advent of distributed teams and remote working, there was a move towards virtual team boards, stored inside computer-based workflow tools. Some popular workflow tools include “Jira” and “Trello” both owned by Atlassian and also “Azure Devops” by Microsoft.
Such workflow tools allow you to create detailed backlog items, containing not only the original problem statement or user story, but all of the associated conversations, images, process flows, links to relevant code snippets and much more. These items then move across a virtual whiteboard from “To Do” all the way to “Done”.
A happy side effect of using virtual workflow tools is that you have a detailed audit record already completed showing how long an item took, who requested it, who worked on it, what the solution was and even a link to the specific code that the developer committed to their repository.
There have been some criticisms of workflow tools, namely that they change the focus of the team to spend too much time on administering the tool itself and that the way in which some teams work then begins to change to reflect the language and default workflow of the tool itself.
With that in mind, it’s important to ensure that the team is working in the best way for itself and the organisation, by ensuring that the scrum master or agile coach working with the team, guides them to make appropriate choices about ways of working.
Agile Product Backlog
Once the PRD has been distilled into a set of user stories, these stories need to be stored somewhere in priority order. The name for the place that this to-do list is stored is the “Product Backlog”. It’s the product manager or product owner’s responsibility to ensure that the product backlog is in priority order so that the team knows which items will create the most value.
Once the backlog has been created, further discussions can begin with the team in a process known as “refinement”. This allows the necessary detail to be added to user stories to allow the development work on them to proceed.
Although the product manager specifies the priority order of the backlog, the team is free to choose items from it in the way that best makes sense, as they are better informed with regards to the dependencies involved in the development process.
Conclusion
Product management is a complex area, ensuring that the views of all relevant stakeholders are considered, prioritised, assessed for value and then translated into actionable development items. Product managers need to be able to speak to people from a diverse range of backgrounds such as board level directors, users and developers.
As with everything in agile, this is an iterative process where improvements are made along the way, both to the engagement process with stakeholders as well as the development of the product itself.
By using our Jira plug in you can help smooth the product management process by providing an easy to read view of your user stories and user story map, including the progress and priority of each one.
