Table Of Contents
- Table Of Contents
- Workflow Summary & Key Principles
- Other Comments
- Communication Summary
- Product Development
- Ideas & Feature Requests
- Dealing With Bugs
- Product Development Summary
Just recently I came across the following article:
No Meetings, No Deadlines, No Full-Time Employees
→ Jan 7, 2021 I started Gumroad in 2011. In 2015, we reached a peak of 23 full-time employees. In 2016, after failing to raise more money, I ended up back where I began: a one-person company. Today, when I'm asked how many people work at Gumroad, I respond with "ten or so."
Shortly described, Sahil Lavingia (CEO of Gumroad) managed to create a successful digital product with millions of users without full-time employees in a fully distributed environment.
I was fascinated by the approach and the scale at which the company with such an environment operated.
So I decided to investigate and study it in more detail and answer the following question:
How did Gumroad manage to achieve such ⭐ success working with the "No Meetings, No Deadlines, No Full-Time Employees" policy?
And the sub-question:
What are the practices and tools you can re-use and apply to your own company?
Workflow Summary & Key Principles
For me as a digital product manager & business owner, the workflow is one of the most interesting aspects of Gumroad's case.
🤔How do they manage the development of digital product on such scale with no full-time employees, meetings, and deadlines?
I am going to review and comment on some of the statements observed in Sahil's article and Gumroad Public Wiki.
Instead of having meetings, people “talk” to each other via GitHub, Notion, and (occasionally) Slack, expecting responses within 24 hours. Because there are no standups or “syncs” and some projects can involve expensive feedback loops to collaborate, working this way requires clear and thoughtful communication.
Having a good set of online collaboration tools is essential for distributed teams. GitHub, Notion and Slack is the perfect "stack" that would fit a development team from any domain.
Clearly, without standups and syncs, it can be difficult to get feedback and reach agreements fast enough. Therefore asynchronous communication is one of the key aspects of the company's workflow.
Everyone writes well, and writes a lot.
This factor alone might be one of the most important on the road to Gumroad's success. It is the one and only explanation for communication to stay at a decent level.
While you work 9x5 in an office, you can freely chat with colleagues throughout the day. The need for written reporting almost disappears.
In a fully remote team, it is not the case. If you cannot coherently express yourself in writing, you create a barrier between your team and the goal.
In my opinion, ability to write is one of the most important attributes for a member of a distributed product team.
Studies show that for some people, this may even be the preferred way to communicate. Gumroad must have cultivated this culture which attracts the appropriate type of talent to fit into the system.
There are no deadlines either. We ship incrementally, and launch things whenever the stuff in development is better than what’s currently in production.
You can achieve this by following the KanBan approach. One of the benefits of it as it doesn't require a lot of project management and control. The downside is that it's hard to line up big features that need input from multiple teams (e.g., design + backend + frontend). So one part of the feature can stay pending for a while if one of the parties is busy with other important work.
I will further comment on the highlights from the article in a table, where the original statement will be on the left side and my remark on the right.
>> We recommend a weekly flow like this to get your work done and stay roughly in sync with everyone else (though to be clear, we require zero synchronous communication).
It is always good to split and plan the work in chunks. Periodic check-ins ensure everybody is on the same page and all the critical blockers are raised and resolved in time. One week is an optimal period for slowly moving products.
>> Do all work that is blocking other folks.
This is a critical part. Even the smallest blocker can delay a feature release by days. During one of my projects, the new team member didn't know the login credentials. It took more than 2 days for him to reach out to the team and access the system. Everyone was busy fixing bugs on production.
>> If you're running out of work, move some tasks from Notion to GitHub
I assume that GitHub is used for day-to-day task management and has a backlog of tasks for the nearest few days. And Notion is for high-level feature planning and contains the roadmap with most of the user stories. It is a good solution.
>> Try to tackle 1 technical debt issue a week
I assume the "technical debt" is one of the important types of issues that have to be resolved regularly. It is a good practice to have explicit categorization like this
>> Look at issues marked priority on GitHub
Although understanding high-level prioritization is important, knowing what to focus on day-to-day is vital as well. Having certain prioritization labels for GitHub tickets is a must
>> Address any outstanding questions in #support in Slack
I assume that everyone from the product team has access to the customer support channel. That's a good practice and helps the team become closer to the users — know what the common issues are, what kind of questions are asked, etc.
>> Provide a weekly update in #updates-log in Slack
It is good to keep all the updates in the same place so that the team members can efficiently discuss them
>> Resume ongoing work!
One of the mistakes of amateur development teams is to switch the focus too rapidly. Whenever a new request arrives from the product owner, sometimes the team switches their attention to it — leaving work-in-progress abandoned. It is inefficient as it takes a lot of time to recover the stuff left behind.
>> We don't have teams. Everyone works on individual projects. If an idea requires a "team," it is broken down into at least two projects (e.g. design, front-end, back-end).
It is an interesting idea. However, for it to work nicely, team members should have a complementary set of skills that would allow them to work effectively as individuals.
Here we will dive a bit deeper into Gumroad's communication setup and discover some of the best practices for remote development teams.
We use three tools: Notion (hi!), Slack, and GitHub. Notion is for our Wiki and product management. GitHub is for our codebase. Slack is for everything else. It's the closest to real-time we have. You are safe checking this once a day, if not less.
This is a perfect combination of tools for remote teams. It is quite remarkable though what lengths Gumroad had gotten only checking Slack for no more than 1 time per day.
>> Integrations are set up to notify you about all relevant activity in #engineering-chatter, #releases, and #infrastructure. 500 errors go to #errors (ignore if new).
Gumroad makes use of the powerful Slack integrations — a topic I covered in my previous researches.
Below I will summarize some of the highlights about the setup of Gumroad's Slack.
>> #engineering-chatter: most important channel to join and keep track of. where we chatter!
Dedicated channel for general product-related conversations
>> #infrastructure: where engineers chatter about infrastructure (aws, downtime, and more).
Separate channel about the product infrastructure
>> #support is the channel used for the support team to get help with answers for our creators.
Dedicated channel for customer support requests from Gumroad's creators
>> Every Monday, people post what they're working on in #updates-log.
Separate channel for progress updates
>> The #design channel a great place to see what the designers are up to.
Separate channel for design discussions
>> Product-specific channels such as #consumer-mobile-app #discover, #library.
There are also different channels for big app features or branches. Allows having all the messages about the specific feature at hand when needed
Disable emails from GitHub to reduce duplication of notifications. We recommend using #engineering-chatter and GitHub.com or the app directly instead.
Disable emails from CircleCI, New Relic, Bugsnag.
Turn off all notifications from your phone!
With all these Slack integrations, sometimes the number of notifications can be overwhelming. It is very considerate of Gumroad to giving such recommendations. These kinds of little details decrease the excess of information intake and reduce individual's overhead for processing such information.
- Major portion of messages from Gumroad's Slack is automated
- At least 5 external apps are configured to sent notifications in Slack channels about various events.
- GitHub → Issue updates and pull requests.
- CircleCI → Deployments & releases
- Help Scout? → Customer support chat
- Aws → Infrastructure
- New Relic → Analytics, error reporting
Every organization struggles to put their prioritization process and shipping workflow into a structured process. This is our attempt.
The document is brief and very easy to read.
Such description has great value when onboarding new team members — in 5-10 minutes they understand the key concepts of the workflow.
Here are some highlights.
Ideas & Feature Requests
Ideas come from three main places: people who work at Gumroad, Gumroad's creators, and creators who are not (yet!) using Gumroad. There are others, but these are the most important to listen to.
Identifying key sources for product ideas makes perfect sense. It is important to know who to listen to and whom to ignore.
The board of ideas we have (called the Icebox)
It is a great concept to separate ideas from the tasks in development. Most of the product teams I had been working with have a single massive backlog. There is everything — user stories, bug reports, ideas, improvements, infrastructure tasks, even marketing tasks. Such structure can create clutter and difficulty navigating through the backlog even for mature product managers.
Icebox is great.
(Icebox) has six columns: No Status, Scoping, Design Needed, Ready to Add to GitHub, No Priority, Technical Debt
Icebox has its own workflow.
It goes through
Scoping with engineers — probably where all the high-level requirements are validated and converted into actionable steps.
Design Needed — is where UI/UX designers take over.
The final stage is
Ready to Add to GitHub — it indicates that feature can be added to the day-to-day production board.
Most ideas are worth building, but not right now!
It is a fundamental principle, yet many companies forget about it.
When a new idea pops up, it may seem superb and bring immediate value to the product. But it is worth keeping it cool and walk each idea through the regular process.
Ideas grow into shipments over time, until they answer: What the feature looks like and does: - Scope - Designs if needed - A list of atomic, independent shipments - everything we ship is as small as possible. Why we're building it - what problem does this solve for creators?
The question of Why is always the most important and must be answered first.
It is also worth highlighting the process of breaking down the feature into "atomic and independent shipments".
Small and incremental shipments are the essence of the Lean Startup methodology. It is a powerful approach that helps to get customer feedback as early as possible. In Gumroad's team, every member takes responsibility for a single independent shipment, simplifying the delivery process by a lot.
We have themes. You can read about this in our Roadmap. In general, ideas that are closer to the theme will be chosen. E.g. Next quarter our theme might be "spring cleaning," so more weight is given to things that "clean up" the product experience
Themes are a very interesting concept. On top of the baseline priorities, the theme adds up the next layer of prioritization. This way, the team can focus on a specific product aspect for a limited period of time. This allows leveraging an existing or new feature and delivering it at exceptional quality.
We sometimes pick what's fun and feels good to work on!
That's the spirit! Sometimes fresh and great concepts are born this way.
Dedicating 20% of work time to what's fun can bring enormous results. Google products like Gmail, AdSense, and Google News were born this way.
Now that the idea lives in GitHub, within Notion it can be moved from Icebox to To launch, another board that informs the design and content teams that the feature has begun shipping. They can start to plan polish and constructing materials for the launch announcement (blog, email blast, social, press, etc).
Gumroad has a process for a smooth transition of a feature from Production into Marketing (Growth).
Moving an idea from Icebox into To launch (a separate environment) is like establishing a link between the production and growth teams. This is also something that we use at OB Trader. It helps to maintain alignment across different teams.
Dealing With Bugs
As soon as a creator reports a bug, we file it. Once two creators report the same bug, we move it to the front of the queue and fix it.
The main source of bug reports is the Gumroad creators (users). Assumingly, Gumroad doesn't have its dedicated internal QA resource.
With the following structure, it is essential to prioritize bugs reported by users. Especially when reported by multiple people, bugs can cause companies to lose money and customers if not fixed quickly.
Product Development Summary
Finally, Gumroad has a clear list of DO's and DO NOT's about their product development.
This card by itself works as a great reminder to all people involved about how things should be.
Unarguably, Gumroad's workflow & collaboration principles affect the company culture. As Sahil Lavingia, CEO of Gumroad, said in his blog:
This way of working isn’t for everyone. There are no retreats planned, and no social channels in Slack. There are limited opportunities for growth. And we can’t compete with the comp packages that big tech companies can provide.
And he is right. This is not for everyone.
Most certainly, the key priority of employees of such a company will not be the company itself. They won’t bond and unite by keeping such distant and scarce relationships between each other. Strong company culture is not achievable this way.
What such an approach allows is flexibility.
Each employee can shape his schedule in his own way and focus on things that matter most. For instance:
- Want to spend 2 hours working on creative tasks in the morning and spend the rest of the day with the family? That’s possible
- Have an amazing side-project idea? Spend half of the day following your passion and another half completing the tasks.
- Traveling? No problem. Get a few days off, complete your tasks during the weekend.
Your work becomes a hobby, and hobby becomes work.
Of course, it all sounds good in theory, but there is a key question a founder of such an organization should ask himself:
How can you effectively make people do tasks for your organization and achieve common goals? Most importantly, how can you make them want to do that?
Well, the first answer is obvious: money.
You pay an expert for his time spend on your project. If the pay is reasonable — everyone is satisfied. But that alone will not make the expert to be driven to deliver tasks until the utmost completion and focused on achieving company goals.
The second answer is — strong company vision. And Gumroad did a great job about it.
Instead of setting quarterly goals or using OKRs, we move towards a single north star: maximizing how much money creators earn.
Gumroad worked well on their vision statement and positioning, which is shown on their Public Brandbook page.
It presents answers to 5 key questions about the company. It brings clarity to both employees and customers about what to expect from Gumroad:
- Why we exist
- Who we are
- How we talk
- What we look like
- How we act
Gumroad has an authentic, sounding, and altruistic purpose.
The most obvious and important association is that its purpose is to help people.
It also creates empathy to those who use the platform — the creators.
So, everyone can make the following relation:
Working for Gumroad → Doing good.
That's a compelling statement that by itself can attract many enthusiastic talents to join the company (not only it's also a great marketing line)
That statement right there has immense value to the organization.
It brings clarity on what to focus on.
By just knowing this simple sentence, people at Gumroad can understand what tasks to prioritize.
This aspect simplifies the decision-making drastically and ensures everyone is on the same page.
For remote teams, this quality is essential.
No common vision = no common success.
- Written communication is key in the distributed teams. You have to write well and write a lot. Most importantly, you have to love to write.
- Make use of online collaboration tools. Choose tools that will cover your needs. Usually Slack, Notion, and GitHub work well together. Slack — communication and integrated automations. Notion — documentation, wiki, and product management. GitHub — production and version control.
- Have a clear and structured workflow. Document your processes and share them with all your members. Everyone on the team must be on the same page about prioritizing and moving issues across your workspaces.
- Establish a clear vision and mission for your product. It is much easier to get people aligned when everyone is driven by the same purpose.