I've never heard of this product before, but it definitely does sound interesting. I know exactly how hard it is to get a small / medium sized company to switch to a new product, its definitely not easy.
That aside, I wish Slack was more customizable (or open to allowing some customization) that would enable it to function more like what Derrick was trying to accomplish with Level. That would be the best of both worlds.
"The gist is that it’s tough to get unbiased feedback during customer validation." - I wish this was taught along with lean startup content. Too many times I have heard founders say they validated the idea when all they have done is gotten biased feedback while asking self-fulfilling questions.
I mean, iterate on the product until it sells like hotcakes that's your validation. Then you'll spend the rest of your days trying to STOP the torrent of complaints, feature requests, etc. Better yet have actual experience in the industry that the product is targeting rather then expecting that industry to go out of its way to tell you what to build.
Ideally you have orders for the product before you start building it, don't put all your eggs in if I build it they will come.
Not really that unambiguous depending on the market and/or product. You could make the argument that these HIV drugs are miraculously helpful! As you jack up the price. People keep buying it at any price, must means its fantastically effective, right?
Even in less extreme cases, it may be just that you have extremely good salespeople / marketing team. With good enough sales, you can sell any kind of garbage, and in many markets it might be unlikely that complaints of existing users will reach or discourage new ones.
Yep, it is extremely hard. Lean Startup makes it sound trivial when it's almost impossible. Almost nobody is going to clear up their day to talk to you about their problems, answer your questions, give you feedback, be your guinea pig, etc.
The ideal way to validate it is to be so immerse in the industry/problem such that you understand most of the pain points. Do the job that your ideal customer is doing. Attend the conferences they're going to. Visit the forums they're visiting. Read the websites they're visiting. Analyze the reviews they're posting in TrustRadius/G2Crowd. Look at their Linkedin profiles to see what their day to day involves.
> The ideal way to validate it is to be so immerse in the industry/problem such that you understand most of the pain points. Do the job that your ideal customer is doing.
I think this is a great reason to have a co-founder. I co-founded a company with a domain expert, and her ability to get in front of and understand our target audience was way more important to our startup success than my development ability (and the equity shares reflected that). I mean, we needed each other, but she was far more unique than I was.
The alternative for a developer is you immerse yourself into a different domain, or you build tools for developers. Both of which are good paths, but the former is far more time commitment and latter is more common (and thus more competitive).
I agree overall but it's not that hard to get people to talk to you if done a certain way. If you are trying to sell them while talking, yes that will be hard/impossible. However if you approach it as learning from experts, then I find people are much more receptive because most people like to help and feel important/useful. I always say I want to learn from them and offer to pay for their time which shows them I understand they are busy. I still get some NOs but that's okay. BTW I've never had someone want me to pay them, but I would if they did.
You're right. Getting to the real crux of the problem that someone faces but also are willing to pay for a solution is not easy.
Though I have had good experiences talking to different industries because it could be as simple as a 20 min phone call.
I find that if people are really facing problems that they want to get rid of and someone is genuinely interested in solving it for them, they are usually open to chatting. It does take some effort to reach out.
I have had success talking to 30-50 individuals before I come up with a solution and customer development is also a skill that needs to be develop .
I agree entirely with your second paragraph. With that being said, I do think it is very possible to test unbiased product-market fit. Simply do the promotional channels you would do if you had a product and pretend you have the best version of your product already and see if anyone will bite.
For instance, cold call companies and pretend you have the best version of your product on the phone or create a landing page that offers your "future product", buy PPC ads, and get people to fill out a lead gen form.
In both cases, once you talk a little bit, let them know the product is still under development and ask if they'd like to be contacted again once development is done.
One thing I realised recently is when you have traction, this is a much easier problem to deal with. Everyone keeps hounding you for improvements and you prune these requirements to increase utility and demand.
So its critical that you find a good sponsor/client in the early days. One that you have easy access to and you work together with until your product gets to the point where its utility is obviously apparent to new clients. And work it from there.
When your working with your first client they will inevitably drag you down into the small details (improve this/ make this). I call these the "meh" features. What you need to do is focus on analysing the underlying reason why they want the "meh" features and work on eradicating that reason. If you crack it, you get a "wow" feature. And that brings traction.
For example, we designed a financial platform for schools in a developing country. Finance operations in schools is complex with varying chains of manual processes. Our "meh" features were digitising these processes, improving each individual task. Our "wow" feature was to completely automate the end-end process for a small subset of schools with similar requirements. Instead of making their tasks easier, we just completely removed the need to do them. After that it was pretty apparent what we had to do.
After doing 10-20 of those interviews, I got pretty good at coming up with an internal "pain scale" - where this particular problem sits in terms of overall pain the customer is experiencing, and thus how much they are willing to commit to solving the problem.
I say it every time, to every founding team I meet.
Read “The Mum Test”[1]. It will make you aware that you to get unbiased feedback you need to remove your identity from the idea so that people aren’t nice to protect you.
I also keep recommending this book to everyone. The TL;DR is: NEVER ask questions about hypotheticals. Ask people about what they do, how much they pay, how much time it takes, and so on. Facts, not answers to "Would you use this if...?"
Indeed! One of the things I found frustrating about the article is that he talks about people 'lying' constantly... when if fact he had just asked meaningless questions.
Interestingly enough, that’s also a principle of behavioral interviewing. Hypothetical questions allow the bullshitters to shine, but specific targeted lines of question about what the interviewee did in a specific situation is frequently enlightening.
For a technical sales job, I would have people do a role play about suggesting a technology. They’d always start saying “I would tell them about...” and I’d pause and ask them to tell me the thing, not talk about telling me.
My point is that I believe hypotheticals take a lot pressure off and allow you to be super vague in interviews. For the past, talk about real situations. For the present, do a role play.
Removing your identity is incredibly helpful. The last time I did this from scratch, we didn't have our company name on the door. We were doing a consumer-focused product, so we told all our early test users that we were doing market research. Eventually a significant percentage of test subjects figured out that one of the products discussed was ours, because most of the later questions focused on it. But that was after we got their honest, early reactions.
Basically, if you want to find out whether you're baby's ugly, you have to make sure people think the photos are of a baby, not your baby.
thank you. Skimming through this now and seeing how clearly it maps to recent conversations we've had that have turned into customers vs conversations we thought would and never did
Huh. I think this is often taught. Indeed, I think it's at the core of the LS approach. The build-measure-learn loop is the heart of the process, meaning that whatever ideas you have, you test them as soon as possible with customer behavior.
As an example, I mentored at Lean Startup Machine. We'd have them form up into teams around ideas. The first thing they'd ask for was verbal feedback. But they were quickly supposed to move to increasing levels of demonstration of commitment.
One team, for example, had the notion that restaurants needed an easier way to get insight into customer experiences. They went out and found restaurant managers, and first confirmed that they had the hypothesized problem. But they quickly moved beyond words, asking if the managers would be willing to let them trial the system in the restaurant. Since enough of them said yes, they build something simple and put those little printed cardboard triangles on a bunch of tables. They then hacked together reports for the managers based on the data collected. The managers liked the reports. They then asked the managers how many would be willing to pay, right then, some modest monthly charge for ongoing use of the system.
If I recall rightly, this team discovered that when actual money was on the line, the reports were just a nice-to-have. In that situation, it's still reasonable to persevere, as you may have hypotheses about what really will get them to cross the line. But it's also reasonable to kill the idea.
There's a big difference, though, between what is taught and what people do. I was an early adopter of both the Agile movement (XP in particular) and Lean Startup approaches, and in both cases I'm kinda horrified by what it turned into in practice. With the Agile movement, it was quickly captured by companies who wanted to feel like they were doing something different while still retaining most of their top-down pathologies and high-debt code bases.
With the Lean Startup approach it's harder to say how it turned out, as early-stage startups rarely produce reports like this. But my general impression is that, as with Agile, people pick the parts that seem fun and easy, and avoid the hard parts. I think this was made worse by the flood of VC money, especially around Uber-for-X startups. Who wants a method that will kill your probably-bad idea early if you can get tens or hundreds of millions? The bad idea might work out or you might thrash your way to a good one. And if it still failed? Well, now you're a seasoned founder of a venture-backed startup. By some measures, although not mine, that's way better than having a quiet, cheap failure.
The buyers of a Slack for an enterprise organization wouldn't be developers doing "Deep Work". The buyers would be executives and managers, ie: the people pushing the content that causes the annoying notifications, anyway.
I am a product manager and basically live in slack. My job is basically to communicate all day. On the flipside I've spent the last couple years learning to code in my free time and I can't imagine being interrupted by slack while im in a groove. It's def made me better about waiting to talk to my devs in our daily meetings despite being right next to them
Is "a year" supposed to add a lot of impact here?? I frequently spend multiple years on more dubious endeavors, and have zero regrets about it. That's life.
Edit: Okay this came out pretty harshly, but what I am poorly trying to express is that most people spend more time on worse things, so "a year" doesn't parse as the intended intensifier for me.
Thatcs actually supposed to be read as encouraging, as he said the guy did something better than him and in a shorter time. And thus he should feel less remorse than he does, which he doesn't. If that makes sense...
The website doesn't look the same for different resolutions. If I set my resolutios to HD, it's fine. If I set it to Full HD, half the screen gets covered by the photo and it's very distracting.
Oh, please. You may have some rationale that makes a certain kind of sense, but clearly a lot of others don't care, or value other things. So ... subjective.
I think for things like business chat, since the purchasers of the product are different from the users, and not completely aligned with them 1:1, VC-backed companies with the connections and credibility to said stakeholders may have a much easier go at getting paid users. You can also trade profitability for growth, which is something bootstrapping precludes.
P.S. I read @rwalling's "Start Small, Stay Small" a few months back, and it was a phenomenal read. Highly recommend.
Agreed! I think products where the purchaser and the user are different are an enormous graveyard for startups. There's a big difference between building a product and building a business no matter the sector. But when the purchaser and user are different, it can be way worse. Good designers and engineers want to focus on improving the user experience, but that may not translate into sales at all.
I'm guessing you're referring to this part at the end:
"In hindsight, I took on an unreasonably audacious endeavor with Level in part because of my internal “this might get big if I play my cards right” dialogue. It would have been far better to either deliberately go for the big idea (and probably seek venture funding to make it happen), or start far smaller and build my way into a sustainable company of one."
I appreciate this passage... a thoughtful reflection.
Slack has a staying power that the author didn't catch: once you've got all kinds of apps reporting data directly into Slack, and all kinds of rooms set up for specific data purposes, it's even more sticky than email.
Before a Slack-using company would switch, the competitor would need to support many/most/all of the integrations that the company is using. You've really only got two chances to win Slack's customers: the point before they seriously adopt Slack, and the point in the future where Slack does something stupid like jack prices way up or suffer a serious breach.
Not that it'd be easy but I imagine that you can steal their customers by adding chat rooms and integrations slowly to some other type of software, rather than a more direct angle where you have to win at one of those two moments.
My employer ran several pilots of alternative chat systems alongside our primary. It sucked. Having both clients open, remembering which rooms are actually in active in which systems, etc. was obnoxious. Might work for a single closed-loop team but even then.
That's the discussion we're actively having now. My only concern is how to move the knowledge and context that's currently in Slack somewhere else. Also, who knows if Teams will actually catch on - though with Microsoft threatening to get rid of Skype, it'll end up being the more official looking meeting app anyways, so why not bring the rest along?
I’m pretty sure Teams is here to stay. It’s growing. MS is investing a lot of resources and it’s improving rapidly.
But I think your point about MS getting rid of Skype for Business in favor of Teams is the most important one. Once that happens, which MS has stated publicly, Teams will become a necessary app for MS to support, since enterprises won’t tolerate MS not having s chat service in O365.
The company I worked at previously tried to force MS Teams on everyone. Problem was that most developers there ran Linux and the client was far inferior to Slack on that platform. Unsurprisingly very few developers used Teams and it failed horribly as a decent communication replacement. It became yet another communication channel devs may, or may not, respond in. End result: email still reigns supreme, complemented by xmpp for the non-devs with the technical know how to understand how to connect to the internally hosted server.
So my view is that until Microsoft get their act together, Teams is not a serious contender to Slack. Companies can get it
"free" together with their Office subscription, but most developers won't use it until it works decently on their development platform of choice.
You could make this same argument to argue that Slack would fail against email.
Something like: there are all kinds of email integrations, user-specific and group-specific setups, etc. at companies. How can Slack ever compete?
The answer was that Slack was so much better for many companies that it made sense to suffer the pain of switching.
The company that beats Slack will likely be 10x better communication software or something very similar but distributed much more effectively (maybe Microsoft Teams in the enterprise).
Chat is a complement to email, not a replacement. Over time some people may take their formerly-email activities to chat, but no cutover is required.
Running two chat systems side by side, on the other hand, is a huge pain. There really is a pressure to get everything migrated and the old one turned off.
Email is for outside the boundaries (outside-of-company, outside-of-division in a silo'd company), chat is for inside - there's still people who do prefer email especially in partner facing roles, but I think its fair to say that most prefer using chat if they had a choice.
Not necessarily true. For example the enterprise I work in doesn't allow saving chat history. This makes email better for technical discussion that needs recorded.
Legal. When we are sued (we make equipment used in dangerous environments, and we have a lot of money, so if there is the slightest chance we can be blamed we will be sued) US law says we need to give all relevant information to the other side. That includes any saved chat logs and emails. However if something was deleted before we are sued we don't have to give it out.
We lost a law suit once because a [not native English speaker] wrote "the bearing will fail with disastrous consequences", he meant the shaft would need to be replaced, but when a fire started in the area of the bearing that email was part of discovery and the jury decided the bearing was at fault for the fire not the user failing to clean the area which was our story. (legal would rather I not give you the case to read for yourself)
Chat tends to be less formal than email, thus more opportunity exists for something that is easy to take out of context. By not allowing saving chat logs we ensure they they will never get to court.
We have strict rules that emails must be deleted after a few months (unless we legally need to keep them). Any information in the email that is worth keeping longer than that is put in a formal system where legal can examine the words to ensure they won't be taken out of context and used against us.
Sounds wrong to me. Hiding chat logs or other business information from the company itself as well as customers (albeit suing ones) seem stupid. How would the company ever be able to audit its own operations? Getting sued is sometimes also not too bad as it can reveal bad practices within an organization. An analogy would be an X-ray, not entirely healthy but very revealing.
Normal companies do not operate voice recorders in offices/conference rooms or even telephone wiretaps, except for specific regulated positions. Text may be more convenient to collect and search but I don’t think it’s morally any different.
It doesn't matter what sort of business you are in, you need to have some ad-hoc communication that isn't part of a "permanent record", or else you incur communication friction everywhere.
Having it broken down by system is a pretty practical approach.
Depends on the company. At our 6 year old startup, email is dead except for external communication. Everything is on slack including ops, stand ups and informal communication. At Google, hangouts was lightly used but everything was on email.
Yup. I can't think of last email that was sent within my startup. Only clients and partners. Though some partners we have shared slack rooms, so even that may be going down.
Those integrations are slack's moat, but I think many of those useful integrations are already multi-tenant (having to support hipchat for large corps), or through a proxied service that can add a new output integration. For smaller businesses who just use the slack connector store that might be more difficult.
Author here. Slack is undoubtedly sticky, although I challenge the assumption that all integrations need to be replicated in a niche play. Those who did adopt Level were willing to give up a number of integrations that were low-value to them or were just causing noise that proved unnecessary.
I was struck with " They recognize that Slack is not suitable for meaningful conversations, so they automatically delete chat messages older than a few weeks to discourage relying on it for long-term archival." in your article.
It's something I feel quite strongly about: chat should not be archived. There should be no backscroll; being not around when people are talking means not being part of that conversation. Chat messages have no value beyond the moment. Any chat implementation that assigns importance to messages beyond the current conversation is wrong.
For the rest... It was like peeking into an alien world. I've been maintaining an open source application since 2004, and I've had various day jobs, but managed to build it out into my day job the past couple of years. I've never had the startup itch :-) Just let me build up my userbase, my income stream and my contributor team, and I'm happy.
> being not around when people are talking means not being part of that conversation.
Persistent chat is one of the biggest values of Slack or Discord or Mattermost, and one of the big reasons I'll take it over IRC any day.
Persistent chat that you can join and read the backlog of is incredibly valuable. It becomes an asynchronous communication medium, rather than a synchronous one. And it's much richer and lower-friction than email.
With people having the expectation of chat to be instantly replied, like a chat in a real life (someone walking to your desk and saying something) it is not asynchronous in any way.
You seem to suggest people have that expectation, but I think it might be very culture specific. Where I come, people will not freak out if it takes you a day to respond to an SMS.
Agreed about being able to access some backlog being important, but even in well-implemented systems with good search etc. I personally haven't found backlog older than maybe a few weeks that useful.
Similarly, I'd disagree about friction, but I can see how that might be cultural/personal preference - none of the chat systems I've used provides good-enough tracking of "I still need to take care of this" compared to email clients with a few flags.
> It's something I feel quite strongly about: chat should not be archived. There should be no backscroll; being not around when people are talking means not being part of that conversation. Chat messages have no value beyond the moment. Any chat implementation that assigns importance to messages beyond the current conversation is wrong.
What's the value in removing this? I regularly look back to see what was discussed, it allows easier integration across timezones. I don't want to have to be around late for my American colleagues, or have to shift the conversation to large cc'd email. For chat I am involved in, why do you think I shouldn't be allowed a history of what I have talked about with people?
> There should be no backscroll; being not around when people are talking means not being part of that conversation.
We must use chat very differently, because I don't understand this.
The number of times I've found answers to problems ("How do I X? Why can't I get Z to work with vagrant?" etc) by searching through Slack channels, or viewing pinned messages that explained something (or had a workaround/fix for a problem) is huge. This has been especially helpful when joining a team, where searching the archives can be the first step in finding answers.
A lot of what we chat about could safely be ephemeral, but there's a significant amount of company / team knowledge which can be searched (or pinned). The friction necessary to have people put answers in Confluence (or similar) is high enough that often the answers (or discussions around them) are either never written, or not updated later.
I disagree. I use the search function in Slack all the time. Documentation can't replace the meta discussions that give you the bigger picture and help you resolve specific problems. Slack is like our company's own Stack Overflow.
My 2 cents is... don't give up. Make sales calls. Aim to get 100 rejections (makes rejection a metric to aim for, really, so less pain?). Then you get a better view of the market and the real pain points.
I think you could provide a compatible API, or a wrapper around your API that makes it (mostly) compatible, claiming that you do it for interoperability.
If you think that’s too risky, legally, an alternative could be to provide example code showing “to do X in Slack, do this on our API”. If your tool gets some traction, a third party wrapper might show up.
Isn't Mattermost pretty close? When I moved to a company with Slack, I recognized a lot of stuff from my previous job where some of the devs used Mattermost.
zulip has quite a few integrations too apparently.
I've been thinking about giving zulip a whirl with one of our smaller teams at work, and see how it compares to slack. Quite a few items on the "why zulip?" page really resonate with me.
I don't think it does make sense. Funded businesses die all the time. Google cancels products all the time. companies are acquihired and products end of lifed.
Even within organizations there are critically important employees.
At this point in time, Slack is a billion dollar unicorn that can magic money out of wherever it needs to keep going as long as it wants. It's not going away any time soon. The worst case scenario for Slack is acquisition and long slow death over a decade.
All it takes is one information leakage scandal, and customers will abandon Slack at the drop of a hat. It's just a chat app, so it's very easy to replace.
Equifax is a consumer product with uninformed customers, wherein the 'blowback' can't really be had by individual customers, rather, it has to pick up as a media storm.
Slack contains a world of sensitive corporate information.
Oddly though I don't recall any major email company losing gazillions of emails to a hacker either, but I could be wrong.
It's an existential risk for Slack, but not unlike most other SaaS companies as well, so it's just part of the cost of doing business a per the industry.
It's important not to forget that this isn't about whether Slack is something a company should adopt. Any such risk you can attribute to using Slack will be multiplied a million-fold with a nascent service being developed by a single person or startup. All of these are reasons to continue using Slack instead of switching to Level.
Actually it makes perfect sense for all the reasons you stated.
"Funded businesses die all the time. Google cancels products all the time. companies are acquihired and products end of lifed."
So it makes perfect sense to avoid Google offerings (especially consumer side ones, which Google kills whenever it wants) and avoid "funded businesses" and newcomers that in danger of being acquihired and EOLifed.
Letting the careless early adopt those kinds of services, and using only mature ones (that have proven their longevity and aren't going anywhere even if acquired) in your company, makes sense.
Month-to-month, a new project by a single developer has many times the probability of folding than a company like Slack does. Shack is a significantly lower risk.
Further, there is much higher trust that Slack would give a reasonable notification period of they decided to stop existing, compared with a single dev's project.
When you deal with a solution provided by a startup that is a one man army you can play with the product, but you don't trust it enough to buy it. The story tells exactly why you should never trust such a product. These are not socks, buy a pack of three and throw it away in 6 months, people expect to use the solution for 3-5 year and there is no guarantee there will be updates, upgrades and support even next month. Trust, risk management, rings a bell?
I don't think that's the kind of "mature" they were talking about. From context, I think it's pretty clear they were thinking about product maturity. If customers are suspicious of organizational stability, they use a different set of excuses. E.g., they'll ask about funding, large customers, track record.
But it's also true about presentation. If you're selling B2B, you have to be a business - preferably a convincing full-fat business with employees and an office and a reputation (for something, at least).
Otherwise you're a jumped-up contractor with a hobby project. And you're not going to be taken seriously as a business partner.
I learned this the hard way in the early 00s. It's one of the fundamental marketing elements in B2B, and it has nothing to do with the quality of the product, its features, its ability to solve problems for a convincing price, and anything rational.
You can even say that anything above the very lowest levels of corporate B2B marketing - excluding the trades and very small mom & pop SMEs, who are a separate market - is about projecting business charisma and potency, not so much about solving actual problems with any efficiency or effectiveness, and certainly not about solving them at an affordable cost.
It's entirely tribal. And if you're a one-person shop you're an outsider - effectively just a potential employee or remote temp - and not part of the tribe.
IMO no amount of marketing and validation can overcome this bias in B2B. You're just not going to be considered a worthy equal, no matter how you spin it, or how good your offering is.
Great post - it really resonated with me, having personally tried to do an overambitious startup that failed with a small budget. I agree with you that doing a 'lifestyle business' and getting to really zero in on a niche group's needs is an ideal area to be.
Thanks for sharing, and hope you find what you're looking for in your next venture (and keep sharing details!).
Level is a pretty well designed product. Tried it briefly and I really did like it. My team was already using other communication tools (not Slack, but email and other options) and using Level might have become an eventuality if I or someone else on my team pushed for it harder.
That said, as someone who also creates and launch products, I think it's hard to MVP into a space like this. It's better to wedge yourself into some aspect of that space and eventually branch out once you have a paying user base that already likes your product.
I work on something that would be a competitor to Level, so I'm sad to hear this, not only because of market viability, but also because I share the belief in Slack being anathema to any sort of focused work. There's a lot to unpack here, but briefly:
— The amount of effort, design expectation and polish everyone expects from a product is exponentially increasing. 'I'm one guy, Google is 75,000 people' is no longer a valid argument. Arguably it never was, but especially now you cannot ship a product that does not do what it says it will do to a very high degree. That effectively makes for longer product development processes and probably makes bootstrapped competitors to Slack unviable. At least, this was the logic I ended up going for institutional venture capital: it buys me the time to make it work.
— Non-real-time communication is useful when the team size grows above a certain point, however when that happens the companies grow and have higher expectations of their tools. So this market is an interesting one in that it largely forbids scrappy, just-alpha-don't-mind-me kind of products. Trying to sell to smaller (less than 5 people) startups will fail since they do not yet have a problem with Slack, and anything above, companies get increasingly desperate, however, the tool space rapidly diminishes as companies grow.
— This sort of non-real-time communication requires a lot of trust in other people in your company, in that they will see and eventually respond. In real-time, you can know if somebody hasn't responded in a few minutes. Your delay risk from a single question moves from a few minutes to a few hours, to a day, or larger if your team is distributed across the planet. It requires a certain type of team with this kind of trust to make it work. It's a cultural issue as much as a tools issue, and a good designer not only builds the tools to make things work, but also builds them in a way that they shape the team culture so that the tool can work. In our specific case, our main goal is to make your team a more trusting, more efficient one, not just to make you focus by reducing notifications spam.
— Derrick is a bit of a known person, with a podcast and all, and I think in this case it worked against him somewhat. He mentions receiving interest from his fans, this (fans of your personality) is an audience that converts especially poorly.
— Slack is a complex tool serving a variety of needs, so it is very hard to replace it without being Slack - and if you try that, you'll end up with just an inferior copy. However, what one can do is to handle a subset of tasks it does better than it. However, even this will take multiple years for a team that has no runway problems because of the expectation of polish mentioned above.
— "Everyone is lying", as a designer, I do take a bit of an issue with that: it's not that everyone is lying, but that everyone has different incentives. And when you're a known person, those incentives align with keeping you happy, so that you'd become their acquaintance for potential use in the future. This is not conscious, this is just human nature. This happens even when you are just a nice person that they don't know. Empathy from your users is a powerful thing. It is also your enemy.
They are not lying to you. They want you to be happy. I won't blame users for that. It is your (our / mine / other designers') job to counteract that.
I have a lot more, but I'll leave it here since this is already too long because I think about these all day every day. If you think this is interesting, though, happy to chat. (Email in my profile.) We're launching pilots in a few weeks. The core idea, I like to say, is that Slack is a marketer’s idea of what a good comms tool should be, while Aether Pro is an engineer’s.
Powerfully familiar. I have learned similar lessons. In my mind “The Mom Test” is the most important business book for high-tech entrepreneurs, and I wish it existed a few years before it was released.
I'm not sure I understand the business model Derrick was pursuing, but the objective seems very interesting. Maybe instead of shutting it down he should consider pivoting Level to a FOSS approach modeled on something like lichess. Maybe a set of early adopter companies would be interested in joining in to help build and support the product. There would obviously be less or maybe no immediate financial incentive in it for him, but he would be continuing with a very constructive aim. In my experience, that kind of involvement in a growing project usually pays dividends, one way or another.
I agree. It seems like he pulled the plug a bit early but honestly he would know better than all of us if it makes sense or not. Perhaps he have found a better project to sink his teeth into...
It seems like one of the main problems is that their target market was too large, and they were directly competing with slack which dominates that market. A better approach might have been to target a more niche market in the business communication tool space, and be the best tool in that space, before broadening to the wider market.
If you target the business communication space you are dead in the first second: you cannot compete to Skype for Business, for example, that is backed up and supported by Microsoft (and that matters a lot) and it is already feature-complete. Not unless you have a product that can compete on features and backed up with guarantees you will offer upgrades and support for many years, this is what companies want first.
The thing is Slack wouldn't be as successful as it is without some merits. I think understanding why it is so successful could be a very interesting exercise for anyone wanting to get into that market.
We actually have the opposite problem where I work. We have Slack and only a handful of people out of 50 use it regularly, all of which are remote devs such as myself. The only communication that works is face to face meetings or casual corridor conversations, so remote people are basically excluded from everything that happens. Email is generally useless too. Writing skills are not abundant here, when the emails do get answered.
The way I see it, it's not that people don't like Slack, it's that people don't like online chatting in general as the official way of communicating inside a company. I don't think that the solution to that problem could ever be another chatting tool.
Exactly. Chat means you need to stop what you're doing all the time and chat, which is hell for people who need quiet time to actually get work done. Email can be addressed when there is time for it. (and yes, in principle you can wait to reply in chat applications as well, but the drift is for people to expect quick response).
Chat is just as async as email or any online communication platform - there's no obligation to respond immediately, and you can disable notifications for as long as you please.
In practice, people expect a response in a relatively timely way, it is after all chat, not email. It does seem a lot of companies treat it explicitly as ephemeral (and therefore requiring frequent checks). Even slack deletes old messages for free accounts, and the search is pretty poor IME. It is also full of chatter irrelevant to the topic at hand as far as I've seen in the slack groups I've participated in (though I have avoided it for work, so have not experienced it working well in a work environment).
I can imagine it is very useful for responding to a live incident for example, so perhaps people use it for that sort of thing. For a developer working on product though it seems crazy to me to have a chat window open for any significant part of a working day. People work differently though I guess and perhaps I just haven't seen it used well.
I recently had to do this with https://chart.ly. We've had great success doing data visualization service projects, but building a product in this space just became untenable due to the market's maturity and my teams lack of resources.
Better to cut the cord than keep kidding yourself. Thanks for sharing!!
I read this, and all through the article I kept waiting for the part where the author would talk about his own experience using his own product.
What I'm getting at is that, its really difficult to get people to love something you build unless you love it yourself, Seth Godin touches on this in his book "This is Marketing"
I like the data driven approach to product development, but sometimes passion trumps data, if you build something you yourself cannot live without, it's much easier to slowly win people over to your way of thinking.
And if you say to me "well he was the only one working on it", then my answer to you is like that punchline in the Famous "Coming to America" skit ...
"aha!"
It is infinitely better to work on problems that you have a firsthand understanding of/experience with otherwise you're always going to be depending on others for product insight, which is not terrible, but much much harder than when those insights come from you directly.
> What I'm getting at is that, its really difficult to get people to love something you build unless you love it yourself
This reminded me of a quote which is totally the opposite, and imo more accurate: "Most entrepreneurs fall in love with the wrong thing. They fall in love with their products and their business when they should be falling in love with their clients and customers" -Jay Abraham
Both sentiments are however; worthy food for thought.
There’s a superb YC video that rephrased this correctly for me - be in love with the problem, not your current draft of a solution. Certainly not your first draft.
But you do need love. I had a similar experience with https://whatsgoingon.in - I fell in love with my own live blogging product, but I don’t have the problem of actually needing a live blog for anything in my life. That craters motivation pretty quickly.
I found that I am passionate about my skillset but not the industry as a whole. So my industry experience doesn't lend itself to spotting problems I can care about. Passion has never really affected my ability to deliver once I spotted a problem I thought I could solve, but I would be lying if I said I hadn't quit early on a few projects because I just didn't care if they failed. Sometimes I wish I were more ruthlessly in love with money to use that as a driver, but I'm not.
So I have been trying out developing cycling products. My skillset still applies, bootstrapping an online business and all the technology involved with it. Except now the purpose is delivering a product I care a bit more about. I am finding it far easier to stay motivated for this project. If only because I actually want to use it myself once it is done.
I'm exactly like that, if I feel the product has value, I can get behind it. I'm a good salesman for a 'good product'.
The flip side is that I have worked on many a drab project and site, that could have been improved with a little technical finesse, and simple UI overhaul, but there hasn't been the wherewithall from others. Hence perhaps an initially loved or cared for project has slowly declined.
I've also been at a startup, after many of the developers took the money and then departed. On a site that two founders had poured all their money into. People hadn't even the courage to tell them to quit, or throw out some un-needed features. That's almost heart breaking, but you do understand when those people have invested so much. I'm talking about remortagaging houses on a punt, to a pay a developer for a middle of the road product.
I've poured months of time into projects that have gone absolutely nowhere also for one reason or another. Not personal projects I might add. I have lost time and not been paid either. But by comparisson with the above have just taken it on the chin.
I get that, but the more intimate you are with a product, it's also hard to see the warts, especially when it comes to usability. I remember using ebay for the first time, and absolutely loathing the experience. I had to get used to the product. And there is much friction. Transparant simple UI is very hard. I am always noticing troublesome UI areas, and usually when mentioned, I get the response: oh that's just the way it is. Luckily you later forget those initial irritations. Anyway, just saying however critical you are, you are likely not the best person to reveal insights into your own product.
On a more abstract level I feel he was trying to enable/enhance deep work, just this particular implementation didn't fly the way he expected it to. Instead of targeting people who are somewhat annoyed by slack and the like I believe the whole value proposal should be more along the lines of promoting the concept and benefits of deep work.
I've actually been following Derrick and the development of level on GitHub. The code is open source. It's remarkably well engineered and I use it as a source of reference for my own codebases.
So while probably unintentional, he's already helped others by building it.
I built and ran a groupware/crm system from 2001 to 2009. But didn't get the traction I needed and couldn't afford the co-located hosting any longer. I spent 3 years developing it full-time myself and very part time on it the rest of the time. While also supporting a wife and two kids.
I moved it to very cheap hosting, told everyone it was closing, but then never closed it but didn't accept new signups. Checking now there is still a little usage in 2019 (although the majority of usage stopped in 2016).
It costs me $20 to keep alive, using GoDaddy. It was $14 a month but GoDaddy keeps raising their hosting price with no notification.
Eventually I will re-design the UI to Boostrap to make it modern and relaunch it.
What I am trying to say is if you made something nice that you like, you can keep it alive and work on it sometime in the future. You never know when Slack is going to bought out and then eventually die. You could be the DuckDuckGo to Google but for Slack. If you had a million dollar marketing budget things would be different.
220 comments
[ 3.1 ms ] story [ 261 ms ] threadThat aside, I wish Slack was more customizable (or open to allowing some customization) that would enable it to function more like what Derrick was trying to accomplish with Level. That would be the best of both worlds.
Ideally you have orders for the product before you start building it, don't put all your eggs in if I build it they will come.
Exactly. The best validation is people paying for a product.
The ideal way to validate it is to be so immerse in the industry/problem such that you understand most of the pain points. Do the job that your ideal customer is doing. Attend the conferences they're going to. Visit the forums they're visiting. Read the websites they're visiting. Analyze the reviews they're posting in TrustRadius/G2Crowd. Look at their Linkedin profiles to see what their day to day involves.
I think this is a great reason to have a co-founder. I co-founded a company with a domain expert, and her ability to get in front of and understand our target audience was way more important to our startup success than my development ability (and the equity shares reflected that). I mean, we needed each other, but she was far more unique than I was.
The alternative for a developer is you immerse yourself into a different domain, or you build tools for developers. Both of which are good paths, but the former is far more time commitment and latter is more common (and thus more competitive).
It's called an inducement for a reason.
Too many "product people" or "visionaries" or whatever just don't know how to do user research and validation.
Too many people also have no idea how to solicit unbiased feedback and too many rely on asking questions and not nearly enough observation or testing.
Though I have had good experiences talking to different industries because it could be as simple as a 20 min phone call.
I find that if people are really facing problems that they want to get rid of and someone is genuinely interested in solving it for them, they are usually open to chatting. It does take some effort to reach out.
I have had success talking to 30-50 individuals before I come up with a solution and customer development is also a skill that needs to be develop .
For instance, cold call companies and pretend you have the best version of your product on the phone or create a landing page that offers your "future product", buy PPC ads, and get people to fill out a lead gen form.
In both cases, once you talk a little bit, let them know the product is still under development and ask if they'd like to be contacted again once development is done.
So its critical that you find a good sponsor/client in the early days. One that you have easy access to and you work together with until your product gets to the point where its utility is obviously apparent to new clients. And work it from there.
When your working with your first client they will inevitably drag you down into the small details (improve this/ make this). I call these the "meh" features. What you need to do is focus on analysing the underlying reason why they want the "meh" features and work on eradicating that reason. If you crack it, you get a "wow" feature. And that brings traction.
For example, we designed a financial platform for schools in a developing country. Finance operations in schools is complex with varying chains of manual processes. Our "meh" features were digitising these processes, improving each individual task. Our "wow" feature was to completely automate the end-end process for a small subset of schools with similar requirements. Instead of making their tasks easier, we just completely removed the need to do them. After that it was pretty apparent what we had to do.
After doing 10-20 of those interviews, I got pretty good at coming up with an internal "pain scale" - where this particular problem sits in terms of overall pain the customer is experiencing, and thus how much they are willing to commit to solving the problem.
Read “The Mum Test”[1]. It will make you aware that you to get unbiased feedback you need to remove your identity from the idea so that people aren’t nice to protect you.
[1] http://momtestbook.com/
They were miswanting. And it's a HUGE glossed over fact when talking to customers.
https://en.wikipedia.org/wiki/XY_problem
My point is that I believe hypotheticals take a lot pressure off and allow you to be super vague in interviews. For the past, talk about real situations. For the present, do a role play.
Unfortunately I only read it after making all the mistakes it lists - but I know from personal experience that everything it says is correct.
Basically, if you want to find out whether you're baby's ugly, you have to make sure people think the photos are of a baby, not your baby.
As an example, I mentored at Lean Startup Machine. We'd have them form up into teams around ideas. The first thing they'd ask for was verbal feedback. But they were quickly supposed to move to increasing levels of demonstration of commitment.
One team, for example, had the notion that restaurants needed an easier way to get insight into customer experiences. They went out and found restaurant managers, and first confirmed that they had the hypothesized problem. But they quickly moved beyond words, asking if the managers would be willing to let them trial the system in the restaurant. Since enough of them said yes, they build something simple and put those little printed cardboard triangles on a bunch of tables. They then hacked together reports for the managers based on the data collected. The managers liked the reports. They then asked the managers how many would be willing to pay, right then, some modest monthly charge for ongoing use of the system.
If I recall rightly, this team discovered that when actual money was on the line, the reports were just a nice-to-have. In that situation, it's still reasonable to persevere, as you may have hypotheses about what really will get them to cross the line. But it's also reasonable to kill the idea.
There's a big difference, though, between what is taught and what people do. I was an early adopter of both the Agile movement (XP in particular) and Lean Startup approaches, and in both cases I'm kinda horrified by what it turned into in practice. With the Agile movement, it was quickly captured by companies who wanted to feel like they were doing something different while still retaining most of their top-down pathologies and high-debt code bases.
With the Lean Startup approach it's harder to say how it turned out, as early-stage startups rarely produce reports like this. But my general impression is that, as with Agile, people pick the parts that seem fun and easy, and avoid the hard parts. I think this was made worse by the flood of VC money, especially around Uber-for-X startups. Who wants a method that will kill your probably-bad idea early if you can get tens or hundreds of millions? The bad idea might work out or you might thrash your way to a good one. And if it still failed? Well, now you're a seasoned founder of a venture-backed startup. By some measures, although not mine, that's way better than having a quiet, cheap failure.
http://www.paulgraham.com/makersschedule.html
Edit: Okay this came out pretty harshly, but what I am poorly trying to express is that most people spend more time on worse things, so "a year" doesn't parse as the intended intensifier for me.
We usually sit right at the center of our main monitor for a reason. Reading that website on a large 32'' monitor is annoying.
Oh, please. You may have some rationale that makes a certain kind of sense, but clearly a lot of others don't care, or value other things. So ... subjective.
P.S. I read @rwalling's "Start Small, Stay Small" a few months back, and it was a phenomenal read. Highly recommend.
I learned almost precisely the same lesson in the same way over the same amount of time (a year) a few years back.
It was _incredibly_ helpful to have those insights going into my next startup, and I approached customer development entirely differently.
Lessons learned can be quickly applied!
"In hindsight, I took on an unreasonably audacious endeavor with Level in part because of my internal “this might get big if I play my cards right” dialogue. It would have been far better to either deliberately go for the big idea (and probably seek venture funding to make it happen), or start far smaller and build my way into a sustainable company of one."
I appreciate this passage... a thoughtful reflection.
Before a Slack-using company would switch, the competitor would need to support many/most/all of the integrations that the company is using. You've really only got two chances to win Slack's customers: the point before they seriously adopt Slack, and the point in the future where Slack does something stupid like jack prices way up or suffer a serious breach.
But I think your point about MS getting rid of Skype for Business in favor of Teams is the most important one. Once that happens, which MS has stated publicly, Teams will become a necessary app for MS to support, since enterprises won’t tolerate MS not having s chat service in O365.
So my view is that until Microsoft get their act together, Teams is not a serious contender to Slack. Companies can get it "free" together with their Office subscription, but most developers won't use it until it works decently on their development platform of choice.
Something like: there are all kinds of email integrations, user-specific and group-specific setups, etc. at companies. How can Slack ever compete?
The answer was that Slack was so much better for many companies that it made sense to suffer the pain of switching.
The company that beats Slack will likely be 10x better communication software or something very similar but distributed much more effectively (maybe Microsoft Teams in the enterprise).
Running two chat systems side by side, on the other hand, is a huge pain. There really is a pressure to get everything migrated and the old one turned off.
We lost a law suit once because a [not native English speaker] wrote "the bearing will fail with disastrous consequences", he meant the shaft would need to be replaced, but when a fire started in the area of the bearing that email was part of discovery and the jury decided the bearing was at fault for the fire not the user failing to clean the area which was our story. (legal would rather I not give you the case to read for yourself)
Chat tends to be less formal than email, thus more opportunity exists for something that is easy to take out of context. By not allowing saving chat logs we ensure they they will never get to court.
We have strict rules that emails must be deleted after a few months (unless we legally need to keep them). Any information in the email that is worth keeping longer than that is put in a formal system where legal can examine the words to ensure they won't be taken out of context and used against us.
Having it broken down by system is a pretty practical approach.
It's something I feel quite strongly about: chat should not be archived. There should be no backscroll; being not around when people are talking means not being part of that conversation. Chat messages have no value beyond the moment. Any chat implementation that assigns importance to messages beyond the current conversation is wrong.
For the rest... It was like peeking into an alien world. I've been maintaining an open source application since 2004, and I've had various day jobs, but managed to build it out into my day job the past couple of years. I've never had the startup itch :-) Just let me build up my userbase, my income stream and my contributor team, and I'm happy.
Persistent chat is one of the biggest values of Slack or Discord or Mattermost, and one of the big reasons I'll take it over IRC any day.
Persistent chat that you can join and read the backlog of is incredibly valuable. It becomes an asynchronous communication medium, rather than a synchronous one. And it's much richer and lower-friction than email.
Similarly, I'd disagree about friction, but I can see how that might be cultural/personal preference - none of the chat systems I've used provides good-enough tracking of "I still need to take care of this" compared to email clients with a few flags.
What's the value in removing this? I regularly look back to see what was discussed, it allows easier integration across timezones. I don't want to have to be around late for my American colleagues, or have to shift the conversation to large cc'd email. For chat I am involved in, why do you think I shouldn't be allowed a history of what I have talked about with people?
We must use chat very differently, because I don't understand this.
The number of times I've found answers to problems ("How do I X? Why can't I get Z to work with vagrant?" etc) by searching through Slack channels, or viewing pinned messages that explained something (or had a workaround/fix for a problem) is huge. This has been especially helpful when joining a team, where searching the archives can be the first step in finding answers.
A lot of what we chat about could safely be ephemeral, but there's a significant amount of company / team knowledge which can be searched (or pinned). The friction necessary to have people put answers in Confluence (or similar) is high enough that often the answers (or discussions around them) are either never written, or not updated later.
Great article, very informative. Thank you for the effort.
If you think that’s too risky, legally, an alternative could be to provide example code showing “to do X in Slack, do this on our API”. If your tool gets some traction, a third party wrapper might show up.
Maybe not in the US, where APIs are under copyright, but outside it could work...
Nothing new here of course, tech shops have been doing it for decades. Centuries even maybe.
See also: certification programs.
I've been thinking about giving zulip a whirl with one of our smaller teams at work, and see how it compares to slack. Quite a few items on the "why zulip?" page really resonate with me.
They all made the right decision, as it folded only a couple months later.
Even within organizations there are critically important employees.
So, no, it doesn't make sense.
Slack contains a world of sensitive corporate information.
Oddly though I don't recall any major email company losing gazillions of emails to a hacker either, but I could be wrong.
It's an existential risk for Slack, but not unlike most other SaaS companies as well, so it's just part of the cost of doing business a per the industry.
"Funded businesses die all the time. Google cancels products all the time. companies are acquihired and products end of lifed."
So it makes perfect sense to avoid Google offerings (especially consumer side ones, which Google kills whenever it wants) and avoid "funded businesses" and newcomers that in danger of being acquihired and EOLifed.
Letting the careless early adopt those kinds of services, and using only mature ones (that have proven their longevity and aren't going anywhere even if acquired) in your company, makes sense.
Further, there is much higher trust that Slack would give a reasonable notification period of they decided to stop existing, compared with a single dev's project.
Otherwise you're a jumped-up contractor with a hobby project. And you're not going to be taken seriously as a business partner.
I learned this the hard way in the early 00s. It's one of the fundamental marketing elements in B2B, and it has nothing to do with the quality of the product, its features, its ability to solve problems for a convincing price, and anything rational.
You can even say that anything above the very lowest levels of corporate B2B marketing - excluding the trades and very small mom & pop SMEs, who are a separate market - is about projecting business charisma and potency, not so much about solving actual problems with any efficiency or effectiveness, and certainly not about solving them at an affordable cost.
It's entirely tribal. And if you're a one-person shop you're an outsider - effectively just a potential employee or remote temp - and not part of the tribe.
IMO no amount of marketing and validation can overcome this bias in B2B. You're just not going to be considered a worthy equal, no matter how you spin it, or how good your offering is.
Thanks for sharing, and hope you find what you're looking for in your next venture (and keep sharing details!).
That said, as someone who also creates and launch products, I think it's hard to MVP into a space like this. It's better to wedge yourself into some aspect of that space and eventually branch out once you have a paying user base that already likes your product.
Good luck on your next endeavour.
— The amount of effort, design expectation and polish everyone expects from a product is exponentially increasing. 'I'm one guy, Google is 75,000 people' is no longer a valid argument. Arguably it never was, but especially now you cannot ship a product that does not do what it says it will do to a very high degree. That effectively makes for longer product development processes and probably makes bootstrapped competitors to Slack unviable. At least, this was the logic I ended up going for institutional venture capital: it buys me the time to make it work.
— Non-real-time communication is useful when the team size grows above a certain point, however when that happens the companies grow and have higher expectations of their tools. So this market is an interesting one in that it largely forbids scrappy, just-alpha-don't-mind-me kind of products. Trying to sell to smaller (less than 5 people) startups will fail since they do not yet have a problem with Slack, and anything above, companies get increasingly desperate, however, the tool space rapidly diminishes as companies grow.
— This sort of non-real-time communication requires a lot of trust in other people in your company, in that they will see and eventually respond. In real-time, you can know if somebody hasn't responded in a few minutes. Your delay risk from a single question moves from a few minutes to a few hours, to a day, or larger if your team is distributed across the planet. It requires a certain type of team with this kind of trust to make it work. It's a cultural issue as much as a tools issue, and a good designer not only builds the tools to make things work, but also builds them in a way that they shape the team culture so that the tool can work. In our specific case, our main goal is to make your team a more trusting, more efficient one, not just to make you focus by reducing notifications spam.
— Derrick is a bit of a known person, with a podcast and all, and I think in this case it worked against him somewhat. He mentions receiving interest from his fans, this (fans of your personality) is an audience that converts especially poorly.
— Slack is a complex tool serving a variety of needs, so it is very hard to replace it without being Slack - and if you try that, you'll end up with just an inferior copy. However, what one can do is to handle a subset of tasks it does better than it. However, even this will take multiple years for a team that has no runway problems because of the expectation of polish mentioned above.
— "Everyone is lying", as a designer, I do take a bit of an issue with that: it's not that everyone is lying, but that everyone has different incentives. And when you're a known person, those incentives align with keeping you happy, so that you'd become their acquaintance for potential use in the future. This is not conscious, this is just human nature. This happens even when you are just a nice person that they don't know. Empathy from your users is a powerful thing. It is also your enemy.
They are not lying to you. They want you to be happy. I won't blame users for that. It is your (our / mine / other designers') job to counteract that.
I have a lot more, but I'll leave it here since this is already too long because I think about these all day every day. If you think this is interesting, though, happy to chat. (Email in my profile.) We're launching pilots in a few weeks. The core idea, I like to say, is that Slack is a marketer’s idea of what a good comms tool should be, while Aether Pro is an engineer’s.
The thing is Slack wouldn't be as successful as it is without some merits. I think understanding why it is so successful could be a very interesting exercise for anyone wanting to get into that market.
We actually have the opposite problem where I work. We have Slack and only a handful of people out of 50 use it regularly, all of which are remote devs such as myself. The only communication that works is face to face meetings or casual corridor conversations, so remote people are basically excluded from everything that happens. Email is generally useless too. Writing skills are not abundant here, when the emails do get answered.
I have no idea how other programmers tolerate chat as a communications medium for work. Why would you prefer chat over other async mediums?
I can imagine it is very useful for responding to a live incident for example, so perhaps people use it for that sort of thing. For a developer working on product though it seems crazy to me to have a chat window open for any significant part of a working day. People work differently though I guess and perhaps I just haven't seen it used well.
Better to cut the cord than keep kidding yourself. Thanks for sharing!!
I've spent years building products, the first year is alpha at best.
Distraction is not a problem with slack, it is an individual problem that must be solved by everyone individually.
What I'm getting at is that, its really difficult to get people to love something you build unless you love it yourself, Seth Godin touches on this in his book "This is Marketing"
I like the data driven approach to product development, but sometimes passion trumps data, if you build something you yourself cannot live without, it's much easier to slowly win people over to your way of thinking.
And if you say to me "well he was the only one working on it", then my answer to you is like that punchline in the Famous "Coming to America" skit ...
"aha!"
It is infinitely better to work on problems that you have a firsthand understanding of/experience with otherwise you're always going to be depending on others for product insight, which is not terrible, but much much harder than when those insights come from you directly.
Don't find it but it sounds fun! Got a link?
This reminded me of a quote which is totally the opposite, and imo more accurate: "Most entrepreneurs fall in love with the wrong thing. They fall in love with their products and their business when they should be falling in love with their clients and customers" -Jay Abraham
Both sentiments are however; worthy food for thought.
https://youtu.be/vDXkpJw16os
But you do need love. I had a similar experience with https://whatsgoingon.in - I fell in love with my own live blogging product, but I don’t have the problem of actually needing a live blog for anything in my life. That craters motivation pretty quickly.
This is also data driven. It may be mere "datum", but complex, with many components, far richer than any statistical data.
So I have been trying out developing cycling products. My skillset still applies, bootstrapping an online business and all the technology involved with it. Except now the purpose is delivering a product I care a bit more about. I am finding it far easier to stay motivated for this project. If only because I actually want to use it myself once it is done.
The flip side is that I have worked on many a drab project and site, that could have been improved with a little technical finesse, and simple UI overhaul, but there hasn't been the wherewithall from others. Hence perhaps an initially loved or cared for project has slowly declined.
I've also been at a startup, after many of the developers took the money and then departed. On a site that two founders had poured all their money into. People hadn't even the courage to tell them to quit, or throw out some un-needed features. That's almost heart breaking, but you do understand when those people have invested so much. I'm talking about remortagaging houses on a punt, to a pay a developer for a middle of the road product.
I've poured months of time into projects that have gone absolutely nowhere also for one reason or another. Not personal projects I might add. I have lost time and not been paid either. But by comparisson with the above have just taken it on the chin.
I've actually been following Derrick and the development of level on GitHub. The code is open source. It's remarkably well engineered and I use it as a source of reference for my own codebases.
So while probably unintentional, he's already helped others by building it.
I moved it to very cheap hosting, told everyone it was closing, but then never closed it but didn't accept new signups. Checking now there is still a little usage in 2019 (although the majority of usage stopped in 2016).
It costs me $20 to keep alive, using GoDaddy. It was $14 a month but GoDaddy keeps raising their hosting price with no notification.
Eventually I will re-design the UI to Boostrap to make it modern and relaunch it.
What I am trying to say is if you made something nice that you like, you can keep it alive and work on it sometime in the future. You never know when Slack is going to bought out and then eventually die. You could be the DuckDuckGo to Google but for Slack. If you had a million dollar marketing budget things would be different.