Walking Away from the Product I Spent a Year Building | Hacker News Reader

Walking Away from the Product I Spent a Year Building

derrickreimer.com

494 pointsrwalling215 comments

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.

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.

Best case scenario: you are the customer. In this case, both sentiments can be true.

Turns out that the real productivity hack was learning to love yourself.

I think a great example of the eat-your-cooking thinking is Slack itself. It started out as an in-house tool at Butterfield's now-defunct game company Glitch: https://readwrite.com/2013/08/14/stewart-butterfield-tiny-sp...

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.

> then my answer to you is like that punchline in the Famous "Coming to America" skit ...

Don't find it but it sounds fun! Got a link?

https://www.youtube.com/watch?v=CKsSvR5u-qk

That's actually really good

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.

> problems that you have a firsthand understanding of/experience of

This is also data driven. It may be mere "datum", but complex, with many components, far richer than any statistical data.

"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.

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).

Sure people will give you their time. It's very simple to get. Pay them.

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.

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.

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.

Pay could be a fancy lunch while discussing the issues.

You don't need them to clear up a whole day, and people are surprisingly willing to talk about their job and their frustrations.

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.

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 .

This was the post that made the lights come on for me: https://customerdevlabs.com/2013/11/05/how-i-interview-custo...

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.

[1] http://momtestbook.com/

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.

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...?"

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.

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.

He used the word lying. They didn't know they were lying.

They were miswanting. And it's a HUGE glossed over fact when talking to customers.

Yes, it's the customer development version of the XY problem.

https://en.wikipedia.org/wiki/XY_problem

Can’t recommend this book highly enough.

Unfortunately I only read it after making all the mistakes it lists - but I know from personal experience that everything it says is correct.

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

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.

> hotcakes that's your validation

Exactly. The best validation is people paying for a product.

I would go so far as to say it’s the only unambiguous validation you can get.

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.

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 Paul Graham essay on start up ideas comes to mind [1]. Everybody kinda wanted this product but they didn't need the product. This paragraph sums it up:

> The danger of an idea like this is that when you run it by your friends with pets, they don't say "I would never use this." They say "Yeah, maybe I could see using something like that." Even when the startup launches, it will sound plausible to a lot of people. They don't want to use it themselves, at least not right now, but they could imagine other people wanting it. Sum that reaction across the entire population, and you have zero users.

Granted, it's not like I possess a magical "good startup ideas" power. And I don't have a successful startup under my belt. But still, I find it curious that many people haven't read this essay.

[1] http://www.paulgraham.com/startupideas.html

The problem I see, from briefly looking at the landing page is that you can achieve what you want on Slack by disabling notifications and then checking slack every hour or so, when you've just committed some code and feel like your mental cache can be flushed. This is what I do. There isn't a big enough problem being solved, especially to move away from the slack ecosystem. Even if the 'other' product had all the things slack has, the cost of getting another tool and getting used to it seems too high when that effort could be put into swapping a different tool for a different reason with more upside for the team. The cost of the product itself in this equation is almost irrelevant.

Having said that no one wants to be the "Dropbox is just rsync " guy. Or Lily Allen turning down thousands of bitcoins (although she's successful anyway so she probably shouldn't care). If you see what I mean ... no one wants to say an idea sucks before hand, and if they do you can just say "well they said that about Dropbox".

If there's one thing Hacker News lacks, it's biting criticism and pessimism :P

Kidding aside, I see your point. I guess it's important to distinguish between criticism and dismissal of an idea. "Dropbox is just rsync" seems like a dismissal, not a critical look at the validity of the idea. And Lily Allen turning down bitcoin? Well honestly I'm a little with her on that one. "Oh yeah can you perform and we'll pay you with a totally legit online currency we swear." Not exactly a great sell.

He did get people to pay before even launching, so I don't know if reading this would have swayed him much. He had a considerable amount of positive signals. The lesson may have been how much these signals were skewed by the source of the signal (e.g. fans of his podcast).

I actually use a completely different criterion.

If I see people constantly resorting to bad solutions and complaining, when a tech solution could solve the whole thing, I like the idea.

Then I think whether I can make it viral and engaging to bring user acquision costs to zero.

If yes - it can be done!

Hindsight is 20/20.

Completely so. I don't want to act like I know better–I don't. But the lessons of this post do line up with the lessons in the essay.

this is what I needed to hear

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.

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.

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.

People expect an instant response on chat, but reading emails from time to time. That makes a huge difference in interruptions when you work.

This is dependent on a particular workplace's culture, not an inherent aspect of the technology.

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.

Curious, how large is the startup?

In the ballpark of 140.

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.

What's the rationale behind that?

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.

You can make chat unavailable after x months along with email. Of course if actively being sued that may be longer.

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.

I suspect that part of it might be legal. It's too easy for someone to say something in chat that will look bad when you're sued.

I can organize and search my mail archive much better than chat, and I disable the notifications on chat anyway, so I'm not sure about that.

Email feels more asynchronous than chat. With an email, I don't expect an immediate answer, and I expect a better-researched answer.

Well, and email integrations are easy to replace - it's a single, uniform interface.

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.

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.

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.

SMS is NOT chat.

That's also culture-specific.

> 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.

Don’t use confluence. There are knowledgebases with way less friction.

Please name them for those of us looking

I'm also super interested in better, or more usable, recommendations.

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.

> Author here

Great article, very informative. Thank you for the effort.

There's a lesson in there, viz. that an ISV ecosystem around your product is a major retention factor.

Nothing new here of course, tech shops have been doing it for decades. Centuries even maybe.

See also: certification programs.

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.

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.

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.

Microsoft Teams with their decent video conferencing might have an angle plus being “free” part of 365.

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.

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.

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.

Couldn't you offer an integration API that's compatible with Slack?

Maybe not in the US, where APIs are under copyright, but outside it could work...

What's stopping potential competitors from making slack-compatible APIs?

This.

"Every large team I spoke to had an exceptionally high bar and was unwilling to entertain Level until it was significantly more “mature.”"

They all made the right decision, as it folded only a couple months later.

That kind of circular reasoning is only more maddening because it makes sense. It is a self-fulfilling prophecy combined with a prisoner's dilemma.

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?

It also requires time travel to implement; the folding knowledge was not known at the time of decision.

You don't need a time travel device, just a bayesian prior on probability of folding. (which happens to be close to one.)

It's not time travel, it's risk management.

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.

So, no, it doesn't make sense.

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.

I am willing to bet that 99% of users will not blink an eye if there was an information leak. See Equifax, Facebook..

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.

Big difference with Corp data. Even FB never leaked that.

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.

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.

That's correct, I was referring to feature-richness.

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.

Harsh, but completely true

Every company has a "first customer"

It is hard to entertain a messaging product for which the author says they’re explicitly intending to stay solo.

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.

Good luck on your next endeavour.

Thanks so much

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.

This is sensible. Nice point of view

I've been listening to The Art of Product podcast since the start and Level really didn't make sense to me as a solution even though I understood the problem.

Most issues are around context and focus when moving from an individual contributor to a lead. If a programmer I'm leading doesn't implement a feature in a way that I expect it is because the context that is in my brain hasn't been transferred to the programmer's brain. If a feature isn't being worked on then I having communicated focus and priority.

A solution would focus on revealing context and focus by:

1) Deeply integrating with Slack, JIRA, Github, etc. The tools that we already use. A new product can't be a silo.

2) Mobile or GTFO. Leads are in meetings, on airplanes, in transit, etc.

#2: it depends on the kind of team you have. My team of developers never had any chat client installed on their mobile for work use, they were either in front of their computers or away and not available. We did not discuss in airplanes as we were trying to focus when we had discussions, not to board and block the other passengers because we were busy chatting in the middle of the embark flux.

My take is that this was a case of hubris. Can happen to the best of us. Where it really derailed was here:

“Others were not decision makers, so I had to take their feedback with a grain of salt.”

Most users of this kind of product are not decision makers, at least when it comes to selecting the product. But they are the ones that have to use it and their opinions are critically important.

The idea of soliciting feedback before building a start up really doesn’t make sense to me. If you like your idea (“this is something I’ve always wanted”), are willing to dedicate yourself and have the means then you should try it. Otherwise you’ll never find out. If the creator of the automobile had listened to people they probably would’ve thought it was a dead end because unlike horses cars can’t reproduce. The idea that you can explain your vision to people who will spend one minute thinking about it with you and get useful feedback is also not obvious. Build the product or you’ll never know.

That's true of products that are true innovations, that is, they create entirely new product categories. Here, however, he's just improving on an existing product. Getting opinions about what's wrong with the current product makes a lot of sense.

For sure. I've worked in finance and we did tons of market research when before giving loans to companies like Rite-Aid, CVS, etc, knowing that they did their own market research, too. But, I'm not sure how far that carries over to tech. Even "commodity" ideas aren't always so commodity in this sector.

The cold hard truth is that just because you like it and want to build it doesn't mean anyone else gives a shit.

The idea that everyone should just roll the dice with months/years of their lives because they like an idea isn't actually tenable.

That's what I'm saying, but I'd go further that even in 100/100 people tell you that they love your idea, that may translate into 0/100 using it. You shouldn't just try anything willy-nilly, but you won't know until you try it.

It is a matter or wording: you don't ask for feedback per se, you do user research to understand their needs and their pain points with existing solutions. Developers are not necessarily good communicators :)

> If the creator of the automobile had listened to people they probably would’ve thought it was a dead end because unlike horses cars can’t reproduce.

Actually, a true story: Ford said that if he were to listen to what people want better than a horse, he would have built a carriage with hitch for 6 horses :)

It's not a true story. People wanted less manure and fewer horse corpses. They were thrilled with the automobile because it neatly solved their top two transportation complaints.

Not sure about my particular anecdote, I can't verify that to be accurate or attribute it to Ford (I have heard it on many occasions, and even once saw a clipping from a newspaper but can't find it now), but https://www.saturdayeveningpost.com/2017/01/get-horse-americ...

Skeptical at first, but came around quickly. The quote is apocryphal.

> If I’d asked people what the wanted, they would have said, ‘A faster horse’

Is how I believe that quote goes.

Sorry but the outcome seemed obvious from the get go. Of course you weren’t going to be able to single handedly replace a platform like slack, while improving upon the pitfalls it’s creating in cross-team communication. The insight into your experience is great, but it’s really the type of thought that is born and dead within a few minutes of most developers minds. Especially when we think of the effort and consequences of such an endeavor.

> “Ugh, Slack distracts me so often. You’re right; everything feels urgent even when it’s not. I’m super interested in what you’re building here. We’re pretty open to change at my company – I don’t see switching being too big of a deal.”

This is such a common mistake. When doing customer development, do NOT stick to asking "would this be of general interest to you?". In fact, you can get away with not asking this at all. Instead ask: "how much would you pay for this?" And if you like the price tag, also throw in: "can we set a date to sign next week/month/quarter?"

Though 'would this interest you?' may not be the way to start, neither would 'how much would you be willing to pay?' either.

Consider that even for established products 'willingness to pay' may be zero until there's a sales process i.e. they trial it, they like it, they discover some things, then the sales person starts to do a 'close'.

The problem with the 'how much would you pay for it' kind of discovery is it misses the opportunity for the company to determine in a material way why it's valuable to them.

There's a similar problem in consumer land as well, you can't hardly establish price points by asking how much people will pay.

Also - price isn't really the big concern. It's not going to be a margin issue, it'll be a volume issue if anything. The price for such a service would probably be very low per-person, to the point of not being that important. Price is not the big point.

And since companies will pay for stuff they find valuable ...

The 'real' question you want answered is: 'will they find this thing useful' in one way or another, or better yet 'what problems near my product do they need solved' so the maker can add that functionality or even pivot a little bit.

I think it's possible to rationalize the process of getting to that point, unfortunately it often takes industry experience beforehand, and probably a longer dev curve up front with some willing pre-customers.

I have a lot of similar thoughts about Slack and also had the idea to go head to head with it a couple of years ago. I partnered with a PHD researcher who had expertise in the area of focus.

Before I started building I launched a paid sales campaign to see if people would be interested with a mocked up website looking like we already had the product. I had a lot of website visitors, but nobody signed up for a demo. Not one person. At that point I realized that whether or not the product was a good idea, I didn't know how to sell it, so I ditched the idea, deleted the test website and moved on.

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!!

Not hosting my data in Libya!

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.

Great post, Derrick!

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!

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.

Thanks so much!

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!).

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.

Original post about "The Madness"

http://justinvincent.com/page/951/the-madness-the-all-consum...

"It is not the function of the artist to be the critic. The winnowing out, the deciding what is good from what is bad, comes later. That is a community process. The community decides what is good and bad art. But the individual should pour this forth." - Terence McKenna

What I take from this as an entrepreneur is: Have a vision and bring it into the world. The market response, and the financial outcome, are irrelevant.

If you disagree, it's probably because you feel that the ultimate goal of entrepreneurship is wealth. I used to believe this myself, and I can certainly understand the perspective of those who do.

As for the article, this line is pretty telling:

> make a bold statement about the problem (without too many specifics about the solution) and gather email addresses of people who wanted to join the movement

This particular journey seemed a lot more "tell me what to build and how to make money from it" than "here is my vision," and there's already some grandiose idea of a "movement" before even some vague outline of an actual solution/product have been conceived.

There's also a strong whiff of the toxic "fail fast" mentality. Oftentimes, tremendous persistence and radical care are the difference between success and failure. I shudder to think how many fantastic products have died under this type of thinking, when the real issue was some deficiency in execution, positioning, etc.

I say this in part because a year is not much of a sacrifice, at least from the perspective of an entrepreneur, and especially when you have the financial runway to do it. Any sane person would probably disagree, but it's neither the job nor the nature of founders to be sane.

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 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).

Yes I honestly have no idea what problems in our workflow chat would solve, but I can think of loads of problems it would introduce.

I have no idea how other programmers tolerate chat as a communications medium for work. Why would you prefer chat over other async mediums?

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.

Thank you sincerely for not contributing energy to realtime chat, FOMO, and the "constant inbox".

I personally find amazing productivity when I turn my phone to DND (helps with robocalls too) and quit all chat apps. On most phones you can configure who can call you in DND.

> I spent the next six weeks building. By that point, my customers were loving the product – even my largest customer that started out highly skeptical of the paradigm. Everyone who had converted so far applauded the user experience and agreed Level was a beautiful product.

I wonder why they switched to Level and loved it when most were fine with Slack. Is it because they were fans, or do they have some real pain that drive them to action? Maybe the author accidentally hit a niche?

If it's me, I'd find that out before giving up. So most people are fine with what they have and won't switch, so what? Isn't that to be expected? Aren't you supposed to find some earlier adopters and grow from there?

I walked away from mine only after 8 years. It was difficult realizing it had to go. Taking something that was a part of your life for so long out behind the metaphorical barn with a rifle is tough...

> If people were ravenous for a solution, why weren’t most people even attempting to pilot Level?

This is _not_ purely the "everyone is lying" problem, i.e everyones lack of ability to quantify the actual importance of a problem... The original questions were deceptive to both parties because they are unwittingly framed with the assumption that a "solution" in the form of a product or technology is a _valid_ form of solution.

Not all problems deserve or need technical solutions, but the subjects are denied the opportunity to consider this aspect. If you identify a problem everyone will likely agree it exists, which is useless, this doesn't qualify it for a solution let alone a solution in the form of a product.

I'm not very trusting of market research, but if I had to, i'd try to make this possibility intuitively clear by offering alternatives for comparison e.g: Do you think problem x would be better solved by a workplace policy or a technical solution / product?

I attended a UX seminar once. We split into groups and were assigned a scenario: improve the check-in experience at a fictional hotel (acted out by the organizers). Literally every other group began their presentation with, "We built an app that..." Most involved checking in by phone.

Meanwhile, our group noticed a number of basic inefficiencies and suboptimal interactions, and proposed about 5-10 improvements to policies and staff procedures.

We all watched the same skit. I thought the solutions were so obvious as to be on the nose, but evidently not.

I mean I've done this with things I spent 3-4 years building :/

Same here. I am in the process now of checking out The Mom Test book and seeing how we failed in getting soft interest.

Hope it's helpful somewhat. Give me a shout if you have any further questions or issues with it.

I would assume that switching team tooling would have a social credit cost/risk. Didn't see that mentioned in the article. People don't want to appear incompetent if the new thing doesn't work out. It has to be really good. Maybe it has to have a certain momentum on personal projects...

I think product development takes a bit of madness - a leap of faith, something that you believe that others don't ...... yet.

I don't think any amount of asking people what they want is a replacement for building something and putting it in front of people - only then do you get a true reaction.

If you like the idea of Slack alternative that promotes focus and reduces distractions, I recommend looking at https://twist.com/.

I used it briefly and really liked it. It's created by the same team that makes Todoist.

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.

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

Paul Graham's essay "Maker's Schedule, Manager's Schedule" should be required for anyone working with developers.

http://www.paulgraham.com/makersschedule.html

Thanks for recommending that, well written and gives clarity to something that can be a source of misunderstanding and friction.

IMO there's a ton of untapped potential in good old email still, with chat being last resort when realtime response is really necessary. There were a few startups years ago that tried to tackle some of the warts of email UX (e.g. Xobni) but nothing came of it it looks like.

Slack is cancer. I'm working with a client right now that uses Slack, and I bill every single minute I have to spend on Slack, so I know exactly how much time is wasted there. It's an open invitation to just shoot wind all day never accomplishing anything, which is, unsurprisingly, how people use it, mostly. Especially people who get paid a fixed salary.

Great read.

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 problem is that a product like Slack does not wear down, you do not have to replace it every second year, so there's no good opportunity for a competitor to sell a replacement product. It either have to be an order of magnitude better, or you have to sell it as an alternative, not a replacement, to customers that not already have their needs fulfilled. So when people search for a team chat product, first you need to make sure people know that your product is an option, but not only that you need a very good explanation of why they should pick your product and not the most popular one.

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's good to see that the author had early feedback and performed interviews. However, looking at an early post at the interview methodology, it seemed like there was the lack of validation around the product. The author successfully validated the problem, but not necessarily what he wants to build. A good read is the "Customer Driven Playbook" - which details a hypothesis driven model in product development to get more measurable outcomes. I think he should keep at it - but set more specific outcomes and look at smaller sets of things to improve within the larger space.

I dislike immediacy of chats, so one may imagine I'm the perfect match for the product. But no, for people like me, I think, email works just fine. Level.app webpage says about its alleged superiority above Slack which looks a lot like returning back to good old email traditions (inbox, which you can check when you like, no presence status etc.) Fine, but... er, I already have it, as well as a variety of trusted tools, and everything based on the open protocols. So maybe the guy was solving the wrong problem all the time.

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.

Hah, me too, but couldn't write it till I had taken my knocks first ;)

> An engineer at Stripe told me about their careful balance of email, forums, and Slack. 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 retrospectives, team members often reflect on whether they chose the right medium (email, chat, or forum) for various conversations.

This is bad news for Slack's freemium economics. I'm going to recommend we don't upgrade with this in mind.

if slack becomes your hub and you start adding in integrations the app limit (10) can hit you pretty quickly as well

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.

Why is there no screenshots of the level app on the homepage or Github page? A picture of the app would help me decide whether I want to use it.

I was curious also, but found some in the docs.

This was a really interesting read - it's so difficult to walk away from something you've put heart and soul into for so long.

This also sounded familiar:

"The gist is that it’s tough to get unbiased feedback during customer validation. I already knew this to be correct, but I underestimated to the degree to which everyone lies"

Has anyone found effective strategies for getting honest customer feedback?

I walked away from a product I spent 10 years building. My advice: don't look back. It's easier and more profitable this way.

As a listener of the Art of Product podcast I am a little sad with this announcement. But rationally I don't think I should be. The founder was very aware and honest about the challenges of his product; and this decision, at this time, seems very mature and right.

Good luck on your next endeavor, which, I guess, will be a developers'tool :)

Great read, and also a strong bull case for Slack no matter how unbearable it gets at any significantly large organization.

Very hard to do front end build out and UI tweaks and backend and product planning and customer development as a one man shop. Consider finding a motivated offshore dev to hand over the non-core bits and pieces - the net time it frees up can be dramatic, speaking from experience.

Great article. Thought the author sounded really bright, practical, mature, customer focused and motivated, did a lot right. Seems like someone I’d love to found a company with. But the simple truth is startups are hard, most of them fail even if you get a tonne of things right.

I’m a bit sad. I couldn’t for the life of me figure out how to make my company switch to something like this, but if I were ever in the position to make that choice myself?...

The problem is the decision makers don’t mind being interrupted all the time.

So. Will you open source the code?

https://github.com/levelhq/level

No screenshots as far as I can tell?

I've never been more annoyed by a basic website. Center your content!

It's one of those subjective things with design and why we have so many cars/etc to choose from. To each his/her own. I personally like the design.

It's not subjective.

We usually sit right at the center of our main monitor for a reason. Reading that website on a large 32'' monitor is annoying.

> It's not subjective.

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.

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.

Just hit Reader Mode in Firefox.

A year is pretty short.

this is the toughest thing ever

Too dark; didn't read.

You only spent a year building something, thats nothing.

I've spent years building products, the first year is alpha at best.

Depends on the products, some can be final polished version 1.0s in a year or less.

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.

There's no need to be so judgemental of a well written article describing someone else's experience, even if it isn't as grand and wonderful as yours.

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...

Did you write an article about your experience?

Reply on news.ycombinator.com