What if technology never changed? On the plus side, there wouldn’t be constant updates to contend with, no new blogs to read about the latest and greatest (ahem), and no new buttons and menu items to figure out.
With change, there is always inconvenience — until it becomes the new norm.
As we’ve talked about before, our goal at Huntress is to accelerate and streamline security defense. A key pillar to accomplishing this is to release what we’re working on early and often — specifically with your feedback in mind. That way, you (our partners) can obtain value as soon as possible without waiting for long traditional development lifecycles, while also helping define what needs to be done. As a vendor, there’s a fine line between agile development and having all customers become testers. So how will this work?
Beta = Learning
Traditionally, when you think of products or features in “beta,” they are often considered “not finished.” Many beta programs are “opt-in” asking for early adopters to reach out and proactively sign up to help buff and shine these features before being released to the masses.
But at its core, a beta phase in the product lifecycle is to learn: learn how it lives in the real world, learn if there are user corner cases that haven’t been discovered, learn if there are gaps in the user journey that need to be addressed.
At Huntress, beta means learning. We’re learning how you use a new feature, what problems it is solving, as well what problems it isn’t solving. We want to maintain a tight feedback loop to ensure we are focusing on the right things.
The Journey of a Feature
Before we dive into how Huntress does things, let’s look at a general pipeline that features go through before they are released:
Learn & Prioritize
With any good product, it’s about digging deep and understanding what problems need solving — then tackling the ones that make the biggest impact. All technology vendors have to prioritize- — but the key is to prioritize the problem, not the button or the widget. And the only way we can do this effectively is by talking to you — our partners.
Now that we know what problems we want to solve, it’s time for us to ask: how will we solve these problems? What resources do we have and need in order to execute? What questions will help us figure it out and how will we find the answers? This is where the problem gets translated into the solution, where the button/widget/feature/etc. is decided, and where we start to engineer the solution.
The definition of beta is very different for many vendors; in most cases, they are reserved for new products or more complex features. They are traditionally closed and early adopters need to actively seek out participation with full knowledge that things are not fully available or might break.
In the gaming world, Early Access means access to games once they reach a playable state without all the bells and whistles that would come with the official release. Early Access may also be interchangeable with Beta, or it could be a way to open up access to a slightly larger audience, but without an official communication of the release.
Commonly known as “General Availability,” this last step implies that engineering, QA, and product management have all put their stamp of approval for the full release and that it meets all the objectives for the problem it is trying to solve. Marketing dollars and communications are focused here and many customers may not hear or know about new features until the product reaches this phase.
How Huntress Does Beta
In truth, we’re not doing anything unique or out there — it’s very much in line with what everyone is already used to. The main distinctions are:
- We release an “Early Access / Public Beta” version so all partners can use it rather than limiting it by manually granting access
- We like to use the phrases “Private Beta” and “Public Beta” (distinction below)
- Our “Early Access / Public Beta” phase might last a little longer given our commitment to stability in this stage.
Why We Do It This Way
Let’s go back and think about the traditional approach in the world of cybersecurity. With problems changing all the time, there is risk of spending too much time potentially chasing an outdated problem. If we wait until full release, a lot of time passes between when development starts and when our partners and customers can start receiving value. Especially in cybersecurity, we just don’t have that luxury of time given how fast our adversaries evolve — so why wait?
Shipping new features early and often is not a new concept, and it is a philosophy we are fully embracing as part of the Huntress culture. And we’re in a good position to do so — not just because we are a SaaS product, but because of our commitment to delivering continuous value.
Can You Give Me an Example?
When Huntress first started as a persistence hunting tool, the first thing we did was capture endpoint telemetry about autoruns for a handful of friendly partners. At that point, the UI was barely there, PSA integration was not available, and alerting was essentially non-existent.
But even with just the endpoint data, we were getting tons of valuable information, giving our ThreatOps teams the ability to hunt for threats. Even though it wasn’t optimized, we were still able to use this data for manual investigation and important alerting.
In the security world where remediation and fast action is critical, there’s no reason why we would have held back information about incidents from our partners — even though the product wasn’t fully available yet. This is where we realized a tight feedback loop and integration with the beta phase becomes so important.
Beta gives us an opportunity to hear from those who will actually use it in real environments. We are learning and evaluating whether or not our assumptions were correct. Then taking that information and feeding it back into our research and development.
Public Beta vs. Private Beta
Private Beta (on occasion):
For most new features in Huntress, we will not go through a “Private Beta” phase. But in some cases, such as Managed AV, we decide that a traditional beta phase is warranted — especially if we are changing something on the endpoint that could cause unexpected behavior. In this case, we do need some users to kick the tires and help us surface all those corner cases.
The goal is to get to a threshold where the endpoint passes engineering and QA standards for protecting and preventing disruption. We try to open this up to as many partners as we can support. We learn a ton from these partners and are incredibly thankful for their willingness to contribute to our product lifecycle.
Public Beta (most occasions):
This is when we will start to announce our new features and allow you to simply opt-in through the Huntress dashboard itself. Once a feature or service is offered into Public Beta, it means it is ready to go for anyone and everyone without having to contact support to have features enabled.
Here the goal is not about stability; it’s about understanding how you are using these features. It allows us to learn and iterate — but more importantly, it allows you to gain additional value from new services and features as early as possible with the confidence that Huntress is at a stable release.
Doesn’t Beta Mean It Will Break In My Environment?
Nope! Once we have moved into Public Beta, our commitment is that Huntress is at a stable release. In addition, you will still have the option to opt-in to those features. Although we don’t expect major issues at this stage, full and complete support is offered to ensure that Huntress is operational in your environment.
Keep in mind that while there are some features that are in a beta state, there are still high value services that are very mature and have already reached a full release stage — such as Persistent Footholds.
As we’ve mentioned, we want to release features early and often in order to give you hands-on access. This way you can have a voice to help us drive change. You might notice that a feature might remain in Public Beta for longer than one would expect; this is so that we don’t have to stop developing and can continue to push and prioritize the items that you need.
How Can I Give You My Feedback?
We’ve got a few options for you:
- Give us feedback through our new feedback portal! Here you can get some visibility into upcoming features, submit feedback or new feature requests, and vote on previously submitted features.
- Email is always an option: firstname.lastname@example.org
- Reach out to your account rep! Their contact details are in the Partner Enablement Service portal of your dashboard.
In full transparency, we want you to stay with us so we can join forces in elevating SMB security. We don’t want you to hang with us just because you feel like you have to. We want you to stick with us because you are genuinely getting value out of what we are delivering. And the only way we can stay on the right path is by working together.