I’ve started a mentee collection. Not a manatee collection:
I’m mentoring three new Product Owners, collecting them into my posse as I encounter new Product Owners who have no peers/colleagues from whom to learn the ropes.
The rant below was inspired by a real-life plea for help from a newly-minted Product Owner at my company. Knowing how anxious and overwhelmed I was when I realized what I’d gotten myself into, these are the kinds of “start small, start here, build on your successes” advice I’d give my past self (can we use Skynet’s back-in-time portal yet?):
- I’m inclined (especially with new teams, new process, new roles) to start small – get a rhythm, build a few quick wins, get small pieces shipped in short timeframes, even if it’s not technically a “potentially shippable product”
-
- The important thing is to start seeing chunks of more valuable engineering work delivered earlier
- For example, I’m currently getting the team to work on a “research spike” to determine if they can figure out how to add “test our site using IE11” to the test coverage – plus we’re doing the second story (broken up from a larger story) to deliver an Export capability to our project planner (just started with flat file, unformatted CSV as an export deliverable for now – it’s good value to users, and we’ll refine and “gold plate” it later)
- I’ve also had them working on some of the more ‘valuable’ tech debt over the last few months – cleaning out old database tables, removing dependencies on legacy code and data structures, etc. – all written as “stories” (probably doesn’t fit the dogmatic definition), small bits of work each, that ideally could’ve been done all at once, but are easier to schedule, are establishing a rhythm, and have given them hope that I’m committed to systems hygiene as part of our negotiation between “user value” and “systems integrity”
- Encourage the team to adopt SCRUM (or whatever flavour of Agile-ish behaviour they’re aiming at) in stages – don’t try to swallow it all at once
-
- As a fresh PO, I’d stand up and tell them I don’t expect them to get everything right the first time, and especially not when they’re playing with all these new “process toys”
- e.g.. Try the “sprint planning” and “retrospective discussion”, and drop everything else, for the first sprint – see how it goes, spend the time discussing “things to do more of and things to do less of” at the end, and ask them whether they’re ready to add “daily stand-ups” or “story point estimation” or “story breakdown” to their process
- Personally I don’t want process to get in the way of the engineering – I want it to be a net break-even, and if you try to do all the process all at once, there’s no way that they’ll get any effective engineering done that first sprint or two – just too much flailing and failing on friggin terminology, not enough on learning to succeed at the job with incremental improvements along the way)
- As quickly as possible, focus your efforts on the WHAT and the WHY of every piece of engineering work that the team sets out to do.
-
- Any of us that come from engineering will still trip over the HOW too many times to count before we get really good at this, but it’s worth the effort to learn.
- The most satisfying feeling as a PO is setting the team a challenge you yourself have no idea how they’ll deliver, and watching them struggle, flail and invent something they never knew they could do.
- Over time, they’ll recognize your trust and confidence in them – in giving them the leeway and slack to take on challenging problems and kick the shit out of them]
- It’s taken me years to let go of this, and I’m still meddling more than I should, but it’s satisfying to imagine how it’d feel for my ‘product CEO’ to have faith that I’ll do an amazing job figuring out how to make it happen
- The big focus for you – for as long as you inhabit this crucial role – is to spend as much time in the heads of your users (and unfortunately, stakeholders who aren’t end users) to understand what will be the most valuable thing to deliver to them as soon as possible
- The trick is “most valuable part of functionality”, not the ideal solution
- e.g. The users want to be able to import the set of security requirements into their ‘work tracking system’ (Jira, RTC, Rally, Trello, etc).
-
- It would be awesome to have it pre-filtered to just what they need, pre-annotated to fit exactly the field structure of each of their tools, and able to be exported back into our system
- However, the most important first incremental delivery of value before we work out all those problems is “structured list of the names of the tasks, their current status and a link to more info on how to deliver them” – a far cry from the ideal solution, and probably ten steps between here and there
- I’ll carve out this first step as a story, where the WHY is “I need to track this shit in my native work tracker”, and the WHAT is “the details that are critical to me tracing back to what I need to know to be successful”
- The rest of that work I’ll represent as notes in a parent Epic, or one or more Stories that may or may not be fleshed out enough for the dev team to tackle (depending on how soon I/we think we might get around to delivering that residual incremental value)
In a future post I’ll introduce the fever-dream “system” I use to calculate priority for each story and Epic, but seriously you’ve got plenty to chew on just getting out of the starter’s gate. We can setup a 1:1 call for whenever in the future you want to review results/commiserate over failures/discuss additional experiments that you’re ready to try.
It’s an adventure – a Very Real experience in both asserting control and letting go of absolute control over the direction of the product. It’s a blast. If you’re a new Product Owner, welcome to the tribe.
The rattled cough of a Hyper-Empathetic PM 