A day in the life of a PO - day two

If all the required talent is already in your team, what's your unique selling proposition as Product Owner, you ask? The Guardian of the Roadmap is the best answer I can come up with. And it is a worthy task at that.

Welcome to project Utop.ia

In a position of some influence, it is important to understand and yield your tools well. The most powerful instrument in the toolbelt of a seasoned PO is that Technical Roadmap. The place where heroes are born and budgets die, really.
Since the roadmap is what you point at when Business comes up with an unexpected feature request. And where you fall back on when they ask that rarest of questions, "how much additional budget would you need for that feature?" - I've heard rumours of that happening. Or if you know your tech lead is working on something crazy on the side, some strategic management of the roadmap can let it bubble up just at the right time for maximal effect.

For the purists, a Technical Roadmap equals a prioritized backlog.

Day two

Let's talk about the sprint. No, not this one, the next. Actually, if you are now talking about the current sprint, something went wrong in the setup of the previous.
I know, the senior developers and scrum master are having all the fun, and the PO not allowed to join. It's sad. And also what I'm being paid for.

Document highlight: the technical roadmap.

Start of day

The interesting thing about getting to work on a week one Tuesday, is that you feel in control. Obviously because of it is the day of the beforementioned roadmap. Also, if you are commuting to work today, you probably didn't get fired on the spot yesterday during the release meeting.

Try to leave the tech and scrum part of your team alone today, since they will be fully caught up in ticket refinements, a strictly off limits zone due to high micromanagement risk.

Tuesday's agenda...

Roadmap worksession

A roadmap worksession crowd depends highly on your personal character and your trust level with the other stakeholders of the project, even the stage of the project you are in. It might lead you to a quiet solitary place - or the exact opposite.
I find a long train, flight or Uber commute usually the best moment to process notes and mind droppings into the roadmap. All the same, carve out dedicated time in your agenda for it.

The science of roadmapping is in simplifying the features ahead by assessing the amount of sprints a unit* will work on it, and then apply some buffer. If you don't know your team well yet, double your assessment - never ever minimise. You'll recieve lasting praise for making your deadlines, not for making promises.

The case of shifting units

The key force behind a roadmap is that the units are like water, they are mobile but incompressible. If a feature gains priority, something else has to give. If nothing can give, you can only add units (read: budget). For a new PO it might be a bit daunting to be that hard-lined, but any solid Sponsor will -after trying anything that implies the opposite- respect this. It's your job.

Your team will be interested in the roadmap, so come up with a smart way of balanced knowledge sharing. The developers might be best served with a view on the next quarter to half a year. Your storyteller should have a full view, to anticipate priorities in user stories. The Sponsor is best served with the current year (including history).
Don't forget to keep them updated on changes. Besides the obvious practical advantage of working on a correct document, steady reporting is a soft proof of your leadership. In some cases, a valid target for your worksession is exactly that: a weekly debrief.

* A team can be a single unit, or be made out of multiple execution units, depending on the nature of the developers and the job

Stakeholders: Sponsor (optional), PO (leader), Functional Analyst (optional) and Storyteller (optional)

Wireframes refinement

Wireframes are the backbone of your user stories, and accurate user stories are the greatest good. Therefore it is fair to state that wireframes deserve the proper amount of love. You might be the one maintaining them, or you might enjoy the pleasures of a design-powered team. In both cases, try to get changes sorted out early in the sprint.

You'll mainly come across two kinds of refinements.
Priority changes. Be prepared to kill your feature design milestones, some features will gain momentum over others. Inform your (UX) designer about those during this meeting, even if you mailed about them. Questions will come up.
Feature changes. Change requests might also have an impact on your user stories, therefore you'd might want to have your storyteller around.

If Wireframes are your thing, a little shout-out: proper elaboration on wireframes as instrument will happen on "Day 9" of this series.

Stakeholders: PO, Storyteller and Designer (leader)

The technical roadmap

A colourful list of blocks just comprehensible enough for all the stakeholders to realise you are needed after all.

I haven't really come across a standardised version on this. Use a dedicated tool, or simply a spreadsheet, with 3 axis: time, team & features.
Depending on the depth one of those 3 will be vertical. In the example file, this happens to be the features.

Define the weight of your block unit (full sprint, half sprint, ...), and break down features to the level where you feel confident to assign sprints to it. The rule of thumb is straight forward. If you are at a level where you need less then half a sprint on average, you've gone too far. If none of your features take less then 2 sprints per unit, break down more.
Obviously, for these assessments you need to have full ownership of the features. Prepare that first, don't feel shy to get better informed by your tech lead later. Don't forget to buffer*.
An average roadmap can span up to 12 months without being the exception. Keep improving your assessment on nearby units, and put on the rough brush for horizon features.

At the end of the day, the stakeholders who would like to do the roadmap assessments for you, should in no way be allowed. And the other way around - the ones who could potentially do a useful job, really will hate you for it. Don't delegate this job.

Document source: technical roadmap

* To buffer: get to know your stakeholders. One's assessment you have to double, other's you'll typically have to cut of a third. Whatever pattern, always add some time to the critical features, and plan some nice-to-have units around, which can be easily killed in sprint.

Outro

If you haven't lost your feeling of control by the end of the day: congratulations, you've met the maturity point of your roadmap. Or maybe even the project - but let's not get ahead of ourselves just yet.