IBM Acquires Ubiquity-backed Databand: Reflections from Databand CEO Josh Benamram

Learn Josh's top lessons on finding co-founders, selecting the right trends, avoiding red herrings, and building a global team

On July 6, 2022, IBM acquired Databand (see IBM press release) to address the full spectrum of data observability and help businesses ensure that trustworthy data is being put into the right hands of the right users at the right time. Ubiquity Ventures backed Databand and its CEO Josh Benamram in their March 2019 seed round, and in this post we interview Josh on his reflections as a founder from this 3+ year journey.

Can you sum up what Databand does in one sentence?

Databand helps organizations make sure that the data that they use to run their business is reliable and means what it's supposed to mean. 

What is the big news that Databand just announced?

We announced that we were acquired by IBM. We’ll be joining the IBM team to help progress their own efforts in data observability, our space.

Let’s dive into the story behind the acquisition and lessons learned. Going back to the beginning, how did you meet your Databand co-founders?

I met my co-founders in the Tel Aviv startup ecosystem - the tech community in that area is pretty tight-knit. The relationship actually came initially from folks I worked with at my previous company, Sisense, who understood that I was interested in starting something and going the founder route. They introduced me to two crazy engineers who were starting to work on something interesting that they did not understand and could never try to explain. They thought I might be good at going in and understanding what the technology was all about and whether there was a market for it. I got to know my co-founders Victor and Evgeny over the course of six months or so, and we fell in love and got married and started the company together.

How did you and your team notice this customer need for proactive data observation? 

The simple answer is that we talked to a lot of data engineers and they said that this was the biggest problem they were dealing with. 

I think the smart bet that we took on the market was that this role of data engineering was going to be really important, and that's a position that I learned about in my previous company, Sisense. Data engineers were just starting to come on the scene about that time, and they were starting to get more and more responsibility within the data organization. I knew that these data engineers would have really specific needs and that they had very new ways of working that would require new tools. They also had tons of responsibilities that were hard to keep up with. My co-founders came from data science and data engineering backgrounds themselves, so they worked more directly on these teams. 

What we saw was the convergence of a couple of trends: the growing importance of the data engineer in every data team and the huge transformation that companies were going through in the cloud. And then the last major factor is the cliche that every organization is trying to transition into a data organization; it's not just software eating the world, it’s now data quantifying the world. With that, we decided it was really important to give services to this data engineer persona. We learned that the biggest challenge the data engineers were facing was knowing what data they have to work with and that it was high quality and reliable, and feeling comfortable shipping data to end customers. I think it was that intimate understanding of the people we wanted to serve that helped inform that focus for us.

What failed attempts did you and your team try before getting to your current product?

A lot! I would say in the beginning, we tried to boil the ocean and do everything in our product because we saw such a huge diversity of problems that data teams face. What we learned over time was that we don't need to do everything, just certain things very well.

In fact, data engineers like using best-of-breed tools at every layer of the stack, and our unique value proposition was better suited towards specifically the monitoring and observability piece of the puzzle. We found we could deliver more value to the client by focusing solely on that need, matched with a specific customer profile, and plugging our product  into any data service that they were running. I think this is also what makes us excited about the IBM story, because there's a huge amount of resources we can tap into to build out further product integrations, as well as a growing portfolio of data services to integrate with and begin to provide better visibility into for IBM customers.

Were there any red herrings or false starts along the way?

I think what can be really distracting is when a young startup in an exciting space gets a lot of prospective customer attention from bigger companies early on, and then that attention motivates you to do some work on a business development track that isn't directly tied to specific customers. This can end up spending a lot of cycles and wasting time.

We’ve had inbound that would come from different big organizations where we’ve spent a month building something and engineering the team only for it to end up not going anywhere; the person championing our partnership left, or whatever happened, and that deflated the project. So I think one of our key learnings there was whatever you do in any scenario, it needs to always be immediately tied to some key customer deliverable. There needs to be an end pain point being immediately addressed that people are motivated enough to solve that they'll pay for something. That’s a really key learning for us that has helped us focus-in our product efforts.

What are your top lessons learned during Databand’s seed-to-acquisition journey?

There’s this huge movement around agile methodology, which is a really productive innovation in the market where you don't spend a lot of time cooking an idea internally and scoping out all the requirements there. You just ship an early product to market, gather feedback rapidly, and iterate once it’s out; that's how most scaled up businesses do work really effectively.

However, I actually think the place where this “deliver software first, ask questions later” mentality really works is after a company has already found initial product-market fit. A lot of the core assumptions are already addressed in the product and you use this agile methodology to iterate with experiments that have low cost of failure, and there's a team with a lot of knowledge that can quickly back out of bad bets and right the ship that's already kind of moving.

I think a startup, at day one, is a really different story. The initial bets that you take as a company can actually have huge costs of failure associated with them, because they carry inertia really far to the rest of the business. If you're operating with one or two engineers and they push out a product into market after two months just to get it out there, it can actually be very hard to get feedback quickly enough from just the one or two customers that you have to be able to cycle through fast iterations of that. And you don't have a lot of resources to be able to drop that entire functionality that you just shipped and spin into a totally new direction.

One of my really big lessons from Databand is: for the early days of a startup, do less in actual development and do more in business development, more in cultivating a future sales funnel, and more iteration outside of the core development track so that it's easier to turn things. And only when you have a pretty good, well-informed bet - ideally even with customers lined up for after you've built the product - only then get to the work of actually developing and pushing out product and have it in a somewhat more baked form. Once you have product-market fit, then it makes a lot more sense to shift to this iterative, agile, “ship first, then ask questions” methodology. Until then, it can actually be pretty expensive to do so.

Given your US and Israel presence, have there been any lessons learned around building a global organization? 

Being a global organization like we are allows us to tap into where we have competitive advantages. So for us, we have a competitive advantage in building our sales team in the U.S. because we’re really close to where the strategic market is, versus other Israeli startups who are only sitting in Israel and don't have any sales efforts going. Likewise, we have a competitive advantage in the talent pool in Israel and in our Ukraine team, whereas elsewhere it might be very difficult to find that kind of talent. So the broader the geographic footprint that you create, the more competitive advantage you can build because you have more resources available; but it comes with a lot of challenges.

This is very specific to Israeli companies, but there is a really toxic idea in Israel about not looking to other Israeli companies as customers. When you’re a startup in Israel and you're just getting started out, a lot of investors will tell you, “Don't sell to any Israeli companies because your true market is in the U.S. It's too different, and you need to just focus on getting companies in the U.S.” That is a very bad idea because you really want to be able to get as much customer feedback into the company as possible from day one. If you’re kind of hanging out and waiting to have some product that you can bring to the U.S. that people will look at, you're losing a lot of feedback time. You just need to know that the sales motion is going to be really different, and the buyer profile and how decisions are made are going to be different in a lot of ways, but getting design partners and getting feedback into the company as early as possible (even pre-product) is the most important resource to build on from day one.

What keeps you going during tough times?

My team, for sure. We've had a lot of tough times. We've had a pandemic that we've worked through, we've had two wars that we've worked through as a team, and currently one - unfortunately - that is still ongoing in Ukraine. And what I get inspired by is the level of commitment, energy, and drive to succeed and learn that our team members show on a daily basis. Without them, it would be fairly hard to stay motivated. So, definitely having these very smart and driven people around me is what keeps me going.

What would you tell your past self if you could give them advice?

Aim first, then fire. I think in the early days we probably flexed a little too hard on the iterative motion. I think we took some bets without thinking through the second and third-degree order changes that it might bring. Aiming first a little bit and being more thoughtful about go-to-market tracks might have helped us skip some painful lessons.

On the flipside of that: aim more, but once you’ve made a bet, be quick to double down or be quick to take the money off the table. Be quick to address failures and once a decision has been made, then be fast to evaluate and decide whether or not it's good to change course or double down.

The things we did well that I would tell myself and my team to keep doing are adapting and learning. I think we were really good at being dropped into or jumping into an environment, seeing what the trends were out there, and being adaptive to that and not being held back by ego or prior investments. Once we recognized something, we were really quick to move and go in the flow of where we thought the market was going. I think that aptitude towards learning is something that I would applaud our team for.

What’s your advice to budding technical founders who haven’t yet taken the leap to launch their new company?

Do as much as you can before you actually “launch”. Talk to people that you think are customers and talk to team members. Do it in a way that fits whatever work arrangement you have with your current employer, obviously, but do as much as you can to build the company in your head or on the whiteboard before you actually hit the ground running.

Once you start and you pull the initial team together, the clock moves a bit faster. Once you raise that first round of financing, the clock starts moving even faster. Then once you actually have feet on the ground and you’re running, that clock just keeps moving faster and faster. The more you can do to build what you want to create on the whiteboard beforehand and get customers lined up, the easier it will be on the other end to start delivering and to adjust your expectations or assumptions as you learn new things. If you're doing all of that learning in the timeline of actually creating a company - and worse, post financing - those are just very, very expensive learnings to go through once the clock starts.

---

Are you a founder working on a “software beyond the screen” startup? Let’s talk!

Ubiquity Ventures — led by Sunil Nagaraj — is a seed-stage venture capital firm focused using “software beyond the screen” to bring real-world physical problems into the domain of software, typically through the use of smart hardware or machine learning.