Important trait of PM while communicating with Engineering
I came across this TED talk (https://www.youtube.com/watch?v=qp0HIF3SfI4)by Simon Sinek long time back but I was able to appreciate it more deeply as a PM. His golden circle framework of three concentric circles of ‘Why’, ‘How’ and ‘What’ gave me lot of insight during my grooming sessions with engineering teams and helped align them with same vision.
WHY
During grooming sessions, I start with ‘Why’: why are we developing this product/feature? why would customers need this product in their lives? I don’t talk about the feature set or show prototype without explaining customer problems. Over a period of time, I realised that the better understanding I have about customer and their problem, the easier it is for me to explain ‘why’ to engineering and other internal stakeholders. I have seen smart engineers asking me ‘Why on earth are we building this?’. Communicating ‘why’ part of product development to engineering team is immensely important:
- most of the time a PM is closer to customers and engineers get second hand information of customers from PM (agreed, that during some product discovery sessions engineers are present). Without proper understanding of customer and their pain points engineering team will not be able to come up with right solution.
- explaining ‘why’ of product development gives an alignment to the teams. People function as vectors in a team — our work has both direction and magnitude. When people all work in precisely the same direction, their magnitudes are added to each other. When people have any degree of deviation, the varying directions subtract (at least somewhat) from the maximum amount of productivity that could be achieved. I have noticed that teams think and work in same direction if they are explained ‘why’ part clearly.
While I was working on barcode scanning feature in our mobile app (B2B product), I started off with an use case to explain ‘why’ part: “Jane (user persona) currently uses a handheld scanning device that emits infrared signal to scan barcodes on back of assets. After scanning is finished, the barcodes are saved in a spreadsheet, that spreadsheet is manually uploaded in system and then Jane’s manager will get to see latest asset attributes. This is definitely not a great real-time experience.
Apart from being non real-time experience, this process requires a good amount of Jane’s time to set up handheld device.
Do you guys think that we should solve Jane’s problem by giving her similar functionality in her phone so that her life becomes easy?”
WHAT
Once teams are on the same page on ‘why we should develop this product’, I start ‘what we should develop’ and skip ‘how’ part. UX designers and I run thorough clickable prototypes to show how solution would look like. These clickable prototypes are result of product discovery sessions with customers. When I draw the boundary for ‘what we are going to develop during this release cycle’, essentially I define scope for product.
Taking the barcode scanning example, at this time, I showed engineering teams what the end product should look like with complete user journey: new user role, scanning screens, update buttons, filtering options, etc. As I had explained ‘why’ part earlier, teams were already empathizing with user and trying to verify the solution from user’s perspective. Engineers came up with important scenarios that were missed out during prototyping. (‘What happens to those scanned assets if user logs out without taking action on them?’)It helps in brainstorming the right solution.
HOW
I don’t spend much time on ‘how we should develop this’ i.e. the technical feasibility. Engineers are smarter than PM to weigh technical solutions, especially when architecture, tech stack related nitty-gritty are involved.
Coming from a technology background, I know what engineers think of PM :)
Continuing with same barcode scanning example, engineers decided how to make API calls to fetch data from backend and how to make it configurable for customers. Configuration option is a must for B2B products; each organization have their own way of defining asset management database and storing asset data.
At the end of grooming session, I am able to:
make engineering teams resonate with customer problems — ‘why we should develop this’
draw a (fine) boundary, based on time and other constraints, of ‘what feature set and functionalities we want to develop’ and their UI/UX
give engineering a free hand approach for ‘how to develop this’ and I keep away from stepping on their toes.