In case you missed it, we raised a 1.4 million dollar seed round for our API management platform, Treblle, in July 2021. We started working on Treblle while we had our, now ex, software development company because it helped us solve many of the API problems we had to deal with on a daily basis.
When we developed our MVP we set out to get some "real-life" feedback from people that were not in our inner circle. So we applied for Web Summit 2020. If you join Web Summit as a startup you get exposure to early adopters, VCs and angel investors. And boy did we get exposure. Investors started reaching out left and right. Asking questions. Jumping on calls. Demanding a deck. Given we weren't looking for an investment we didn't have one π. I always kinda thought: "Well OK, I'm gonna show them the product and explain them my dreams" π Soon I realized that dreams are just dreams and we needed to make a deck.
I'm a huge fan of learning by example. That's one of the fundamental ideas behind Treblle - allowing people to learn how to use an API with concrete examples. In line with that the first thing I did before making a deck was I Googled "Startup deck examples". To my surprise I didn't actually find many real life decks. Most of the examples I saw were for pretend companies. Some of the ones I did see were all filled with perfect team photos, fancy 3D renders, buzz words, crazy numbers..It was a bit confusing and I thought we could do better.
So we sat down and made a deck that WE wanted to see. A deck, we thought, would help others understand the amazing things we were building.
Before you ask, yes, I'm totally going to share that deck with all of you. Slide by slide. With my high level notes for each of them π
But before we continue...some music. The first song that popped in my mind was from a local and really talented band called Dubioza Kolektiv. The song is quite funny, somewhat symbolic if you will, and it has a really creative video. Heads up: It is a bit on the edgy side π
Slide 1: Intro
This one is pretty easy, but the idea behind it is that it should be a slide that has your company/product name, some kind of a one liner about the product and, if you can, some interesting graphics.
Why? Well this is the first slide - duh! You just want to give your listeners and viewers an intro. A glimpse. A peek. Show them what they can expect. So keep it clean and simple. Aim for intrigue. Remember - you'll be on many calls with this slide open, sharing your screen, waiting for others to joinβ¦
Our one liner was "Stay in tune with your APIs". I think it sounds cool and mentions our market/topic. It's also a nice play on words. I remember I was sitting with Darko, my co-founder, on my balcony and we were coming up with ideas for the one liner. Given that treble is this high pitched sound, opposite of bass, I wanted the liner to be in that same tone and genre. We started with "Stay in sync with your APIs" but we eventually arrived at "Stay in tune with your APIs".
PRO TIP: Come up with a one liner! Just do it. Have a short version of it and have a longer version of it in case you have more time to explain it. If it can sound nice and smooth then great but above all it has to say what you do. The people who are reviewing decks do that for a living. All day. All night. Try to make their job easier. They'll like you more π
Slide 2: Who's who
This slide, in my mind, should be all about you and the team. Not the whole 20 person team, just the co-founders or the core team. Give an intro about yourself and the rest of them. Talk about your previous experiences - especially your work experience. The goal here is to establish your credibility and show the investor that he/she is talking to someone who know their s**t!
For us this wasn't a problem, Darko and I worked together for the past 10 years and Tea joined us mid way. So we all knew each other for a very long time and more importantly we worked together for a very long time. This showed that we can actually work together and overcome any differences or problems that were thrown our way.
Another plus for us was that we all were, what investors like to say, domain experts. I've been developing APIs for the past 10 years. Darko has designed countless websites and mobile apps over the same time period. Tea had multiple apps on the App store behind her. All around a pretty technical team with a lot of time spent boots on the ground, as the Americans say.
Slide 3: Past successes
I had a lot of doubts about this slide. On one hand I wanted to demonstrate to everyone some of the cool things we've built together. On the other hand we've always been a really tight knit team that worked on a couple of projects per year but we did them well. I wasn't sure if this would be a plus or a minus. I ended up highlighting some stats about the previous company we founded and worked in for the past 10 years.
Now I can understand that many of you might not have that kind of a history nor experience. If you don't, simply don't add this in. If you do have some experience I would highlight it. Even if you and your team members worked at other companies, just write that. Write what you did and why you think it was great! That way you're showing to someone who's probably hearing about you and your team what you're all about.
One thing that I'd definitely like to mention is that you shouldn't lie. VCs talk to hundreds of people a month. They've seen experts from all fields. They know exactly how those experts talk and behave. If you lie or pretend you don't stand a chance. If you don't know what you're claiming you know it's going to come out sooner or later.
NOTE: I removed the logos of the companies we worked with just so I don't get into NDA problems. But basically you have a couple of car companies, some beverage companies, clothing companies and some medical companies π
Slide 4: The topic
Here's where we introduce the topic of our conversation and the real reason why we're all here. If the topic is quite technical you can't expect everyone reading to understand everything you're talking about. Hence try to humanize it a bit and bring it closer to your average Joe. It will simply make your job easier going forward.
I tried to do that with this question "What do you use everyday but don't know it?". More importantly I provided an answer on the same screen π It simply makes the conversation about APIs seem more familiar - doesn't it? Yes, most people never saw an API request. Yes, they don't usually talk about them. Yes, they are a mystery to almost everyone who isn't working with them. But by giving everyone a hint you remove a layer of complexity usually reserved for more technical people.
Don't get me wrong, investors know their markets and topics but they might not know it from a technical side like you do, rather they know it more from a business perspective. One interesting thing I learned is that VCs can have a focus. Either as a company or within their company they have teams with specific focus. For example you might have VCs who only invest in SaaS and then inside their company they have a team who handles dev tools like Treblle or marketplaces like Etsy. I think this is great and that you should look for investors who know your market and have a focus on it. They will simply be able to help you more and the amount of knowledge they have about the market is more precious than the money they give you.
Slide 5: The problem
This is where you peak the interest of VCs. You need to clearly define the problem you're solving. Explain why there's a problem, how big of a problem is this, how many times does it happen and who has to deal with it.
In our case the problem was building and working with APIs. I've spent every day for the past 10 years working on APIs by myself or in teams. In every single combination you can imagine. I knew, personally and exactly, what happens from start to finish. So this slide, for me, was simply a list of my own frustrations. if I had those frustrations, well probably, many other developers did as well. And yes, I did ask many of my developer friends about their experiences and API frustrations.
But regardless of personal experience it's always a good idea to back things up with some real world, real life data. That's why I noted the fact that the number of developers will double in the next 10 years. If someone Googles that they will find that to be true which adds even more credibility to your deck. So build your credibility based on facts that you can back-up and can be easily checked. They of course have to be relevant to your market, product or the story you're telling.
I've mentioned lying before. So just in short. Don't.
Slide 6: The market
Now we get to the bread and butter of the deck. I haven't asked, but this is probably the slide VCs love the most - the market. This is quite an important slide so in my opinion you should use as many numbers as you can. Your goal is to show that the market is BIG and, even more important, that it's growing. At the end of the day VCs love super growing or trending markets. Just go check how many ML, AI or crypto startups get funded daily or monthly. Why? Because it's a popular market and it's growing.
In our case, our market is developer tools - specifically APIs. The good thing for us is that that market is growing and has been growing for the past 20 years. I'm not saying that you can't get funded if you have a small market or a fading one but it sure won't make your job easier. I spent a lot of time researching data for this slide. Yes, it's really hard to come up with numbers sometimes but try to be innovative here. Think outside the box. Connect the dots and make the numbers make a splash.
Slide 7: The solution
This is your chance to shine. This is the slide where you finally unveil your solution. A plan to fix the horrible problems that are happening in the market you just described. This is where you become the savior of your market and the visionary genius VCs are looking for. If you've done a good job hyping up to this slide the VCs should be jumping on their seats waiting for you to show it.
Make this slide count! Describe your solution and product in the simplest possible way. Highlight a few killer features. Explain what makes your product THE ONE. I'm not saying you should lie here but paint a beautiful picture if you have to.
For us this meant a few things. First, I wanted to highlight that this is an SDK for developers. Second, we made it super simple to use and we wanted everyone to understand that. Finally we focused on a few core features of Treblle like: real time API monitoring, error logging, automatically generated documentation, API analytics and a quality score of your API. It may seem like a lot of features but we had even more of them π
Slide 8: More product galore
In the last slide you gave everyone the basics of your product but here you want to dig a bit deeper and highlight some more things that are unique to your product. I wanted to add this slide because I think it adds more fuel to the fire in terms of features. It shows that we know what the product is and that it's a gift that doesn't stop giving.
We listed a lot of the features that would delight me as a developer. So things like device detection, location detection, endpoint grouping and similar. Of course there are more π but I've chosen some of the ones that I know others haven't done. It was also important to somehow illustrate that a lot of these features are focused on understanding, analytics and observability. We built Treblle so it can help everyone working with APIs and in every stage of the API lifecycle. A huge part of that lifecycle is actually understanding what's going on.
Slide 9: Demo time
For me personally this is the best slide. You get to show off your product. Now I understand not all of you have a fully working demo you can show off. That's fine. You don't have to give a live demo, you can use a video, something pre-recorded or even just a pretty graphic if you're still building it.
My advice would be to still show something. Anything. Just show it. It will prove to investors that you are working on it. That there is something to see and feel. If it's real and working then even better.
In our case we had a fully working platform that we used daily and I always gave the demo live. In my opinion that shows cojones because we all know how live demos can be tricky. Luckily I haven't had any major problems. Just a couple of smaller glitches which I hid like I was David Coperfield.
PRO TIP: Make sure you time this part perfectly. Don't spend more than 10-15mins on the demo because usually VCs will give you 30mins. If they like you, you'll get more but count on 30 mins from start to finish including intros, the deck, demo and questions.
Slide 10: Traction
Let me give you a PRO tip here before we even continue. You control this. You have full control over the data you want to highlight here. It's up to you. Why am I saying this? Well because I know how tricky and hard it is to show traction. I dreaded making this slide as all the numbers seemed low. But don't be afraid of it. You are getting started. It's OK if you don't have numbers that are in millions.
We had over 50 people using the product on projects world wide. This was our big advantage. So we highlighted all of those including the company logos. Remember logos are important. It doesn't matter if you have a logo from a company nobody ever heard about - if they are using the system - they should be here. Alongside the companies and people we really did process around 2M API calls that year. Which isn't a lot considering we are processing 8M per month nowadays but still it's a number in millions π
One last thing on this slide. Please don't lie. People will check. Multiple VCs have reached out to our clients from this slide and asked them about us, our product. If you burn down the bridge of trust there is no coming back from this.
So choose your numbers wisley.
Slide 11: Your insight
Try to explain why you figured it out. Why out of N other players only you can build this. What did YOU figure out that none else has!
Your insight can really be based on a multitude of things. It can be experience in the field, a moment of genius, a smart or cheaper way to do something...It really depends but in most cases if you're building something you probably figured something out. So tell everyone what that something is and how you came to the idea.
Again the goal is not to make things up but rather try to understand your advantage. For Treblle we knew that all other products focus on back-end developers only, manually doing things and covering only a smaller part of the entire API cycle. We knew that we wanted to do things differently. So we focused on allowing everyone on the team to understand APIs, automating as much as humanly possible and building a solution that works from start to the end of the API lifecycle.
Slide 12: You VS. Others
Funny story, we named our decks like this: "treblle-deck-v1.0.pdf", "treblle-deck-v1.1.pdf" and similar. This slide didn't exist in version 1.0,1.1 and 1.2 π I didn't even want to add this slide at all. For many reasons. One of them was that I don't think you can compare products that easily. It's not like we took a product like Postman or Rollbar or RapidAPI and listed their features and made a new product that did all those plus some.
But I learned that this should be in because it will show a couple of things: one, that you know who the players are and that you know why you're better or different. I think it's more about being different rather than better at everything. Again, some of the comparisons didn't make sense at all. Mainly because not all VCs know that Bugsnag tracks only code based errors and doesn't do auto generated docs. But they would still ask us about AWS API Gateway, RapidAPI, Bugsnag, Rollbar...you name it.
Hence we named every category and every product we were asked about before. Some made total sense, some made no sense and we missed some of them. But you should try to know ALL the players. If you're planning on competing in a space that it makes sense that you research and learn what others are doing.
You will be asked about all of them and you need to have answers to questions like "How are they doing", "How much did they raise", "What is their focus" and similar...
Slide 13: Business
This one is quite important. For investors, at least. But realistically it should be for you too. Here you get to talk about your business model and how will you execute that business model or more popularly called your go to market strategy. You need to indicate, and more importantly be able to explain, what is your business model, how much will you charge, how often, for what...You need to be comfortable with this and you really need to understand this because you will be asked about this. Repeatedly. And you will have to argue your case. Prove you're right. They will test you on this, poke holes and try to catch you off balance. So now you know and you have no excuses.
For us the business model was simple. We are a traditional SaaS company who charges by usage. For Treblle that means the number of API requests you get on your API. We think that's more than fair. We don't charge you for features, for seats, for users or any of that BS. I'm a strong believer in not limiting and butchering your own product if you don't have to. Hence we stayed true to that and our investors understand that.
The even more delicate part of this slide is going to be about the go to market strategy. So, what I wrote about the business model just double the intensity π I've had so many debates about this. Where are the users? How do we reach them? How do we sell to them? What do they use now? What do they think? How much are they worth?...Every single question you could imagine I've answered. You can't "learn" this slide. You have to understand this. You have to know better than anyone else and you have to be ready to defend your beliefs.
In our case we wanted to focus on the bottom up go to market strategy. That means that we start with developers and not CTOs, CEOs and the likes. Why bottom up? I strongly believe that we can help developers the most and from my own experience I know that once you help a developer out you have a fan for life. It's also, in my mind, one of the hardest strategies because it requires a lot of work. You have to gain the trust of developers. They have to believe in what you're doing and what you're building. That takes time. A lot of it. Finally, being a developer myself, I find myself most at home with that GTM.
Again both of these really depend on the type of product you're building and is something you should research, model, test and if need be, change or adapt. Yes, it's not a sin to pivot from your GTM or business model if you figure out something else works better. Just be prepared to justify that with quantitative data.
Slide 14: Pricing
This is one of those slides that I didn't add in the first version but we kept being asked about it. The reason why I didn't want to include this slide is simply because we didn't yet strongly define our pricing. I've always been up front about that with every VC. And even 6 months after we are still thinking, testing, adjusting...I think it's going to stay that way for a few more months until we figure it all out.
In any case, if you have some pricing options, include them and explain the logic behind it. For us we always knew that we'll never butcher our own product by using featured based pricing. This is where the developer in me wakes up and starts screaming: "Don't do ittttt"! So all our packages have all the features. Our free account really is free. It doesn't require a credit card and includes a plethora of requests per month. The only thing you pay for is the number of API requests we process. Anyone and their mom can understand that and, in my mind, it's more than fair.
Slide 15: The ask
I've learned they call this slide THE ASK. It's really interesting when you think about it...In any case this is where you get to write a big number. In millions. I don't think you should nor can be subtle about it. It will be a big number however you put it.
People always ask me how much do I ask for? How did you know? I didn't know and I don't know. This is very complicated to answer. It depends on a multitude of things including, but not limited to, the market, your location, your hiring plan, your needs, your willingness to give equity, your stage, world trends...What I can tell you is that you should ask for what you need and be ready to back that up by data. And i do mean like real, hardcore data. Math. Formulas. Projections. You will be asked about it. Not on the first meeting, not on the second but someone down the line will ask you about the details and it better match up. You are raising money for the next 12 - 24 months of runway. It's hard to plan things out for that long but try to do your best because at the end of the day it will help you.
We asked for 1.5 to 2M EUR because when we started doing the math and writing a plan of what we wanted to do, it made sense. We knew we needed to hire what we wanted to do in terms of marketing and growth. We made a master Excel sheet and added everything from salaries to events to software. Did we make mistakes? F**k yeah. Did we save on some things? Absolutely. As always in life we tried to achieve a balance.
I have to note: whatever you're thinking you'll be paying your developers just assume more. We assumed higher than what I would usually be comfortable paying and still missed by 30-40% in today's market π You can thank me for this tip by creating an account on Treblle π
Slide 16: Post funding plan
f you've done a good job crunching numbers and coming up with a plan for "the ask" then this should be easy. Simply make a rough outline, per quarter, of key events that you think will happen. So it can be key hires, product updates, features, sales...
Write them as bullet points aka shorter but be ready to do a deep dive into any specific quarter if need be. Again, many of these things are very hard to predict. Even impossible. But try to do it as best as you can. It also might not be a bad idea to have backups for some key events if things go wrong. Having a backup always shows a level of maturity because let's face it: things will go wrong.
Slide 17: Thank you
If I had to tell you one thing I learned over more than 10 years in business it would be to say thank you. Especially after pitching to someone who you've never met. Yes, it's their job, but think about it - they sat down and listened to you pour your heart out while asking for millions. The least you can say is thank you.
Besides that leave your contact details. No, not your mothers maiden name. An email and phone number will do. Finally, ask for questions. Better yet, beg for questions. Why? Well to show that you know things and didn't recite this deck for starters. Then to learn something new. New players, new market insights, how VCs think, where your product sucks, where it's great...If the VC likes you or your product there will be questions and comments. Don't be afraid of that.
Finally don't try to determine if and when a follow up will happen. That's not your decision to make. Trust me, they have all the details they need if they want to contact you. I always used to say that they should feel free to ping me with any questions, problems or suggestions they might have. But that's about it. Don't chase. Beg. Scheme. You can't trick someone into giving you millions by being obnoxious or irritating.
Go work on your product and forget this ever happened until someone tells you otherwise.
Pitching tips
I'm basing these tips on my personal experience of pitching over 50 times by now and all the observations I was able to make.
The number one tip you should know is that in most cases you'll get 30 minutes the first time you speak to any VC company. 99% of them will give you 30 minutes to pitch and/or talk. 1% will give you 15% minutes. You need to organize your time accordingly and you should allow 5 minutes of intro and 5-10 minutes of questions at the end. Some VCs will ask you questions along the way and some will wait for you to finish. If you get more than 30 minutes consider yourself lucky: you either have a very good product or the person on the other end likes you a lot.
Next up, be prepared to repeat yourself. A lot. I really do mean a lot. The first time you speak to someone from a VC company you most likely are speaking to an analyst. His job is to find awesome new founders and products. But this is just the beginning. After you speak to him for the first time you might meet again. Then if all checks out you'll probably meet his boss which is probably in the middle of the hierarchy. Both of them will have a couple of meetings with you and if that checks out you get to go in front of a partner. This was usually the case. Sometimes this might change depending on the fund size or your popularity. But in each of those meetings you will be presenting. Personally I hated constantly repeating myself so I would tweak things from time to time and make it interesting π
VCs have interests. At least the goods ones do. This means that if you have a product in the developer tools space you will talk to someone whose job is to find, talk and invest in developer tools. Same goes for any other market. Why is this important? Because they most likely know all the players, all the competitors, have talked to them personally, know all the products in the market and how much they raised. Again, why is this important? Because you need to either know the same as them or even more. If you are living and breathing your product you will either way but if you're an outsider who is stepping in for a shy founder get ready to rumble.
One thing a lot of founders forget is that VCs are people too. They would rather have an honest conversation with someone than listen to a fairytale for 30 minutes or watch you sweat bullets. I understand that raising is super stressful but try to go into a meeting relaxed and focused on what you are there to do. Work on your confidence. I don't really mean to sound like Gary Vee but being able to communicate is probably the number one thing I would recommend you learn. Especially for technical founders. I know it's tough but getting out of your comfort zone, talking about your product and dreams is not the scariest thing in the world. People go to war, have open heart surgeries and live to tell the story.
One final piece of advice: Don't write a script. Just don't do it. Don't learn things. Understand them. Yes have an outline, do a few practice runs but don't read off paper. It won't work. There are no shortcuts with this one.
PS. We're launching a Startup program at Treblle with a goal of helping our fellow founders grow both in terms of their API as well as funding π It will be invite only, but if you want early access join our Slack community and the be the first one in π
