5 principles to build engaged distributed Product teams
It’s no longer a secret that splitting product-related activities; requirements, user stories, refinement, ceremonies, decisions, artifacts, etc., among Product Managers, Product Owners, Requirement Manager or Scrum Master (to name some), is a practice that is gaining some ‘popularity’ when it comes to remote teams work. However, how pragmatic this approach could be, it demands other actions behind the scenes to ensure successful product delivery and to deliver the right product to your customers.
This is the reason why I felt like sharing some insights taken from my last experience working with Product Teams outside my own organization. I’m not saying that the points below are applicable in all cases, but perhaps, they can serve you as an example to build your distributed product team before jumping into storming phase and push the ‘Panic Button’ on.
Establish the ‘1-team’ figure
Before assigning roles and responsibilities, and then rushing to produce a bunch of documents or tasks, I found crucial for the success of your product, to get all the players in a single forum to discuss -and agree- why we are working on this product (or project), what it’s the ultimate value, what are the general details of the business need, etc. Furthermore, it will be useful to set some basic ground rules and parameters in how, from the individual outlook and work, we all will act as a ‘single voice’ across the stakeholders; aiming to close gaps in how to react when questions or problems arise, or simply to prevent them.
Let me set an example, imagine there is ‘Company A’ working on the back and front-end development, whereas the UX/UI is driven by ‘Firm B’, now, these two parties are working for the main Client. In this model, we have a clear split of responsibilities and scope of work. However, this is not a reason why the Product Owners at both ends can’t be aware of one another’s work or progress in front of the client in terms of Product knowledge, status and direction (joint roadmap, vision, backlog). Hence the need of acting as a Single Product Team comes into the picture, which happens by constant communication between the Product Managers (or Owners) regularly, building a shared understanding around all the product aspects. E.g. in the eventual case that one player is not available, the topics can be covered in one way or another, at least at a high level by the Product Team.
Be careful though, like an old popular saying from my country reads: ‘Between firefighters, we do not step over each other’s hose’ is strictly applicable for these cases. Always mention that you are providing some details in response to your counterpart absence and will be validated at the earliest possible time. In this way, you’re providing a sense of unity and synergy among the Product team, which might cause a positive effect on the person who you’re addressing.
However, this kind of situation brings another piece to the Product Team puzzle.
Create a common language
…by common language I’m not referring to English or a programming language. It means getting all the semantics and terminology clear as possible, in this way, do not confuse or mislead the team members by subjective understanding about what the Product Owners meant when talking about X or Y functionality.
Another critical aspect to keep in mind when building this ‘Language’ is not to assume that a word, term or abbreviation is obvious and has only one way to be interpreted. For instance, in one of the projects I worked for, our extended client’s Product team had issues understanding what our designers will deliver at the “wireframing” stage, and what will come within the “mockup” stage. Because of this misconception of terminology, the project had setbacks, and the regular course of action got disrupted, causing a reshaping of what and how things will be delivered to the development team.
The takeaway of this situation is very straight forward: invest some time in creating a language that both you and your Product counterparty understand. It is not a one-time exercise, so be prepared to reiterate over and over again the meaning behind the terms, abbreviations or names used across the project, don’t get frustrated, the payback will be worthy.
Play around a common Endgame
Once you have built the foundations of the ‘One Product Team’ mindset, which speaks the same language, you’re off to make things happen by rolling the ball to achieve that ultimate Endgame, however easy to say; you might need to work on that from several flanks.
First of all, the team must have a clear picture of what the Endgame is:
· delivering a brand-new product
· enhancing the experience of your current users
· revamping an existing solution, etc.
Knowing the direction, we are aiming to go and what lays behind that goal is the key to success. In this way, the decisions made by the Product team will orbit -as well- around how we can make our product ‘future proof’ (instead of only focusing on the immediate needs to resolve).
Additionally, embracing the common Endgame will increase the Product team confidence in driving discussions from all angles regardless of the audience, without entirely relying on a technical or design lead -when not available-. Thus, bringing alternatives on the table on time that can be further considered, validated or adjusted by your extended team.
Lastly, don’t be afraid to be the ‘Bad Cop’ in front of your team or even the stakeholders, when you have a clear picture where the Product must go, you will feel comfortable saying ‘No’ when needed. This level of assertiveness can be only developed knowing by heart the ultimate goal, that Endgame you’ll be preaching over and over again across your teams.
‘Enable’ each other
You can’t make it all on your own, regardless of how much of an advocate of your product you can be, how much exposure or experience lays on your back, you will need support from your extended team, same as they will need you. That’s why you better be conscious about your essential role in the game; to be your team ‘Regista’ (if I may use some football terminology here).
Being a ‘Regista’ only means that you will steer, control and bring the Endgame to life by enabling others to ‘play’. It happens by combining what we have been talking:
· knowing your Product,
· setting the right requirements,
· speaking the very same language,
· shielding your team from unnecessary work -or meetings-,
· covering each other’s back when needed,
· not contradicting your fellow Product Managers (or Owners) in open forums,
· maintaining that ‘One Product Team’ mindset all across the Product development cycle,
· educating your teams about the decisions made (functionalities, navigation paradigms, user journeys, edge cases, alternative scenarios, etc.),
· keeping the ‘Why we are doing this’ alive at all times,
…and the list can keep going. You will learn how to identify what is relevant for your teams.
Ultimately you will be enabling your team to work towards the Endgame, by placing your Product Team in the front line of the development; meeting stakeholders, writing down user stories, making decisions, setting the baseline of your product, to name some, and then, passing over the relevant information to the team, without disappearing from their sight, but instead, be always present in one way or another.
Tailor your messages
Lastly, I would like to highlight the importance of tailor your messages across the team, and this goes closely tied together with the common language mentioned before. Bear in mind that nowadays, distributed teams are no only based on a single geographical location, this figure implies differences beyond that: sex, religion, background, education, etc. For this very reason is vital that you know your team’s composition and tailor the way you communicate with them, and this not only applies to your direct Product counterpart but the whole extended team.
Identify the preferred and most effective way to cascade a message or to communicate regularly, perhaps a face to face meeting, a quick call, email, a workshop, IM, JIRA/Confluence, etc.
The technology had close all these gaps with a vast number of alternatives, and part of your role as Product Manager is to utilize the tools and tailor them to increase the contact and touchpoints with your team. Do not be afraid to experiment, nor to fail, but never stop trying and most importantly, do not lose touch with your direct and extended team, the success of reaching the Endgame relays on the ultimate team trust and spirit that is being built in the process.
—
Some final thoughts that are worthy of sharing since they are applicable all along with your teamwork:
-Time management across time zones; be mindful with your colleagues, stakeholders and with yourself.
-Be available; setting a personal approach in how to work with your peers is valued by everybody, block in your calendar some time in where you’re fully available to answer any query or discuss a pressing matter. Answer your team emails as soon as possible, reserve your time to work (and to take rest too!), etc. when you do this systematically, your team will get used to, and the cooperation will run smoothly.
-Involve key team players for the decision making; yes you know the product, yes you know what the Endgame is, but you might not have all the answers when in doubt, do not hesitate to reach out your SMEs, team leads or business representatives to move things forward.
-Map your stakeholders; key people in your project might come and go, that’s why is essential to keep your map up to date, keeping details such as name, email, location, role, and a brief description in which cases this person might be the right one to contact. This will ease the involvement of the key players when needed. Be mindful though about this map, share it on a ‘Must Know’ basis.
-Limit your team’s involvement in meetings; ‘yet another meeting that could be an email’ is a real thing. You as a Product person should be in the capacity to assess why a particular team member might be needed in a meeting. Avoid pulling all your development team to meetings that do not bring any value for them, as well, minimize the topics for a single meeting and keep the communication flowing all across the different levels.
