Another day in the life
Some people describe product management as being the Conductor of an Orchestra. Even without the soft name, the business trusts us to create high-performing teams that can work towards a shared goal. It can be cha
One of the challenges we face as PMs is that we often have to lead by example. We don’t have authority over Engineers, they report to the Head of Engineering and we definitely don’t have authority over the UX team either. In actual fact, we are constantly having to work with our stakeholders to really get access to customers and win games (that’s competitive speak for get results).
I remember the first time I jumped on a refinement video call with a new development team I had been given to work with. I had nerves of steel but I sounded confident AF! I managed to answer all the questions that came at me...but the question is why did I feel for a moment like they were ganging up on me?
What Engineers value in good product manager is a clear direction of what the team should be working on and particularly why. There is nothing worse, irrespective of the role, of working on something without fully understanding why you are doing it in the first place. Over time I’ve come to realise it’s okay to not know everything. The biggest challenge is getting the C-Suite to understand that which is easier when there are strong Product Leaders who can go about creating a culture of experimentation.
Create a shared understanding
It’s all good thinking you have all the answers when you first start. But you’ll quickly come to your senses when you 2 weeks goes past and you realise that the development team just “built what you asked”.
We always know what we can plan, but we never know what we will discover
For me that’s low-level, and you don’t build great products that way either 🙅
One way that I that I tackled this was by repeatig boldly:
Shared documentation is not shared understanding
Servant-Leader
Even when you are not in the C-Suite, you have to reinforce this regularly. This is why I think great PMs are empathic and seek to understand things.
I worked with a Head of Engineering who created the Pre-Refinement meeting. This doesn’t even exist in Scrum! 😂
What he was doing was trying to stop was PMs moving unfleshed out items to the top 10% of the backlog. He advocated that we bring in technical consultants i.e. Tech Leads in when we wanted to clarify what we were building so that they were fit to take into Refinement sessions with the wider team. At refinement, the engineers can scan through the tickets and give estimates.
Good estimates come from engineers who really understand what they are estimating
Whenever I am creating Product Requirements or going to Refinement meetings it's a question I have to ask myself. I have found that sometimes it requires me to probe my team for inputs. I might say something in the Slack channel like, "this is what I think, but I am sure I have missed something".
It is through Ken Norton's work that I have learned this mindset of bringing the donuts.
When engineers give you big story points, its because there is less predictability. I can always tell when certain Engineers understand the what to do. There was this one Engineer (let’s call him Dave). Whenever he understood a story he would come with questions.
