Good Pain vs. Bad Pain

aka: You know it’s supposed to hurt, you just don’t know which kind of hurt is the good kind

One of the common problems when people start lifting weights (or doing CrossFit) is that they inadvertently overdo it. Why don’t they stop when it hurts? Because everyone knows it’s supposed to hurt. Hypertrophy is the goal, so the pain is part of the deal... right?

Pain, Guaranteed
In an old interview on the rise of Twitter, Ev Williams said something really interesting: in pursuit of the fabled startup we’ve gotten so used to praising the entrepreneurial struggle, and so often repeat the myth of the starving entrepreneur, that people tolerate the pain of a bad/unviable idea longer than they should. He said that seeing Twitter go viral, made it clearer how Odeo hadn’t.
When Twitter took off, he just about said: “So this is what traction feels like.”
This is an interesting problem. The cult of entrepreneurship is strong and there’s no shortage of glib one-liners pumping people up to worship the grind. In putting yourself through it, you could be building the ultimate beach body, or you could be setting yourself up for a lifetime of chronic back pain. So how can we tell the difference? How do you know if this is the necessary pain that all young companies endure or if you are actually giving yourself a digital hernia?

An obvious answer is customer feedback, but this isn’t that simple. I’ll discuss why, through the lens of two different products we built: Phish5 and Canary.

We built Phish5 in 2012 with the logic that network admins and security teams would be able to sign up, pay a few hundred dollars and run high-quality phishing campaigns against their own companies. It worked well and over the years had reasonable success. (By this I mean that it found customers all over the world, and it made a few hundred thousand dollars while costing a fraction of that to run). Over time, self-phishing became a bit of a cottage industry as more and more players entered the market. We still had some multinational customers using it so we kept the lights on, but didn’t invest too heavily in it..

In 2015 we released our Thinkst Canary. High-quality honeypots that would deploy in minutes and require almost zero management overhead. It took less than a month to realize that Canary was going to be different. Our early Phish5 sales were nearly always to people we knew (from our previous lives) while Canary almost instantly found customers we never knew in verticals we would never have explored.

Phish5 customers used the service until their license expired, and then (maybe) signed up for a 2nd round. Canary customers typically  add more Canaries to their networks part way through their subscription, upselling themselves in the process.
Most of all though, while we had Phish5 customers who told us they liked Phish5, Canary customers oozed “love”.
Paul Graham famously suggests that winning with a startup begins by “making something people love”. Part of the problem with this, is that like many tweeners, you can’t tell if it’s love when you’ve never been in love before.

We had users recommend Phish5 to their friends and it was even featured in an article or two. But it was only with Canary that we went: “Ooooh.. that’s what love feels like”. Email feedback was tangibly “gushy” and we’d increasingly hear Canary mentioned lovingly in security podcasts. The unsolicited feedback on Twitter was beautiful (and was much more than we could have asked for!)

https://canary.tools/love
We have our roots in the security research community and we work hard to push the boundaries with our products. Nothing shows love to a researcher, like other researchers citing (and building on) your work. Phish5 appeared in a few news pieces over the course of 5 years but the Canary family almost instantly slid into other people’s slide decks.

From short introductory vids to industry legends like CarnalOwnage discussing Canary usage in his day-job; from rock stars like Collin Mulliner stretching CanaryTokens for RE Detection, to smart folks like Mike Ruth talking about deploying Canaries at Scale. People (other than us) delivered talks and papers around our birds.. Nothing close happened with Phish5 (and to be honest, we didn’t know it happened ever).

The love delta is obviously reflected in our numbers too: With Canaries deployed on all 7 continents, more than 95% of our Canary sales are still inbound & word of mouth referrals. We’re not saying “We’ve won” or that Canary’s success is a fait accompli. But we do know that it’s on a radically different trajectory to anything we built before, and we wouldn’t have gotten here if we kept “grinding away” at Phish5.

Determination and focus are great, but make sure that your doggedness doesn’t stop you from ditching your Odeo to build your Twitter¹ .

__
¹ That wasn’t us.. That was Ev..  Check back with us in 5 years to see how it worked out for us

Comments

Post a Comment

Popular posts from this blog

Simple Graphs with Arbor.js

Image
We recently released a tool at http://cc.thinkst.com to capture and collect infosec conference details. We commented on it [ here ]. One of the cooler components of it, is the ability to view the relationships between speakers/researchers who have collaborated. This post is a quick introduction to the library we used to build our graphs, with enough info to get you up and running in minutes. As I mentioned, we use ArborJS library which is a a graph visualization library using web workers and the popular jQuery . The API is really well documented [ here ] but like most people, I learn best by example (and there are precious few of these). Hopefully this post will fill that niche, and by the end of it you should have a basic understanding of how to use arbor.js in your project. Our Aim: We will be building a simple contrived example as seen in the image above. Project setup : Create a new html page and include script references to the following libraries (Download them from the links...
Read more

Small things done well¹

Image
Bad design is bad  In 2015 Moxie Marlinspike pointed out that the manual page for GPG is (now) 50% of the novel Fahrenheit 451. Any software whose man page approaches 20 thousand words better have a good excuse, and GPG can only gesture vaguely at decades of questionable design. GPG gets a bad rap but it isn’t really much of an outlier. Security software has a long history of crumby, unintuitive interfaces and terrible design choices. A deep dive into the factors behind awfully designed security software isn’t the purpose of today’s blogpost, but suffice it to say there is seldom pressure from the end users. Security software mandated by a security team is often rammed down users’ throats, so it doesn’t bother being pleasant. It’ll sell anyway. We’ve worked hard to buck this trend from our first version. It’s one reason why we are one of the few pieces of security software that customers actually talk about in terms of love: https://canary.tools/love Recently, we released a major...
Read more

Using the Linux Audit System to detect badness

Image
Security vendors have a mediocre track record in keeping their own applications and infrastructure safe. As a security product company, we need to make sure that we don’t get compromised. But we also need to plan for the horrible event that a customer console is compromised, at which point the goal is to quickly detect the breach. This post talks about how we use Linux's Audit System (LAS) along with ELK (Elasticsearch, Logstash, and Kibana) to help us achieve this goal. Background Every Canary customer has multiple Canaries on their network (physical, virtual, cloud) that reports in to their console which is hosted in AWS. Consoles are single tenant, hardened instances that live in an AWS region. This architecture choice means that a single customer console being compromised, won’t translate to a compromise of other customer consoles. ( In fact, customers would not trivially even discover other customer consoles, but that's irrelevant for this post. ) Hundreds of consoles runn...
Read more