15 lessons learned working remotely for a Product Company

While working remotely is not suited to all, I've been really enjoying it, so thought I'd write up some of the things that I've learned about working on a product team remotely, both in terms of culture and working practice.

I've spent the last few months working on the design team at Prezly, a storytelling platform used by companies to easily publish newsrooms, blogs, galleries and more online to help people build audiences and reach their fans.

Prezly is properly remote - while technically based in Belgium, it's a team of 25 people based in 19 countries (mainly Europe, but also South America, Asia and Africa) across an 11-hour time difference! 😮

I'd had previous jobs that were full-time remote (and have written about remote working tips in 2014 and 2019) but I'd usually been located in the same time zone/country.

Nearly 140 days in, what have I learned about remote working culture?

1. One-to-one relationships are key.

Remote work often misses out on the water cooler conversations and moments you really get to know someone outside of a project context that you'd find in a traditional office environment.

Luckily for me, I started right at the same time as another designer when the company got together for its annual meet-up, and I had a great week getting to know people properly.

These initial bonds were invaluable in both making new friends, and learning who people were and what they did, enabling me to communicate better with them online and I've plans to meet up with colleagues soon to renew those bonds.

Suggestion: If you can, meet up with your colleagues at least once a year. If you can't, try and organise social activities online where you can get to know people better.

2. Meetings suck - have fewer of them.

Having worked in past roles that sometimes had 6 hours of meetings in a single day, I'm a firm believer that most meetings are unnecessary.

There's nothing wrong with jumping into Zoom for 5 minutes to iron out an issue instead of writing something up or running a workshop, but far too often 'traditional' meetings that are pure status updates with no clear agenda are often a waste of time:

• they are hard to document.
• they can torpedo flow or focus.
• they often don't have a solid agenda or outcome.
• they are often centred around a single person speaking.
• they aren't asynchronous - not good for lots of different time zones.

Prezly's approach is to default to text first and only meet when necessary, allowing people to read and digest things in their own time. The bonus is there's a searchable record of everything.

We use Linear (for shorter-form issue writing - great for nicely-threaded project-based discussions) and Notion (for longer-form writing). We also use a bunch of other tools (like Discourse) and even our product internally to document and present things.

Suggestion: If you have to have a meeting, set a timer. Have a clear agenda. Invite as few people as possible. End with an outcome that someone is in charge of following up.

3. Writing is Key...as are visuals!

As a result, writing well is very important. Get to the point fast if you can, but also ensure you set the scene and clarify to avoid confusion.

As a designer there's also a lot we can do visually - annotated screenshots help - a picture paints a thousand words.

Suggestion: Share your writing with others before sharing more widely, and ask for critical feedback.

4. Get good at presenting and recording videos.

I like recording asynchronous demos and talking through design decisions. I use a tool called CleanShotX to record video demos, which can then be posted elsewhere for people to watch at their leisure. The combination of a short video with dialogue and interactivity really helps.

Suggestion: Start on easy mode: If you aren't confident talking to the camera, start small and record demos for just your team and you'll soon improve.

5. Good tools are important!

We use tools like Figma, Notion, Slack, Linear, and Zoom at work. I use CleanShotX to annotate, make screenshots and record videos.

You don't have to be precious about specific tools - it's more about what works for you and your team and meets your needs.

I'm still a big believer in paper and pen - I keep a daily to-do list and write up all the tasks remaining at the end of the day for the next day - great for emptying your head and starting the next day right.

Suggestion: Shifting tools at a team level can be hard/downright impossible, but if you feel your tools aren't working for you, ask your social network what they use.

6. Turn notifications off and check at scheduled points.

Modern tools like Slack and email are great but are designed to suck you in - if you are not careful they can lead to a very interrupt-driven culture.

I've got used to the fact that unless it's an emergency, it's OK not to expect an immediate response - be mindful of others' time.

Suggestion: Try closing all distracting browser tabs you might normally have, silence notifications, and set a schedule to check for updates and notifications.

7. Block out your calendar and work when's best for you.

Despite a lack of meetings, I do schedule ad hoc meetings with people and encourage others to do so with me if they want to talk about something. I block out focus time when working on projects, allowing me to choose the best time of day for meetings, and letting people know I'm busy.

Working remotely is about outcomes and outputs, not presenteeism or the 9-5, So you can work at times more suited to you. I generally work a regular day, but usually start early as my brain works best then.

Suggestion: If you have a lot of meetings, try and group them so that your day isn't punctuated by them. It takes time to get into a flow state.

8. Err on the side of over-communication without being too noisy.

The more you can be clearer on the problem you are solving and desired outcome, the better framed your communication will be, but there's no need to write a novel. Be as clear as you can, and don't be afraid to ask for clarification from others.

The worst you can do is go away for weeks without communicating or showing your work.

Suggestion: If your tools allow, write regular status updates.

9. Work to fixed deadlines with variable scope.

I've worked on a lot of endless projects in my time, to which features kept being added. Without a time limit, there's always a better version.

The problem with this is that quality often suffers and QA and testing get left to the end.

As the saying goes, "Perfect is the enemy of done". We are experimenting using a methodology called Shape Up, which I'm loving, and have lots more thoughts and posts about coming.

There’s no absolute definition of “the best” solution. The best is relative to your constraints. The ultimate meal might be a ten-course dinner. But when you’re hungry and in a hurry, a hot dog is perfect. - Ryan Singer

Suggestion: Get things in front of others, get other viewpoints, think of edge cases, and be clear on what you are trying to achieve and what your appetite is given a fixed amount of time. What would you do if you had half the time?

10. Giving feedback and taking criticism is harder online - be humble and positive.

There are nuances to giving and receiving feedback that are often lost digitally, so it can be easy to misinterpret things for more than they are.

Suggestion: Learn how to give good feedback at the right time and learn how to take criticism well - it's rarely personal, and everyone is trying to make the best thing possible. Discussing Design is a great read.

11. Stand on the shoulder of giants - involve others.

I work with a bunch of crazy smart people, all experts in their disciplines (like Marketing, Customer Success, Support, Design, Development and Sales).

I try to keep learning from them, ask for their advice and get them involved where I can, as my work is invariably better as a result.

Suggestion: Get other folks involved in your projects early on, even at a high-level, as their perspectives often change how you would approach things.

12. You don’t have to build what the customer asks for.

We all know the misattributed Henry Ford quote about listening to customers and building faster horses. If you added every feature to a product someone asked you to you'll quickly end up with a mess. If you try and please everyone, you'll please no one.

Customers aren't UX or Design experts, so often not aware of what's possible. Collate feedback requests, and note when people start asking for the same thing. We use a tool called ProductBoard to highlight and surface feature requests over time.

Suggestion: Continuous feedback loops help you solve the highest-priority problems. Ask why, look at underlying pain points, and validate actual needs.

13. Get closer to the customer.

I am on a rota to help out the Support Team occasionally. This can be unnerving to start with for those not used to customer support but is well worth it.

Good analytics are important, but as a designer, there's nothing like seeing and helping customers first-hand with their requests to understand how people use things.

For the sake of a few hours every month, it brings you close to those you are designing and building products for.

Suggestion: Even if you haven't got time to work with your support team, block out a few hours to look at what gets requested regularly, and synthesize this information if you can into a high level overview.

14. Ship small and fast if you can, but make sure it's right.

The product will never be finished - there's always more to do. If something feels like an insurmountable problem, ask yourself whether it can be broken up into smaller parts you can ship and validate separately.

I loved 37 Signals Seven Shipping Principles:

Everything that goes out has to easily pass the dual questions of Is It Right? and Is It Good?

Suggestion: Ask whether something can be solved more simply. Sometimes simpler solutions emerge. Test edge cases, and see if others can break what you've made.

15. Get new hires looking at your product - fresh eyes are good.

Even when you feel you have a part of your product dialled in, set up user testing scenarios for new hires, get new members of staff to roleplay and try and walk through a process.

Get a few other colleagues to silently watch and take notes. I guarantee new ideas and improvements will fall out of this.

In conclusion...

If you are starting with remote work, I hope the above helped! There's still so much to do and for me to learn, and I'm learning new things almost every day. Got good tips for remote working? Let me know!

I’ve loved it so far and can’t wait to see where the role takes me - there’s so much potential in the product, and I’m looking forward to doing some great things with the team in the next 12 months.

While these are very much my unprompted thoughts, if the above excites you, Prezly is always on the lookout for good people, so keep an eye on their job board.

Credits: Earth image from Pexels - CC0