Early stage cofounders can be unproductive when working solo, because they’re working remotely without any remote practices

Learning (and using) remote practices for early stage startup teams

Vlad Shulman
6 min readJun 8, 2019

A surprising realization came several months into moonlighting with a friend on a new startup idea — we were hyper productive when working together in a crappy co-working space, yet drastically less productive when we were instead working apart in our homes / coffee shops — turns out, we were kinda working “remotely” when we were apart, except without any remote practices implemented to encourage productivity. After studying some companies recognized for their remote culture, we adopted six techniques which allowed us to individually work on the right things when “away from the office”, resulting in having more time to brainstorm changes / pivots on the few days when working together.

m = more information available
v = vlad’s (my own) personal experiences

Online headquarters

We started noticing that everything mentioned in-passing would be promptly forgotten, so we digitized them into what became our online HQ for topics that needed a team discussion [v.1]. However no matter which tool we used, it would quickly turn into a disorganized mess, so we also adopted an intake process [m.2].

📝 Inbox: Anytime someone would think of anything that required a team discussion (ideas / action-items / fyi’s / interesting articles), they would add it into the general “inbox”. Every time we would chat as a team — whether in person, or on phone — our goal was to chat through all the inbox items and decide what to do with them: delete it, mark it done, or move to “categorized inbox”.

📝 Categorized Inbox: After a topic was discussed as a team, it would make it’s way into the “categorized inbox” aka “backlog” and be assigned a label (ie. next step) [v.2]

📝 To Do Until Next Chat: As a way to stay organized about what we wanted to get done before the next time we talked, we would pull items from the “categorized inbox” (or break those items into chunks of work that could be done in time). When a topic would get finished, it would stay in this category until we reviewed/discussed it as a team.

📝 Done, Links: After a completed item would get the “thumbs up” to be marked done — and it DID have reference material in the notes — it would get moved to “Done, Links”. This let us quickly find notes / account credentials / etc.

📝 Done, Archive: After a completed item would get the “thumbs up” to be marked done — and it DIDN’T have any reference material in the notes — it would get moved to “Done, Archive”. Seeing this list grow every month was a nice point of pride for the team.

Daily call

This became our religious practice; a daily call to talk about what was going on (which had side-benefits of helping with motivation and mental wellness).

📝 Venting: We would start the call by talking about life, which helped “get it out of the system” and often would result in new ideas.

📝 Changes: We also used the chat as an opportunity to call out any changes to our plans / way of thinking / personal life, which is usually the biggest disadvantage to remote-work (ie. talking about things that naturally come up in conversation when people are located in same room); when omitted, frustrations start quickly surfacing.

📝 Status updates: We would end the call by walking through our Online HQ to discuss the in-progress work / review completed work in the “to do” list, then review the new topics in the “inbox” list, and finally decide what needed to get done before tomorrow’s call by moving more topics into the “to do” list.

Asynchronous chatting

Whether it’s a group text or Slack, asynchronous chatting helped us remember that the cofounder exists in the world, and would usually facilitate memes / inside jokes / ridiculous ideas (ie. non-serious conversation). I can’t quantify the benefit this brought to the team, but on days when we didn’t use Slack the team moral felt lower, so that was an interesting observation.

Calendar scheduling of next IRL hangout

Making the effort to discuss (and schedule) the next time we would work together in-person would help us mentally prepare for the amount of remote work that needed to get done [v.3].

Weekly sprint planning

While most agile practices are unnecessary for a two/three person team, we found that sprint planning helped us take a step back from the day-to-day work, and understand what we were working towards.

📝 2–3 goals: every week, we would agree on two/three accomplishments which could be measured by “Yes” and “No” [v.4].

📝 Corresponding tasks to support goals: these would become our backlog items for the “to do” list.

Monthly retrospective

Another agile practice which we found worked well was to pause on the work we’re doing in order to have a conversation around tuning our internal process / culture [v.5]:

📝 What’s working well: We rarely take the time to celebrate wins, and this is one of the aspects of a cofounder team which is inherently unique to every startup — the “good” properties of a cofounder, which essentially shape the culture of the entire startup. Take this time to call out particular behavior that is helping push the product and team forward [v.6].

📝 Patterns noticed in cofounder that is detrimental to progress: Likewise, we rarely pay attention to our flaws, and a cofounder is in a unique position to call out specific patterns in our work / thinking which can actually make the team and product better. This is a great time to call out pessimistic behavior (and hypothesize potential triggers), as well as personality quirks that negatively impact the company [v.7].

Resources

more information available

m.1, An interview with the Zapier cofounder helped us better understand the typical challenges experienced by remote workforce, and the features within their own internal online HQ https://blog.ycombinator.com/mike-knoop-on-product-and-design-processes-for-remote-teams-with-kevin-hale/

m.2, The Get Things Done (GTD) framework helps collect tasks, ideas, and projects into a very logical system. It turned out to be overkill for us, so we drastically simplified it for our own use case and kept some fundamental theory https://hamberg.no/gtd/

vlad’s (my own) personal experiences

v.1, We tried Google Docs, then Basecamp, then Airtable, and finally settled on Trello as being the most simple for us to maintain.

v.2, Labels we would use for our “categorized inbox”:

  • Later/Idea (for interesting articles to read, or things that we might want to think about doing in the future)
  • Watch / Waiting On / Followup (for people we emailed and are blocked until they respond)
  • Event (upcoming pitch / demo / workshop / info events, for us to attend as team)
  • FYI Done (for things that don’t require any next steps ex. “created a Stripe account”)
  • To Do (the majority of topics would be things someone needed to do; for every to-do that we discussed, we would immediately assign an “owner” and a “date of expected completion — typically “end of this week”, “end of next week”, “end of this month”, “end of next month”.

v.3, Our team did not have “remote work” as a virtue, so we found that it helped our moral to know the next date when we would be working together in the co-working space.

v.4, Some examples of goals: “login screen works with X credentials”, “itinerary approved by Y partner”. It’s tempting here to pick tasks instead of goals, so one way we made a distinction between “tasks” and “goals” was to ask ourselves “what incident needs to happen at the end of the week which will make us happy” — this becomes the goal, and the chain-of-events that need to happen for that incident to take place helped us decide on the corresponding tasks. We found that 2–3 weekly goals were manageable, and would occasionally throw in a “stretch goal” if we wanted to get more things done, which would only be worked on when “main goal” would be finished.

v.5, I would caution against having this conversation more than one-per-month, because it’s heavy and the team can grow to resent each other.

v.6, Example of positive things we would notice: habits used to get through times of stress, a time when the cofounder helped without being asked, verbiage used to explain the product in plain English.

v.7, Example of negative things we would notice: ego when talking with prospective partners, destructive habits during times of stress, confusing verbiage when explaining product.

--

--

Vlad Shulman

I appreciate you tuning into my thoughts on launching product ideas. Feel free to let me know what’s on your mind @ vlaaaaad.com