My role as a PO (product owner) and related roles in a tech company.
Beeing a product owner in the tech world isn´t an easy role at all, plus it is ambiguous itself. Many companies call it “business analyst” and others mix it up with “project manager”, “product manager” or even “scrum master”, increasing confusion among management roles within tech companies. Let´s clarify a bit what the different roles stand for and my approach as a PO, based on my professional experience.
Tech management roles.
Project manager.
Starting off with the most important role on any project, be it digital or not, the project manager role is the person responsible for driving the project forward, usually between managing budget and people for bureaucracy, technicalities (such as purchase of software, licensing, etc.), infrastructure and employees (work force and salaries), aligning these constantly with the project needs, while establishing and maintaining routinary contact with stakeholders.This role is the one of this comparison that is mostly focussed on people, alongside with human resources and team leads.
Product manager.
Even though sometimes, the product itself is a project or entire company, there are many other times when a project encompasses multiple products, specially in big companies. The product manager is the person that is responsible for the product entirely, specially for shaping the future of the product through the analysis of client usage data and stakeholder´s requests. Usually, the product manager brings down these epics (big sized items to be worked at) in the roadmap, a schedule tool for milestones, which is very useful at providing stakeholders an overview of things that will evolve in the future and it´s impact on the product. Furthermore, the product manager creates metrics (measurement of success) for all existing and new features. If stakeholders need to discuss anything on the product, the product manager is the point of contact.
Scrum master.
Tech companies follow some procedures for the development of their products. Often, it is a SCRUM framework, under the agile development mindset. Well, the scrum master is nothing but the one responsible for checking constantly the health of the process, detect things to improve and look for room of improvement as well as its optimization. This not only applies to the ways of working, but also to tools such as scrum ceremonies and their effectiveness on the process evolvement. Since there is no process that fits perfectly to any project, I consider a scrum master to continuously tailor a custom process for a project.
Product owner.
When it comes down to be working under a SCRUM framework, the development team delivers its deliverables (pieces of work) in sprints (which is an agreed constant timeframe, be it weekly, bi-weekly or monthly). The product owner is the one who is responsible for breaking down epics into user stories (smaller amount of pieces to work on, which are technically more descriptive), planning and prioritising based on the sprint capacity (work capacity of each developer summed up for the whole team) for each sprint. The backlog is a list of work items to be done, and the product owner must be constantly prioritising and describing all user stories, since often a lot of urgent tasks come in, while also evaluating the progress of the product, specially for the work in progress tasks.
Ultimately, the product owner is responsible for the product delivery, ensuring an adequate and default-free implementation.
PO duties and responsibilities.
Where my duties start within the development process.
As a PO, the input is provided by product managers, whom which I discuss the vision and later on add product epics into the backlog, which provide a big size picture of each implementation. I even faced the case that some epics converted into projects due to their complexity!
Constant backlog refinement and prioritization.
The heaviest duty of a PO is to be constantly breaking down epics into user stories and specifying them as much as possible on the technical side, plus doing a rough estimation on the workload. For me, this has been around 75% of the workload. Refinement sessions stand for the clarification in case of technical doubts, which I conduct once in between a sprint with lead developers, since they are experts and have a broader technical overview.
Things to describe on each user story by myself are the user story description, following a similar structure to the one I used when working as UX designer and creating user journeys:
As [product-related role],
I want [action to be performed],
So that [product value proposition].
Furthermore, I also detail a bulleted acceptance criteria, which is very helpful fore engineers in order to know how it must be implemented and marked as done, as well as to perform a valid quality assurance so that the feature is entirely delivered.
Find below an example of a user story I developed for a product case challenge.
Based on the allocated workload of the entire team and the estimation of the workload for each item, I order and prioritize the user stories for the upcoming sprints in the backlog, focussing firstly to cover the next sprint.
The ultimate goal here is to have enough items perfectly described and organized for a couple sprints ahead.
Sprint ceremonies.
Another part of the job is to conduct short but frequent update meetings (5–15 minutes, ideally but not necessarily daily) with the team, so that the progress on the development can be tracked and any incoming issues or doubts can be addressed soon. We don’t want to lose time, and remember it’s a PO´s responsibility to deliver on time.
Before actually starting each sprint, the tasks are estimated with the development team and any corrections on the user stories are made during a so called sprint planning session.
Right before each sprint ends and only after all committed work has been accomplished, the sprint review / demo is conducted by the product owner in order to showcase stakeholders and other team members the features that have been delivered.
Lastly, a sprint retrospective session is made, which identifies pain points and upsides of the current sprint on the process. Theoretically, this meeting should be driven by the scrum master, since it covers mainly the process, but I have been involved in this meeting as a PO since we sometimes discussed product things as well.
Where my duties end.
Theoretically, the duties of a PO end when the product feature is delivered with quality. This means that the extend of the PO for any item is not limited to just development, but also to QA. I would say strategy and some kind of UX are fields that fall out, since here the responsibily falls under the product manager´s duties.
