This was precisely our approach, but we built our own features for the "gaps" that we believed existed in the other products.
If an existing app was doing a decent job, we didn't want to compete with them. The issue is that we ended up arriving in this "dead-zone" where we didn't replace an existing tool and pull budget from an existing category of tooling.
I knew we needed to build a suite of tooling, as our goal was to be a "hub" for the most important stuff at work. In retrospect, we built too much product.
If I start another company, I will spend all my time focused on solving a very big pain-point with a few simple product.
With Friday, I wanted to keep the product simple, but the people we talked to always were talking about the "yet another tool problem" - so there was a desire to consolidate. How I interpreted this was that we needed to build the "suite" vs. spending all our time on one feature.
I could go on and on about what I would do differently, but I'm thankful for the opportunity and have learned a lot that will (hopefully) make me more effective in the future :)
I made the decision after a lot of reflection. We still had ~6 months of runway so I could have spent more time "pivoting" around.
The issue was that what I was hearing from prospects, customers, users signaled a bigger issue that could not be solved with a product tweak or two.
At the end of the day, I felt like the story I would need to tell a future investor (and new/existing employees) would increasingly become disconnected from the reality I was experiencing talking to customers/users.
I didn't feel at peace about it at all. I considered it to be a form of lying.
I am considering it. I have a fiduciary duty to try to fetch a fair value for the assets, but if no one wants the codebase, I'd consider opening it up. Still TBD as I just announced this a couple days ago :)
Hey, I'm the founder. We worked really hard to not position ourselves as a task management tool, but instead, a tool that integrates with existing systems.
Task management is extremely competitive and we didn't want to play in the space. With that being said, we viewed our job as an interface to "glue" the work together, no matter the source.
tl;dr - I wrote a 200 page user manual for team leaders and CEOs to navigate working from anywhere and open sourced it online for free: https://friday.app/anywhere
I'm Luke, the founder of Friday.app. 8 years ago, I first read Remote by 37 Signals and it's what caused me to start working remotely back in 2013. At the time, the book laid out a case that more organizations should offer remote work.
Over the years, I worked for a few different distributed companies in a variety of roles. I've seen what works and what doesn't. Now, I run a software company building async tools for distributed teams. I've also spent years digging through research on distributed teams, asynchronous communication, and more. Basically, it's been a huge area of focus for the past 8 years.
When the pandemic hit, people were CONSTANTLY asking me if I had any book recommendations. Unlike 2013, people didn't need to be convinced about the benefits of working from anywhere, which Remote did a great job covering. Now, they were looking for a playbook on how to implement this stuff in a way that tapped into the benefits of distributed work - primarily the flexibility.
I never imagined writing a book, it's not really my forte. But after seeing so many companies rollout terrible policies/practices that made working from anywhere worse than going into the office, I decided to throw my hat into the ring.
The book teaches high-level principles and then dives into specific practices and playbooks, like:
- How to go async-first
- What meeting should be an email? What email should be a meeting?
- How to hire people you haven't met
- How to quickly onboard new teammates
- How to feel connected & stay accountable
These are all questions I hear all the time. This book is heavily focused on shifting towards an async-first environment, because I believe this is the #1 transition an organization needs to do.
Anyways, the entire thing is available for free online. There's an audio version too and spent quite a bit creating illustrations for each of the chapters. If you want a hardcopy, I'm offering that at cost on Amazon (I make 1 penny for every book sold).
I hope this helps you all. I'm just tired of seeing people act like this is all brand-new, when in reality, there's a mountain of evidence and best practices that can save you a lot of headaches.
async is not a losing battle. Trying to handle async communication processes manually is.
Right now, most async communication processes (like status updates or daily standups) involve a ton of manual effort to make sure that people share this information.
I strongly recommend creating systems and using automation as much as possible here.
Most workplace communication tools are focused on improving the efficiency of communication. I think of this as laying "pipes". It's never been easier to jump on a video call or ping someone in Slack or email. What happens is that the information/communication doesn't flow on a repeatable or predictable basis.
What people really need when remote is a way to help create and automate a series of communication habits/workflows, so instead of hunting around or perusing Slack to understand what's going on, the information flows to you. Like a series of communication pumps.
Right now, most managers manually collect this, which is an epic waste of time.
Self plug, but after 8 years working remotely and constantly running into the workplace chat firehose, I've built software to help automate any routine update at work (https://www.friday.app).
Any wiki software suffers from the problem that only a small percentage of the company uses it. It's essentially a tax on the most productive people. If someone asks you for the same thing 8x, you will write it down and share it via a wiki.
I've spend years trying to solve the problem - how do you get the average person writing more at work? What I've come up with resembles a company "journal", but helps you automate any routine communication or update (daily standup, weekly update, retros, etc).
Would love any/all feedback on the idea, here's the website (https://www.friday.app/). You can use it as an individual, team, or with the entire org.
This is right on. Slack's pricing is based on regular usage, so they have an incentive to keep you distracted (to put it bluntly).
Microsoft sees chat as a piece of an overall communication "puzzle". They have Sharepoint for more persistent information and Yammer for "outer-loop" communication.
My startup (https://www.friday.app/) is based around the idea that there needs to be a "home" for the most important stuff at work that complements workplace chat. It's somewhere in-between Slack and a wiki (which most people don't use regularly).
Workplace chat tools like Slack are wonderful for quick collaboration, but if you over-index here you will run into trouble. That's why Zapier, Automattic, and Stripe have all built their own internal tooling to help.
My journaling habit started with Ohlife.com way back in 2014. I found the idea of quickly recapping my week to be therapeutic., plus it was great to see entries over time.
I ended up building a product (https://www.friday.app/) to make this easy and automated. While it's built for teams to share updates and reflect (think weekly updates, retros, etc), there's "single-player" mode available too.
I like the digital journal format because I could never start the habit with paper. The automated reminders were critical to establish the habit. I still keep a regular notebook where I'll document thoughts, but it's more ephemeral.
When running a startup, it's natural to have unknowns, and for the most part, that's okay and to be expected.
But if you discover a new reality on the ground and continue to tell a different story, you are lying. I didn't want to do that.