5 things that remote developers want Product Managers to know

Product managers: ever feel like there’s a disconnect between you and your remote developers? If you find that you’re struggling to work together effectively, it may be because your developers aren’t telling you what you really need to know about your shared and individual workflows.

I chatted with some remote developers in the Arc.dev remote community to find out what the top barriers to successful collaboration are – and what product managers can do to overcome them. Here are their tips!

1. When it comes to product planning, the more context and details, the better

Create a thorough plan

Developers aren’t mind readers, and product strategy may not be their strength. A loose outline will only result in a loose fit for your goals. The clearer the details at the outset, the less back and forth there will be later on, the less extra communication will be required, and the less time will be needed to redo what’s already been done.

While this is true for all engineering teams, it is even more true when team members are remote. Unless a product plan and product strategy are communicated clearly, there is no way for remote developers to just pick up on the information!

You should also inform the team of the reasons behind choices in features, styling, and workflow. This helps developers better understand the goals of the project and reduces friction between you and the team.

Try Miro’s product roadmap templates.

Prioritize tasks from the outset

You have your blueprint and reasoning ready to take to your developers – now what? Time to indicate which features are most important. Just as bugs are labeled according to priority, features need to be prioritized too.

Prioritizing features requires looking at each one in detail and determining:

• Importance of the feature within the system
• Number of potential users of the feature
• Development effort required to build the feature
• Damage caused by omitting or not finishing the feature
• How likely it is the feature will be omitted or unfinished

Each of these criteria may be assigned a number value, meaning their priority can then be expressed as a weighted number.

If you only give your remote developers a basic list where everything is tagged as high, medium, or low priority, then they won’t know which tasks to work on within each category. You’ll end up spending more time setting up conference calls and dealing with incoming messages from a confused engineering team.

Read more about prioritization frameworks for product managers, or check out Miro’s product management templates or prioritization templates for inspiration.

[rtb_inline_subscription id=”1″ size=”small” header=”Subscribe to learn more about product development” button=”black”]

2. Developers can only complete one feature or bug at a time

If everything is labeled ‘urgent’ it needs further prioritization

Labeling everything as “urgent” isn’t going to help you get work completed effectively. Developers will either start at the top of an urgent list, go in and pick which one they believe might be the most urgent, or pick the task they’d most like to do first.

None of these choosing strategies are going to align with what you really want. Instead, the number-weighted priority system shows your remote developers a clear indicator of which tasks should come next.

If priorities change, let your remote developers know

Priorities always end up evolving. However, simply updating them in your system isn’t necessarily going to catch a developer’s eye. Instead, you have to proactively let them know. This can be done easily with the right system push notifications (e.g. a Slackbot hooked up to your project management system, or a comment on a Miro board). You’ll also need an alert for “stop work on everything and work on this instead” – but this type of alert should be used as sparingly as possible.

Be aware that if priorities are constantly in flux, this will be frustrating and you will wind up with a lot of half-finished features.

Minimize overloading and changing priorities

According to the Stress in Agile Software Development: Practices and Outcomes from the International Conference on Agile Software Development, the ability to manage changing priorities is strongly correlated with developer stress levels.

While it’s possible for a developer to work on many different components in a day, only one feature or bug will be completed at a time.

Overloading or changing priorities often leads to frequently switching tasks, which interrupts a developer’s train of thought and boosts their stress level. The more task switching they do, the less productive they will be. Remember, developers aren’t machines.

3. Be thoughtful about communication

Show when you are available to chat

Let remote developers know your availability to talk – either on the phone or online – in real time. You can switch your status to online (or use a personalized message – e.g. “call or message me here, my door’s open!” ) on whichever communication platform you’re using.

If you aren’t clearly displaying your availability, remote developers may wind up thinking you’re never around. Ask developers to do the same so that everyone can communicate more effectively.

Define your availability clearly

In addition to showing ad hoc availability, you should also have fixed time slots for communications, so developers know when they’ll definitely be able to reach you.

When working remotely, we don’t all follow a regular schedule. However, remote developers do need to know some set times when they’ll be able to get in contact. Commit to these time slots unless you’re unwell or on vacation.

For instance, if you are using Slack and Google Calendar, you can connect the two with an app that syncs your Google Calendar event with your status.

Know when a quick call is actually a time-saver

Remote workers have a tendency to rely heavily on instant messaging to communicate –it feels natural when you’re already using a bunch of online collaboration tools. However, messaging isn’t the best choice for all scenarios.

A conversation of more than 10 lines on the same topic probably works better as a phone call. Make sure to send across notes of the call for traceability. This is also a chance to flush out any misunderstandings surrounding either what was discussed, or which actions need to be taken following the meeting.

Understand that remote developers aren’t available 24/7

Just because you’re having a brainwave at 12pm on a Tuesday, doesn’t mean your remote developer on the other side of the world is available to chat about it or start work. Just like you, they’re working on their own schedule.

Developers, like you, should have their own defined availability slots, as well as online statuses. (For more tips on this, see this post on the Arc Blog: How to Work Across Time Zones as a Remote Team: A Best Practice Guide.)

4. A continuous feedback loop is valuable for both of us

Set weekly feedback catch-ups

A Gallup study notes that managers who regularly meet with their employees almost triple their levels of employee engagement. The same results can apply to cross-functional partners, even when they aren’t direct reports.

Continuous feedback is valuable for both product managers and developers. Schedule one-on-one meetings with each team member to check in and see how you’re both tracking. Even if it’s just a 15-minute catch-up, it can help each of you glean insights into what’s happening at an individual level.

Since your developers are working remotely, these catch-ups can’t be left to chance — you need to actively schedule them, and ensure they happen.

Let’s be as courteous as we can to each other

If we’re frustrated, communications can break down more easily over text. Be courteous: if there’s a problem, have a video call to sort it out instead of amplifying the effects of frustration over instant messaging. Don’t let the frustration fester!

5. Dedicate time and money to keep the product up to date

Work on a basic upgrade of the product first

Legacy projects and technologies are difficult to deal with. This is one area of software development that product managers may not think about very often. “The product’s built, so it’s fine and good to go!” is not actually the case.

When libraries are updated, software patched, and API methods deprecated, it takes work to keep a product up to date. This may be beyond the scope of a product manager during the maintenance phase, but if you are given a legacy product to update, it requires work before more features are built or added to it.

Although focusing on user stories/features is far more exciting, if you start building new things straight away then there’s a risk of not having time put aside for refactoring, library upgrades, etc. If you have a legacy system, get it up to code first. While this can be frustrating for a product manager, as you want to get to work quickly, allow developers time to do this – and make sure you inform upper management why it’s necessary to do so. You can be your remote developers’ advocate here, while you work on fleshing out features and stories.

Wrap up

As a product manager working with remote developers, it almost all comes down to communication. Product managers set the tone for the entire team, so carefully consider your approach. If you bear these tips in mind, you’ll have a happy and productive team!

This article was co-authored with Debbie Chew, Senior Marketing Specialist at Arc.Dev