EC Enterprise Applications
Auto Added by WPeMatico
Auto Added by WPeMatico
I’ve met hundreds of founders over the years, and most, particularly early-stage founders, share one common go-to-market gripe: Pricing.
For enterprise software, traditional pricing methods like per-seat models are often easier to figure out for products that are hyperspecific, especially those used by people in essentially the same way, such as Zoom or Slack. However, it’s a different ballgame for startups that offer services or products that are more complex.
Most startups struggle with a per-seat model because their products, unlike Zoom and Slack, are used in a litany of ways. Salesforce, for example, employs regular seat licenses and admin licenses — customers can opt for lower pricing for solutions that have low-usage parts — while other products are priced based on negotiation as part of annual renewals.
You may have a strong champion in a CIO you’re selling to or a very friendly person handling procurement, but it won’t matter if the pricing can’t be easily explained and understood. Complicated or unclear pricing adds more friction.
Early pricing discussions should center around the buyer’s perspective and the value the product creates for them. It’s important for founders to think about the output and the outcome, and a number they can reasonably defend to customers moving forward. Of course, self-evaluation is hard, especially when you’re asking someone else to pay you for something you’ve created.
This process will take time, so here are three tips to smoothen the ride.
Pricing is not a fixed exercise. The enterprise software business involves a lot of intangible aspects, and a software product’s perceived value, quality, and user experience can be highly variable.
The pricing journey is long and, despite what some founders might think, jumping headfirst into customer acquisition isn’t the first stop. Instead, step one is making sure you have a fully fledged product.
If you’re a late-seed or Series A company, you’re focused on landing those first 10-20 customers and racking up some wins to showcase in your investor and board deck. But when you grow your organization to the point where the CEO isn’t the only person selling, you’ll want to have your go-to-market position figured out.
Many startups fall into the trap of thinking: “We need to figure out what pricing looks like, so let’s ask 50 hypothetical customers how much they would pay for a solution like ours.” I don’t agree with this approach, because the product hasn’t been finalized yet. You haven’t figured out product-market fit or product messaging and you want to spend a lot of time and energy on pricing? Sure, revenue is important, but you should focus on finding the path to accruing revenue versus finding a strict pricing model.
Powered by WPeMatico
Few people thought of virtual events before the pandemic struck, but this format has fulfilled a unique and important need for companies and organizations large and small during the pandemic. But what will virtual events’ value be as more of the world attempts to return to life before COVID-19?
To find out, we caught up with top executives and investors in the sector to learn about the big trends they’re seeing — as the sequel to this survey we did in March 2020.
Certain use cases have been proven, they say. Today, you can find numerous small niche events available year-round that might have been buried in the back of a larger in-person conference before 2020. For organizations, internal virtual events can also be instrumental in helping connect and promote engagement for remote-first teams.
However, some respondents acknowledged that low-quality virtual events are growing ever more common, and everyone agreed that there is much more work to be done.
We surveyed:
With the pandemic hopefully becoming more manageable soon, do you feel a return to in-person events is inevitable?
Certain types of events will go back to in person. Obviously, something to do with a President’s Club — the company rewards you with a party in Hawaii — that kind of thing will not go virtual. I think events more focused on increasing reach will continue to trend toward virtual.
“Hybrid is just another buzzword to say that both online and offline events formats will coexist. Of course they will.”
We’re also seeing that many events are getting smaller, more niche. Before the pandemic, if we look at a general pediatric conference, for example, an attendee may only be interested in two topics out of the 200 offered. But now we’ve seen that there’s a rise in many niche events that focus on very specific topics, which helps streamline these events for attendees.
I think such events are still going to happen virtually just because they’re easier to organize and people can have more in-depth conversations. Internal virtual events for employees is another category that is getting more traction, because companies have been going remote. So many the internal events like the company happy hour — events that help employees engage better — we think that’s still going to happen virtually. So there are a number of use cases we think will continue to be virtual and are probably better virtual.
Help TechCrunch find the best growth marketers for startups.
Provide a recommendation in this quick survey and we’ll share the results with everybody.
What sort of trends do you think will emerge once in-person events are possible again?
Another important trend we’re seeing is that a lot of organizers have begun hosting events more frequently. They were doing large conferences in the past, but now they’re pivoting or they’re rethinking their strategy. They realize that hosting maybe 10 events a year is better than hosting one big event every year. A traditional conference is usually multiday, with maybe 200 different topics and 100 different speakers. Now a lot of people are thinking about spreading it out throughout the year.
Powered by WPeMatico
Enterprise startups have several viable exit strategies: Some will go public, but most successful outcomes will be via acquisition, often by one of the highly acquisitive large competitors like Salesforce, Microsoft, Amazon, Oracle, SAP, Adobe or Cisco.
From rivals to “spin-ins,” Cisco has a particularly rich history of buying its way to global success. It has remained quite active, acquiring more than 30 startups over the last four years for a total of 229 over the life of the company. The most recent was Epsagon earlier this month, with five more in its most recent quarter (Q4 FY2021): Slido, Sedona Systems, Kenna Security, Involvio and Socio. It even announced three of them in the same week.
It begins by identifying targets; Cisco does that by being intimately involved with a list of up to 1,000 startups that could be a fit for acquisition.
What’s the secret sauce? How it is going faster than ever? For startups that encounter a company like Cisco, what do you need to know if you have talks that go places with it? We spoke to the company CFO, senior vice president of corporate development, and the general manager and executive vice president of security and collaboration to help us understand how all of the pieces fit together, why they acquire so many companies and what startups can learn from their process.
Cisco, as you would expect, has developed a rigorous methodology over the years to identify startups that could fit its vision. That involves product, of course, but also team and price, all coming together to make a successful deal. From targeting to negotiating to closing to incorporating the company into the corporate fold, a startup can expect a well-tested process.
Even with all this experience, chances are it won’t work perfectly every time. But since Cisco started doing M&A nine years into its history with the purchase of LAN switcher Crescendo Communications in 1993 — leading to its massive switching business today — the approach clearly works well enough that they keep doing it.
If you want to be an acquisitive company, chances are you have a fair amount of cash on hand. That is certainly the case with Cisco, which currently has more than $24.5 billion in cash and equivalents, albeit down from $46 billion in 2017.
CFO Scott Herren says that the company’s cash position gives it the flexibility to make strategic acquisitions when it sees opportunities.
“We generate free cash flow net of our capex in round numbers in the $14 billion a year range, so it’s a fair amount of free cash flow. The dividend consumes about $6 billion a year,” Herren said. “We do share buybacks to offset our equity grant programs, but that still leaves us with a fair amount of cash that we generate year on year.”
He sees acquisitions as a way to drive top-line company growth while helping to push the company’s overall strategic goals. “As I think about where our acquisition strategy fits into the overall company strategy, it’s really finding the innovation we need and finding the companies that fit nicely and that marry to our strategy,” he said.
“And then let’s talk about the deal … and does it make sense or is there a … seller price point that we can meet and is it clearly something that I think will continue to be a core part of our strategy as a company in terms of finding innovation and driving top-line growth there,” he said.
The company says examples of acquisitions that both drove innovation and top-line growth include Duo Security in 2018, ThousandEyes in 2020 and Acacia Communications this year. Each offers some component that helps drive Cisco’s strategy — security, observability and next-generation internet infrastructure — while contributing to growth. Indeed, one of the big reasons for all these acquisitions could be about maintaining growth.
Cisco is at its core still a networking equipment company, but it has been looking to expand its markets and diversify outside its core networking roots for years by moving into areas like communications and security. Consider that along the way it has spent billions on companies like WebEx, which it bought in 2007 for $3.2 billion, or AppDynamics, which it bought in 2017 for $3.7 billion just before it was going to IPO. It has also made more modest purchases (by comparison at least), such as MindMeld for $125 million and countless deals that were too small to require them to report the purchase price.
Derek Idemoto, SVP for corporate development and Cisco investments, has been with the company for 100 of those acquisitions and has been involved in helping scout companies of interest. His team begins the process of identifying possible targets and where they fall within a number of categories, such as whether it allows them to enter new markets (as WebEx did), extend their markets (as with Duo Security), or acqui-hire top technical talent and get some cool tech, as they did when they purchased BabbleLabs last year.
Powered by WPeMatico
I worked at Google for six years. Internally, you have no choice — you must use Kubernetes if you are deploying microservices and containers (it’s actually not called Kubernetes inside of Google; it’s called Borg). But what was once solely an internal project at Google has since been open-sourced and has become one of the most talked about technologies in software development and operations.
For good reason. One person with a laptop can now accomplish what used to take a large team of engineers. At times, Kubernetes can feel like a superpower, but with all of the benefits of scalability and agility comes immense complexity. The truth is, very few software developers truly understand how Kubernetes works under the hood.
I like to use the analogy of a watch. From the user’s perspective, it’s very straightforward until it breaks. To actually fix a broken watch requires expertise most people simply do not have — and I promise you, Kubernetes is much more complex than your watch.
How are most teams solving this problem? The truth is, many of them aren’t. They often adopt Kubernetes as part of their digital transformation only to find out it’s much more complex than they expected. Then they have to hire more engineers and experts to manage it, which in a way defeats its purpose.
Where you see containers, you see Kubernetes to help with orchestration. According to Datadog’s most recent report about container adoption, nearly 90% of all containers are orchestrated.
All of this means there is a great opportunity for DevOps startups to come in and address the different pain points within the Kubernetes ecosystem. This technology isn’t going anywhere, so any platform or tooling that helps make it more secure, simple to use and easy to troubleshoot will be well appreciated by the software development community.
In that sense, there’s never been a better time for VCs to invest in this ecosystem. It’s my belief that Kubernetes is becoming the new Linux: 96.4% of the top million web servers’ operating systems are Linux. Similarly, Kubernetes is trending to become the de facto operating system for modern, cloud-native applications. It is already the most popular open-source project within the Cloud Native Computing Foundation (CNCF), with 91% of respondents using it — a steady increase from 78% in 2019 and 58% in 2018.
While the technology is proven and adoption is skyrocketing, there are still some fundamental challenges that will undoubtedly be solved by third-party solutions. Let’s go deeper and look at five reasons why we’ll see a surge of startups in this space.
Docker revolutionized how developers build and ship applications. Container technology has made it easier to move applications and workloads between clouds. It also provides as much resource isolation as a traditional hypervisor, but with considerable opportunities to improve agility, efficiency and speed.
Powered by WPeMatico
Two decades after businesses first started deploying AI solutions, one can argue that they’ve made little progress in achieving significant gains in efficiency and profitability relative to the hype that drove initial expectations.
On the surface, recent data supports AI skeptics. Almost 90% of data science projects never make it to production; only 20% of analytics insights through 2022 will achieve business outcomes; and even companies that have developed an enterprisewide AI strategy are seeing failure rates of up to 50%.
But the past 25 years have only been the first phase in the evolution of enterprise AI — or what we might call Enterprise AI 1.0. That’s where many businesses remain today. However, companies on the leading edge of AI innovation have advanced to the next generation, which will define the coming decade of big data, analytics and automation — Enterprise AI 2.0.
The difference between these two generations of enterprise AI is not academic. For executives across the business spectrum — from healthcare and retail to media and finance — the evolution from 1.0 to 2.0 is a chance to learn and adapt from past failures, create concrete expectations for future uses and justify the rising investment in AI that we see across industries.
Two decades from now, when business leaders look back to the 2020s, the companies who achieved Enterprise AI 2.0 first will have come to be big winners in the economy, having differentiated their services, scooped up market share and positioned themselves for ongoing innovation.
Framing the digital transformations of the future as an evolution from Enterprise AI 1.0 to 2.0 provides a conceptual model for business leaders developing strategies to compete in the age of automation and advanced analytics.
Starting in the mid-1990s, AI was a sector marked by speculative testing, experimental interest and exploration. These activities occurred almost exclusively in the domain of data scientists. As Gartner wrote in a recent report, these efforts were “alchemy … run by wizards whose talents will not scale in the organization.”
Powered by WPeMatico
Startups and SMBs are usually the first to adopt many SaaS products. But as these customers grow in size and complexity — and as you rope in larger organizations — scaling your infrastructure for the enterprise becomes critical for success.
Below are four tips on how to advance your company’s infrastructure to support and grow with your largest customers.
If you’re building SaaS, odds are you’re holding very important customer data. Regardless of what you build, that makes you a threat vector for attacks on your customers. While security is important for all customers, the stakes certainly get higher the larger they grow.
Given the stakes, it’s paramount to build infrastructure, products and processes that address your customers’ growing security and reliability needs. That includes the ethical and moral obligation you have to make sure your systems and practices meet and exceed any claim you make about security and reliability to your customers.
Here are security and reliability requirements large customers typically ask for:
Formal SLAs around uptime: If you’re building SaaS, customers expect it to be available all the time. Large customers using your software for mission-critical applications will expect to see formal SLAs in contracts committing to 99.9% uptime or higher. As you build infrastructure and product layers, you need to be confident in your uptime and be able to measure uptime on a per customer basis so you know if you’re meeting your contractual obligations.
While it’s hard to prioritize asks from your largest customers, you’ll find that their collective feedback will pull your product roadmap in a specific direction.
Real-time status of your platform: Most larger customers will expect to see your platform’s historical uptime and have real-time visibility into events and incidents as they happen. As you mature and specialize, creating this visibility for customers also drives more collaboration between your customer operations and infrastructure teams. This collaboration is valuable to invest in, as it provides insights into how customers are experiencing a particular degradation in your service and allows for you to communicate back what you found so far and what your ETA is.
Backups: As your customers grow, be prepared for expectations around backups — not just in terms of how long it takes to recover the whole application, but also around backup periodicity, location of your backups and data retention (e.g., are you holding on to the data too long?). If you’re building your backup strategy, thinking about future flexibility around backup management will help you stay ahead of these asks.
Powered by WPeMatico
Anomaly detection is one of the more difficult and underserved operational areas in the asset-servicing sector of financial institutions. Broadly speaking, a true anomaly is one that deviates from the norm of the expected or the familiar. Anomalies can be the result of incompetence, maliciousness, system errors, accidents or the product of shifts in the underlying structure of day-to-day processes.
For the financial services industry, detecting anomalies is critical, as they may be indicative of illegal activities such as fraud, identity theft, network intrusion, account takeover or money laundering, which may result in undesired outcomes for both the institution and the individual.
There are different ways to address the challenge of anomaly detection, including supervised and unsupervised learning.
Detecting outlier data, or anomalies according to historic data patterns and trends can enrich a financial institution’s operational team by increasing their understanding and preparedness.
Anomaly detection presents a unique challenge for a variety of reasons. First and foremost, the financial services industry has seen an increase in the volume and complexity of data in recent years. In addition, a large emphasis has been placed on the quality of data, turning it into a way to measure the health of an institution.
To make matters more complicated, anomaly detection requires the prediction of something that has not been seen before or prepared for. The increase in data and the fact that it is constantly changing exacerbates the challenge further.
There are different ways to address the challenge of anomaly detection, including supervised and unsupervised learning.
Powered by WPeMatico
Today, Tractable is worth $1 billion. Our AI is used by millions of people across the world to recover faster from road accidents, and it also helps recycle as many cars as Tesla puts on the road.
And yet six years ago, Tractable was just me and Raz (Razvan Ranca, CTO), two college grads coding in a basement. Here’s how we did it, and what we learned along the way.
In 2013, I was fortunate to get into artificial intelligence (more specifically, deep learning) six months before it blew up internationally. It started when I took a course on Coursera called “Machine learning with neural networks” by Geoffrey Hinton. It was like being love struck. Back then, to me AI was science fiction, like “The Terminator.”
Narrowly focusing on a branch of applied science that was undergoing a paradigm shift which hadn’t yet reached the business world changed everything.
But an article in the tech press said the academic field was amid a resurgence. As a result of 100x larger training data sets and 100x higher compute power becoming available by reprogramming GPUs (graphics cards), a huge leap in predictive performance had been attained in image classification a year earlier. This meant computers were starting to be able to understand what’s in an image — like humans do.
The next step was getting this technology into the real world. While at university — Imperial College London — teaming up with much more skilled people, we built a plant recognition app with deep learning. We walked our professor through Hyde Park, watching him take photos of flowers with the app and laughing from joy as the AI recognized the right plant species. This had previously been impossible.
I started spending every spare moment on image classification with deep learning. Still, no one was talking about it in the news — even Imperial’s computer vision lab wasn’t yet on it! I felt like I was in on a revolutionary secret.
Looking back, narrowly focusing on a branch of applied science undergoing a breakthrough paradigm shift that hadn’t yet reached the business world changed everything.
I’d previously been rejected from Entrepreneur First (EF), one of the world’s best incubators, for not knowing anything about tech. Having changed that, I applied again.
The last interview was a hackathon, where I met Raz. He was doing machine learning research at Cambridge, had topped EF’s technical test, and published papers on reconstructing shredded documents and on poker bots that could detect bluffs. His bare-bones webpage read: “I seek data-driven solutions to currently intractable problems.” Now that had a ring to it (and where we’d get the name for Tractable).
That hackathon, we coded all night. The morning after, he and I knew something special was happening between us. We moved in together and would spend years side by side, 24/7, from waking up to Pantera in the morning to coding marathons at night.
But we also wouldn’t have got where we are without Adrien (Cohen, president), who joined as our third co-founder right after our seed round. Adrien had previously co-founded Lazada, an online supermarket in South East Asia like Amazon and Alibaba, which sold to Alibaba for $1.5 billion. Adrien would teach us how to build a business, inspire trust and hire world-class talent.
Tractable started at EF with a head start — a paying customer. Our first use case was … plastic pipe welds.
It was as glamorous as it sounds. Pipes that carry water and natural gas to your home are made of plastic. They’re connected by welds (melt the two plastic ends, connect them, let them cool down and solidify again as one). Image classification AI could visually check people’s weld setups to ensure good quality. Most of all, it was real-world value for breakthrough AI.
And yet in the end, they — our only paying customer — stopped working with us, just as we were raising our first round of funding. That was rough. Luckily, the number of pipe weld inspections was too small a market to interest investors, so we explored other use cases — utilities, geology, dermatology and medical imaging.
Powered by WPeMatico
Every application is a palimpsest of technologies, each layer forming a base that enables the next layer to function. Web front ends rely on JavaScript and browser DOM, which rely on back-end APIs, which themselves rely on databases.
As one goes deeper down the stack, engineering decisions become ever more conservative — changing the location of a button in a web app is an inconvenience; changing a database engine can radically upend an entire project.
It’s little surprise then that database technologies are among the longest-lasting engineering projects in the modern software developer toolkit. MySQL, which remains one of the most popular database engines in the world, was first released in the mid-1990s, and Oracle Database, launched more than four decades ago, is still widely used in high-performance corporate environments.
Database technology can change the world, but the world in these parts changes very, very slowly. That’s made building a startup in the sector a tough equation: Sales cycles can be painfully slow, even when new features can dramatically expand a developer’s capabilities. Competition is stiff and comes from some of the largest and most entrenched tech companies in the world. Exits have also been few and far between.
That challenge — and opportunity — is what makes studying Cockroach Labs so interesting. The company behind CockroachDB attempts to solve a long-standing problem in large-scale, distributed database architecture: How to make it so that data created in one place on the planet is always available for consumption by applications that are thousands of miles away, immediately and accurately. Making global data always available immediately and accurately might sound like a simple use case, but in reality it’s quite the herculean task. Cockroach Labs’ story is one of an uphill struggle, but one that saw it turn into a next-generation, $2-billion-valued database contender.
The lead writer of this EC-1 is Bob Reselman. Reselman has been writing about the enterprise software market for more than two decades, with a particular emphasis on teaching and educating engineers on technology. The lead editor for this package was Danny Crichton, the assistant editor was Ram Iyer, the copy editor was Richard Dal Porto, figures were designed by Bob Reselman and stylized by Bryce Durbin, and illustrations were drawn by Nigel Sussman.
CockroachDB had no say in the content of this analysis and did not get advance access to it. Reselman has no financial ties to CockroachDB or other conflicts of interest to disclose.
The CockroachDB EC-1 comprises four main articles numbering 9,100 words and a reading time of 37 minutes. Here’s what we’ll be crawling over:
We’re always iterating on the EC-1 format. If you have questions, comments or ideas, please send an email to TechCrunch Managing Editor Danny Crichton at danny@techcrunch.com.
Powered by WPeMatico
There is an art to engineering, and sometimes engineering can transform art. For Spencer Kimball and Peter Mattis, those two worlds collided when they created the widely successful open-source graphics program, GIMP, as college students at Berkeley.
That project was so successful that when the two joined Google in 2002, Sergey Brin and Larry Page personally stopped by to tell the new hires how much they liked it and explained how they used the program to create the first Google logo.
Cockroach Labs was started by developers and stays true to its roots to this day.
In terms of good fortune in the corporate hierarchy, when you get this type of recognition in a company such as Google, there’s only one way you can go — up. They went from rising stars to stars at Google, becoming the go-to guys on the Infrastructure Team. They could easily have looked forward to a lifetime of lucrative employment.
But Kimball, Mattis and another Google employee, Ben Darnell, wanted more — a company of their own. To realize their ambitions, they created Cockroach Labs, the business entity behind their ambitious open-source database CockroachDB. Can some of the smartest former engineers in Google’s arsenal upend the world of databases in a market spotted with the gravesites of storage dreams past? That’s what we are here to find out.
Mattis and Kimball were roommates at Berkeley majoring in computer science in the early-to-mid-1990s. In addition to their usual studies, they also became involved with the eXperimental Computing Facility (XCF), an organization of undergraduates who have a keen, almost obsessive interest in CS.
Powered by WPeMatico