Leading a Distributed Remote Team Pt. 3: Internal Tools and Processes.
What are the processes and tactics for collaborating with a remote product team?
Today we’ll talk about the processes and the tactical side of leading a product organization completely remote. We’ll discuss:
- The tools: I’ve used as a product manager;
- The Journey: The why and how we decided the tools, and how we adopted them.
- The Key Lessons.
This is part 3 of Leading a Distributed Remote Team:
Leading a Distributed Remote Team Pt. 1
How to lead a distributed organization? What are the challenges of product management working with a remote team?
What tools have I used with Distributed Teams?
If I had to categorize the tools by area, then like any other company, there are 4 main tools you need as a product manager:
1. Tasks & Todos: Product/project management.
2. Wiki: Documentation.
3. Communication: Messaging.
4. Scheduling: Meetings, agendas, calendar.
I’ll focus on these areas because they’re related to the product team. We also used also Hubspot for Sales and Intercom for customer service.
When I joined Paybook we were using:
Slack + Google Cal + Jira + Confluence.
We realized Jira and Confluence were too robust for our needs. So we moved to:
Slack + Google Cal + Asana + Google Docs.
We operated like that for a year and a half. Then we moved to Notion.
Let’s focus first on the Asana setup, then deepen into Notion.
The Product Development Structure
I implemented this process first with my team and then trained the other product manager to implement this across the company.
As the product team, we would hold Weekly Stand-ups, plus the follow-up meetings. 80% was written, 20% was meetings.
The team I led were:
- 2 Frontend Developers + 1 Full-Stack
- 1 Backend Developer
- 2 Designers: Mobile UX & WebApp.
- 2 Mobile Developers: Android & iOS
For the product marketing team, I had a weekly standup with the PM and the head of marketing. We would review the board and sync-up for the week.
Asana + The Other Apps
The approach we took was to centralize everything around Asana, the goal was to reduce the number of tools. The fewer tools to maintain the better.
Therefore, we integrated all tools to Asana.
Tools & Processes
Purpose: To have a place for everything. From roadmaps to sprints, to tasks. Merging all the company’s tasks under one place.
Who used it? Product, Design, Engineering, and Marketing/Customer Support.
How? We used it in different ways. I can actually write a whole post about using Asana as a product manager. Let me know if you are interested down below.
In general, we used Asana:
- To have a public product roadmap;
- Track Bugs from different sources;
- Visualize the interconnected projects; and
- Product Development for spring planning.
Asana became the source of truth for the product team and the rest of the company. We integrated different tools for different utilities:
Usersnap: Usersnap is a bug tracking & feedback tool. Incoming bugs created a ticket in Asana in a Board call BugBash.
That ticket was automatically assigned to the Product Manager and also added the customer service (“CS”) agent as a follower.
Then, the PM added the ticket to her board by assigning it a workspace tag. From there the PM can prioritize it with the rest of the backlog.
The CS agent would get notified any changes automatically by following the task.
We also integrated Asana to Slack, each new bug from UserSnap would send a notification to Slack. The Slack + Asana integration allowed us to make any changes to the tickets directly from Slack.
As the PM you want to source requests and ideas from all stakeholders. When you are in an office getting ideas is a bit easier. You can run into someone, or by being in a meeting, new ideas will come out.
When you are working remotely, as a PM you should set up a process that helps source new ideas. Doesn’t matter the time, or the location.
I’ve used this process before at Payclip. Even though I was on location, we had distributed offices in San Francisco, Utah, and Mexico.
The purpose is that anyone can add ideas to the roadmap. Then I’d prioritize according to viability, feasibility and desirability of our north-star. After that, I’d call for a meeting to present my suggested prioritization, and by consensus agree on the roadmap.
Anyone could add ideas by:
- Creating a ticket on the Asana Board, in the Ideas Column with a template; or*
- GoogleForm / Airtable Form that automatically creates a task in Asana in the same Ideas Column.
If you take option 2, then you need to use Zapier to automatically create a task to Asana.
My experience is when using option 1 a lot of people would write on the Asana Template, instead of duplicating it.
So option 2 is better, all questions are mandatory in the form. This forces them to think and elaborate on why we need the feature.
*Asana has a new feature for Forms, I haven’t tried out.
Roadmap & Sprint planning
For strategic planning, we’d gather as a team to create a High-Level product roadmap on Google Hangout. After a long discussion, together we’d arrange the ideas in an Asana board called Roadmap.
As the product manager, you must come with a plan, a vision, and an agenda.
If planning is hard, doing it remotely in a conference call is even harder. People get tired, and after a while, the team won’t participate.
I suggest defining your product attributes. This will help you prioritize in moving the meeting in an efficient manner.
It’s a balance between the vision, the goals and the problem you are trying to solve in relation to whatever you want to build.
I recommend you to read the IDEO Innovation Framework. You can use the following framework as an example.
Should you use this approach? Yes.
Would you recommend Asana: Hell Yeah.
Asana is a great tool, I love Asana I’ve used it for a very long time.
There are some challenges, but they around product development e.g. archiving tasks. Not related to distributed teams or remote work.
The only issue I had using Asana in relation to distributed work was a high-level summary. (Applies when reviewing things asynchronously)
Let’s say the CEO wants to know where we are with Product. That’d require her to go to the sprint board, and see the individual tasks.
There’s no simple way to get a general overview of what product, engineering or marketing are working on Asana unless reviewing the tasks.
If you want to know from a strategy standpoint where are we standing, then the PM needs to update the roadmap board in relation to the sprint board manually.
There’s no easy way to connect everything, and automatically update the high-level board with the low-level operation.
I’m thinking more like:
OKRS > Company Mission > Objective > Team Mission > Objective > Tasks
The way to solve this was by doing manual reports and sharing them on Slack. Asana also has a progress tab on each board, I didn’t use.
Asana + Google Docs
We could’ve used Asana + any other wiki, but by using Google Docs it kept us in the Google ecosystem for Google Cal so fewer screens/apps to go to.
Purpose: To have a wiki and collaborate for defining the product requirements.
Who used it? Product, Design, Engineering, and Marketing/Customer Support.
How? We divided the documentation by area: Engineering, Product, Marketing etc. For example:
The Product folder would have Sprint 1.0. So the Marketing folder had a shared folder for the release content for Sprint 1.0.
The Collaboration Process.
Internal Press Release
How Amazon Internal Press Release change my approach to product management and product development.
Note: We would create a task on Asana: “Review / Read document XYZ” and assign it the stakeholders with a date.
The process was pretty simple. We uploaded the templates on Google Docs, so anyone could go to the Project Folder-> Create from Template, and start working.
Should you use this approach? No. I don’t know why I suggested approaching documentation by Area: Marketing, Product, Engineering.
It pushes the areas to be too siloed.
You should tackle things by themes or products which we did later e.g. Retention vs growth.
Issues and improvements:
Wiki View: The biggest problem (the main reason why we moved to Notion) it was hard to see the document’s hierarchy and path. Finding documents took time because Google Docs wasn’t made for Wikis.
Lack of Integrations: The design team started using Figma, so we included the URLs in the PRD to see the mock-ups, whereas Notion allows an embedding view, this can’t be achieved on Google Docs.
Comments: The sidebar was crazy to manage when a lot of people commented or added suggestions to the document.
Also, permission and controls are limited. When working with a marketing agency, they’d share a folder, and you couldn’t access it because it was created on their domain.
This would affect efficiency, I’d had to wait until they wake up to have access wasting 5 hours in the meantime.
Would you recommend Google Docs: No
Moving to Notion
Even though we had a cadence tackling tasks and projects, there was something missing. We had documentation debt. The main reason was Google Docs plus how we collaborated as a team
We got into the habit of discussing everything on Slack, so a lot got lost in the abyss. [So dramatic…], the items we’d discuss were:
- How to solve problems, from technical to marketing solutions;
- Specs and requirements, what are the use cases?
- New ideas from pricing to product features.
You’d think, fix it with a process, and move the conversation to a document. But if everyone is on a flow state on Slack discussing something.
Would you let the flow continue or try to move the conversation by interrupting it?
So I thought, how inviting the platform is for collaboration? If the main objective of the tool isn’t collaboration, then no process will be enough if the tool was built with different behavior in mind.
It appeared to me, that Google Docs didn’t motivate the team to update the documentation. Everything was revolving around Slack + Asana.
The journey was like this, we’d kick things off on a Google Doc as I mentioned above. The documentation started very well but then no continuous iterations on the document. We’d just go to Slack and open the discussion.
There were times that things got worst, we’d have several versions of documents in different folders I’d try to copy paste conversations from Slack to Asana Tasks, or to the document, but it wasn’t scalable.
So I decided to give Notion a try because it has a lot of potential. It tackles the challenges that I mentioned above, such as:
- Conversations + Comments
- Wiki + Tasks
- Tables + Boards + Calendars
I believe if we kick things off in a more conversational and collaborative tool like Notion it should improve documentation debt.
I must mention that, we didn’t move product development to Notion, we’re using it just as a Wiki and planner.
Now by using Notion, we can see in the same document, the:
- Mocks from Figma;
- Loom to see to see interviews;
- Code snippets ;
- Calendar & a Table assigned to testers with future releases.
Plus, Specs and requirements.
Key Lessons: Processes for Remote Work
My main takeaways are:
- Be Public: The easier the access to a document the better for everyone. Give access to everything and to everyone. Be public asynchronously.
- Be Repetitive: For any new process, repeat the process, point out what document you are referring to.
- Be Clear: As a remote team, you should leverage different working times. So be clear, and don’t leave space for assumptions. You don’t want people starting to work in the wrong things.
- The Less the Better: The fewer tools and the more consolidated everything is then the less cognitive load.
- Enjoy it.
Tweet me on DanielYubi, for feedback, and to geek out any of the above subjects. 🤝
Note: Airtable & Notion are affiliated links 😄