Krishna Yadappanavar and the Trouble with a Perfect Product

A perfect product can be an awkward thing to sell. Its creators know why every piece belongs. The customer knows why Tuesday was a disaster. Somewhere between those two bodies of knowledge, a company has to make a living. Krishna Yadappanavar has spent much of his career in that gap, building the software beneath other people’s software and learning that technical confidence needs a companion: a reasonably good pair of ears.

The telling detail comes from his own reflection on Springpath. The team had built what it considered the ideal product without sufficiently listening to customer requirements. Its partnership with Cisco changed the conversation. Here was a founder discussing an acquired company and choosing to remember the correction, rather than simply polishing the trophy. A product can be impressive and still need to be taught some manners.

The machinery beneath the screen

Before the founder titles, there was the work of making data behave. Yadappanavar’s background includes VMware, where he helped develop VMFS, the company’s virtual machine file system. Think of the file system as the arrangements backstage: the audience may never see them, but the performance becomes rather difficult when nobody can find the scenery.

A 2009 technical paper on decentralized deduplication credits him among the engineers who developed the core of VMFS. The acknowledgement is a useful glimpse of infrastructure work as it usually happens: several people, difficult shared problems, and an accomplishment that disappears beneath the applications it supports. The paper’s subject was reducing duplicated data in clustered storage. Even the vocabulary insists on getting below the surface.

That work helps explain the continuity in his career. Storage, virtualization and observability can appear to occupy different corners of a conference hall. They all depend on arranging information so that something useful can happen without the machinery collapsing under its own demands. His projects keep returning to that practical question.

His education includes computer science at BITS Pilani. The route from studying computation to building its less visible foundations is less glamorous than the usual startup montage, but considerably more specific. The product may be a file system. The ambition is to let other people do their work without having to think about the file system at all.

Springpath, before the price tag

In 2012, Yadappanavar and fellow VMware engineer Mallik Mahalingam started the company initially known as Storvisor. It later became Springpath. By its public emergence in 2015, it had raised $34 million from investors including Sequoia, NEA and Redpoint. The founders were taking their experience with virtualized infrastructure into a company of their own.

Springpath’s proposition was concrete: a software platform that used standard servers for storage. Its design combined flash for caching with magnetic disks for persistent data, presenting storage for virtual machine deployments. A buyer could care about the engineering, certainly. The buyer could also care about what equipment needed purchasing and how the system would grow. An architecture diagram eventually meets a purchase order.

The engineering record has its own quieter milestones. Yadappanavar is named among the inventors on a patent for efficient snapshots in distributed hybrid storage and compute nodes. A snapshot preserves a view of data at a point in time. Making that operation efficient across a distributed system is the sort of problem that can occupy serious ingenuity while earning absolutely no applause at a dinner party.

Cisco and Springpath had worked together since 2016 to deliver HyperFlex. In September 2017, Cisco completed the acquisition. The transaction is an important career milestone for Yadappanavar, and the relationship preceding it matters too: this was a company whose technology had already entered a larger commercial partnership.

A transaction gives a story a number. His later reflections give it a lesson. Read together, they suggest that building the technology and finding the setting in which customers can use it are intertwined jobs. A company does not finish the first and then casually turn its attention to the second.

A second company, a different set of questions

After Springpath and time at Cisco, Yadappanavar turned toward the increasing volume of data produced by developers and operations teams. Kloudfuse took shape with Pankaj Thakkar and Ashish Hanwadikar. The company was incorporated in 2020; a January 2021 filing identifies Yadappanavar as its chief executive. The paperwork supplies an early marker for an idea that later became a public product.

Its launch out of stealth came in November 2023 with $23 million in funding, including a $17 million Series A. The founding team brought experience from VMware, Nicira, Springpath and Cisco. They were applying that experience to observability: the information engineers use to understand what their running systems are doing.

At launch, Yadappanavar described a mission to make unified cloud observability more accessible and scalable. The audience was familiar: developers, DevOps teams and site reliability engineers spending time on troubleshooting and data management. The company proposed bringing the signals together in an observability data lake inside the customer’s virtual private cloud.

The location is part of the proposition. A system designed around the customer’s own cloud asks a different purchasing question from a service that receives data in the vendor’s environment. Where does the information live? Who can work with it? What does keeping it cost? These are wonderfully unromantic questions. They also determine whether software earns a place in production.

Five letters for a complicated working day

Yadappanavar made his argument easier to discuss through a set of C’s. In a September 2024 conversation, he focused on cardinality, control and cost. By December, his explanation included consolidation and causality. The terms describe a working problem from different angles: too many combinations of data, questions about ownership, expense, scattered tools, and the search for a cause.

Cardinality is the least sociable word in the group. Operational data can carry labels for a service, a region, a version or another attribute. The possible combinations multiply. An engineer investigating a failure needs the relevant detail, rather than merely an impressive heap of detail. The challenge is preserving the ability to ask a precise question.

At KubeCon North America in 2024, Yadappanavar discussed that problem with Savannah Peterson and Rob Strechay. He also described customers wanting to keep their data in their own environments and bring it together for querying. The conversation connected architecture to the practical experience of investigating an incident.

Causality puts a limit on the sales pitch. In his December explanation, he acknowledged that a platform cannot claim to identify the root cause every time. That qualification matters. An operator needs help examining an unfamiliar failure. Promising certainty about every future failure would be a rather ambitious warranty.

The customer gets a vote

The Springpath lesson returned in Yadappanavar’s discussion of early selling. He emphasized founders staying engaged with customers, understanding actual use cases and adjusting the product. Listening, in this account, has consequences. It changes what gets built. A conversation that cannot alter a priority is liable to become a ceremony.

There is a useful symmetry here. Observability is about paying attention to signals produced by a system. Building a company requires paying attention to signals produced by its customers. The analogy is ours, but the practical connection is plain: information has value when it can influence a decision. Collecting it is only the beginning.

“Our customers know what they need, and we collaborate closely with them to ensure we meet those needs.”Krishna Yadappanavar · December 2024

His public work also extends to advising and investing in emerging companies across data, cloud, security and AI. That puts the same product questions in front of founders at earlier stages. Expertise can help with architecture and strategy. Experience becomes especially useful when it helps somebody else recognize an assumption before the assumption becomes expensive.

Two weeks in India, more questions to bring home

In August 2024, Yadappanavar wrote about a two-week trip to India to visit customers and meet prospective buyers. He had grown up there; now he was looking at companies building with cloud and container technologies. The visit brought him back to the cost of operating an observability system, including the people needed to maintain it.

He reported conversations with CTOs who estimated that building and maintaining their own system could require 12 to 24 additional engineers. That was their estimate, rather than a universal staffing rule. It makes the buying decision tangible. A team choosing infrastructure software is also choosing which work its engineers will spend their days doing.

His January 2025 writing took a similar practical approach to AI tools. He argued for careful adoption and human oversight, including attention to situations where generated code might create additional review work. The attraction of a tool deserves to be weighed against the work it leaves behind. Even progress has housekeeping.

The design brief keeps changing

Kloudfuse has continued developing beyond those early conversations. Its current leadership page names Pankaj Thakkar as CEO. Yadappanavar’s place in this story is as co-founder and the executive who articulated its early direction. In May 2026, the company introduced version 4.0; in September it announced a CloudX award for cloud monitoring and observability innovation.

Those later developments belong to the company’s continuing story. Yadappanavar’s career supplies a more durable question for anyone building a product: what happens when the customer’s definition of useful disagrees with the maker’s definition of complete? His own answer has involved partnerships, conversations and revisions.

The file system, the storage platform and the observability data lake are different pieces of machinery. The people operating them still need something fairly ordinary: a way to get their work done. A founder can arrive with a sophisticated answer. It helps to stay long enough to hear the question.