Product Development June 30, 2020

It's official: either I get a mentor to help organize my remote software development team or ....

Dima D @DimaD88

Help! Help! Help!

I posted earlier this week about the most effective product development tools. But as my team got to work, I realized it's not the tools that are scaring the schnitzels out of me. It's the process itself.

I don't know the best practice for effective workflow management of a remote team.

How do you ladies & gents organize the workflow of your team?

I have a team of a full-stack engineer, UX/UI designer, and a copywriter.

  1. 3

    It's so weird to see 13 comments, and almost nothing about the most important part of workflow - the time part.

    I searched for the words "sprint" and "day" and "week" and "month" :)

    You can have a rhythmic workflow, using sprints or weeks or months.

    Depending on the timezones, you might want a daily cycle. At least for some days of the week.

    You'll want to consider your team's preferences. But most professionals appreciate if the principal lead declares an initial plan.

    Your roadmap looks pretty lumpy. You could do agile-y things to break the lumps down so they fit in a rhythm.

    That's what a workflow process means to me, anyway - the part that aligns with the dimension of time.

    1. 1

      Thanks Lloyd! Yes, clearly need to set the "time part".

      Is sprint = development cycle? I.e. can I just set the development cycle for my team for two weeks = sprint of two weeks?

      And then I have daily updates with my team on progress/limitations/roadblocks?

      When you say lumpy roadmap - what does that mean? The items are not broken down enough? There is no prioritization?

      1. 1

        You are correct! Sprint == development cycle.

        Two-week sprints are pretty standard. And daily or twice-weekly standup/status meetings

        Wrangling those meetings is a whole art :) Keep them short.

        When you say lumpy roadmap - what does that mean?

        The "Difficulty" field is empty for a lot of items.

        There's a recent IH startup that's all about nicely dealing with difficulty levels.

  2. 2

    There is a good amount of knowledge in these pages that might be of help to you:

    1. 1

      Awesome! Love such knowledge bases.

  3. 2

    Don't sweat it! It will take time for you to find your groove with managing a remote team, because culture plays a big part. No two teams are the same.

    I've been working in fully remote teams for years, and used to run a web dev agency that's fully remote, with members in Asia, Europe, Canada and LatAm. I was always the client-facing project lead so I was the "process guy". The challenges are usually with the humans, not the tools :)

    There's some excellent advice already here, but FWIW, here's mine, based on what I've learned along the way:

    1. Definitely start with a process but be prepared to bin it and recreate it regularly. Almost daily at first, but it'll start being less frequent as you find elements that work.

    2. Encourage over-communication. Write more than you think others need, and encourage others to do the same. Look at what you've written and check if there are any hidden assumptions in it, before sending it out. If there are, clarify them. Unchecked assumptions are mini time bombs in remote teams.

    3. Have team video calls to keep the team bond fresh. Maybe once a week at first, then adjust the frequency according to how everyone feels about it.

    4. Have one single place for the project's home, so you and your team know where to find things. I tend to use Trello for it because it's easily customisable according to the team, and easy to reconfigure along the way. I usually have one space for workflow and another for resources (eg, URLs, file locations, documents, etc).

    5. Since your team is small, I'd keep the product workflow simple. I'm not sure what stage your business is, but if you're still starting up, your focus should probably be speed rather than over-optimising for quality. Be careful when reading tips made by larger teams - they will feel over-engineered for what you need.

    6. You're probably testing the product manually for now, but make it a repeatable process. As new features are developed, I would write down the test steps for it in a test script. Every time you build a new feature, run through all the tests again. This way you can be confident that the tests are repeatable and you haven't missed testing a part of the product. This also means you can delegate the testing job to someone else easily. In future, you can also easily reuse these scripts to write automated tests.

    7. Don't spread across so many timezones like I did! Your sleep will suffer.

    8. All of the above are risks, and it will take time and sometimes money to get right. So add in some buffer for time and money cost, especially at the start. Give yourself room to make mistakes with the process and tweak it. E.g. try not to have tight deadlines at the beginning.

    That's all I can think of at the moment, but feel free to DM me here or on Twitter ( More than happy to help.

    Hope that was useful!

    1. 1

      Farez hi! Thank you so much! So much invaluable advice!

      Two follow up questions:

      1. Can you elaborate on how you would write the spec sheet for items to be developed?
      2. Could you elaborate on the testing? As in automating the testing through scripts?

      Be careful when reading tips made by larger teams - they will feel over-engineered for what you need => this rings a bell.

      1. 1

        Glad it helped. So to answer your follow up questions:

        1. Can you elaborate on how you would write the spec sheet for items to be developed?

        I create "user stories" rather than a list of features. User stories makes you focus on the value you're trying to deliver before and then decide on the best feature to deliver that value. A user story is basically a sentence that follows the following structure "As a [type of user], I want to [do something], so that [the benefit of doing that thing]". E.g. "As a subscriber, I want to be able to change my card number, so that my account is not cancelled accidentally". See more on user stories at

        You may want to use weekly or fortnightly "sprints" to structure your work, as recommended by other commenters here. You would then, at the beginning of each sprint, have a planning meeting where you pick which user stories to work on during that sprint. The meeting is attended by the whole team.

        I would put all the user stories in a Trello column called "Inbox". During the meeting I would then move stories we want to complete during the sprint into the "Todo" column.

        1. Could you elaborate on the testing? As in automating the testing through scripts?

        No, not automated testing. That's a whole different kettle of fish! What I mean is just writing the down in English the steps of how you would manually test a feature, but do it for all features. Example of a test script for the "Login" feature:


        1. Login

        1.1 Scenario: Login with wrong password

        Test steps:

        • Click on Login link. Login popup should be visible.
        • Enter email
        • Enter a wrong password
        • Click the "Login" button

        Expected result:

        • Login form should reload with the error message: "You have entered a wrong email or password"

        1.2 Scenario: Login with correct password

        Test steps:

        • Click on Login link. Login popup should be visible.
        • Enter email
        • Enter the correct password
        • Click the "Login" button

        Expected result:

        • The user should be logged in and the Dashboard should be displayed.


        So you'll have a whole bunch of those scripts, perhaps in a Google doc somewhere. So before you deploy new features (usually at the end of a sprint), you/someone would go through all the scripts and step through the tests manually and check the expected result. It does get more and more time consuming as your product grows!

        Hope that helps. Happy to answer any more questions here or on a call if that helps.

  4. 2

    Hi Dima. What sort of process are you using at the moment?

    Normally I gather the requirements, write specs and pass that over to developers. Depends on what is needed, I break those specs down and/or create some mock ups.

    Then, in the dev team, they self-organise to plan who will be working on this demand, according to skills/availability.

    Whenever the feature is ready, it's deployed on a testing environment. If everything is ok, the features are deployed to production following a deployment schedule. If hot-fix, it goes straight to production after tests.

    Hope that helps

    1. 1

      Thanks, Leo for such a quick response.

      So what I have now:

      1. Launchpad where I linked all the relevant items for the project (
      2. Product development roadmap: (
      3. Slack communication with the team. I have two channels:
        -> Broad team (copy + growth guy + dev team + social media freelancers)
        -> Dev team (UX/UI + developer)

      Now I am thinking of either setting up Asana or Jira to manage the workflow of the dev team.

      Lmk if you see sth wrong with the set-up.

      1. 1

        Jira is a rather laborious piece of software. With a very small team such as yours, I'd recommend looking into ClickUp or even Quire. I had used Jira for about a decade before shifting over and find that Jira is an overkill for most purposes.

      2. 1

        For me, this should be enough, as long as the dev team understands what need to be done in each product roadmap's task.

        I don't know your project's size to make sure you need to implement either Scrum or Kanban. Both have their positive and negative.

        I also like Trello board, where you can attach files, developers easily understand, you can map your whole project....I wouldn't go for Jira, as might be complicated to use, too many options, too flexible in my opinion.

        What do you think? I'm happy to discuss more if you want.

        1. 1

          Yes, I had the same impression with Jira.

          Sure, will msg you offline.

  5. 1

    we implement a system called thriveOS that gamifies growth and guarantees execution:

    1. Define 1 Year Vision

    2. Set 90 Day Goals

    3. Review Monthly

    4. Report & Sync Weekly

    5. Daily Accountability Checkpoint

  6. 1

    Have you read any Agile / Scrum books? Think long-term, short-term, now-term. Break work into cycles (Scrum calls it sprints). At start of cycle carve a block of work out of your roadmap. Have short (15min) daily / frequent catch-ups where team shares progress and to-dos. You learn what is hampering progress and act to resolve those while everyone else gets back to their day job of completing the sprint. Tune according to your situation (e.g. team size). Track issues. Track progress. Reflect. Iterate.

    1. 1

      Awesome. Yes bought the scrum book. I will read it. I love to learn by doing the most. So reading + mentorship + doing = sticks the most!

  7. 1

    I'm not familiar with international companies that offer specialized training for going remote, but here in Brazil there are the guys from, a small team of colleagues that worked together years within remote environments that now train other companies on the best approach to working remote based on their experience. They seem pretty solid, and I wonder if they could maybe offer their training for English speakers. Not sure if you're willing to throw money into this sort of thing, but that seems to be a possibility. I would also love to learn about similar initiatives worldwide if anyone is familiar with some.

    1. 1

      Thanks so much for the advice. Interesting.

  8. 1

    You need a Product person to help build out a process for you based on your tech stack. I also suggest reading Jeff Sutherland's book on Scrum to give you a better understanding of the core principles.

    1. 1

      Thanks. As in a CTO? Or a full stack engineer?

      1. 1

        Neither. You need an actual Product person. Either an advisor or an employee that is an actual Head of Product. Yes, they need some technical skills so they can guide the implementation of their process, but they don't need to be an engineer. This person should be responsible for building and implementing your development process including meeting structure and PM technology, analytics to determine success rates and next steps, Design/Code review, internal and external feedback loops, NPS, backlog mgmt, etc.

        1. 1

          Awesome insight. Do you know where could I find someone like this?

          1. 1

            Yes, are you looking for an employee or an advisor at this point?

            1. 1

              I would start with an advisor.

              1. 1

                Connect with me via the email in my profile and I can offer a few suggestions.

                1. 1

                  I completely agree with this sentiment, that you could do with a product focused tech person.

                  If it'd help, I'd be happy to have a chat and see if I can help. Either to gather your thoughts / add some clarity or possibly more directly.