Archive for March 2015
More Tanium Magic
For a just over a year, Tanium Corporation has been impressing enterprise customers with its special brand of Tanium magic — the ability to instantly learn anything you need to know about the PCs, servers, VMs, and embedded devices such as ATMs and Point of Sale devices on your network. About nine months ago Andreessen Horowitz was offered the opportunity to partner with Tanium and the founders David and Orion Hindawi, and we could not be more impressed with the progress and growth of the company. This week Tanium is adding some more magic to an amazing product.
Growing and Scaling
The Tanium team has been hard at work on the platform and in creating a great company. It is worth sharing a little bit about the progress they have made in less than a year:
- Tanium is deployed on over 10,000,000 endpoints, with individual customers managing hundreds of thousands of endpoints.
- Tanium is in broad deployment in over half the Fortune 100.
- Tanium is rapidly growing (and hiring) with a particular focus on expanding internationally.
- Even with growth on every metric, Tanium has stayed a cash-generating and profitable business.
Tanium’s product magic is matched by the team’s amazing leadership and execution.
Reimagining Systems Management and Endpoint Security
When customers first see Tanium, they are blown away by the speed at which IT can learn what is going on with the endpoints on the network. Tanium’s capability to navigate, interrogate, and act on even the largest enterprise network in seconds is the magic that fires up customers –networks comprised of millions of endpoints made up of PCs, Servers, VMs, and embedded devices. This 15-second capability is the foundation of Tanium magic and is unprecedented for large scale environments.
Traditionally, enterprises deploy Systems Management (SM) platforms to control their environments. Prior to Tanium, even the state-of-the-art tools require immense investment in agents, logon scripts, policies, signature files, databases, dedicated infrastructure (servers and networking), and more, just to provide base level information. These tools frustrate end-users and CIOs alike by choking endpoints, burdening networks, and offering up information that is approximate at best and at worse irrelevant, because it is outdated.
Tanium surpasses the state-of-the-art in systems management, which you’d expect from founders whose previous company built the leading tools of this generation before being acquired by IBM. Not content to stop there, Tanium’s ambition is much greater than improving on their previous solution, even if it is already “10,000 times better.”
That ambition is based on an important observation regarding today’s challenges in enterprise security, particularly the realities faced by the nature of attacks. Malicious attacks are no longer brute force attempts to penetrate the network firewall or simply blunt viruses or malware that indiscriminately seize endpoints. We’re all aware that today’s attacks are multi-step, socially enabled or engineered, and by definition circumvent network-based and traditional end-point protection. We’ve seen that in all the recent breaches across Target, Home Depot, JP Morgan, Sony and more, including Anthem most recently.
In every case, once a breach becomes known, the most critical job of the security team is to scope the breach, identify compromised endpoints, and shut them down. Traditionally security teams relied on network-based management solutions since those have the fastest and most familiar tools. In practice, quickly identifying all the endpoints with an unpatched OpenSSL version or all that match a known indication of compromise, for example, look much less like network security efforts and more like endpoint challenges, historically the domain of systems management. The problem is that systems management tools were designed for an era when most of their work took place logging on or during off-hours “sweeps” of assets, with results gathered over the course of weeks.
CIOs recognize that having a systems management team using one set of tools that can barely keep up with traditional demands and having a security team using tools that are only focused on the network edge isn’t ideal by any measure. Systems management is now an integral part of incident detection and response. Conversely, security and protection require full knowledge and control of end-points. Neither set of existing tools deployed in most environments is up to the task.
Tanium has been working with customers from the CIO and CISO and throughout the management and response teams in enterprises to deploy Tanium as a frontline and first response platform that reimagines the traditional categories of systems management and endpoint security. In a world of unprecedented security risks, BYO devices, and ever-changing software needs nothing short of a rethinking of the tools and approaches is required.
Tanium is a new generation of security and systems management capabilities that meets two modern criteria:
- Provide 15-second information on all endpoints. Open your browser, type in a natural language query, and know instantly every endpoint that meets a particular criteria or indication of compromise, IOC, (for example, running a certain process, recently modified system state matching a pattern, particular network traffic, or literally anything you can imagine asking the endpoint). Aside from instant information, the key new capability is being able to learn about any aspect of the running system even if it is something unforeseen or unplanned. Results are real-time, live, and refreshable instantly.
- Remedy problematic situations immediately. Given the set of endpoints matching the criteria, take action immediately by shutting down endpoints, modifying the system configurations, quarantining devices, alerting users, or patching the appropriate modules, all in seconds rather than days. Aside from being able to immediately deploy the remedy, the key new capability is being able to implement any possible remedy across all endpoints, even within the largest networks in the world using minimal infrastructure.
The most innovative products are those that provide new ways of thinking about problems or new approaches that break down the traditional category boundaries. Tanium is such a platform, and that is why enterprises are so enthusiastic about what Tanium provides.
Shipping New Capabilities
This week Tanium is releasing some significant new capabilities that further the vision of a new category of product that serves the needs of both systems management and security professionals.
Tanium IOC Detect. Open to a wide variety of highly-regarded third-party threat intelligence data and indicators of compromise templates, Tanium takes this data and continuously seeks to identify endpoints at risk in real-time. Tanium is able to match the widest possible range of system attributes and patterns without downloading client-side databases or signature files. Security operations no longer needs to sift through all of the intelligence feeds manually or script signatures to feed into legacy systems management tools. Instead, Tanium makes it possible to detect and remediate threats immediately at massive scale.
Tanium Patch. Tanium transforms a process that’s error-prone and time-consuming with the ability to deploy patches across hundreds of thousands of endpoints in seconds, with 99%+ reliability and no scripting required by the IT team. Using two of Tanium’s key architectural elements, the communications layer and the data transport layer, patches are deployed and installed with unprecedented speed and unrivaled minimal impact on network infrastructure. Since many security breaches require updates to endpoints to truly remedy them, Tanium brings together the needs of both security and management processes.
Tanium Connect. Tanium integrates its 15-second data into third-party security and management tools to make those tools more accurate and actionable. For example, Tanium’s ability to quickly see anomalies on endpoints can be used to create alerts in security information and event management (SIEM) systems. Traditionally this data would be impossible to collect or would be routed through existing systems management infrastructures, which are labor intensive and high-latency data sources. Tanium Connect provides the security operations data required to ascertain the threat and, because the data is only seconds old, the team knows it is worthy of investigation.
These are just a few of the improvements to Tanium’s 6.5 platform available this week.
Looking Forward
Tanium’s magic innovation uniquely positions the company at the modern crossroads of systems management and security tools. Tanium’s platform reimagines these categories, while seamlessly working with existing infrastructure, and adds a new level of value and capability to forward-leaning IT teams.
Given this superb team, amazing growth, and unparalleled innovation, we could not be more happy than to lead a new round of investment in this wonderful company. Andreessen Horowitz is incredibly excited to be partnering with David, Orion, and the Tanium team, and I could not be more thrilled with continued service on Tanium’s Board of Directors.
Note: This post also appeared on http://a16z.com/blog.
Frictionless Design Choices
No one wants friction in their products. Everyone works to reduce it. Yet it sneaks in everywhere. We collectively praise a service, app, or design that masterfully reduces friction. We also appreciate minimalism. We love when products are artfully distilled down to their essence. How do we achieve these broadly appreciated design goals?
Frictionless and minimalism are related but not necessarily the same. Often they are conflated which can lead to design debates that are difficult to resolve.
A design can be minimal but still have a great deal of friction. The Linux command line interface is a great example of minimal design with high friction. You can do everything through a single prompt, as long as you know what to type and when. The minimalism is wonderful, but the ability to get going comes with high friction. The Unix philosophy of small cooperating tools is wonderfully minimal (every tool does a small number of things and does them well), but the learning and skills required are high friction.
- Minimalist design is about reducing the surface area of an experience.
- Frictionless design is about reducing the energy required by an experience.
When debating a design choice, feature addition, or product direction it can help to clarify whether a point of view originates from a perspective of keeping things minimal or reducing friction. If people discussing a decision start from this common understanding, I bet a decision will be reached sooner. Essentially, is the debate about adding a step or experience fork, or is it about adding something at all?
Product managers need to choose features to add. That is what makes all of this so difficult. As great as it is to stay pure and within original intent, if you and the team don’t enhance the capabilities of your product then someone will do what you do, but with a couple of more things or a different factoring and you’ll be left in the dust.
Therefore the real design challenge is not simply maintaining minimalism, but enhancing a product without adding more friction. Let’s assume you built a product that does something very exciting and has a very low friction to usage and does so with a minimal feature set. The next efforts are not about just watching your product, but about deciding how to address shortcoming, enhance, or otherwise improve the product to grow users, revenue, and popularity. The risk with every change is not simply failing to maintain minimalism, but introducing friction that becomes counterproductive to your goals.
When you look back you will be amazed at how the surface area of the product has expanded and how your view of minimalism has changed. Finding the right expression of new features such that you can maintain a minimalist approach is a big part of the design challenge as well.
There’s an additional design challenge. The first people who use your product will likely be the most enthusiastic, often the most technical, and in general the most desirous of features that introduce friction. In other words you will get the most positive feedback by adding features that ultimately will result in a product with a lot more friction.
Product managers and designers need to find the right balance as the extremes of doing nothing (staying minimal) and listening to customers (adding features) will only accelerate your path to replacement either by a product with more features or a product with less friction.
Low-Friction Design Patterns
Assuming you’re adding features to a product, the following are six design patterns to follow, each essentially reducing friction in your product. They cause the need to learn, consider, futz, or otherwise not race through the product to get something done.
- Decide on a default rather than options
- Create one path to a feature or task
- Offer personalization rather than customization
- Stick with changes you make
- Build features, not futzers
- Guess correctly all the time
Decide on a default rather than options. Everything is a choice. Any choice can be A/B tested or debated as to whether it works or not. The more testing you do the more likely you are to find a cohorts of people who prefer different approaches. The natural tendency will be to add an option or setting to allow people to choose their preference or worse you might interrupt their flow to ask preference. Make a choice. Take a stand. Every option is friction in the system (and code to maintain). When we added the wheel to the mouse in Office 97 there was a split in the team over whether the wheel should scroll down or whether it should zoom in/out. From the very first release there was an option to appease the part of the team that felt zoom was more natural. Even worse, the Word team went and did a ton of work to make zoom performant since it was fairly unnatural at the time.
Create one path to a feature or task. You add a new feature all is good—you’re in X in your product and then you can do Z. Then someone points out that there are times when you are doing Y in your product and you also want to do Z. Where there was once one path to get to a feature you now think about adding a second path. Maybe that sounds easy enough. Then a few iterations down the road and you have 5 different ways to get to Z. This whole design process leads to shortcuts, floating buttons, context menus, and more. Again all of which are favored by your early adopters and add friction for everyone else, and also add code. Pick the flow and sequence and stick with it. The most famous debate of all between Windows and Mac was over right click and it still rages. But the design energy to populate context menus and the cognitive load over knowing what you can or cannot do from there is real. How many people have right clicked on a file in the Windows desktop and clicked “Send” only to be launched into some Outlook configuration dialog when it would have been frictionless to always know that insert attachment in mail works and nothing will fail.
Offer personalization rather than customization. Early adopters of a product love to customize and tweak. That’s the nature of being a tech enthusiast. The theory is that customization makes a product easier to use because every use case is different enough that the time and effort saved by customization is worth it and important. In managing a product over time, customization becomes an engineering impossibility to maintain. When you want to change behavior or add a feature but it isn’t there or moved you introduce an engineering impossibility. The ability in Office to reorganize all the toolbars and menus seemed super cool at the time. Then we wanted to introduce a new scaleable structure that would work across resolutions and input devices (the ribbon). The problem was not just the upgrade but the reality that the friction introduced in using Office by never knowing where the menus might be (at the extreme, one could open a document that would rearrange the UX) was so high the product was unusable. Enterprise customers were rearranging the product such that people couldn’t take courses or buy books on how to use Office. The constraint led to the addition of a single place for personalization (Quick Access Toolbar) which ultimately allowed for a much lower friction design overall by enabling personalized efficiency without tweaking the whole experience.
Stick with changes you make. The ultimate design choice is when you change how a feature used by lots of customers works. You are choosing to deliberately upend their flow and add friction. At the same time the job of designing a product is moving it forward to new scenarios and capabilities and sometimes that means revisiting a design choice perhaps one that is the standard. It takes guts to do this, especially because you’re not always right. Often the path is to introduce a “compatibility mode” or a way to turn your new product into the old and comfortable product. This introduces three problems. First, you have to decide what the default will be (see the first rule above). Second, you have to decide if/how to enhance the old way of doing things while you’re also adding new things. Third, you have to decide when down the road you remove the old way, but in reality that will be never because you already told customers you value it enough to keep it around. But adding compatibility mode seems so easy and customer friendly! Ultimately you’re creating a technical debt that you can never dig out of. At the same time, failing to make big changes like this almost certainly means your product will be surpassed in the marketplace. See this HBS case on the Office 2007 Ribbon design http://www.hbs.edu/faculty/Pages/item.aspx?num=34113 ($).
Build features, not futzers. Tools for creativity are well-known to have elaborate palettes for formatting, effects, and other composition controls. Often these are built on amazing “engines” that manage shapes, text, or image data. Historically, tools of creativity have prided themselves on exposing the full range of capabilities enabled by these engines. These vast palettes of features and capabilities came to define how products and compete in the marketplace. In today’s world of mobility, touch interfaces, and timely/continuous productivity people do not necessarily want to spend time futzing with all the knobs and dials and seek to minimize time from idea to presentation—call this the Instagram effect. Yet even today we see too many tools that are about debugging your work, which is vastly different than getting work done. When a person needs a chart, a table, a diagram or an image how can you enable them to build that out of high-level concepts rather than the primitives that your engine supports? I was recently talking to the founder of an analytics company struggling with customer input on tweaking visualization which was adding complexity and taking engineering time away from adding whole new classes of visualization (like maps or donut charts). You’ll receive a lot of input from early customers to enable slightly different options or adjustments which will both challenge minimalism and add friction to your product without growing the breadth of scenarios your product enables. Staying focused on delivering features will enable your product to do more.
Guess correctly all the time. Many of the latest features, especially those based on machine learning or statistical models involve taking action based on guessing what comes next. These types of features are magical, when they work. The challenge is they don’t always work and that drives a friction-filled user experience. As you expand your product to these areas you’re going to want to find the right balance of how much to add and when, and patience with guessing too much too soon is a good practice. For better or worse, customers tend to love features that guess right 100% of the time and even if you’re wrong only 1% of the time, that 1% feels like a much higher error rate. Since we know we’re going to be learning and iterating in this regard, a best practice is to consider how frictionless you can make incorrect guesses. In other words, how much energy is required to skip a suggestion, undo an action, or otherwise keep the flow going and not stop to correct what the software thought was right but wasn’t. Let’s just call this, lessons from “bullets and numbering” in Word :-)
Finally, a word of caution on what happens as you expand your customer base when it comes to adding features. Anything you want to do in a product can be “obvious” either from usage data or from customer input. The challenge in product management is to create a core set of principles or beliefs about how you want to move the product forward that allow you to maintain the essential nature of your product while adding new features. The tension between maintaining existing customers via stability or incremental improvements versus keeping pace with where the marketplace is heading is the classic design challenge in technology products.
It shouldn’t be much of a surprise, but a great deal of product bloat comes from adding the obvious feature or directly listening to customers, or by failing to stick with design patterns. Ironically, efforts to enhance products for today’s customers are often the very features that add friction, reduce minimalism, and lead to overall bloat.
Bauhaus to Bloatware
This march from Bauhaus to Bloatware is well-known in our industry. It is part of a cycle that is very difficult to avoid. It is not without irony that your best and most engaged customers are often those pushing you to move faster down this path. Most every product in every segment starts minimal and adds features over time. At each juncture in the evolution of the product there is a tension over whether additions are the right marketplace response or simply bloat.
This march (and tension) continues until some complete rethinking introduces a new minimal product addressing most of the same need but from a different perspective. The cycle then starts again. Operating systems, databases, instruction sets, peripheral connection, laptops, interfaces, word processors, and anything you can name has gone through this cycle.
This re-evolution or reimagination of a product is key to the long term viability of any technology.
By adhering to a set of design principles you are able to expand the breadth of use cases your product serves while working to avoid simply adding more friction to the core use cases.
After publication three typos were fixed and the example of personalization clarified.
Learning by Shipping 