A few years ago, I went to the Scrum Alliance's Product Owner certification (Certified Scrum Product Owner/CSPO) training course. I didn't know it at the time, but the company I worked for had internal training that was a discount to the cost of getting external training but in retrospect I'm glad I went to see what it's like outside of the company.
I couldn't prove it but I know that if everyone in the training was from my company, it'll just gradually shift toward a focus on the content of the work we were working on, people that inevitably drank the company's "koolaid" and it'll be less about the objective look at the Agile Manifesto and the scrum methodologies.
I was right and I inadvertently made the right choice. Years later, I had gone to an advance Product Manager training course within the company and it wasn't nearly as effectively. Even though they brought in third party trainers, I think there we a sense of the trainer acting as an in-house agent and there was more of a focus on what we were doing within the company rather than a focus on industry best practices.
Theory is all about the practicalities. Theory isn't without it's flaws too but if you can find a trainer that has successfully practiced these and see them successful while leverage across many different companies' best practices, it's likely you'll get a good insights into what works and what doesn't. My CSPO trainer was like that.
Now I've only been to a few official Product Owner or Product Manager training sessions. I don't really have a way to compare the curriculum that is taught and I know that the Scrum Alliance gives a lot of leeway to trainers and instructors.
My takeaway from all the work we did in the 2-full day intensive training was about the 3 C's. Do you know the 3 C's?
Even amongst the 3 C's, I found one to be the most helpful in distilling what agile, scrum or good product ownership or product stewardship means.
The three C's are as follows:
The cards are very straightforward and literal -- you put your user stories or whatever artifact you'd call your requirements into a 3" x 5" index card. The card itself creates the boundary of what you can put on it: not too much words as to make it a waterfall-type requirements document and not too short because you need to illustrate the user story fully.
While ever product teams is different, I've been in product teams where the user stories and Sprints are like mini-waterfalls -- there's so much work that goes into writing the user stories and so much of it is making life almost monotonous for the developers and product team. There wasn't a need to ask questions or think through the problems in full because the ownership of those questions were transfer to the Product Owner or Business Analyst (BA). This is where productivity in lost (in my opinion).
This one is probably self-explanatory and easy to understand but not necessary easy to execute. You prioritize having a conversation with someone over writing it down on paper, or typing an email to answer questions.
Showing, talking face-to-face trumps any other electronic means.
This also goes for the use of Cards too. While there are many product management digital tools out there, like JIRA or UA Agile or Version One (the list can go on and on), teams are more efficient at both creating, mitigating and understanding each other best in person and with the use of some offline techniques like cards and conversations.
After-all, it's people who write the code, interpret users stories and people who use your product. While computers are widely used, there is no replacement for having the conversation face-to-face and to make sure it's clear or make it clear when it's not entirely clear.
As a Product Owner, you own the product. And as the voice-of-the customer, you get to define what is acceptable or not when the Sprint or release is coming due.
Every "story" needs a beginning middle and an end. That's how I like to think of product management which is a creation of a bigger story. The 3 C's help ground that concept into the art of product management.
Cards with its user stories are the beginning. The genesis of the story started there.
Conversations are what you have along the way. Dialog in the case of films, TV or theatre. This is the content and the climax of the story is somewhere within these areas.
Confirmations is where you story ends -- you need to tell your audience (product team) where they need to end and what is the conclusion of the saga (Sprint). What makes a good ending, how do they know they'd created an ending if you don't tell them?
I find the analogy of filmmaking and product management as one in the same. Someone in the product world recently said that product and filmmaking have parallels that it's a "hits" type of game. Sometimes you hit home runs and other times you don't, but it's the products that are exceptional that'll make the all the losses all worth it. I tend to agree. I think that's why we continue to be in this line of work.
The three C's is a good way to remember that even though the output of your work is a digital product with 1's and 0's, the day to day job you have is very much in the real world (IRL). It's flesh and blood that's you primary objective and it'll be good to remember that it's less about managing the product than it is managing the people who have a stake in the product be it marketing, sales, developers, designers, users, business sponsors or even yourself.
Make product management a way to reconnect and I've found a great analogy for this is the you are trying to tell and sell a story.
You create a piece of work where you need to constantly write a new chapter to your novel. Each chapter is new and there is a beginning (Cards), middle (Conversations) and an end (Confirmations).