02 · What I do
Nine years of owning what gets built, and what does not.
Three products where I set the roadmap and shipped them. A startup platform through covid that cut event set-up in half. Three public services delivered in parallel over fourteen months, across four stakeholder groups and development teams that reported to somebody else.
Any team generates more good ideas than it can ship, so a long backlog is never the problem. The job is the cut: which of these earns the next six weeks, what evidence would prove it did, and which two are being carried because somebody senior mentioned them once and nobody has been willing to say no.
Agile since 2017, from inside the team rather than reporting at it.
A product owner decides what gets built next and what does not, writes it down clearly enough for engineers to build from, and is answerable when it ships. In an agile team this is the person who holds the backlog, which is the ordered list of everything the team could build.
The reason this is a job rather than an admin task: any decent team produces more good ideas than it can ship. The work is the cut, and the cut has to survive being explained to the person whose idea was cut.
The responsibilities, and where each one was carried
Nine of them. Every row has a real engagement behind it.
This is the part of a product role that does not appear in a job title, so it is set out plainly rather than summarised. Nothing in this table is a capability I would like to have. Each one names where it was done.
“As it was a redesign, there were many non optimal, ingrained concepts and practices that threatened to be repeated if not addressed. Luis had a challenge ahead of him to not only understand the complex business logic, but also to guide a development team through the implementation of the future vision. He was very quick to grasp the concepts and brought a lot of new and innovative thinking to the project. He challenged preconceived notions and clearly articulated the benefits of different approaches.”
“In my mind, the role is not to simply produce pretty wireframes and usability concepts, but instead to gain an in depth understanding of the purpose of the product, how it fits into the workflows of users, and to make sure the end result acts as an enabler and not a hindrance. Luis achieved this.”
Michael Reid · Product Owner, LexisNexis
The shape of the job
Three questions, and the third is the one people avoid.
Not the feature request. The outcome somebody is accountable for. A request is always a proposed solution to a problem nobody wrote down, and recovering the problem is most of the value in the conversation.
Agreed before the build, not chosen afterwards from whatever moved. If nobody can name the measure now, that is not a reason to build it and find out, it is a reason to find out first, more cheaply.
Every roadmap is an implicit no to everything absent from it, and the nos are almost never said. Writing them down is the single most useful thing an owner does, because it turns a silent omission into a decision someone can challenge.
On your side of the table
Decisions with their reasoning attached, not a prioritised list.
A ranked backlog with no recorded reasoning is a list of opinions in an order nobody can defend six weeks later.
Short enough that the team can hold it in their heads.
- What we are trying to change, for whom, and by when
- A roadmap by outcome rather than by feature, so the how stays negotiable
- The not-doing list, written down and visible, with the reason beside each
Inside the team, in your tools, at the speed the team moves.
- Refinement that ends in something buildable, not in more questions
- Acceptance criteria written before the work, including what failure looks like
- Standups, planning and retros as a participant, not a visitor with a report
The half of the job that is nothing to do with the product.
- Stakeholders given the reasoning and the evidence rather than a status colour
- A cut explained to the person who asked for the thing, by me, not by the team
- Bad news early, which is the only version of it that is any use
So the next person does not repeat the argument from the start.
- A decision log: what was chosen, what was rejected, what it cost
- What we believed at the time, so a reversal can be honest about what changed
- The measures, before and after, including the ones that did not move
Where this has actually happened
Three products of my own, one startup, one consultancy.
I set the roadmap, decided what to cut and shipped all three. One of them now underpins the other two, which was a decision rather than an accident.
Covid, a small team, and a job that was never only design. The call that mattered was making the platform disappear behind the client instead of adding features.
Fourteen months, four stakeholder groups, one delivery lane each, and development teams that reported to somebody else entirely.
The contracts said design. The work, increasingly, was product.
You will notice the title on my CV is not Product Owner, and I would rather say that here than let it surface awkwardly on a screening call. Everything above is real, dated and checkable, which is a stronger basis for a conversation than a line on a CV either way.
What it means practically: I come in already fluent in how design and delivery actually meet, which is where most product roles lose their weeks. Where I would lean on your team early is commercial and pricing judgment, because that is the part my engagements have touched least.
The other five