Whenever I get a chance I listen to some the excellent talks available on Mind the Product website. Over the course of past several weeks I came across three different talks about creating and maintaining a better relationship between the Product Manager and Development team. They also got me thinking about my own experience working with Dev for the past 7 years. Here is what I have learned:
Learn the Dev Language:
You do not need to have Computer Science or an Engineering background to be a product manager (although that can be helpful) but if you work with engineers learn to talk their language definitely earn their respect. Again I want to emphasize that you don’t need to be a programmer but you should have a solid understanding of software development life cycle (specially how the software is deployed and released), the technology stack, how the data flow from front-end to back-end through and back through different components (system architecture) and .
Read this excellent article from Brandon Chu on what he recommends to know about technology. Also I found this article from Suzie Prince about the Continuous Delivery and DevOps quite enlightening.
Build a Shared Understanding:
I talked about the importance of shared understanding among the team in my review of User Story Mapping book. As a Product Manager define in your user stories Who you are building for, Why building this feature or functionality is important. Although I usually come with a suggestion on What to build, I love to see what my team comes up with and if I find their suggestion more convincing than mine I change it. I try to avoid prescribing How the feature should look or function as I trust my team they can figure this out much better than I can.
All of this discussion happens during weekly Backlog Grooming meeting and after a couple of back and forth the ask is clear for everyone. This approach has been tremendously helpful to make sure what dev team is building is what I asked for.
Learn to Work Asynchronously:
I used to walk to the engineering section and tap on someone’s shoulder to get an answer to my question. I couldn’t figure out why I was getting hostile looks and short yes/no answers to my perfectly valid questions!! Oh, now I exactly know why they filled so pissed off! I was interrupting them the way everyone interrupts me now (karma!). And when you’re interrupted, you’re not getting work done. Interruptions break your workday into a series of work moments and you can’t get meaningful things done when you’re constantly going start, stop, start, stop.
The remedy is to learn to work Asynchronously. If your question doesn’t need a response NOW cancel that face-to-face meeting and send an email message instead clearly outline the question and highlight when you need an answer by. Now if you don’t hear back by the date indicated you have perfectly valid reason for the tap on the shoulder 😉 Another good trick I learned from Sherif’s talk on how to make decisions without having meetings.
Make that Decision:
Ideas and requests come from all over and one of the benefits of having a product manager on a team is that s/he makes the decision of what needs to be built “Now” as oppose to “in Future” versus “Never”. Developers need to always know that the code they’re working on now will deliver the most value and they need to focus on building just that. You are here to shield the team and you should be the single point of contact where ideas and requests internally and externally flows in. Listen to all ideas, evaluate them, analyze them and make an informed decision and stand by it. I will write a separate post on how to prioritize.
Agile Works (even if it sucks at the beginning):
Agile is all about teamwork and although it’s easy to get trained on principle of Agile in a day or two, working in an agile team at the beginning is hard. Like a lot of other newbie teams, My team and I had a rough start. Not only as a team we were trying to understand how to work and trust each other but also we were confused on how to build, test and demonstrate something small enough in two weeks time that provides value. Over time, it started to get easier when back-end developers tried front-end coding, hand-off to QA happened earlier. Automation testing happened. We wrote smaller stories and sized them during grooming meetings. We put a Definition of Done in place and soon enough the work didn’t piled up anymore. Bringing a culture of listening, self-organization and collaboration was hard but now with having agile values in place, the fruit is sweet 🙂
PS: Here are the talks in random order: A Product Manager and a Developer Walk into a Bar by Sherif Mansour , 11 Things your Dev team wants from You by Christin Gorman and Product Owners: How to Get Your Development Team to Love You by Ron Lichty