Plum Development Diaries, Episode 02: Do’s and Don’ts

We’re a building a work management software for remote workers and we’ll be sharing details of the development process with our community. If you want to know how it all started, just check these blogposts before you move forward:

Introduction: We’re Building a Tool For Remote Workers

Plum Development Diaries, Episode 01: Why Build This Tool?

Image credits: Sebdeck

What should we do? What should we not?

Plum is being build very laterally within our team. Everyone is a planner, everyone is a creator. We need Plum to, first and foremost, work for us. So it’s important that everyone feels comfortable to share their needs.

Of course, this mostly lack of hierarchical creation process means we’re going to disagree. A lot.

In the absence of a big judge slamming the hammer, we need to establish some general guidelines that would help us coming up with decisions faster and precisely.

With that in mind, one of the first things we decided on was on filters.

If we’re having a hard time coming up with an agreement, we let the filters rule out.

As an extra bonus, our filters rhyme! Here they are:

Simplification, Facilitation, Automation, Initiation, Limitation, Conversation.

So let me show our filters in details, and some of the cases we ended up needing them to come up with the decisions.

I’ll break it down in two different posts for a lighter read.

Simplification

Make It Simple.

“When presented with two or more options, go for the simplest one (shorter, easier to understand, less clutter, less options, not ambiguous”.

Right off the bat, we wanted to build a simple application. Simple, but not simplistic.

The idea is that we always aim for features that solve complex issues but are simple to use.

Most often I hear phrases such as “software X is easy to use after you put many hours into it”. Well, that’s practically an oxymoron, right? If it’s easy to use, you don’t need to put hours into it.

When the team discussed about what status we should have for tasks, we were thinking about cases such as “what if I was assigned a task but in the end I couldn’t finish it because of technical issues?”. This led us to consider status such as unresolved, can’t do, etc.

After applying Simplification, we understood that it doesn’t matter how many status options we offer because all of them will carry one of this three characteristics: it was worked on, it is being worked on, it will be worked on.

So there you go, let’s keep it simple:

Facilitation

Make It For Beginners

This is not a tool for highly technical engineers only. It’s not a tool for experienced project managers. This is for remote workers in need of a tool to help them do a better job. And yes, some of them – maybe a lot – are beginners in managing their remote life.

One of the biggest difficulties for us on the development side of things is that we end up getting used to our own ideas. After several months or years with the same tool, we end up losing track of what is an intuitive feature to understand and use, and what is just us comfortable with something we used for a long time.

That’s why Facilitation is here, to keep us in check that there will be people using Plum that have no idea of our long discussions and ideas behind what we’re building.

For example, we discussed what kind of progress tracking and project management features we would have to schedule and track work done. But instead of relying on project management science to dictate what we would use, we simplified it to a point where a very inexperienced worker can easily organize, schedule and track the progress.

Instead of asking our users “do you like to use an Agile management, or perhaps program evaluation and review technique?”, we just set a simple and effective interface and let our automation – which we’ll explain afterwards – do the work.

Automation

**Make It Self-Reliable

The software works for the user; the user won’t work for the software. Constrain customizations, have less options and necessary steps and inputs. Ask very little from the user.

We don’t want to build the kind of software that is always asking an extra click of the mouse, an additional pop-up tutorial to explain things, a “complete this field otherwise it won’t work” kind of setup.

It’s easy to just add extra fields and extra options and expect the user to learn another rule and fulfill that rule. But the hard truth is: it’s not easy at all to keep users engaged if we keep asking them to do more.

That’s why we’re aiming to automate processes as much as we can.

For example, we created a section that we’ll temporarily call My Workspace. In there, you can see things such as the tasks you have scheduled on your week, or a space to write down important announcements to share with your colleagues.

Before Plum, the team used to write down every single week on a shared document what we were going to work on.

Instead of going that route, Plum is taught to collect the My Workspace information and aggregate them all in what we temporarily call My Organization. So the whole team is accountable, sharing their workloads without having to waste time writing it down so that everyone else can see it.

So next time you are using any software and it asks you do something, try to think of Automation and how your life would be better with it.

This was our 3 initial filters that are guiding us now. Come back in a while to learn about the rest of them, follow us on our social media (Instagram, Twitter) or sign up to our newsletter and we will let you know when it’s ready!

The post written by Geraldo Figueras

Originally from Brazil, living in Tokyo since 2017. Remote worker since 2012. Favorite thing about remote work: My 5 seconds commute from desk to couch when work time is over; being able to crank up the air conditioner as I see fit.