Sweating the small stuff with Haroon Meer, founder of Thinkst Canary

Haroon Meer is the founder of Thinkst, the makers of Thinkst Canary. Canaries look like real devices on a customer’s network and can be deployed as hardware or software. But if they’re accessed, they trigger an alert to let the organization know they might have been compromised.

Canary is the only security tool I’ve seen that has a page on their website dedicated to customer love. And much of that comes back to product strategy and design choices, which means it comes back to Haroon. So I sat down with him to find out how he thinks about product strategy when building infosec products, what has led to Canary’s success (Thinkst hit $11M ARR last year), and more. 

Some of my favorite takeaways:

• The Thinkst team thinks just as deeply about the features they don’t include in Canary as the features they do include
• As a founder sometimes you have to trust your gut, even when you can’t articulate why you feel a certain way
• Metrics are overvalued at the earlier stages of company building
• In security, just being easy to setup and install is a competitive advantage
• Small, delightful, “nice-to-have” features are valuable for attracting not just  customers, but also great product people to join your team 
• You have to let yourself (and your team) be wrong to be great

Enjoy this edited interview with Haroon Meer, CEO of Thinkst and brilliant product leader.  

Haroon, you had this great line in one of your posts: "Security software mandated by a security team is often rammed down users’ throats. And so it doesn’t have to be well-designed—it still sells." Do you feel that is still true, or is the industry evolving?  

Haroon: In a fairytale world, better-designed products will immediately win. But in this one, and our industry in particular, products are still being forced down customers’ throats. So you still get ugly software.

I think it will become increasingly obvious that thoughtful design leads to better product adoption, less churn, and—hopefully—better products overall.

For example: back when I was pen-testing, I always had one iPhone and one Android because I wanted to make sure I was comfortable on both.

Super early, even if there was a feature parity with the iPhone, I just used the Android less. I’d tweet less from it; if I needed to surf something, I still questioned: "Is the site going to work on this mobile? Is it janky?" which I absolutely didn’t do with my iPhone.

There were little things Apple put into the iPhone they never spoke about. Here’s one:  when you tap a link on your screen, you’re never quite touching where you think you are, and Apple used onboard machine learning to figure out where you think you’re touching. Then in Safari, they basically track your finger and then radiate outwards in circles till they find the link.

They never spoke about that feature, but I suspect it manifested for me in trusting Safari over Chrome on an Android device. 

I don’t think you can convince someone of that. It’s more that you give it to them, they use it, and don’t churn. Or they use it, and something about them likes the product. I’m not sure those things can be or even need to be articulated. They need to be felt. 

Note from Andrew: this is the whole idea behind Product-Led Growth. You can’t necessarily convey good design in marketing copy: you have to show it. So then the idea becomes: how do we shorten the time it takes customers to experience that feeling?  

You wrote this blog post on how shipping features is not solving problems. Can you talk a little bit about that concept?

Haroon: Shipping features is easy. If you’re building a new product, you can make a checklist of things that need to be hit, hire N developers and engineers, and just keep shipping. A bunch of product companies do exactly this, and that’s why so many products become a feature checklist: we do X, we do X plus Y, we do X plus Y plus Z.

However, in this race few people go: "Does this feature actually work? Does this feature actually deliver what the customer needs?" Security products in particular  are terrible at this, which is why you see so many of them race for feature parity; and then buyers end up checklist-buying without actually checking whether the product reasonably solves the problem. 

We’ve tried really hard not to do that. In some respects, we’ve been lucky because that’s a choice the market can just kick you in the teeth for: customers can just say "Hey, you don’t have XYZ. You don’t meet this bar, we’re not buying." 

But from the start, our customers were pretty happy with our decisions. In fact, just this month we had an analyst call who said: "We noticed you don’t do this thing. When are you going to add it?" To which I replied: "I’m not sure we’re going to, because I don’t think it really adds value." 

And the analyst pinged me afterward to say he’d never heard anyone say that before.

Can you talk a little bit about how you set your roadmap at Canary and how you prioritize? Which features make the cut or don’t? 

Haroon: We don’t have super long-running roadmaps. 

Early on, we had the minimum set of things we thought needed to be in there to make the product valuable. Fundamentally, we are security geeks, and there was stuff we really wanted to do from the start, but would have been a lot of work for a feature that barely showed up for customers. 

As time went by and more people and engineers joined the team, we were able to start aiming for more ambitious features. We were able to say things like:  "You know what? Let’s have these two really smart engineers work for a bunch of time on this feature nobody will see, but when somebody sees it, it’s going to make their day."

We ended up with a really nice push-and-pull between Marco, our head of engineering, and myself, effectively the head of product. As bad as it sounds, every Sunday night we have a meeting and agree on what everyone’s going to be aiming at for the next week. 

As per features where we don’t know if something can be built, we run periodic tests. For example, we are about to release a version of Canary that runs on Docker inside Kubernetes. Almost everyone in the deception space went there super early, and we can tell why they started it—a customer said: "But we are a Kubernetes shop," and they went: "Sure, we’ll port what we’ve got so that it runs inside of Docker." 

For a long time, we felt that’s just not how that system is attacked. It goes back to the feature checklist approach: we could have shipped a thing just to say "We also do Docker," but we didn’t feel that real attacks were happening that way.

Periodically, we’d assign relatively heavy resources to the project and say: "Okay, let’s spend another three weeks on it and see if we’ve got more clarity." We waited a long time before we got to where we are now, where we think we’ve cracked it. 

You recently redesigned the Canary console. How do you think about prioritizing and testing a bigger initiative like that?

Haroon: The console redesign is super interesting. I think we can tell the story as a really good example of things working well and an example of where they could have worked horribly.

We tried to solve two problems there: one was to modernize our JS front-end and move to React, Vue, or something like that, and the other was to give the interface a fresher look.

We had one of the engineers spend a lot of time on the first problem, make a call, and pitch us a solution. But we had three cracks at the second problem internally with a designer: we worked with them, had multiple iterations, but I didn’t love them. And I didn’t have a good vocabulary for what I didn’t like about some of them. 

The third iteration was dangerous because we sunk a lot of time into it and kept adding engineers. We got to a point where, on one of the Sunday night meetings, I said to Marco: "We’ve got to pull the plug on this thing. I’m hating it." And he warned: "Our team is not going to take it well. People are putting their lives into this stuff, and you’re just shaking your head going, ’no, this is not good.’"

I think, in truth, you get some benefit from being the founder. If I wasn’t the founder, that would have been a harder discussion to have. But I was able to pretty easily say to some of them, "Hey, listen. See this thing? It just feels wrong. And I don’t know why. But we’ve got to decide what we’re doing." Luckily, most of the senior engineers on the team had a similar feeling.

So we spent a lot of time on that one version until we figured out the problem: we had made it heavier. We had moved away from being a really light console to having big movements, big animations on click, and stuff like that. We ended up calling it "midnight suede" because that’s the feeling I got from it: it was elegant and still pretty, but just heavy–like suede. 

Part of what sucked is that user feedback was good: we rolled out betas of midnight suede to some people, and they liked it. Still, sometimes, you’ve got to trust your gut. We had people complimenting it, but we felt it had to be lighter. Eventually, when something clicked with the new version, it was beautiful. Everyone saw it, and it was lighter, and it was nicer. 

I think one of the things that make design hard is that this kind of discussion is a hot mess.

Note from Andrew: Haroon is hitting on something really powerful here. One of the hardest parts about design is that most people don’t have the vocabulary or tools to express what they want, or why they don’t like something. We work with clients to try to give them this vocabulary and use tools like moodboards to capture their vision. 

If you had to give some advice to other founders, how could they hone that intuition?  

Haroon: I think someone from outside could look at that whole situation and say, "Well, you wasted a year and a half on a thing you didn’t ship." For us, I’m always worried about not being efficient. You start to think: "Well, is this how companies atrophy? They start doing stupid things like this? We wouldn’t have done that when we had five people, but we do it now that we’ve got 15. Is this us getting wasteful?"

I think you always have those competing goals, and the internal "just ship it" voice. But how do you decide when it’s one that you just ship versus one that just doesn’t cross the line for you? I honestly don’t know.

And I don’t know that we’ll always get it right. I think you’ve got to allow for being wrong, and also for trying. You have put some time into it, and it could work, but when it doesn’t, it takes some effort to say, "No, we’re going to roll this back because it doesn’t completely work." 

To go back to Apple again, I think we’ve just seen Apple roll back the touch bar and the keyboard. You have to have the product version of strong opinions loosely held.

One of the little things I loved from that redesign was Inyoni, the bird. How do you think, as a founder, about the value of some of those delightful little features that aren’t necessary? 

Haroon: First, I think it’s super-valuable, even just for the team, to know we’ve done all this work but there’s one more bow we can tie on it. Of course it’s more effort, but it reinforces with the team that that’s who we are: we put in those extra flourishes because we like stuff like that. 

And second, it turns out doing those things delights people, and they want to pay us more. But if they didn’t pay us for it, we’d still do them.

Getting the opportunity to have a product where you can have those small things is a blessing. It’s one of the hidden secrets that people maybe don’t know about starting a product company: there’s a lot of work, and there’s pain, but if you do it well, you get an opportunity to do slightly cooler stuff. Like, now that this works, we can add a little inyoni mascot and do cool stuff. We love it probably more than our customers. 

But there’s an interesting flip side to that. We often see it with very young developers who come in and lean towards flourish before utility. They’re quick to add an Easter egg or a little cunning turn of phrase because now they can make a bird joke. There’s a point where you have to go: "Yeah, but you can’t overuse that stuff."

I don’t think you can exactly teach that thing: it’s more of a feeling people build up. 

Do you all pay much attention to metrics? 

Haroon: No. And you’ll notice that answer came out really quickly.

What’s interesting is lots of the people who joined us later were surprised by it. One of them pushed back hard, like: "How are you doing this? Like, without metrics?" 

And my honest answer at that point was just an overriding: "There will come a time when we will really need them. But we don’t right now.”

We wanted new companies using us, we wanted them to rank us highly on Net Promoter scores, and we wanted our churn to be low—but other than that, we didn’t push crazily for metrics. 

I suspect we sometimes were on the wrong side of that. We release features, we’d feature-flag them, and then after a while, we’d go like: "Hey, is anyone using that?" 

We had to get a little better about that stuff, but even right now, we’re not crazily metrics-driven. I think that will come someday when you grow and are no longer able to understand your customers without metrics. But, at our stage, we get our feedback from how the product is being used.

How do you think about demonstrating value with a product that rarely ever alerts? 

Haroon: We got a little bit lucky, again, in that we were born in an industry that’s terrible. 

In the security industry, people buy products they can’t install or get set up. With us you buy Canaries: they’re up and running in two minutes. Our first promise to you: this will be easy. We put a crazy amount of effort into that.

And so, someone gets it, and they install it in two minutes. At least they go "Well, that was different." 

I think people are also really tired of other security products that use constant alerts as a growth hack. Everyone went for this "I’ll alert you every time something happens" approach that worked for a long time, but most people now know that that’s a stupid way to do things. 

On the flip side, we’ve really got to not drop the ball when it matters. Like all developers, we have different classes of bugs, and we have (blameless) postmortems and stuff like that, but: if a canary should have alerted and didn’t, for us, that would be a nobody-goes-home problem. Its a promise we can’t break. And for the most part, this has been our recipe. We make a handful of promises, and then work like hell to keep them. If customers like what we are promising, they buy us, and if we keep our promises (and keep sweating the small stuff) they will keep renewing.