What is the structure and frequency for how you go about engaging with engineering team?
I notice my scrum teams significantly lack this in the past. There has been mismatch in engineers understanding customer pain points or visualizing the impact of their work on the product roadmap. Largely because (1) I have been busy - not that it is an excuse but I work with 3 teams and had no help but this won’t be a problem anymore (2) the most we had would be 1 show n tell on product vision. (3) we are an internal product that’s at the end of work life and not used by internal users but by internal systems so its all web API that send stuff our to external world.
Please share how you go about it. I think this is a pretty big gap and need to address it at leadership level. There has to be a consistent discipline to it. Thank you for your help.
Firstly let me say that being a PM on three teams is the primary issue here, I can’t see how I’d be able to focus on three different teams when one is already a challenge. That said…
I’ve been doing product management for several years and I personally don’t treat vision and strategy differently from other types of product development teams. A “show and tell” is the first indicator to me that this is not a cohesive and tight team. The PM, engineers, and designer (if applicable) all need to build this together.
Every team has customers – whether they’re consumers, other businesses, internal users, or developers. Your PM needs to focus on their problems and build a vision from there. This doesn’t have to be complex stuff. Assuming your customers are developers, simply talk to 5-10 of them and get a sense of their biggest problems – what doesn’t work about the internal systems. Once you have a bunch of quotes/problem statements, you can write up a simple vision statement from here by thinking what the world would look like if you solved their problems and made solutions that are even better than what they can even think of.
I regularly have sessions where I ask our users to show us (including the engineers) how they use our tools. We see their pain, build empathy, and simply want to improve their lives. This lets the team buy into the vision even more. As long as I tie achieving this vision to business impact (e.g. reduce investigation time by 20% or improving developer productivity by 10%) then it’s simple stuff.