The story in brief
Druva’s story examines data protection as an operational responsibility. A managed service is valuable when customers can understand which work it takes on and how that work is verified.
Business data can move into the cloud without making the responsibility for protecting it disappear. Druva, founded by Jaspreet Singh and his cofounders, built its identity around that responsibility. Singh’s company biography records earlier work at Veritas and Ensim, giving the story a foundation in enterprise infrastructure.
A service beyond the software
Druva presents its offering as cloud-based data protection delivered as a managed service. The distinction matters to the buyer: the product includes work that a customer would otherwise need to organise and maintain. Storage, protection and recovery belong to an operational setting, not an isolated feature demonstration.
Trust must survive a difficult day
Infrastructure products are often judged most seriously when something goes wrong. A polished normal-day experience is only part of the proposition. A buyer also needs to understand the limits, recovery process, responsibilities and support arrangements. Those questions should influence how a young enterprise company communicates its value.
The founder lens
Our reading of Singh’s journey is to look for burdens that customers carry repeatedly but do not consider their own core work. Turning such a burden into a dependable service can create a clear proposition. It also creates an obligation to explain precisely which responsibilities the service assumes and which remain with the customer.
Evaluate the moment the service is needed
A routine status screen may look reassuring without explaining what will happen when information must be recovered. For a founder building an infrastructure service, that gap between normal operation and a difficult event deserves attention. Define the customer’s task, the service’s responsibility and the evidence available to confirm the outcome. A managed model can simplify some activities while leaving others with the customer. Those boundaries should be understandable during onboarding, not discovered in the middle of an incident. The useful business lesson is to sell a clearly described operating responsibility and keep the supporting process visible enough for a buyer to evaluate it.
Put the idea to work
Use these questions to investigate the idea in your own context.
- Describe the outcome a customer needs during a recovery event.
- Separate provider responsibilities from customer responsibilities.
- Ask what evidence demonstrates that the expected process works.
A closer look
Does moving data to a cloud service remove every protection responsibility?
No. Responsibilities depend on the service and the customer’s setup. This article explores the product and company-building question, not a security assessment of Druva or a recommendation for a particular backup configuration.
Sources & editorial note
This profile draws on the public sources below. Company and founder accounts describe their own perspective. Our analysis, questions and takeaway are editorial interpretation. This is not an original interview or a sponsored feature.
See our editorial standards or request a correction. For another perspective, read What an incubator brings to the table.
