Businesses aren’t created in vacuums.
They’re contextual. They exist in a specific time, operate alongside fluctuating market trends, and are influenced by founder personalities and customer preferences.
After helping build three to four products a year for the past seven years, we’ve seen this firsthand. We know no two businesses are built or run exactly the same way — which is why strict playbooks for startups often don’t work.
Yet, that doesn’t mean other companies and founders have nothing to teach us.
We’ve noticed that while the exact playbook, or recipe, a company uses may differ, the base ingredients stay the same. There are tens of recipes for amazing pasta dishes, but they all involve some similar base ingredients. Namely, pasta noodles and salt.
Likewise, in this age (which is sometimes called “The Age of the Customer”), many successful companies actively gather and implement feedback from customers. Involving customers is to product-building what pasta noodles are to a great pasta recipe — an essential base ingredient.
In that spirit, here are four product lessons we’ve learned from three cybersecurity founders we’ve worked with — and what you can do with those base lesson ingredients, too.
Table of contents (aka your ingredients):
- Community: Involve your community for more clarity and less guesswork
- Prioritization: You’re juggling a lot — here’s how to drop something
- Buy-in: Your product is only as good as the CSO can prove
- Outsourcing: Work from your strengths, not your weaknesses
Lesson #1: Involve your community early and often
Business narratives tend to over-focus on individuals. There’s the “lone genius” narrative that says Elon Musk and Steve Jobs-esque visionaries changed the world single-handedly. And there’s the story of the “solopreneur,” an entrepreneurial lone wolf who’s out to establish their business come hell or high water.
Yet, these narratives are not only misleading (in our experience, no founder or business is truly an island!), they miss one of the biggest advantages you can tap into: a community.
First Round Review calls a community “the new moat” (aka defensible advantage), and their survey reports 80% of founders agree a community is important to business, with 28% describing it as critical to success.
What is a community?
The definition of community is quite broad; it’s a group of people who have something in common. That commonality could be geography (like a neighborhood) or niche interest, like internet background noise.
The GreyNoise community is built around that niche interest. It’s active on Slack and has 145+ members these days. And when Andrew Morris, founder of GreyNoise, worked with us to build out the GreyNoise Visualizer, he didn’t overlook how powerful this group of like-minded people is.
Communities are a wealth of feedback...if you tap into them
When Andrew was building the Visualizer with us, he did something very unusual. He shared in-progress wireframes and designs throughout the build and gathered input from 50+ people.
Then, he sifted valuable comments from fluff.
If feedback checked any of the following boxes, he threw it in the fluff-bucket and didn’t pass the comment on to our team:
- Missed the point
- Addressed a factor we intentionally ignored at that stage
- Focused too much on cosmetics
- Fell outside of the brand
- Fell outside of Morris’s principles
For example, he didn’t pass on comments like “you should use emojis for these things.” Emojis are fine, but they don’t fit the GreyNoise brand or personality...at all. This feedback was outside the brand, so Andrew didn’t pass it on to our team.
Everything else went straight to us.
Community feedback increases clarity and reduces product guesswork
What good were all those comments and notes?
The feedback GreyNoise collected directly translated into design improvements. Andrew estimates for every 1 in 5 people, “we made a tangible change based on something they recommended, generally because they thought of something we didn’t think of.”
Put another way, a big thing all that feedback did was cut back on guesswork — aka “where do we go from here?” or “what improvements do we need to make?”
And when you eliminate a pile of guesses clouding your view, you can more clearly see where to go next. Case and point: when Andrew started sharing the beta version of the visualizer with users, most of the feature requests he received were already in his pipeline! He knew what should be in the product pipeline because he’d been listening to his community all along.
Takeaway: While there will always be some level of guesswork in product building, you can cut down how many guesses you make by involving your customers early and often.
The early part is something most entrepreneurs miss. It can be unnerving to show work that’s in progress or feels half-finished with a community. Many entrepreneurs are more comfortable with guessing about direction during a build and then testing a finished product.
Yet, we’ve seen time and again that our most successful clients do something different. They overcome those “not ready yet” fears, share works in progress, and readily incorporate customer and community feedback along the way.
Don’t forget customers (if you have them) are also a community
When Sentinel Intrusion Prevention Systems was building out their dashboard, they didn’t have a Slack group to tap into like GreyNoise.
What they did have was a happy group of paying clients.
A small group of loyal customers is also a type of community — their commonality is your product and the pain point(s) it addresses. What’s more, this type of community consistently delivers accurate feedback data because they’re paying customers.
When Sentinel was working on their product, they also gathered feedback during designs. But they used a more targeted approach — user testing. To see how designs were coming along, our Creative Director Austin Price set up a series of interviews with the two parties who would use the dashboard regularly: Sentinel’s support team and Sentinel’s clients.
This user testing did two important things:
- Gathered crucial feedback: Putting a clickable prototype in front of the people who use it identified important holes and sticking points. For example, some users were confused by certain colors and text labels or struggled to open a support ticket. Knowing this took the guesswork (notice a theme here?) out of what improvements we needed to make next. It also ensured we caught any major usability issues before building the product. That’s important because it’s much harder and more expensive to fix those issues later.
- Signaled progress to active customers: Several customers knew Sentinel’s dashboard was in the works and were anxious to receive it. Including these customers in design reviews signaled, “We’re working on this and making progress.” It demonstrated Sentinel was actively listening to their customers, which helped further build loyalty — and improve retention.
“We wanted our customers to know we were working on something. It’s a great way to signal, ‘Hey, we’re actually working on this and we’re making progress. Because if they don’t see movement, they may just assume there’s no movement."
— Chris Gathright, CTO at Sentinal IPS
While Sentinel’s method of involving their community differed from GreyNoise’s, the outcome was the same in both cases: clarity around what to improve next and better engagement with potential/existing customers.
Lesson #2: Know what you’re juggling...and what you can drop
Mike Murray, CEO of Scope Security, has held several positions and started several companies. From experience, he knows every company and founder has a lot to juggle.
But the trick isn’t keeping all the balls in the air; the trick is knowing what you can drop.
Here’s a helpful analogy Mike uses to think through this. Some of the balls you’re juggling are glass while others are rubber:
- Glass balls are fragile. They’re priorities you don’t want to drop because, when you do, they get irreparably damaged. They shatter and won’t ever be the same when you pick them back up.
- Rubber balls are durable. They’re priorities you can drop and pick back up later because they bounce. It’s easy to scoop them back up into your juggle, and they’ll be no worse for the wear when you do.
Building products often means dropping rubber balls #
Every founder and company juggles both types of balls, and there’s no job where you can keep all the balls in the air all of the time. That’s why the trick is knowing what you can drop. This, of course, means figuring out what’s glass and what’s rubber.
“There are corners you can cut and there are corners you can’t.”
— Mike Murray, CEO at Scope Security
The distinction isn’t always obvious, but here’s a clear example: when Scope was deciding what to put in their dashboard, they realized some features, like interactive comments in the user interface (UI), were rubber balls. Not only did Scope lack the manpower to respond to these comments round-the-clock, but it also wasn’t a high-priority item for customers. So, Scope’s team could drop this “rubber ball” from the first version and pick it back up later.
But other aspects, like security, were definitely glass balls — dropping them wasn’t an option. Scope deals with hospital data, and Mike says Scope’s customers “can't afford for us to make their security job harder by us losing their data. They're already understaffed and overworked and our job’s to make that easier, not harder.” If Scope dropped the security ball, it’d shatter, and the company could cut itself to shreds on the shards. That ball had to stay in the air, no matter what.
Dropping features sounds scary, but it doesn’t have to be #
If you haven’t built many products, dropping a few features — even when you suspect they’re rubber — can still be intimidating. Andrew Morris likes to remind himself, “you can always come back. Perfect is the enemy of good. You need to get something in people’s faces as soon as possible.”
“...you can always come back. Perfect is the enemy of good.”
— Andrew Morris, Founder of GreyNoise
It’s also helpful to keep in mind that dropping non-essential features is a healthy part of product-building. Many founders cling to their original overstuffed ideas and visions — but that close mindedness can be toxic.
For many reasons, very few (if any) products wind up looking like the founder’s original idea. Although he admits he’s guilty of doing it, Andrew cautions, “You can’t fall in love with an idea...the output is not what you think it’s going to be. If it was, you would’ve fucking gotten it right on the first try.” (Fun fact: Andrew built multiple versions of GreyNoise over several years before he figured out what resonated with his audience.)
To determine what went into the current GreyNoise visualizer, Andrew started with his customers. He focused on five known, distinct use cases and worked to enable those.
He’d uncovered these use cases from years of working with the data (remember, he didn’t get GreyNoise “right” the first try), improving the API, and interacting with users. If a feature or idea wasn’t crucial to one of the use cases, Andrew put it on the chopping block. “Anything that wasn’t contributing to those five things didn’t matter,” he says.
Lesson #3: Your product is as good as the CSO can prove
Security products are often designed for engineers, and this makes sense — engineers are usually the main group of people using security products.
But they’re not the only people using them, and someone has to get security products into engineers’ hands to begin with. That someone is often the Chief Security Officer (CSO) or another executive with purchase power.
This is why we say your product is only as good as the CSO can prove.
Scope understood this, and they prioritized showing ROI to key decision-makers in their dashboard.
Demonstrating ROI often means making the invisible, visible
Like other security services, when Scope’s team is doing their jobs well (as they do), there’s very little to report.
While that’s good news for customers, it also means it’s easy for stakeholders to forget what’s happening behind the scenes — unless you show them. This is why one of the first things you notice on Scope’s dashboard is a simple funnel graph. From left to right, it visualizes potential issues the healthcare team could’ve faced but, thanks to Scope, don’t have to face. Meaning, it also reminds customers what they’re paying Scope for...to head off problems.
Sentinel did something similar in their dashboard as well. Take a look at the top of their user interface:
One of the first things you see is the number of flagged alerts (“3” in this image) vs. the number of total alerts (62,195). This visual, like Scope’s funnel, reinforces how hard Sentinel’s suite of services and products are working behind the scenes.
Making the invisible more tangible is what GreyNoise did with their Visualizer, too. Only, their approach is a bit more conceptual.
“Internet background noise” is a notion that’s difficult to grasp. That was a problem for GreyNoise. If you can’t drive through all the data background noise generates, you can’t understand its scale and relevance. This means you also can’t understand why a tool like GreyNoise is necessary.
The Visualizer tackles this visibility issue head-on. It makes both the problem GreyNoise solves and the way they go about solving it obvious.
Lesson #4: Work from your strengths, not your weaknesses #
Scope’s founding team is essentially computer hackers, an AI expert, and an infrastructure expert. They’re extremely talented, but their skills don’t extend to frontend design.
“Nobody on my team is a front-end person and I can barely draw a stick figure effectively,” Mike explained.
This means it’d largely be a waste of Scope’s skillset to focus on designing an interface. “If you ask John, our head of threat Intel, he'd probably tell you he's good at this, but ultimately he's also one of the best hackers in the world.” Mike explained, “and I'm not going to have him designing user interfaces for a living. He’s here for a reason and it's not UI.”
For Mike’s team to keep working from their strengths, they needed to hire or outsource their weaknesses. (That’s part of why they chose us. Partnering with Krit allowed Mike to craft a beautiful, effective UI in a short amount of time, without compromising any of his teams’ strengths.)
“We used Krit to get the headstart that allowed us to get to a place where all the basics are covered...Everything I vetted is awesome.”
— Mike Murray
This strategy is something Andrew used, too. He knows that, especially when you first found a company, you’ll be in charge of everything. But this doesn’t mean you have to be good at everything. He says, “It’s fine that you don’t know everything, and you need to accept that you don’t know everything.” Rather, you just need to be good enough to grow to a size where you can hire some help.
“It’s fine that you don’t know everything.”
— Andrew Morris
Work from your strengths and outsource your weaknesses once you can.
Want more insight into the intersection of product design and cybersecurity? Sign up for our newsletter to get new articles straight to your inbox.
