Lessons from the experiences of a hi-tech Product Manager
POs: Consider communication channel & Dev Team type [Product Management]
This article is part of a series on Product Management based on my experiences.
The Background
I’m a Product Manager + Product Owner at a mid-sized multi-national company. I came to Product Management from User Experience. In this series I share learnings from my experiences with the hope it can be of use.
Which Product Person works with Developers?
In broad strokes: Product department defines what to build, system architects define how, and development teams (in RnD department) actually build it. The role of the Product Department person defining what to build can be ‘Product Manager’ (PM), ‘Product Owner’ (PO), or sometimes both (PM/PO). According to the Scaled Agile Framework (SAFE), it is the Product Owner who works more ‘inbound’ (directly with development teams), and also defines more details about the product (user stories, acceptance criteria, definition of done), while the Product Manager is in charge of more strategic elements of the product, like a roadmap, and works more ‘outbound’ (with customers). In the Squads model created by Spotify, it is the Product Owner (PO) who works with the development teams. In many product management job interviews, they ask ‘do you work outbound or inbound?’ and ‘what percentage of each?’
What I discuss below relates to the Product person who works directly and regularly with development teams. My role is technically PM/PO, and my experience is in working directly with dedicated development teams who are ‘my’ teams. I work with local teams, and with remote international development teams.
Which RnD Person Works with Product?
On the RnD / Developer’s side, there can be various roles who are the main point of contact with the product owner. Developer teams of between 6 and 10 people are common in agile development environments. A PO can and does work with every single one of the developers on the dev team. In Agile the PO attends ‘dailies’ (short check-in meetings), planning, retrospectives and more. However, other non-critical meetings should be kept to a minimum, as they come at the expense of actual development time, which is a precious resource. Meetings that do not require all members of the development team are generally done with the representative or representatives of the developer team. This role can be the Technical Lead of the development team, or the Scrum Master of the development team, or both. Sometimes this is the same person. I know of startups (up to 100 people) who like to reduce hierarchy, and have not yet implemented any function of leader or representative on each development team.
Channels of Communication by team type
Other factors that change the relationship of interaction between the PO/PM and the dev team are the channel of interaction (on-site, hybrid or remote), and the type of dev team (front-end, back-end or full-stack).
Let’s explore these below, and consider how the PO should adapt accordingly.
Channel Type
On-Site/In-Person. On-site or in-person interactions are naturally more intimate. More than 50% of communication is non-verbal, and much of those subtle non-conscious messages are lost when interaction is through only audio, or through narrow window of remote conference software. On-site interactions include informal interactions — bumping into someone on the way to the bathroom, having lunch with a colleague, etc. This strengthens the intensity of the relationship: if you like someone, you’re going to like them more, and if you dislike someone, it will probably also be exacerbated. I’d say for on-site, the PM/PO has to work on giving her dev. teams space. They don’t want to feel overly scrutinized or micromanaged. A downside of this important and valuable interpersonal communication is that it can be at the expense of work- if you have a long conversation with a developer about her dog who is at the vet, then that time is time not spent developing. I am not proposing that we should be robots and deny interpersonal non-work-relation interaction; the opposite! I think it is important and valuable, and can also lead to better work. But I am pointing out that time is a zero sum game.
Remote. On the other end of the scale is fully remote channels of communication. It is harder to build rapport this way, and harder to know that the communication is effective. These relationships can tend to be more focused on the professional and less on the personal, since you only communicate if you have a concrete professional reason to do so. For this type of setup, I find it important to deliberately make room for the inter-personal and non-professional. It is easy to ‘forget’ that the person on the other end of the screen is actually, a person. And that they have a life, interests, problems — outside of the work you are doing with them. Of course, being a PO is no license to pry into the private lives of developers. But asking how devs are doing beyond work can at least invite them to share and connect, if they want.
Hybrid . It’s in between, and I view it as having the benefits of both — you can develop the interpersonal connection by seeing the devs in real life, and on days you don’t come in you tend to focus more on what is more narrowly professional.
Team Type
Front-end teams. The relationship between PO and dev. team also are influenced by what kind of dev. team. If a PO’s dev. team is solely front-end, then you will be sharing a lot of screens, and doing a lot of visual work, in order to communicate requirements.
Back-end teams. A dev. team that is solely back-end tends to be more technical, in my experience. The nature of the questions and interactions are going to be more technical. Here, though, even the most technically-oriented developer will appreciate when you view her as a person too, beyond her incredible professional skills.
Full-stack teams. Full-stack developers do both front-end and back-end, and I’ve noticed that this versatility can have some correlation with versatility of personality. Some teams, however, can be considered full stack in that they contain both front-end developers, and back-end developers. I’ve worked with teams who have back-end developers, front-end developers, and full-stack developers. These teams have very holistic views about products, and knowledge transfer and sharing within the teams should be encouraged, so that the entire team can gain that perspective. These teams can tend to be more independent, because sometimes the BE folks answer questions to the FE folks. While this is convenient for the POs, it create the danger that the answers are not what the PO intended according to the product requirements. So the PO has to work harder to be more involved and with her hand on the pulse.
Front-end | on-site. The benefits of this setup are the quick ‘let me show you’ conversations you can have. It’s really hard to communicate about visual things. When a PO has a front-end team and can go look at a feature in development on a local environment, and tweak ui together, the iterations can be much faster and more efficient than setting up a meeting and sharing a screen.
Front-end | Hybrid. Collaborative real-time with between Product and RnD can be saved until the days when they meet in person.
Front-end | remote. Often there are responsivity issues when sharing screens over conference software. Also, there are scheduling issues abound, especially when you have to schedule with some back-end developers from other teams. These scheduling issues can significantly delay development time, and often the PO has to work hard to push things forward.
Back-end | remote. It’s really important that POs are extremely precise and thorough in writing user stories for this setup. Of course that is always important. But when POs are working with remote BE developer teams, it becomes even more important. This is because if there is ambiguity or imprecision in product requirements, it will be harder and take longer to find the undesired outcome. As opposed to front-end when the visual error may be easier to catch earlier on, errant functionality may only reveal itself during a demo. By that time, changing the functionality may be costly. So as a PO, make sure it’s clear and what you wanted, and try to check in regularly to validate that you’ve communicated the requirements well. Additionally, POs have to put an emphasis here on communicating the business context, sot hat the back-end teams understand what it is they are developing, and why. Otherwise, they risk losing engagement.
Back-end | on-site. Here the PO has the ability to check in with devs more easily. Questions come up during informal interactions, so can be identified while it’s still easy to make changes.
Back-end | hybrid. Nothing clever to add here.
Full-stack | on-site, hybrid, remote. It would be fascinating if anyone was doing a PhD to research whether there are indeed any consequences of these factors, and the interaction between them (mode X team type). Until then, it helps to be aware of these differences, so you can find the right way to communicate with your team.
Thank you for reading.
About this Series
This article which is part of a series on Product Management based on my experiences.
About The Author
I’m a UX Designer turned Product Manager, with experience in startups, freelance, and agile B2B companies. Writing helps me reflect & continuously learn. Connect with me on Twitter.
