Pieter Hens
Product Order Telegraph
Navigate the product management waters.
As a product owner, I felt lost.
"Product Owner is a role you play on a scrum team, Product Manager is the job." - Melissa Perri
This was one of the revelations I had when I was struggling to find my position as a junior product owner. It broadened my view of what I was supposed to do and manage.
Beyond the realm of "JIRA backlog management" lay an entirely new world: the world of product management.
And the landscape was vast...
That was immediately the second problem I faced. I enjoyed exploring the amazing world of product management, but there was a lot to learn. A LOT. And there were no paved roads, tour guides, or signposts to guide you.
Where did I have to start? 🤷♂️
As Product Manager, I had to know how to:
-
Understand the companies vision… (do they even understand it themselves?)
-
Create a compelling product vision... (how do you even do that?)
-
Understand the current market...(which market?)
-
Know how to do Generative Research... (what does that mean?)
-
Translate problems into opportunities... (how do you define that?)
-
Manage and align a product roadmap... (I have never been good at answering the question "when will it be done?")
-
Be aware of your assumptions... (I think I am?)
-
Translate assumptions into Hypothesis... (what is the difference?)
-
Perform scientifically rigorous experiments... (really?)
-
Translate validated opportunities into Requirements... (finally, something I understand).
All while still performing my Product Owner role.
Because… yes… even though “Product Management” is the job, the Product Owner role does not cease to exist.
-
Elaborate requirements in detail without ambiguity...
-
Define detailed priorities…
-
Manage that backlog…
-
Follow up on the state of software development...
-
Understand the Big Picture...
-
Understand the nitty gritty details...
-
Define the underlying processes...
-
Get things moving / done / released...
Someone has to do it. There was still a development team that required me to:
ALL AT THE SAME TIME.
I was lost in that vast landscape. Product is hard.
I started to chart the oceans.
I decided to chart the landscape by walking every corner and drawing it on a map. My goal was to create a tool that could help me navigate my work as a Product Owner or Manager. I needed something that would allow me to figure out:
-
Where I am now?
-
What should I be doing next?
-
Which techniques can I use?
-
Who do I need to involve?
This is how the Product-Order Telegraph was born.
I took control as captain of the product.
I compare the Product-Order Telegraph to the throttle of a ship.
The ship's captain controls the throttle and can choose from different stages based on the situation ahead:
-
Stop,
-
Standby,
-
Full ahead,
-
Full Astern,
-
Dead slow ahead, and so on.
In older ships, this throttle was called an Engine-Order Telegraph and functioned as a communication device between the captain and the engineers in the engine room.
The throttle was not directly linked to the engine but was used to communicate intents to the engine room. The team of engineers would quickly respond by controlling the speed of the vessel: dead slow ahead or full astern.
The same comparison can be made when talking about product development. Place a handle on top, and you have got yourself a Product-Order Telegraph.
Something to communicate your product-intents.
I now understand where-I-am.
This visualization greatly aided me in comprehending and conveying the various stages of the product idea. It effectively communicated my intentions as product manager to the entire team. It is a telegraph, a communications device…
Additionally, it enhanced my understanding of the pace of product development. The choice to embrace speed and take a leap of faith became evident through this visualization. I could opt to bypass the testing stage and proceed directly to implementation. By making it transparent to everyone, I ensured visibility and awareness.
Similarly, I can now effectively communicate and initiate discussions about the importance of testing our hypotheses before proceeding further, pausing the rapidly advancing development process when necessary.
So, dear captain: what is the situation up ahead? And what will your next step be? Do you purposefully decide to skip some steps? Or go back a few stages, all for the success of your product? I was able to communicate this intent to the team, align the team with the next steps and speed up.
I now understand what-to-use-when.
Another valuable advantage of the telegraph was its ability to provide context amidst the multitude of techniques available. It allowed for a clear comprehension of when and where specific techniques should be employed, as well as how they interconnect with one another.
Placing techniques in context (when and where) helped me to understand them better.
I now understand the gaps-in-my-knowledge/experience
Most importantly, by charting the landscape, I could identify gaps in my knowledge and experience. I was able to create my own training program, specifically tailored to my needs.
I learned that I needed to progress through these 3 milestones:
Level 1: Be an Expert Product Owner.
I first needed to fully master the actual Product Owner role. I needed to understand the responsibilities and skills required to effectively lead a development team, control the inflow of work, and have a comprehensive understanding of how everything functions in the development process.
Think: User Story Mapping, Story Elaboration, Kanban / Scrum, Domain Modelling, etc.
Level 2: Increase Confidence before Building.
Once I have a firm grasp on the Product owner role, and could manage the inflow of work for a development team, it was time to learn the essential techniques for validating ideas, conducting tests and designing experiments. Here I had to learn how to move from a high level opportunity idea, to concrete, validated requirements. “Validated” is the keyword here.
Think: Assumption Mapping, Hypothesis definition, Experiment Design, Evaluative Research, etc.
Level 3: Establish Focus and Alignment
Once I had honed my skills in the Discovery phase, I needed to learn how to effectively communicate and articulate strategy, and how to translate this into actionable opportunities. And more importantly: how to set focus in the multitude of opportunities out their… Before doing all the solution-validation work from Level 2, I wanted to make sure that I was tackling the correct problem. The problem that has the highest priority at this moment.
Think: Defining a Product Vision and Strategy, Generative Research, Jobs-to-be-Done and Product Roadmapping.
You can use it too.
I hope that you can benefit from the telegraph as well. I have charted the domain to help you avoid the same mistakes I made.
Utilize the telegraph to
-
gain clarity on your current position and make informed decisions about your next steps (and communicate these intents).
-
understand and postion the plethora of techniques out there; and
-
choose a training path to follow and grow as product owner (or manager…)
