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.
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.
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.
Great article, very informative. Thank you for the effort.
Nothing new here of course, tech shops have been doing it for decades. Centuries even maybe.
See also: certification programs.
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.
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.
Maybe not in the US, where APIs are under copyright, but outside it could work...
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.
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.
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.
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 .
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.
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.
Unfortunately I only read it after making all the mistakes it lists - but I know from personal experience that everything it says is correct.
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.
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.
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.
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.
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.
Don't find it but it sounds fun! Got a link?
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.
This is also data driven. It may be mere "datum", but complex, with many components, far richer than any statistical data.
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.
> 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.
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".
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.
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!
“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 that everyone should just roll the dice with months/years of their lives because they like an idea isn't actually tenable.
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 :)
We usually sit right at the center of our main monitor for a reason. Reading that website on a large 32'' monitor is annoying.
I have no idea how other programmers tolerate chat as a communications medium for work. Why would you prefer chat over other async mediums?
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.
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.
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.
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.
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.
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?"
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.
Better to cut the cord than keep kidding yourself. Thanks for sharing!!
P.S. I read @rwalling's "Start Small, Stay Small" a few months back, and it was a phenomenal read. Highly recommend.
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?
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.
This is bad news for Slack's freemium economics. I'm going to recommend we don't upgrade with this in mind.
I've spent years building products, the first year is alpha at best.
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.
Thanks for sharing, and hope you find what you're looking for in your next venture (and keep sharing details!).
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.
http://justinvincent.com/page/951/the-madness-the-all-consum...
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.
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 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 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.
I used it briefly and really liked it. It's created by the same team that makes Todoist.
— 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.
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.
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.
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.
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?
Good luck on your next endeavor, which, I guess, will be a developers'tool :)
The problem is the decision makers don’t mind being interrupted all the time.
