Welcome to “How to Start a Startup,” a short series aimed at giving aspiring entrepreneurs a range of views about starting a new team, product, or initiative.
This week, our panel of founders will discuss what marks a company’s progress beyond the startup stage.
Michael Shaulov, CEO and Co-founder of Fireblocks:
"I think that building a three-year roadmap is a bit meaningless. It’s better to have a strategy that lets you say, “In three years’ time, this is essentially what we're going to build"
Everything we've discussed to now is about planting the seed of a company. You've got an idea. You take it into it and find your co-founders and your first hires. You bring a little money in — and it feels like the moment when you really start to look ahead. What sort of things are you really thinking about? How do you set that seed up to grow?
The main thing is to make sure you keep executing into the right market. Even if you've gathered a lot of information for your seed round, markets remain dynamic — especially if they’re new.
Most of my startups were in completely new markets that continuously evolve. Something you thought was a huge opportunity yesterday is no longer an opportunity today. But meanwhile, a new opportunity opens up next door, and you need to pivot to it.
Also, many times you think that you're executing in the market in a particular way, but conversations with customers reveal that they actually view you very differently from the way you view yourself.
This sort of self awareness about markets and value propositions is the most important part of the journey.
How do you go about setting roadmaps at that time? What's the right level of detail?
A strategy document — a set of assumptions and analysis — should be like two or three pages. What do you want to be when you’re really big? What assumptions are you making about how the market is going to evolve or expand? What will support the growth to take you from point A to point Z?
You do need to be honest with yourself. When you look at a lot of the blockchain projects from 2017 or 2018, that was essentially what was missing: the plan. They basically said, "We are going to take over the world. Gold is a $4 trillion opportunity. We are going to take this opportunity, and we're going to be like the tokenized gold exchange."
But is what we’re going to build really worth $4 trillion? That's not true, right?
At the end of the day, you have a long set of assumptions and a long list of things that need to happen — and some of them are within your control. And actually to be worth $4 trillion, some of these thigs are outside of your control.
Those things need to be mapped. I think that building a three-year roadmap is a bit meaningless. It’s better to have a strategy that lets you say, “In three years’ time, this is essentially what we're going to build. Now let’s execute for the next six months or the next nine months.
It's much less of a product roadmap and it's more of like a company roadmap at that point, right?
Yeah. A lot of the time people think, “We will build it and they will come.” And that's not the way it works. There’s a concrete set of actions in terms of market education, evangelism, displacement of incumbents, whatever — like, 10 activities you need to run. And another 10 activities that are completely out of your control, like the market conditions at every given moment.
Any one of your assumptions about how the market will evolve can fail, and you need to be very aware that those assumptions are failing.
Ben Milne, Founder and Chairman of Dwolla Inc:
"When we started looking more inward directly at helping our clients grow and really fortifying our infrastructure for them and stopped focusing on the narrative with the media, it's amazing how much noise just went away"
So you've got this thing set up. When did you really start to look ahead? When did you start thinking in bigger increments than in the early days? Was there a particular moment when you started to think about a three-year roadmap or growing to 100 people?
Within the first couple of years, we were still building the most needed thing without a specific roadmap. Until after about 20 to 30 people, we didn't have a single product person. We were just cranking on everything now, fast, get it out, solve it.
“What's the next thing? What's the next thing? What's the next thing?”
After we raised a round from Andreesen, we opened a San Francisco office with the intention of building an executive team that would really run the business and take it to the next stage.
Once that VP team was built and things transitioned to the new product leader, we started to get more professional: “These are the initiatives, these are the themes, this is how it's going to tie together.” And we started to build out real processes — not just around how we built technology, but how we communicated and mapped the work that we're doing to what we hope to achieve.
That measurement helped us see the divergence between work and objectives and understand that we needed to make a change in the company.
Do you wish you had done that earlier, or do you think that you timed that at roughly the right time?
It's really hard to know. That period was extremely, extremely chaotic. In retrospect, I can speak to what I learned and be self-aware of how to use it in the future — but I don't actually know whether or not that was the right call. We did the things we said we were going to do. When we realized what wasn't working, we made a change. I think those are the right things to have happened. They may have and probably would have happened regardless of where we were … But it was a really crazy time.
Up to that time, I was outside of the company and out on the road evangelizing the company and what we were working on. I was doing a quarter million miles a year on Delta alone.
Can you point to like one thing in particular that you think has had the biggest impact in terms of the change in the company?
I can tell you, my quality of life is significantly better than it used to be.
What change made that possible?
I told people until X, Y and Z was fixed, I didn't want to travel. I stopped accepting conference invites. I started setting an allotment that I would travel and forcing myself to pick what it was. I started sending other people — and if they didn't want to go, we just wouldn't do it.
And one of the other things that we changed was we made a conscious decision to stop doing PR focused on the company where we were paying homage to ourselves.
We decided that if we were going to be an infrastructure company, we needed to find a way to focus first on our clients’ growth and success and focus our strategy on telling their stories. We don't need to be running a PR program to do that.
When we started looking more inward directly at helping our clients grow and really fortifying our infrastructure for them and stopped focusing on the narrative with the media, it's amazing how much noise just went away. It became more about the work itself; the work continued to get better, and more customers continued to come in. Customers became clients, clients became partners. The DNA really started to evolve, and it became less about the story and more about, “Hey, who launched? Did they have any errors? Holy smokes, this is really great. That's a new payment flow. They onboarded a bank. Hey, let's put this stuff together.” And no one was concerned about telling anybody about it, just doing super high-quality work.
That changed the company.
How did you go about instituting that across the company?
When we restructured, the company got small really quick. That part of it was painful for everybody involved. Those were hard days.
Sometimes we bite off really hard days for the actual benefit, right? So we've got to take our medicine. The business takes some medicine so that we can have the benefit of what's on the other side.
That means there are many roles that are not just not around. And by not filling them again or by changing the business' structure and by changing goals, you can quickly change the course of a business.
A lot of problems are functional. People, process and technology, change one, change all three. Sometimes you're the thing that needs to change — but you can always have an impact if you want to, I think.
Arti Arora Raman, founder and CEO of Titaniam:
"That's the beautiful thing about having people involved along the way is they feel like they own your roadmap as well"
You started with the thesis, "OK, I'm working towards this end goal, this bigger sale, but I've got these great internal sales, and I'm gonna build." So how do you incorporate them into your roadmap? Do you keep the same destination in mind?
It's basically a credibility journey. In our business, the same company uses the same product in many different places in the organization. Within a large financial institution, there will be 20 or 30 places where they could use my product.
So early on, I was very focused on the highest-value item without thinking too much about what bar I am going to have to meet to get them to deploy my product more widely. Now I can get an internal use case: You can try me out, I'll still be paid, and I can build up both my revenue as well as my credibility. Often you need a champion who's going to use your product — and this gives us a way to get that without creating too much risk for the organization.
I initially ignored that milestone along the way, but I'm super bought into it now.
Do you have some sort of way to present these roadmaps externally? How do you think about that information when someone says, "Hey, what's your roadmap?"
We don't put months of quarters on it. But we just say, “We're tackling this problem now. We need to tackle this other problem later.”
And the type of data we present depends on who we're talking to. The actual user of the system will be more interested in feature availability, and we keep it at that level.
But if we're talking to an executive, we talk about protecting sensitive data across the organization over the next five years.
And they have a hand in shaping it. That's the beautiful thing about having people involved along the way is they feel like they own your roadmap as well. So it's never, like, "Hey, you told me two months ago, you're going to do this, and here you are doing something else."
Throughout my career in consulting and security, the best relationships haven’t been us vs. them; you're going to discover things together.
So what's your strategy for your early users? Will you use a completely un-scalable but very hands-on of process and then rely on some word of mouth? Or will you start thinking more about marketing?
Ours is a product you can download, deploy and use, and we don’t have to be on site unless something's horribly broken. So we spend most of our time with customers understanding their requirements before we write the code. But once we deploy the product, we don't need to hold their hands too much.
Our goal is to have self-service trials — some sort of self-service conversion, where we can say, okay, this trial is free for let's say, 60 days, and after 60 days, we will automatically start invoicing or something like that. Where there was an expectation, there was some sort of terms and conditions, and we can go there. So that's our goal. But there is another element to our product where it isn't an online cloud service type of thing. They do download it, they do take it and we aren't as able to monitor it as you would a cloud service. So we're going have to balance that but there's nothing about our product that would require us to hold their hand.
Daniel Chait, CEO and Co-founder of Greenhouse:
"So what we did was, we would literally sit down and write the story that we were going to use to raise our next round"
How do you start to think about that first year? Do you build a roadmap? Are you trying to get an MVP done?
There's no such thing as raising one round of VC. If you decide to be on the VC path — which is a decision you shouldn't make lightly — the only question was what are you going to raise and how are you going to raise your next round? We just raised money, now we have two years and we die. What are we going to do?
And more than anything, that really governed our planning and prioritization from that point on. So what we did was, we would literally sit down and write the story that we were going to use to raise our next round. “Hey, I just raised my seed round. What's my Series A story?”
Are you bragging about how many customers you have? Are you talking about your deep R&D innovation? What are you going to hang your hat on? Back it out quarter by quarter from now till the next year: What are you going to do?
That was really helpful in focusing our energy in those early years. At that point it was really clear: I can show this much growth, or launch this feature or do these things, that's going into the deck. Everything else you do that isn't leading up to that is secondary.
Did you ever rewrite the deck, or did it stay fairly stable?
Writing an actual fundraising doc means polishing it for a given context. The crux was why we were going to raise our next round. What's it going to be driven off of? What kind of metrics do I really need? Is it 2x growth or 5x growth? Have we shown a shift into more of these types of customers than those types of customers? Did we launch this product?
What proves that we've done what we said we were going to do last round and justifies the money for the next round?
The worst time to find out that your fundraiser isn't going to work is after you tried and failed.
Did you start socializing that second-round thesis as soon as you closed the first round?
I would talk to other investors and say, "Look, I'm not raising money, but here's what I'm thinking. If I'm going to raise a Series B today, I know it'll be at $X million of ARR. I've got to be growing this much, I ought to see these numbers, what do you think?"
You get a little bit of a read on the market and then when you’re at that number or better, you can come back to them and say, "Hey, when we talked last year you said if we got to 18 this year that'd be a pretty good outcome. Well, we got to 20, what do you think? Is that good?"
And they'll go, "20? That's amazing."
By the time we were 50 or 70 people, I was explicitly talking about “the fundraising deck.” But those milestones were effectively the same things that we would tell the company at an all-hands: You show a deck and say how you’re progressing and identify goals for the year.
So it flowed through from this fundraising necessity down to monthly and quarterly sales and revenue and retention and growth and whatever milestones that the company all knew. Not that they were tied to a fundraising process explicitly, but that's what drove it.
How did you get some of your first customers right after you did your funding? Your early ones are super-heavy hand-holding: You’re looking to your network and really bootstrapping it. But then as you start to fold into your business model, how did that inflection point look for you?
We did this course at General Assembly, which bootstrapped a lot of word of mouth. And that word of mouth was better than we ever could have guessed.
At some point — I think after we raised a round — we were like, “Hey what if we even grew faster? How would we do that?”
Because at that point we were just taking calls. We would really just show them the product and send them the price. We weren't selling, we were just taking orders. At some point we sat down and were, like, “OK, what if we tried to get more customers?” And at that early part of your business, you literally don't know what's going to work.
And so we said we're going to hire a marketing person and we're going to hire an outbound, like you do inbound demand gen and we're going to hire a person to build an SDR team and do outbound. And probably one of them is a waste, we just don't know which one. So we're going to hire two people and see what happens.
It turned out that they both started working roughly equally well, and so we just kept adding money to each in more or less equal proportion. If you look today at our business, it's kind of still that. A third of our business is more or less inbound driven. They read our blog, they hear about us word of mouth, they do these other things in a directory or whatever and they come and say I want to demo on the website. And roughly a third of our business is outbound. We have SDRs who call and email and reach out to people and eventually they say, "Yeah, I'll take a demo."
And then a third of our business is hybrid: We track them on our website, and they engage in our community but they never click the demo button until our SDR calls them.
Marwan Forzley, Co-founder and CEO of Veem:
"And so I would say when you're starting that early, don't over-engineer anything. Be flexible. Take input, take a lot of it, adapt to being a child"
So, you've had this idea, you've built your MVP, you've got a couple of people working with you — co-founders or employees. And you finally get your first decent check through the door. What do you start to do at that point? How far in advance are you looking? How far in the future do you think about roadmaps? What do you think that first year after you've landed this capital?
I tell folks that startups are like people, they go through stages. You've got infants, toddlers, teenagers, adults, late adults, senior years, it's important to understand where you are at. In the infant year you shouldn't be doing stuff that really is for teenagers and vice versa.
And so I would say when you're starting that early, don't over-engineer anything. Be flexible. Take input, take a lot of it, adapt to being a child. That's all required to actually move from one station to another. As you move up into the later stages, then you're starting to see processes and the ruggedness and scale. And you'll find that now you'll have less flexibility, but now you're dealing with much larger numbers and customers, and it's a whole different cycle. So plan for the phase you're in, and evolve as you go from one phase to another. They're all different phases.
What's appropriate for one phase may not be appropriate for another, so you just have to change along the way. It's very appropriate in the early days to hack things and move quickly and just dump whatever code you have, because you just want to get customers and make sure it's working. But down the road, that becomes a problem, because then your whole code base becomes spaghetti.
How do you think about growth? Is there some inflection point you're looking for where you really start to grow? Do you try to keep it artificially lean? And do you have any rule of thumb to guide those choices?
The way I usually do it is, if it is working, do more of it. If it works again, do it again. And keep increasing the amount of money and intensity of it, until it is no longer yielding.
But you want to have rapid iterations, and as long as the customers are there and they're taking it and the feedback is positive, you increase the pace. If the customer feedback is so-so, I would slow down and make sure you address the customer pain point before you fail. That one is a little bit of art, a little bit of science.
I say to everyone who’s doing a startup, you don't have to solve everything at the same time. You can do it in phases. And everything ends up sorting itself out. Just be conscious of the stage you're in, be flexible, and also expect ups and downs. I mean, it's an adventure, so you've got to roll with the adventure.
Nimrod Lehavi, Co-founder and CEO of Simplex:
"Someone may fit right in what you need right now, but you're not sure they’re able to grow to the next phase — and that will f*** you up so badly in a few months"
You've got a couple of people in, and you've got a little bit of funding, and now you're starting to plan and think ahead for the first year, year-and-a-half. Do you sit down and build some KPIs? Do you build a roadmap? Do you build a vision deck? What are some of the first things that you're doing as you start to look and plan for the future?
At the beginning, we didn't plan any KPIs. But again, we had a very clear external target: Find an acquiring bank. For us, finding a bank account was a huge barrier, and a company that would process our transactions. It was crazy difficult, treading the thin line between crypto and fiat. Now it's less challenging, but it was virtually impossible then.
So because you're playing in finance, there were some hard requirements for you to get across the line. How did you even prioritize the work that you had to do? Or did you really just tackle problems as they came along?
Kind of, because there were so many do-or-die tasks that are logical AND gating your application. If you miss one, you're f***d, basically.
What happens when you think you've got a plan - you think you've got some bedrock underneath you - then you don't. Things just change suddenly, and you have to respond to it.
In the worst possible manner, and with the worst possible timing. It's insane, especially in fintech and working with banking infrastructure. If your bank suddenly decides to shut down your account, think what would happen if you had customers' funds running through it on a daily basis. That's what we do. We do processing, so money flows in, money flows out. No bank account? Gulp!
I know you had a small board, mostly of founders, but when someone said to you, "What's the plan for the year or the next three months?" or anything like that, would you just walk them through it on a whiteboard?
Again, we had a pretty much clear roadmap on the sense of constraints: what must happen, otherwise we can't grow, otherwise we can't sign that, otherwise we're not profiting per transaction.
I think it's more difficult when you have a standalone product, because then you have to explain why you are doing this instead of that. With us, it's pretty clear: This one's more profitable, so we're doing this one.
How did you get your first exchange to allow you on there?
The first company working with us was actually not an exchange. It was Genesis Mining. Again, it's a small industry, and I was already at many conferences in 2013. Before we even started the company, I started going to conferences, so I knew quite a lot of people.
And I spoke with them as if we were launching it tomorrow! In August 2013 in London, I spoke with a few people and told them we're going to launch it soon. We launched December 14. So I was promising way ahead.
How did you make the transition from the very, very early users and the difficulties there, into a much more scalable process? Did you keep a small group of early users until you nailed your process, and then you scaled it? Or did you just kind of fight through everything as you went and ironed it out along the way?
More of the second. I think that's the way to go. You understand, you get feedback. If you're able to fix it fast enough, then it's much more fast than trying to imagine the entire product in your head and then launching it, only to find out that nobody wants it. I'd rather do like early-phase Facebook: move fast and break things. I think it's smarter for startups.
Again, it's harder when you're a financial institution, because if you break things, you could end up in Guantanamo Bay.
How do you weigh that when you're thinking about dealing with someone's money? I mean, the negative feedback is going to be significantly more angry — but then also the opportunities to make a big mistake are larger, as well.
So on security, we never compromised on anything. That's the main thing, I think. Regulation, when you're doing things in small numbers, nobody gives a shit. Like I can do... again, not illegal things, but kind of a gray area, things in the tens of thousands of dollars, and nobody would care. If it's getting to the millions of dollars, I'm going to get arrested at JFK. We're never doing that.
We might do some tests. My favorite expression with our US attorneys at the time was, “OK, put this risk on the scale between Guantanamo Bay and a slap on the wrist. Like, we're closer to what?” And if it was a slap on the wrist, then we took the risk.
What’s ahead
Each post in the series comprises a short set of questions about a specific topic. Our participants will offer their own views and we encourage you to add your voice to the discussion.
Do you have your own questions for Digital Asset’s panel of entrepreneurs? Please write to us at community@daml.com.
Digital Asset can remove engineering roadblocks for entrepreneurs. Contact us to learn how to build and deploy software with Daml, an open-source toolchain for building applications, and DABL, a scalable cloud environment for launching SaaS applications with a serverless experience.
Daml has also a new learn section where you can begin to code online or try DABL here: