A product person  is…
A product manager is responsible for the quality of their products. They use their knowledge of user needs and business goals to frame problems and set priorities for their delivery teams.
- form the vision for their product and engage their teams and stakeholders in the development of that vision over time
- keep people informed about the development of their products and promote their uptake
- represent users throughout the delivery process and use their feedback to inform continuous improvement.”
The Product Manager is the first among equals in the team and the public face of the project. They define and articulate the vision for what is being built, explain that to the team and the wider organisation they operate in. They need to be able to judge the right time to come to a compromise, and when to go into battle on the users’ behalf. The product manager ultimately prioritises what gets built, when. They choose what the teams next hypothesis to test will be.”
Product people ensure that we test, experiment and iterate rather than return to the way that we’ve done things before. Product people “give the team a north star… to work towards” (18f) and ensure a product is designed to address problems faced by real users.
A product person is NOT…
There are a number of roles that product people can get moved into if the organisation doesn’t understand or isn’t ready for product people. I don’t think this is a complete list, but these are the main ones that I’ve spotted.
1. …a Business Analyst
A business analyst (BA) is someone who analyzes an organization or business domain (real or hypothetical) and documents its business or processes or systems, assessing the business model or its integration with technology.” (Wikipedia)
I’ve worked as a business analyst. In my experience, the roles of BA and product person are closely related. I’d even say that my BA diploma was useful training for being a product person . This said, I think the roles are separate and different and complementary.
A BA will document processes and systems and research approaches and options. A BA will also sometimes draft user stories, but the product person will retain control over the priority of work, the vision to work towards and the shape of the next section of work. All this means a close relationship between BA and product person is essential. When this works well, it provides the rhythm for the rest of the team. The partnership between a BA and a product person provides the best line of defence against crazy or ill-informed suggestions from outside of the team.
The important difference is that, whilst a BA can provide suggested approaches, it is not their job to provide vision or to prioritise and make decisions between options. A product person is concerned above all with their users and with providing value to their users; a good BA will be aware of these factors but will be more concerned with the process or system.
In a small team, a product person sometimes ends up doing the role of the business analyst – researching options, systems, processes – themselves. This can work, particularly if some of the work on existing systems and processes already exists. A product person is not a BA, and missing out on a BA’s ability to understand systems and processes can cause problems, particularly when you come to integrate your team’s work into a wider infrastructure.
If a product person is not able to set priorities, sign off stories or provide vision and roadmaps, then they can end up becoming a BA by default. There are occasions in my product career when I’ve realized that all I am doing is providing options for more important people to approve or reject. When this happens, it’s probably not a good situation for either the product person or other BAs: confusion about roles and responsibility for decisions is the last thing that a team needs.
2. …a Subject Matter Expert (“Business Representative”, “Customer Representative”)
To specify the needs (requirements) of the Users that will use the project products.
To liaise between the Project Management Team and the Users.
To make sure the solution will meet the needs of the Users, especially in terms of quality and ease of use, and against requirements.
To supply the benefits information for the Benefits Review Plan.” 
The description above is from Prince2 documentation but that doesn’t matter so much. A lot of formal programme/project management techniques have the concept of a representative of the end user sitting on whatever board/committee/group is responsible for implementing the new solution.
The role of these positions is to provide a conduit for feedback and thoughts from the people who will end up using whatever is being changed or built and therefore avoid the risk of delivering something that no-one wants. There are two differences from standard agile approaches here.
Firstly, this person will get a chance to comment on either plans or software that have been completed; they may be consulted in their creation but their main feedback will be once something has been done. Secondly, this person has no independent decision making power: their impact is limited to raising issues for the board/committee/group to be aware of.
The difference between a product person and a SME is significant. All that a SME can do is provide feedback on approaches, or raise risks, all while trying to manage the impact of training users on the new system. An SME is frequently chosen from expert users/managers of an existing system, so can sometimes end up providing a more short-term or conservative view (“we must have feature parity”, “but the system should work this way because that’s how it has always worked” etc.).
If you remove access to iterative user research and the ability to determine priorities and be involved in team discussions/decisions from a product person then they are likely to fall back into a SME role, commenting on plans from the viewpoint of the internal user/support team. This drift is particularly likely to happen in the public sector, where we have such a strong tradition of SME roles.
3. …the Comms Person
When one-directional communication was the standard approach, big projects usually had an allocated “comms person”. This person was often overworked and harassed, working on multiple projects at the same time. They looked after the “communication plan”.
The “communication plan” is the embalming of communication activities in waterfall solution. It would be written at the beginning of the project, usually after some kind of SWOT analysis of stakeholders. Changing the fundamentals of it (the channels of communication, the audiences) would rarely happen.
If you were lucky, it would be treated as a tick list and you might manage a few boxes checked before the end of the project. If you were unlucky, there would be no-one with the time to devote to any of the activities and the comms person would get gradually frustrated with the project and the project staff would get gradually frustrated with the comms person.
To communicate a product vision and a direction to both internal and external audiences, there is a need for product people to engage in communication activities. (This is missing from the DDaT product job description, incidentally.) A good product person will be able, at any time, to pitch the importance of their product, the direction of development and the reasons behind the choices made – to any audience.
What this doesn’t mean is that the product person becomes the sole custodian of the gap between the team and the rest of the world. This isn’t good for the team or the product person. In a multidisciplinary team, comms is the job of everyone. That means blog posts, sprint notes, release notes, conference presentations and show and tells should never be the responsibility of one person or role.
An agile approach to comms means throwing the comms plan out of the window, being aware of your audiences and iterating/reviewing the way that you communicate with them. If you don’t do this, think about how to introduce this to your ceremonies. Why not have blog post feedback/planning as part of your retro/planning session?
4. …the Tester
User acceptance testing (UAT) is the last phase of the software testing process. During UAT, actual software users test the software to make sure it can handle required tasks in real-world scenarios, according to specifications.” Techpedia definition of UAT.
A product person should be responsible for signing off or agreeing that stories have met their acceptance criteria and the definition of done. In User Acceptance Testing, the end users are given the responsibility for signing something off as “acceptable” to use. It’s possible to see why confusion between the two approaches can arise here.
This is particularly the case when – because they are often the first people to use a new feature – product people, and particularly technically literate product people, have stepped into a gap and become the people who have accepted responsibility for checking that completed stories are going to work.
This isn’t what should be happening. The product person should be checking that the work – whether feature or other work – meets the description and criteria in the user story. They need to do this to check whether further stories are required, or if there has been a change or misunderstanding.
The process of checking that the work is technically sound, documented, doesn’t cause any problems with the existing code base or architecture, doesn’t introduce any security flaws, and doesn’t break any standards (e.g. accessibility if it impacts front-end): all these should be part of the team testing approach, automated where possible, and included in the definition of done that rules what happens to work before it’s presented to the product person.
Using the product person as the only bulwark between shonky and insecure code and the external world is not a risk you should ever be taking.
5. …the Technical Architect
Creating a plan for a product, and what it should provide for users, is sometimes mistaken for a plan of what the product technical architecture should look like. In a microservices world, good architecture can sometimes end up looking like there is a microservice for every significant task that a user undertakes.
When this happens, that’s fine but it shouldn’t obscure the fact that the technical architect is responsible for determining the best technical way to deliver your product. Product people are responsible for what the product is and does; an architect ensures that the way your technical approach is structured can best deliver this. These are two very different tasks.
Sometimes, a technical decision will have an impact on the product, or vice-versa. In these cases, product and technical people need to work together: the product person is still responsible for the final priority, but they will only understand the impact of their choice with the input of the Technical Architect.
6. …the Project Manager
I hesitated about adding this to the list, but I do still come across people who confuse “Product Manager” or “Product Owner” for “Project Manager”. I can’t improve on the clarification that the United States Digital Service offer:
Project management is focused on managing to a plan. Focus areas include managing schedule, budget, risk, policy compliance and reporting status to stakeholders. Success for a project manager is delivering a defined scope of work on-time and on-budget.
Product management is focused on delivering a product a user wants or needs. Focus areas include user research, design thinking, iterative development, and delivering minimum viable products quickly. Success for a product manager is delivering a product that users love — and use to complete tasks.”
 As in my other posts, I’m going to use “product person” throughout this post to refer collectively to product owners and product managers.I am aware that these two terms have different histories and different uses in different organisations. The problem is that they swap in meaning between organisations so often that it’s difficult to use one of them without inviting misunderstanding.
 It taught me a lot about “requirements” and about how to “elicit” and “validate” these. That’s not exactly the same approach as user needs and user stories that product people typically use, but there are similarities.
 If I can remember through the fog, I think that this role was called a Customer Representative when I went through Prince2 training (this role is now seen as reporting to the Senior User).