S3 E2: Dave Zohrob, Chartable
Code Story
0:00
0:00

Full episode transcript -

0:1

even though we're not what? Strapping on start up dudes anymore. We're like dad's. We just thought like, Hey, maybe there's another shot. Just start something together. We still ended up because we're engineers. We want building stuff, right? So you think it would be cool if we built this thing that once you compare these two data sets of Baba, we don't really know what we're doing. We built this like huge dashboard in just data from all these different places. Nobody really wanted it way kind of like overbuilt, right? But that again, like looking at it now,

like we actually do have customers paying us for that. So it's like in some ways, we're actually more right than we knew at the time. My name is Dave Zohra, but I'm the co founder and CEO of Chargeable.

0:47

This is code story a podcast. Bring you interviews with tech visionaries who share in the critical moments of what it takes to change and and build, and a team that has your back. I'm your host, Noel apart. And today how Dave Zohra charted a course to create a robust tool to measure Podcast analytics. All this and more on code story. Dave's Arab has been coating since. Before he can remember. He's among the crews where their dad's bought the TRS eighties, hooked up the TV and loaded games from tape drives. He loves music and even ran a small record label in San Francisco. But nowadays he focuses on his family with two little kids. While working an angel list, he and his co founder decided to start another thing together. The problem was, they didn't know what to build.

David been a podcast listener for a long time, but never really thought about what was under the hood. After considering a few different avenues, including yet another podcast app, they decided to focus on Podcast Analytics and some might say, the APP Annie for podcasting. This is the creation story of chargeable

2:17

Chargeable is a podcast Analytics ATTRIBUTION Service. We help podcast creators and publishers and networks understand and grow their shows, and we help advertisers figure out if the ads are buying on Podcasts are actually working. So we worked with indie publishers, folks with a single podcasts up to the biggest podcast networks in the world, you know, helping them market. Joe's helping them understand their audiences. And then we also work the other side the folks who are buying ads on those podcasts, helping them figure out which ones are working so that they can optimize their campaigns and get more results out of the money they're out getting towards podcasts. Way started the company. My co founder and I were working at ah started called Angel Lists for a while. I had been there for a number of years. I've hired him a couple of years in, and we really enjoyed working together. And even though we're not, what,

Strapping young startup dudes anymore, we're like Dad's. We just thought like, Hey, maybe there's another shot. Just start something together. We both started companies before we decided to quit our jobs on and live off her savings and try to build something. We had no particular thing in mind other than to work together and try to solve a problem that people pay us money for, which sounds pretty dumb. But it was the plan. I had a kind of natural deadline. We're gonna have another kid, and after my wife got pregnant is like well, you know, there's way either need to have a business here or I need to get a real job. And so we didn't building chargeable after trying a few different ideas.

You know, I've been a podcast listener for a long time. I had never really thought about it from attack or business perspective, just like was enjoying this, like purple app on my phone That gave me a bunch of free, awesome stuff that I didn't even really have to think about. Just push the button and listen. You know, I never really thought about what was happening under the hood. And when we were exploring different ideas, we thought, Well, what we like look into podcasts. The thing we ended up settling on was doing podcasts, analytics, following basically parallels from other media like I used to make maps on the APP store back in the early days of iPhone,

and it was a lot like podcasts are now basically get down with numbers like once a day from Apple, and that way it is. That's about the same is where a lot of podcasts there at far is like how you understand your audience, right? And so there are so many parallels between early app store and where pockets are now. Even the punches have been around wander. A lot of the infrastructure of the medium is fairly underdeveloped. Let's say so. We thought that there was opportunity to bring some of the data in the knowledge that have, you know, tools have been built for other media and bring it to this media. And that was how chargeable was born.

4:53

Tell me about the M V p for chargeable. How long did it take the bill? What sort of tools did you did you set out to use things like that?

5:2

Yes. So we actually had a few different podcasts. Ideas besides that, we did a podcast discovery thing called Tripod. We did a promo swap type app with ideas that podcasters swap promotion breast spots with other protesters. The brother shows help Pod swap, And I do with all of these was too build something super fast using technology we already knew. Get it out there as soon as possible and get in front of users. Right? So I've been using rails since forever. Now it's not cool. The cool kids know what rails anymore. It has its flaws, but I know it really, really well. I'm in like a deep relationship with rails for better force. We ventured like,

you know, a very kind of stable part of our relationship where I never else flaws. I'm not sure frozen is my flaws. Hopefully not eso. We just used the stuff we know and we put it out there as best we can. And the goal is not to build something super fancy. I think those days are behind me as an engineer. It is to get a kick out of using that the coolest NuTec for me. Now it's about about the business and again, maybe because of the pressure of a new child that I had over my head. But it was really about building something that people want not about building something that I thought was cool. Once we figured out that chargeable might be a thing, the idea was kind of app, Annie for podcasts at man. He does a lot of this kind of data aggregation for the APP store and for Google play store. We thought,

OK, how quickly can we get this out there? And so is actually almost two years ago to the day it was last Thursday, June 8th would have been our two year anniversary of our first commit. He's just started cranking and we're old guys. We write a lot of respect for stuff, even if we don't build it on. That's just a habit. I picked up Angel ists and wrote a spot for what could be the minimum viable product. You know, we've got that together pretty quickly, and within weeks we had it in front of like, podcasters. We posted it to read it, posted its various communities and we had sign ups right away. And the initial feedback was super great,

which never happens, right? This is not how it usually goes. Maybe it happened in this case because it was like, our fifth idea ever. Never that, like iterated enough to get something decent.

6:58

So in the short term, what you're building I mean, you're getting subtraction As soon as you build that, that sort of early prototype. In the short term, you probably had to make some decisions and tradeoffs. Either too do something quickly or to cut a feature or something like that. How did you go about that process? And how did you cope with

7:16

those decisions? Yeah, those those decisions have never fun like everything is a trade off, right? Like literally everything. Nothing's for free, Right says. Whether it's trading off my time or money or you know, the completeness of the product or something like that, we always err on the side of moving fast. That's all right. Our biggest thing, especially. I mean, it's less true now because we actually have, like a huge user base and a lot of customers, and reliability is more important.

But in the early days, it doesn't matter if it's reliable, because nobody's using it right. So we erred on the side of moving quickly and getting out in front of people as quickly as possible. That was, Those are guiding lights. Everything else fell by the wayside. A lot of stuff was incomplete. There a lot of buttons that lead nowhere. You know what I like broken pages. Stuff happens. You know, it's hard to have a product out there that is that is broken. That's embarrassing as an engineer, but as someone who is trying to build a business like that to me is, ah is an acceptable tradeoff. I'll have it be broken so that I can move faster and get more feedback from a customer more quickly.

8:17

So then, from that point, how did you progress the product? And how did you start to build a road map of OK, this is the next stuff that's important to our user base. Andi.

8:27

Things like that. We worked really hard to get an initial set of users as quickly as we could, and part of that was from the other experiments we had run. We had, like a small mailing list that we were using. And then things started spreading pretty quickly, organically on on their own, which was great. We do a mix of qualitative than quantitative feedback from customers, customer interviews, or do surveys to get the kind of feelings of what people want and ask people what they want. And then we also do heavy instrumentation on the product itself to see what people are clicking. What are people actually using? What's the thing that brings people back? If there's anything I've learned for building products, some Internet for a really long time, it's like people's expressed preferences are not always the same.

Is there like revealed preferences like what they do is not the same as what they say. So we have Teoh the art of it, the art of building a good product. This kind of trying to figure out where the truth or the potential truth lies in between those two things. So we went to after building a prototype and putting it out in front of people. There was the biggest podcast conference in the U. S. Told Podcast movement was like a little over a month after we started working on travel. Well, right, Okay, What's going happen to be in Philadelphia were based in New York. We hopped on the train, got a super cheap dirt cheap Airbnb and this, like, really sketchy part of town and just,

like, went to the one of the Tom friends and tried to get as many meetings as we could. And a lot of those folks we knew very little about podcasts at that point to be honestly other than being listeners. But we weren't so much from being that that conference and a lot of those folks ended up being customers or even employees since then on, and so it was really just about heavy customer interaction like people that are making these shows no way more. Even though we've had podcasts on, you know, I'm hoping to restart my podcast. You know, the folks that are living and breathing the challenges of creating thes shows every day, whether it's a one person show or, you know, huge radio network, Those are the folks who we serve, right? And so they're the ones who are right. And we just have to decide what what Weaken dio to serve them, you know,

10:28

how did you go about building your team? And and specifically, what did you look for in the people to indicate they were the winning horses to join Chargeable.

10:39

So my co founder and I are both engineers. We both work together, you know, at angels before, So we knew each others like they were both pretty good that we could work together. So our first hire was a non engineer, Scott Karl. Truck lost in here is that wondering which is big podcast network. We hired him because he is You know something more about podcasts, and we dio and, like knows people in the industry so that that first hire are not. Technical hires are a lot about either domain specific knowledge or just like a real passion for this medium. Because, like when we're working with our customers, I feel like that passion translates into better results. Like people can tell whether or not you care about the thing that you're selling, that your care about the thing you're building when it comes to engineers are,

too. We have two other engineers on the team on we're hiring for another engineer. We're much more concerned with kind of raw talents and ability to learn and ability. Teoh. Try things than we are with, Like a great resume. I've worked with votes to have gone so wonderful. Engineering schools and a lot of them were good. Some of them were not to me. I'm much more concerned somebody's ability to learn and to want to do better and to want to do that on their own so they don't need somebody micromanaging their code all the time. So that's self motivation. That intellectual ability is really what we look for, and that's true of managed yours as well.

12:2

You mention the first higher being a non tech higher from wondering where there any other sort of domain specific ones. You can mention that we're impactful early hires.

12:13

All of our non technical folks have some some domain specific knowledge. Our chief revenue officer, this guy Chris Calvi, really awesome duty, had worked with three Shmakov under. He's just like a real sales guru, you know, he just without being a sales guy, you know, like he's not like a sleaze sales guy. He's just a guy who knows how to like, talk to people and his really solutions or an said when it comes to customer problems. And he knows a lot about scaling teams he's built, you know, build cells, teams and run big organizations, bigger organizations that I'm running for sure,

chargeable still really small compared to the last company Christmas running. So that knowledge is super helpful. But ultimately we're still really small on when it comes down to it. Domain specific knowledge will help were think about hiring. Ah, you know, we have a job opening for a senior back, an engineer, and we're the jury's still out, whether we want somebody we deal with, like pretty heavy big data streams. At this point, we're tracking something like $750 million a month right now through our and what its infrastructure, which is a lot. It's like, you know,

hundreds over 100 million requests a day through our like analytics prefix. And that's, you know, pretty big and getting bigger all the time and trying to run these attribution queries against that. It's hard, and it's way outside of my area of expertise. And so the question is like, Do we hire somebody who really already knows that stuff? Or do we hire somebody who has some experience on to learn it? Or do we hire somebody who just take over other parts of our workload as engineers? And then we learn that kind of like heavy Europe, it data stuff ourselves, so we haven't honestly have decided probably depends on which folks be interviewing who comes in the door.

13:48

This episode Coat Story is sponsored by Trista Trista is a mobile app that lets you do business calling and texting from anywhere with dress that you can set up your business phone number, download the APP and start calling and texting Unlimited right away. Trust is the best business phone app on the market, whether you're a founder or freelancer, just starting your business or your already established, especially now as more teams work remote growing your network in your business is all about communication. You've got to be available no matter where you are. Trust offers the call management features that empower you to communicate smarter and more efficiently like auto attendants. Call recording user groups and more, and you don't need any special equipment. Just a smartphone you're already using trust. It is easy to configure, so you can set everything up yourself all online. It's just $15 per user per month with no contract. So start your free 30 day trial today at trusted dot com slash code story that's www dot trista dot com slash coat story. All one word. Did you build this in the beginning to scale efficiently?

Or was this something where you got it working? And then you got a bunch of users? You're like, OK, it's time to make it scale more efficiently,

15:6

so inefficiently built. I mean, still, there's so many, so many things. A lot of a lot of the last couple of months been about reliability and steal ability because, like a sweet talked about earlier were so focused on getting customer feedback. That would, of course, we cut corners from an engineering perspective, and so things were not designed to steal it all. One of our core data ingestion and points called analytics perfect that sits in people's RSS feeds. And when their podcast gets downloaded, our server gets a pain first, and so they were then able to use that Teoh count. The number don't have to help the measure their margin in spend, etcetera,

etcetera, and that we watched that in October of 2018 and we get more traffic now per day than we used to get a month, not that long ago. Even if we have thought about stealing in the beginning, I don't think we would have guessed that would have gotten this big that fast. So there's just always there's always a new bottleneck. Always need fires to put out so classic metaphor. Changing the wheels on the moving car, changing the tyres and women car we're doing that were also simultaneously building a new car, another side that we hope to move into it someday. It's gonna be great

16:10

jumping a little bit to a different topic, a step out on the balcony and look across all that you've built. What do you most proud

16:19

of? That's a really good question. I think I may be us that that we've built something that seems to be valuable. It's a lighter, pretty large swath of people in a really creative medium that I love, right, So there's like something like 50,000 users like not all of them are. He's in the thing on a daily basis, but like, you know, at least 10,000 of them are are logging in every month. And that's a lot that's like a big number of people for a pretty small industry. I'm really proud of that. I know we have a lot of work to do. There's so many confusing part of the product, a lot of things that's broken, you know,

so many things to improve. I look at it and see all the all the way from ways that could improve. But the idea that we've built something that that actually solves a problem for a large number of people that's hard to dio. Let's be honest, right? I built a lot of stuff that nobody cared about. So, uh, I'm happy that we are able to do something that matters here and also that it matters in industry that actually love. Ah, what I said I could love podcasters and and this community. And so the idea that we could be here to help, and so I build something valuable and keep keep, hopefully improving and make use of the better that that's really matters to me. And I'm really proud of that

17:29

on the other side of things. So tell me about a mistake you made and how you and your team responded to it.

17:38

We've made a lot of mistakes. Almost all the stuff that we've built we've designed so that, like it's fairly redundant. Even when things go wrong that we can recover that way, we don't lose data. There have been times where we have lost data, and that, to me, is just the most painful thing, right. It is just like, but there's been times where the thing that sits in front of people's downloads it goes down completely right and it's only happened twice, but when that happens, like there are literally thousands of podcasts that can't be downloaded right, And that's a huge, huge failure on our part, even if it's something that's outside of our control,

as it was the last time that happened. Like, you know, our cloud provider went down right, and we had a backup plan for when that was supposed to happen and the backup plan failed. Our backup plan did not work right, And so in those cases, out of people's instinct is to try toe, try to hide a little bit or to try to cover up the mistake or try to, like, minimize it. But we just really tried to be as transparent as possible with our customers because I think that is what builds trust over the long term. And so we just totally owned up to it and that we've also invested heavily and we, like, built a new backup plan, and we tested.

It writes like I can't guarantee that like it's gonna work that time because, like, you know, it's the Internet. Everything is like, basically thought taped together. Who knows what's gonna happen? But I like to think that we weren't from him. And as the company grows like I said in the beginning we were only interested in moving fast and didn't care at all about quality. That's not true anymore. You know, we have to balance speed with reliability because we have a lot of customers that rely on us, and so we don't want to let them down. And so I think that kind of dialing that in overtime is important. Figuring out when wind speed matters more, you know, is the most important consideration when reliability is most important consideration and always trying to be as transparent as possible. When we screw something up,

19:34

absolutely, it's better tone up and take accountability and say, We're going to fix it, then try to cover it up.

19:40

To me, it's the only way to go. I mean, somehow it doesn't always seem to be that way, you know, with every company. But it's the only way to go. What

19:50

does the future look like for chargeable for the product and for

19:53

your team? So we're growing the team for sure. We took a very conservative of reaction to the Corona virus pandemic. A lot of us are based in New York. It was felt really heavily here a lot of us got sick. The podcast advertising market, like all advertising markets, got hit. So we were pretty freaked out for a while. And we've managed to grow pretty well through the crisis. Yeah, I think that scene that we've been able to grow the business and other products through through this, like, really tough time to be doing business, especially in media. Then I'm Mike, fairly optimistic about the future here and by fairly I mean,

very It's just that I'm an engineer and I can't say that everything is gonna be great without sticking an asterisk on there. So we're growing the team we're hiring engineers were hiring focused on the sales on account management side. From a tech perspective, we have, like, a pretty mixed stack. There's still a lot of stuff on her. Okay, which is what we use when we launched. Believe in moving more stuff, Teoh Disturber list set up on AWS, and that has given us a lot more reliability and control over the scalability issues that we've talked about. But not everything is over there, you know, we also have, like,

data stored in various, you know, something pretty specialized data storage for the date of this floating in so we can run the attribution queries that we need to run. So there's a lot of re architecture to be done there while also continue. You know, we can't have any downtime, writes like everything has to be done live and and seamlessly. So that's gonna be a long project, right of like stealing us. You know, we already went up more than 10 accident last year. It's probably be another 10 X in the next year is gonna require huge set changes on the back end, since in serious beckoned architecture and engineering products state of processing,

21:38

Are you approaching that with the with the micro services mentality or everybody kind of opinion on micro services and how small and how big or it to do

21:47

them at all way? We do use them for us. I think we have work flows where it really makes sense, like when we're ingesting data from a particular data source. Whether that's like a dynamic ad insertion web hooked from ah add provider or, you know, the prefix that sits in there is RSS feed. Those air basically separate ingestion and points We don't want them probable each other at all, right? But they really are like But this is like a classic case for micro services. Totally makes sense. Like the customer facing product, it's just a huge rails model with That's fine, right? Like I don't need to deploy Crazy Micro Services there. You know, unless we have some reason to change that,

will we'll change it. But, you know, given we have a lot of different ways that data can be ingested. We want them to be from a reliability and Dan Point just to be a distinct. They have different requirements, different time requirements, different deployment requirements and, ah, you know, So this is perfect for a micro service.

22:43

So who influences the way that you work? Ah, CEO, CTO architect person, Any person really name a person you look up to

22:52

and why the biggest influences on the career one of them is my friends and former boss novel Rubicon is the founder of Angel ist. We've been friends for a long time. He invested in my first company back in 2007 just, like has a great way of being able to like think about the world in terms of systems and incentives and just just kind of zoomed out. Look at things he's always always looking at things from a different angle. I've internalized a lot of his approach to building products and thinking about markets and how to think strategically about what we're working on. Other folks my friend and former co founder Jim Young, who started this company hot or not, back in the day, which is my first start up job. This is like I worked there in 2005 back when we still had, like, a polo in like South San Jose. But I have to, like, manage, like,

manage physical machines ourselves, which is cool. Hey, we invented a lot of cool stuff at the time, and it gets no credit for which is, you know his way. But we did a lot of really, I think, innovative stuff around database chart and scaling and that hot, and that was a massively popular website of the time. Now there's a lot of out of the box stuff to, like handle that kind of traffic, but this is like PHP four. I think maybe if you'd be five and like my sequel. It really early version before N o D b. So I was like my isom like No,

no, transactional anything. What? We know what he wrote this, like database like charting stuff and, like read, write replicas, Olive I PHP and my sequel in Life. Super early days plus, like code deployment across like 100 plus servers. You know, all this stuff that people take for granted now being able to, I think three like one of the problems and then solve it your own way even, you know, I think that's awesome. And then I just like the obvious.

One would be like Paul Graham. You know, I didn't go through. I see Priest it by 1200 his last company in the early days. But you're thinking of stuff I still refer back to. You know, Paul Graham's essays, I think, are have been really influential for me.

25:2

If you could go back to the beginning of chargeable, what would you do differently, or where would you consider taking a different approach on

25:11

Overall, I think we did things okay. If anything, I think that being even more customer centric, what we still ended up because we're engineers. We went building stuff, right? And so we think it would be cool if we built this thing that once you compare these two data sets Imbaba way don't really know what we're doing. We built this, like, huge dash for in just data from all these different places. Nobody really wanted it. What we kind of like overbuilt, right? But then again, like looking at it now, if we actually do have customers paying us for that,

right? So it's like in some ways, we're actually more right than we knew at the time. Yeah. I mean, like, ultimately, I would have just like every time we get on the phone of the customer and watch them use the thing we learned so much, I would just do more that I should still be doing more. That that's like, it's the number one thing, you know?

25:58

So you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing. They're jazzed about it. They can't wait to show it off to you to the world. I think it's gonna be I think it's gonna make a huge impact having gone down this road multiple times. What would advice would you give that person?

26:16

For me? The biggest thing that's been hard to internalize this just how long? Building something that matters. Tapes like you know, we always hear about the flash in the pan and the instant millionaires or whatever. But everyone I know who's built something meaningful has spent, like, at least like 10 here suing it right, which is totally at odds with the speed of the Internet. Right on distill. My instinct is to move fast, move fast, move fast. But really, it's like you can move fast. But I also recognize that entire process is a decorated more right. So I'm two years into what will be at least 10 years at this company.

And I'm comfortable with that now. Now that I'm like in my, you know, nearing middle age or whatever, like, I'm cool with that right? But so that the young entrepreneurs probably think you're gonna launch this in two months later, you're going to get acquired by Facebook for $100 million. But like thinking about the ark of the project and how you maintain momentum throughout the art and the many highs and lows, emotional highs and lows, business size and lows, so many challenges, great things and terrible things that will happen along the way. That, to me, is like something I'm still working with every day is like Okay,

it's like we're three months into a pandemic. I'm working in my garage. How do I keep my team together? How do I keep growing the business and achieve our goals here? That's hard. That that initial spark, that passion, whatever. Like that we're off. Let's be honest, right? Like it was really cool. Idea ability, new stuff. It's It's so cool to build new stuff, right?

We're in a totally different phase now. To be clear, I'm totally enjoying. It's fantastic, but it's a very different feeling to be in that that kind of more mature stage of a company and solving a very different class of problems than like, how do we have this together and get it out there? I guess that's a really one wanted answer for my plane seat mate, but hopefully they would have sat through that

28:11

Well, they thank you for being on the show today. Thank you for being on code story and telling the creation story of chargeable.

28:18

All right, thanks so much. Appreciate it. Thanks for having me

28:22

in this concludes another chapter of code story code Story is hosted and produced by Noel Apart. Be sure to subscribe on Apple podcast Spotify or the podcasting app of your choice. Support the show on patri on dot com slash coat story for just 5 to 10 bucks a month. And when you get a chance, leave us a review. Both things help us out tremendously, and thanks again for listening.

powered by SmashNotes