CEO Lars Grønnegaard shares Dreamdata’s product story and vision
As Dreamdata continues on its growth journey, CEO Lars Grønnegaard sits down with Code Story host Noah Labhart to reflect on the journey and his vision for the future.
In sharing the tale of how Dreamdata came to be, Lars dives into the dynamics behind getting a product off the ground.
So if you’re interested in what it takes to get a product off the ground, the challenges, successes and learnings, then you’re going to love this chat.
Plus, you’ll get some juicy sneak peeks into the Dreamdata vision for the (not so distant) future 👀
In this post we’ll cover the main points from the conversation, including:
How a need for go-to-market insights sparked the dream that would become Dreamdata
How they created a prototype with duct tape and standard products
Why you shouldn't build to scale
The lessons learned: focus on ICP, even if it means rejecting customers
The vision for Dreamdata
Some tips on what startups should avoid at all cost
and much more! Read on 👇
How Dreamdata came to be
Dreamdata is a B2B revenue attribution platform. Just doing some explanation around how we got to build this product, we'll also explain what it is. I'm a CEO now, but I used to be a product person. So I'm still a product person, but I used to run product at a Copenhagen scale-up called Trustpilot.
In that capacity, we had a very mixed go-to-market. You say we were doing a lot of product-led, we were doing a lot of marketing-led and there was also sales-led. We had many different initiatives of bringing in business to this company.
As the head of product, I cared a lot about the business, of course, especially the product that part of this go-to-market meant that we had to understand, like what was the actual impact of this?
Measuring the impact of our go-to-market efforts
We were giving a lot of product, like freemium models, we were giving a lot of product away. What was the impact then? And essentially that is what attribution is about, that you have certain tactics in your go-to-market.
It can be like big things like giving your product away for free, or it can be small things like running an ad campaign. And you want to tie those tactics into behaviors that you can observe with your prospects or potential customers.
And then you want to tie that again into the business results. So that could be generated pipeline or a new business closed won.
If you want to create a data model of that, so you can do analysis and figure out on the strategic level what's working? Is this whole product led at all, bringing in any business? Is it beneficial at all? Down to the very tactical level where you want to say, "Okay, does buying this keyword actually make sense? Does it impact any customer journeys other than becoming revenue?"
Think about a meeting where you have the head of product, the head of sales and the head of marketing, and they are all discussing their contribution to revenue, and each of them names a number. When you add them up, it gives like 200% of the revenue that you made. That meeting was real and it happened, and I think it happens in a lot of companies.
At some point, you need to figure out what is actually not the truth, but at least something that's operational that can help you make good decisions.
So we basically made the decision, "Hey, we need to figure out what is the impact of the different parts of the go-to-market."
Like many tech companies, we had lots and lots of data. We had a data warehouse. We had data describing everything in the business, but we were missing this model that would glue all those data points together in a meaningful data model that we could use for analysis.
And we went looking for a product that would fix it for us and we couldn't really find one.
So in that context, we built something ourselves so that we could answer the question, right, and start working in a more data-driven way in that company.
Like many founding stories, we also just got frustrated that there wasn't a product for this, that we had to sit down and do all that tedious work of cleaning up the data, joining it, analyzing it, building models.
We decided to basically take those experiences out, and build a company around it.
Dreamdata: the vision
The way we think about it is we have a long-term vision for the company, which I would say stretches way beyond thinking about attribution, because for us, attribution in a way it's just one analysis on top of this data.
So our vision is to use this data set, or this data platform for many different purposes in a company. And we call that revenue automation.
And for us, attribution is just one of those. So I think for us, the main guidance for us and the north star, that is our vision. So that is revenue automation, basically enabling companies to automate as much of generating revenue as possible.
That's a grand vision, right? So we use that for that. And then we will make tactical decisions. Of course, we will try to see what can we then actually take to market? What can we get customers to buy and pay for, that fits inside of that vision?
Creating a prototype with duct tape and standard products
The experience from Trustpilot when we were solving it inside of that company was you can say the first, very first, early prototype we have, what we would do is we would take the data from our tracking. So we used segment.com for tracking our uses on our website and in our applications.
So we had a lot of tracking data and then we would take commercial data from Salesforce. So describing the sales pipelines and the movements in there, and we would take some data from advertising platforms and we would put it all into a data warehouse and then we would process it into nice models.
And that was essentially the text that we then took out and tried to build this like early prototype around. So we knew how to build it because we'd done it once. And then we went out and found a couple of other companies that acknowledged that they had the same pain.
And we actually went deliberately looking for customers that were using segment.com, because then we knew that we'd be able to get the data.
We didn't want initially to build a whole ETL tool and a tracking infrastructure before we could test something. So we had to go looking, we had to go look for someone who had enough data that we could build our prototype product or MVP with them.
So we went looking for somebody who was using Segment that way we could get the tracking data. And they actually also had stored tracking data from historical data and Segment has an ETL product.
So that was a way to get the CRM data out and the advertising platform data out into BigQuery. And then we basically hand-built the models.
That was the MVP app, building that, and then slamming a set of Google data studio dashboards on top of it so that we could visualize the results.
The early trade-offs
The way we went about building the MVP, and the trade-offs of choosing Segment and not building a lot of infrastructure, actually meant that we had fewer constraints than we have had later on.
Because as we sort of moved into building a more scalable product, we had to make a lot of painful decisions and cut off a lot of features because we couldn't build all of it. But because of the path we took, where we stuffed things into BigQuery and we built a fairly structured process of processing the data into the models we wanted.
It was quite easy for us to modify that, and I would say that potentially created a situation where there wasn't a lot of constraints on the MVP.
I'm not sure that was good, but at least sometimes it's nice to have constraints, that means you have to make lots of decisions early on, but we could actually build a lot of what looked like product, because it was basically handmade processing and data and model building inside of BigQuery and then a set of dashboards that we hand-built for customer on top of it.
Maybe too few decisions were forced on us there, but then when we went from say, having proven to ourselves, okay, there is a problem. There are some people that want to pay for this. And we said, "Okay, now we're going to go on and build, say the first version of the product." Then we had to make lots of decisions, right.
Then we had to start cutting away features that didn't really make sense or that nobody was happy about, or we just liked ourselves, right.
Early Dreamdata product
Scaling: why you shouldn't build to scale
I think we have a philosophy of not building to scale too early. The very first prototype, which is duct tape and basically custom-built per customer. Well that scales to five customers, because then you just run out of mental bandwidth to remember all the different modifications you did for different customers.
And then you have to go, "Okay, now we're going to get everybody the same product," because at that stage, we'll say, "Okay, the next goal for us was 10 paying customers." That was 12 months down the line. We wanted 10 paying customers. It's not a massive amount of data we're going to be processing. We can still do a lot of handholding per customer.
It's a higher level of scalability, but it's not real scalability, the way you define it in a larger company.
Then, you've reached the next milestone, so you go to 10 customers and now you're looking at, "Okay, how do we go from these 10 paying customers to maybe 200, 300?" So 10X-ing or 20X-ing the customer base. Now you need a different level of scalability.
You still don't need full scalability, because you're just still just a fledgling little company. You can get away with lots of things. But then we built to the next level, right?
As an example, for instance, one thing that shows how we were thinking about this is when we started out, we got a lot of everything for us is built in Google Cloud. We got a ton of Google Cloud credits because you could get that as a startup.
Well, you have a lot of credits then you don't really care about the cost. I mean, no matter how lazy we were about scalability, we couldn't use all that money because it was just a lot of money.
So no matter how badly all the SQL was written, it didn't really matter. Then we ran out of credits and all of a sudden it did matter.
And then you need to fix scalability to a point where it goes from like, "Okay, I don't have to explain to my investors that we are actually spending 50% of our revenue on Cloud bill," so we need to cut it down to a reasonable level, something that fits our stage.
It doesn't necessarily have to be like you are at scale stage, but it has to fit our stage. We're a seed stage company, right?
Scaling: start with standard product
And it's very similar on the product side of things.
It's like we have in the way we build our models, data models we built, there are certain things that are very standard per customer.
Early Dreamdata product menu
And then there are certain things where every customer will always have a little tweak. They always have a different opinion, especially around how they set up their CRM and their sales pipeline.
They will have called the stages different things. They will have named the pipeline different things. And when you get the data from the CRM system, it doesn't tell you about that structure. So we have to, for every customer, we can make some assumptions. And most of the time it works.
But for most of our paying customers, we have to go in and say, "Well, actually new business opportunity is this pipeline, this stage date field, it's that date field." So there will be small customizations.
And when you are onboarding one customer a month, it doesn't matter. But when you approach onboarding 10 or 15 customers a month, then the data engineering team starts getting super annoyed that they're spending all the time doing that, and that's not scalable, right? Because it was fine that they were doing it one day a month, they were picking up these tasks and fixing them.
But now all of a sudden they're getting disrupted in everything they do. And they come to you and say, "Hey, we can't build anything meaningful because all the time we're getting disrupted with these demands from our CS team, customer success team. They're coming to us with this, we have to build it," and they can't build anything real product.
And then you say, "Okay, well let's make it more scalable because now this is not the right scale anymore." And then you make it scalable.
You try to find ways to get customers to be able to self-service it. Or at least the customer success team should be able to self-service it so that you don't have to bring it to an engineering team. Right? So it's always about right scale.
Building the dream team: what, why, how
So we started out, we were two co-founders that came out of Trustpilot and then we were joined by one of the companies we showed the product, the early prototype to, very, very early on with Steffen who then became the third co-founder.
And then between us, we had our strong product knowledge or capability for building product. We had strong tech and scaling, tech that's Ole. And then we had Steffen who has a very strong commercial, is a very practical marketer. And in many ways represents the core persona that we are selling to.
So we were three guys founding the company, and we raised some money so that we could hire some people. Of course, we were looking for things that we needed. We needed to iterate and go from this, the very duct tape prototype that I described before.
So we wanted to go from that to something that was slightly more scalable, not scalable for a 100 customers, but just at least scalable for 15 or 10 customers, or whatever we needed for the next milestone.
So we went looking for engineers, designers, because we didn't have any design competency, any design skills in the team. That was the first thing we needed because we needed to iterate the first prototype into more of a real product.
And then we went looking for people who had entrepreneurial mindset. That was what we would look for.
Somebody who would also ideally thrive in chaotic environment, because at that stage we got to be six people and everybody's doing everything, and you don't want someone who longs for stable processes and lots of procedures. You want people, at that stage, you just want people who love that there is very little structure and that you can be part of making a lot of decisions.
And, a desire to impact, I think is very important. You want to individually contribute to the success of the company. You want people who have that motivation.
Proud of product and team
We love product. So I think we love, and I love the quality of product we've been able to build very fast and the amount of value that it can bring to customers. I'm very proud of that. But I'm also very proud of the team that we assembled.
So we have a very strong team and growing from these three founders to... We're 27 people now, going from just having a couple product guys and a marketing guy. And then all of a sudden you have a sales team that's performing and they have a process. And lots of things that we maybe did not know how to do, I'm very proud of them.
I'm proud of having built something that if I go back two years and I ask myself, "How do you do this?" I would say, "I have no clue how to do it." And now we are here and we have something that works. I'm very proud of that.
Lessons learned: focus on ICP even if it means rejecting early customers
One thing that I think of as a major mistake we made... I'm not sure that we could have done it differently. I described how we originally built the product around Segment, segment.com because that made for us not having to build a lot of product, to be able to actually sell and get customers on board.
If we sold to customers that were already customers of segment.com, we would be able to just build the valuable part of the product, the unique part of our product, which is the data models. So we had a period where our ICP, our ideal customer profile, when we set out, we thought, "Okay, it's going to be B2B SaaS companies that are venture backed. But at some point we drifted away from that because we had inbound companies that were exciting. So we had companies coming to us saying, "Hey, we think your product is exciting. Can we have it?"
But they didn't fit our ICP. They weren't Segment customers. And they were different, they were not B2B SaaS companies. And that meant we had to build a lot of product. We're happy about the product we built now, but it slowed down the process of learning, it slowed down the process of accelerating towards getting to a real go-to-market, etc. because we had to build much more product.
It's something where I feel we didn't do as well as we could have done. If we had stayed more focused on our ICP, I think we could have moved faster.
And I can see also now we have some parts of our product like we did, because we ended up building some of these features from Segment ourselves, we built some ETL product ourselves. We are starting to say, "Okay, we're actually going to sunset this one integration for this CRM system, because, really nobody uses it."
So there's been some waste there because of that lack of focus.
What would have been done differently?
I think the main place where I would consider doing it differently is what... The thing that I talk about, about focus. So I would've focused more early on, I would've basically stuck to that ICP that we had, and I would have, suffered through the pain of turning people away at the door and say, "Hey, you're not within our ICP. This is not going to be a success for you, Mr. Customer."
And then I would've focused very, very narrowly on those ICP customers, because that would've helped us have much more speed. That would've been the biggest thing that I would've changed.
The Dreamdata future: Revenue Automation
So, for the product, we are moving in like the direction of the grand vision that I was talking about earlier.
So we are moving in the direction of revenue automation. So for us, that means taking the product from being a data platform where we provide a set of analytics or insights on top of it. We want to make some of those insights, and turn them directly into actions.
So we want to take data and give it back to some of the systems that we got it from so that you can directly action the data. And that for us, is helping companies automate revenue more and more and more. So that is what's ahead of us.
From a scaling perspective, we're just... Yeah, we're scaling the company, so we're going to build out our sales team build out our product team. So we are on a typical, rapid scaling journey. That's the path we're on. So it's going to be from 27 people to probably tripling that in 12 to 18 months. It's going to be from, from here on, it's going to be a crazy journey.
