Dani Grant - Why falling in love with your users and the problem you're solving is a differentiator!
18 Sept 2024 · 63 min
In this episode of The Undefeated Underdogs Podcast, Dani Grant, founder of Jam.dev, shares his journey from product manager at Cloudflare and analyst at Union Square Ventures to building a developer‑focused SaaS tool. He recounts the eight iterative product launches needed to achieve product‑market fit, emphasizing the importance of separating problem from solution, using The Mom Test for user interviews, and dog‑fooding before external release. Grant describes Jam.dev’s company‑wide daily demo ritual, the shift from noisy stand‑ups to concise demos, and the focus on a "slide"‑style onboarding that removes friction. He outlines three core lessons for founders: build exactly what users say they need, prioritize a small scope with high quality (no bugs), and create an intuitive, ladder‑free user experience. The conversation also covers product‑led growth (PLG) as distribution, community‑driven marketing, a podcast for knowledge sharing, hiring culture built on explicit values, fundraising as a series of great meetings, and the mental resilience required for long‑term founder commitment. Key metrics mentioned include ~125 K users, adoption by 30+ Fortune 100 companies, $3.5 M logged revenue, and a focus on retaining five core weekly active users before scaling.
Chapters
We were 2 product managers from Cloudflare. We were used to a mode where you launch something and the next day 10,000 people use
it. Whoa.
And when we were first building out our product and we just started this company, we're building the product, we're, we're doing tons of user interviews. They were so excited. We were so excited. And when we did our first Product Hunt launch, we thought, this is the beginning. We're so excited. But a week later, none of them are using
it.
I'm like,
that's weird.
Yeah, let's try again. So we try again, we make some changes to the product, we launch again, thousands of people sign up, and a week later no one is using it. And that's when we learned about product-market fit.
Stickiness of the product.
And it took us 8 tries to get to a product that sign up, they use, and they continue to use for years on end.
Welcome to the Undefeated Underdogs Podcast, where unpack and narrate stories of ambitious people who turn obstacles into opportunities. My goal for this podcast is to create a platform to narrate underdog stories and maybe play a small, teeny tiny role in inspiring you. I intend to highlight the underdog mentality and make authentic conversations with people who play the long game, take action with a chip on their shoulder, and convert obstacles into opportunities. Buckle up, as I'll be bringing some authentic founders, VCs, community builders, and content traders who got underestimated their whole lives, and yet they beat all the odds to become insanely successful. Now today I want to tell you a little bit about our awesome sponsor acquire.com. Selling a business is as tough as building a business. As someone who went through this process once, selling my own startup, I know the pain it takes to get to the end zone. This is where our sponsor shines. Imagine this: You're a founder who's built a solid SaaS product, acquired customers, and generating consistent monthly revenue. The problem is you're not growing for, for whatever reason— lack of focus, lack of skill, or just plain lack of interest— and you feel stuck. What should you do? The story I'd like to hear is you buckle down, somehow reignited the fire, get past yourself and the clichés, and start working on your business rather than just in the business. You start building an audience, move out of your comfort zone to do sales and marketing, and in 6 months you triple your revenue. The reality isn't as simple. Situations may be different for every founder facing this crossroads, but too many times the story ends up being one of inaction and stagnation until the become business The business becomes less valuable or worse, worthless. If you find yourself here or your story is likely headed down a similar road, I offer you a third option. Consider selling your business on acquire.com. Capitalizing on the value of your time is a smart move. Acquire.com is free to list and they've helped hundreds of founders already. Go to try.acquire.com/sharath and see for yourself if this is the right option for you. Now, let's get into today's episode. All right. So, dealing with bugs is ridiculously hard, but communicating them precisely to developers is even more challenging. I was there before as a PM at a Fortune 500 company. I used to struggle expressing what the bug is about, the details about it, and it's a mess. And my next guest is building a tool a product that actually is on a mission to avoid all that and make it one click. Danny Grant is the founder of Jam.dev. More than 125K users, trusted by 30+ Fortune 100 companies. Jam.dev helped log $3.5 million. That's right, you heard it right, $3.5 million, and they're still counting. And I say this I felt like it's the ultimate weapon you need to build a perfect product because it handles everything. It gets you console logs, it gets you additional details that you need as a developer to understand what the bug is about. Dani, welcome to the show. How are you feeling?
Um, thank you for such an intro. I feel so great because the meeting I just came from is my favorite one of the day. Every single day at Jamf, we do company-wide demos. So we all happen to Zoom together and for 15 minutes, um, never a minute more, uh, anyone who has something to demo demos. And so it's super rapid fire. People share what they're working on and it's like, it's just my favorite. It is my favorite meeting.
Is that like a, like a traditional jam dev or is it something that you do, you know, on the fly? What is it like?
This is my favorite. Jam company tradition. When the reason, so one of the things that we believe at Jam is you have to keep iterating on how you're building a startup. Like every few months the startup changes. And so if you're not reacting, like it's, by the way, is the notification noise from my end? Yeah. Oh, it is on my end. I had Intercom open. Okay. I've closed Intercom. So one of the, Last at the last. Okay,
you're too excited. I can say that.
I lost my train of thought. But but here's where this tradition comes from. We used to do a team stand up every single day, but at some point the company got so big that it was irrelevant for most people and really boring. And so actually most people started their day with the worst meeting of the day. It was just, like, not useful and, like, lowered their energy. And so, in our company-wide retro, when we were talking about what are the things we should start doing, stop doing, try new, one of the engineers on the team, Areg, said, hey, like, I think we should change how we're doing standup. And we all discussed as a team, and this idea came up, which is, let's just do the demos part of standup. So, people see what's cooking, The conversations can happen of like, what if it was like this? What if it was like this? And it's really momentum driving. And so for, we just do 15 minutes every single day. And then the next 15 minutes we do individual team standups. So it's useful enough.
Because they already saw what's been built or what's been worked on. And then it makes sense to contextually switching to, from that meeting to like individual. I'm curious, how do, I think developers, engineers, they have something to show every day. or even like, you know, half day, they always build, right? Or they fix stuff. What happens to teams, non-technical teams? What did they bring to the table when it comes to, you know, Demo Mondays or whatever you call it? What would they do?
So it's not Demo Mondays, it's demo every day. There's not a day where we don't do company-wide demos. So for example, today is a Monday, so I shared our Our metrics and dashboards. And we did, here's our update on revenue, usage, signups, and like all of the stats. And we do that every single week. And the reason why that's always one of the founders demos that every Monday is because we believe that companies closest to the truth win. And so, we never let more than a week go by where the whole company's together discussing our stats. I love that. It's one of the demos that we do.
I love that. That's a great tradition. I think more startups should do this because it's kind of show and tell. Then also, I want to add one point, what you said about standups are the worst meetings ever. Definitely. The reason is, one of the reasons I feel is it makes you ridiculously anxious because you only get 1 to 2 minutes and you have to sum up everything that you've been working on yesterday, before day, or the blockers. It's so anxious that I have to communicate that. And it's always on the round robin side or whatever the people use. And I don't know, like something makes me anxious about standups that I feel. And if I were to build a startup, which I will for sure, I think I will pick this tradition. No more standups. Say yes to demos, no to standups. I love that idea. Danny, let's go back to your Early days, you were an intern at Ogilvy, you did a bunch of internships, and then you were a PM at Cloudflare, and then you were an analyst at Union Square Ventures, and then you were the first-time founder at JamDev. Talk to me about the whole transition, or was it always your intention to become a founder from day one?
I used to think that starting a company seemed really lonely. And really difficult. And my favorite part of working, like, at Cloudflare, for example, was the team. I loved the team. I loved building things together. And so, for that reason, I thought, I'll never be a founder. Mm-hmm. But from Cloudflare, I went and joined a VC firm called Union Square Ventures. And it was the first time that I got to see founders up close. And that was so inspiring, like, seeing people who, they saw a problem in the world, And they didn't wait for anyone to solve it. They decided they're going to take it on themselves and do it. And they're going to work every single day for like 10+ years to make it happen. I was so inspired. And so, that changed, that flipped the framing for me. And my co-founder and I used to be product managers together at Cloudflare. We firsthand were trying to ship audacious new products in the world, move fast, try to accomplish a lot as a team. And we firsthand experienced all these back and forths that you have just to clarify issues were slowing us down and preventing us from what we thought was like reaching our full potential as a software team. And so we decided, let's not wait for this to be solved by other tooling. Let's build the tool that we think we needed and help just do that for other PMs out there.
That's how— is that how jam.dev, you know, was born? It's like literally from your own itch.
It's, we're now getting to build for our former selves and we lucked out. So, when we started, when we were like very, very early starting the company, one of the things that I didn't fully appreciate is how much it matters what you work on. Because oftentimes when we talk about like startup ideas, it's just like, what would be a good business? But now, 4 years into Jamf, it's so, we got so lucky that we picked something that we actually care about. Because the company becomes every conversation in your life for, like, 15 years or something, like, if you're lucky. Like, all day, every day, I talk to our users or our team about our company. When I go see my family, even, they ask me, how's the company doing? When I go to, like, a social event and I meet people, they're like, what are you building? Like, they have questions about it. I'm all day, every day talking about a thing that I absolutely love, which is helping software teams build better products faster. And so, it's amazing. But one of the things that— but it was total luck. And one of the things that I think that anyone starting a company should think about is, what will I love so much that I won't get tired talking about literally all the time for 15 years?
I have to tell you this, Dani. I've talked to many founders before. You seem to be so happy talking about Jam.dev or just like talking about startups. Again, all the founders have different ways of expressing. I think you're so joyous, if that is even a word. It feels like you want to be talking about what you're building all day, all night long. Is that true? Like, where did, where did this come from? Is that, is it, is it coming from pure passion of problem solving? What is your innate purpose or reason behind building a company, whether it is Jam.dev or anything?
That's so kind of you. I think, um, I, I love our users. Like, they are so inspiring and I get to talk to them all day, every day. Like, if you think, so every single person who uses Jam is someone who is trying to change the world through building software. Like, That is what they are trying to do, and that is the context in which they use our product. And I love talking to them about what they're building and what impact they're having. And the reason why they've sought out a tool like Jamf is because they want to change that part of the world faster. It's like we just have the best users, and we get to talk to them every day about what they're building and how we can help them. So, I think that if you start a company and you get to build for people who are such positive influences in your life, like there's this kind of virtuous cycle. But there's one more thing, which is like, love your users, but also love your team. The one thing you have control over as a founder, like everything is crazy, things will come and go, like the world is going to be crazy. But you get to pick the team. And that is the most important factor in your startup. And you're like building the Beatles, like, Each person has to be great on their own, but the dynamic together is the thing that just has to rock. And, um, and I am so lucky, uh, to— our, our team is, our team is amazing. Um, and so yeah, if you love your users, you love your team. I don't know, it's every day.
Oh my God, you're, you're, uh, the way you express is contagious. I feel like I have to talk to you more. on a regular basis. As a matter of fact, founders should talk to Dani more. I think you should open up like a hotline or something where you just open up and just talk about Jamf and everything else that you're doing. Just so contagious. I just want to point out that.
So contagious.
Let's go back to the early days. You were at Cloudflare. You were at— you found there is a problem. that's not unleashing your true potential. So the root for Jamf started there. Then you were at this venture company. Yeah. How did you end up saying that, yes, I have to build this? Because there is a transition period from being a PM to analyst to founder, right? It's not like days, it's weeks, not even weeks, like months and years. Why did you still have the problem back of your mind, or did you explore something new? No, you— I have to do this. This is bugging me so long. I have to go back and fix this. Is that how it happened? Or I want to understand the early days of you working on Jamf.
I'll give you the real messy story, which is coming from USV. I knew I wanted to start a company. I was so inspired by all these founders that I got to see for the last 2 years. It looked like such a fun building adventure, had to do it, but didn't know what the company should be. And when you're in venture, you're in the mind space of evaluating business ideas, but you don't evaluate whether you want to work on them for 10+ years. So, I was only in the mind space of evaluating business ideas. And my co-founder Urdafa is someone I loved working with at Cloudflare. And so the two of us put together a Notion of 140-something ideas, like businesses we thought like someone could start and it could be us. And we set up a time to talk about our Notion of ideas. And here's where we got so lucky. In that call, we never opened the Notion.
Wow.
What actually happened is Irdifa was still on the team at Cloudflare, and we're just talking about what he's up to and what they're launching, how it's going. And at the time, they were gearing up for a major product launch. So, Cloudflare has a product called 1.1.1.1. It's a safer, faster way to access the internet, and they were about to launch 1.1.1.1 for families. And so, they're gearing up for this launch. It's this major launch. And so, they're in the last-minute scramble, have to fix these bugs. And They— and Jira is a great tool. It's very heavy in like those little last-minute cycles. And so engineers were like updating spreadsheets and then they were like linking it to the Jira. And it was this like, it was just like massive communication. And we thought maybe actually, what if we just solved our own problem? And that is where we got so lucky.
Wow. Talk about luck and the timing, right?
Yeah.
So a couple, couple of follow-up questions. First thing, Do you still have access to that 140+ business ideas?
I'll send you a link.
Is that something that you discussed on Greg's podcast?
Yes. So that's why— that's— I, I— when I went on Greg's podcast, I pulled it up for the first time in 4 years.
That's so insane.
Yeah, I'll pull it up. It's just—
it's, um, anything that you felt like Uh, just a couple of— let's spend a couple of minutes on that. I'm sure, you know, people listen to you on Greg's podcast. Um, anything that you were like, if I didn't build Jamf, I would have done this, or I would have picked this in retrospect?
So here's, here's our notion of ideas. It's 139 actually, but, um, you'll see there's a lot of stuff that's sort of around Jamf, like Is there a better doc format for writing product specs? Like we were PMs, you know, developer sites, developer portfolio sites, show and tell what's in your laptop, component libraries. Like we were very much interested in the dev space, reviewing PRs. There's just like a lot of product builder stuff. I'll send you the link. So if someone's searching for a startup idea.
I also want to talk about How hard it was. You knew you were to build a company and you wanted to build with someone you know. I think you found a co-founder. You have this passion towards building stuff. The reason I'm asking this question is there are a lot many founders who struggle to get an idea Validate it and then build it, even though they have everything else like skill-wise. And that just hitting starting point is so hard to, you know, overcome. So what was your take on that? And do you have any suggestions founders should— where should they look to find an idea, business idea, when they're like starting on a venture and they have everything in their mind to like go after?
Yes. So, we talked about the founder-company fit matters because if all your dreams come true and the company goes to plan, this is like a decade to 20-year journey. And so, the biggest indicator whether or not you will get there is whether or not you will wake up every single day of those 20 years with the passion to come up with new fresh ideas and— and like change course and do the hard things. And so, that really matters, like your personal connection to what you're working on, I think. But beyond that, there was something that really helped us. There's a book called The Mom Test. Yes. Which is, which as soon as we read, changed how we did user interviews to validate what we're building. What The Mom Test says is, hey, when you do user interviews, most people don't wanna let you down. So, they kind of suss out what you're trying to get at and they sort of say things. that are truthful, but they're also trying to appease you. The Mom Test is a guide for user interviews that is so foolproof that you could do a user interview of your mom, the person who wants you to succeed the most, the person who just wants to make you happy in the moment, and still get actionable user insights. And so, this really helped us flip the script. So, when we first started doing user interviews, we did them wrong. And this led us to build a product that was not quite fit for what people actually needed. And the way we were doing user interviews, we were asking them about like collaboration with developers And like, you know, we were like asking them targeted questions about our problem space. But after reading The Mom Test, we did this. We started asking them, what are your top 5 priorities at work? In your performance review, what will you get graded on? And we made sure that all of our messaging and all of our product was around something that actually mattered to them day to day. And the reason for that is because people are very busy. Their lives are already complicated enough. And so, if something's not like a top 1, 2, 3, maybe 5 priority, they're not going to go search for a tool. They're not going to spend the time to learn a tool, and they're not going to like try it if someone recommends it to them. And so, that book was very, very helpful. So, if I were starting a company again today, the first thing I would do is I would download that book on audiobook, and I'd go for a walk, and I'd listen to it. It's like 4 hours or something.
Yeah. I think you're not the one who Praised about Mom's Test. I think pretty much everybody I talked to, they did wrong in the beginning, they read the book, it was like a 100% transformation. They were like completely new and they did something substantially well because they asked the right questions. So I have a curiosity on this Mom's Test, kind of like an expansion of Mom's Test, I would say, or The question is about when you talk to customers, potential customers, or you do user interviews, is it best to talk about the problem, not pitch the solution? What was your take on how to approach even the problem and limit yourself not talking about the solution? Because solution is so sexy. That's where it's like, okay, this is where we're solving. Yes. We are solving this in this way, in in using AI, etc., etc., or whatever it is, right? You're making, or even showcasing benefits. You might, you'll save time, you'll save money, etc., etc. So yeah, talk to me about problem versus solution.
Yes, we, um, so to give you the context of when we started the company, we were 2 product managers from Cloudflare. We were used to a mode where you launch something and the next day 10,000 people use it.
Wow.
Like that was— that was how we— And so, and when we were first building out our product and we just started this company, we're building the product, we're, we're doing tons of user interviews. We did like 40 user interviews in the first week or something. Like we were, all we were doing was talking to users. They were so excited. We were so excited. And so we were like, this is a home run. And when we did our first Product Hunt launch, we thought this is the beginning of Affinity. And so we launched on Product Hunt and so many people sign up. We're so excited. But a week later, none of them are using it.
We're
like,
that's weird. That's weird.
Yeah. Let's try again. So we try again. We make some changes to the product. We launch again. Thousands of people sign up and a week later no one is using it. And that's when we learned about product-market fit.
Stickiness of the product.
And it took us 8 tries to get to a product that would sign up, they use, and they continue to use for years on end. And, and so one of the actual things that really helped us stay the course as we were iterating for 18 months, like not seeing any progress really, was separating out problem and solution. Wow. So we knew the problem resonated. Because when we would launch something, people were willing to jump through hoops just to sign up. They would pay to sign up. They were learning a new tool. They were actually signing up, right? Like they were willing to—
Right.
Do something when we talked about the problem. So, we knew as long as we could get the product to then actually solve what we're talking about in the problem, they'll stick around. And so, actually separating out problem versus solution was really, really helpful for us. So if I were a founder, like starting today, I would separate out the startup idea into 2 problems. The first is I'd say like promise market fit. Are we making a promise that people want so much they're willing to sign up and then, and maybe, and pay? And then if that is the case, then what does the product have to look like to complete the promise? And the one thing that we did that was very helpful that I would do is for everyone who signs up but doesn't retain, You do your best to get in contact with them and you ask them, what did you expect the product to be when you signed up? And you build that.
And when you talk to these, uh, talk to these people, especially who you want to retain them from, uh, what was your pitch like? I'm curious because it's a hard sell. They, they, they bought the promise, but they didn't for some reason buy the product. That's why they are not using it. So How do you convince someone who saw and didn't buy it to come back again? Is there a technique or a strategy that you used? Is it like fast shipping, listen to them, fast shipping, and prove them, okay, we're listening to you and we're building something for you? Or I'm just curious, what's, what's your experience like there?
I think this is a really important question. I think it is a lost cause. Because humans, like, despite the flaws of this way of thinking, we really rely on our first impressions and they're very hard to break. And I'll give you an example. So, um, I, I think it's unlikely that you use Apple Maps. Yes. Because the first time you used Apple Maps, it wasn't as good as Google Maps. And even though it's been almost 15 years since, and they have staffed The best product managers, product designers, and engineers on that team, and I'm sure it is excellent at this point. Neither one of us has tried it again. And that's because first impressions really matter. You get one shot at a first impression. And that's actually a big mistake we made early on in the startup. When we started, we were like, you know, ship. The YC advice is launch often, launch frequently, go big. You won't know what people will do until they come into the product. And I actually wish that we had gone slower and we hadn't wasted so many first impressions on the thousands of people who signed up to an early version of our product that did not have product-market fit.
That's a very interesting way to look at things. If you were to go back, that's what I feel you would do, not to open up, you know, like the fire hose to everybody. Maybe you do like a waitlist type of a thing, you know. That's very interesting because I feel it's— it almost feels like a chicken and egg problem. If you don't show what you're building, you don't know what you're building, right? The direction you're going. But at the same time, you don't have to show messy, unfinished, unpolished product because you lose the first impression, right? Is there a way to solve this chicken and egg problem, at least in your experience, after trying 8 times? Not one time.
Yes. Um, you do need to get the product out there. You don't need to waste thousands of first impressions. So here's what we did for the 8th iteration, the one that worked. The first thing we did is instead of relying only on user feedback, which is what we had been doing up to date, we decided to trust our own guts and our own judgment. And so the first version of that flavor of Jam. We shipped only to ourselves in the company. And we said, this is not leaving the door until we would miss it when it's gone. And actually, we did not like that version. It was not good. It was really clunky and hard to use. But we felt the pain ourselves and we were brutally honest with ourselves. Sure. Which users, you have to chase them for feedback and then they don't want to hurt your feelings. They give you like half truths. We saw we saw the issues, and we like the iteration was like every day, every day, every day, and the product got so much better in those few weeks of us dogfooding before a single other person used it. The other thing that we did is we used to think like unless you bring in thousands of people, like hundreds of people, how will you know like who it resonates with, who it doesn't? But the truth is, if you show it to ten people who are the target audience and they don't tell other people about it, it's not good enough. And so for the 8th version of Jam, the one that took off and worked, we only— our first goal was 5 weekly active, happy retained users. And that was it. We onboarded 5 people. We found them in like subreddits and Slacks. And we said, we're looking for people who have this exact problem. And our hypothesis was if they have this problem, our product would solve it and they would retain, they would love it. Mm-hmm. And those people not only retained and loved it, they spread it in their teams and to their friends. And so that told us in just a very small dataset that we were onto something versus in the previous world, thousands of people could sign up, but it didn't make any difference.
I think dogfooding is probably one of the most underappreciated strategies because, and a lot many people, a lot many founders try to do it, but they are not doing it in an honest way. Like how you did it. If it's not ready, it's not ready. It's like being very self-aware about it, a product. And then I really appreciate what you said about keeping expectations in a tight way. 5 users who can, who will be retained and bring 5 more users. I think that seems possible, right? It's not impossible if you put 100% effort. into doing something that's such a small niche target. So I want to ask about— I'm sure I kind of know after 8 iterations you learned a lot and you've kind of implemented everything that you've been before. But any— if you want to like summarize into 5 biggest lessons out of launching 8 products, iterating, learning. What would they be for first-time founders? Because you're a first-time founder, you know, at this point I think you're like 8th-time founder because you launched 8 times.
Yeah,
yeah, that's a fun story too. But yeah, anything that you're like, these are the things that people, founders, should pay attention to, and there are like these things that forget about it, it's fine, that people give more attention towards.
Here are my top 3. The first is there's a lot of talk about don't list— don't build exactly what your users tell you. Like, how often I've heard that so many times. It's like your users are going to ask you for a faster horse and your job is to deliver them a car. Like, get to the root of what they want and go above and beyond. We delivered 7 cars that failed. And the 8th time we built exactly what users told us they want.
So you delivered a fast horse and it worked.
It turns out users know what they want. And so here, the formula for that was, so we had promised market fit. People were signing up to the landing page because we were giving them a promise they wanted. And then when they wouldn't retain, we would ask them, what did you expect versus what was the reality? And so they would tell us, I expected a product that looked like this. And when we got pattern matching, when we heard that enough, that 8th iteration, it was just that. Wow. We didn't try to get smart about what is it exactly? Why do they need it? Can we, like, do it better? We just built the thing that they kept saying that they expected it to be.
And that is Jamf.
So, don't build, like, don't outsmart your users. Build. Build what they need. That's one. The second is, we used to follow the, like, standard YC advice of ship fast, ship messy. You'll know you have PMF when people are willing to jump through hoops to use your product, they're willing to use a buggy product. Like we've all heard the saying, like, if you're not embarrassed by your product, you've shipped too late.
Blame him.
15 years ago when he said that, I'm sure that was true. But in the 2020s, software has eaten the world. We have mobile. We didn't then. Like, Facebook had like just released their mobile app. Like mobile was early. We live on mobile. We have remote work. If your software tools don't work 100% of the time, You are going to look bad in front of your friends or colleagues. You're not going to risk your social capital on software that may or may not work. You're not going to bring it into your job. You're not going to recommend it to people. And so, the bar, the quality bar for software is so high today. And so, one of the things that we did the 8th time is we said, small scope, high quality, no bugs ship out the door. And that was the difference between a product people would retain and a product people would not. And so that, that was the second. The third is a great user experience is like a slide, not a ladder. So in a ladder, it takes effort to get to every next step. In a slide, the next steps just happen. And you want a product experience that feels like that. One of the things that we did wrong early on is that our product was complicated in little ways. There would be icons on the page that someone wouldn't know what would happen when they click on it. So they'd have to think for a moment or hesitate for a moment, or they would get to a screen. It would be, it wouldn't be explicitly clear what to do next, like in an onboarding flow, they would sort of just land somewhere and say, think, what do I do? And these are moments where it's like, well, I have other stuff. I'm not gonna learn this tool. And so they would just drop. And instead, the product experience should feel like a slide where it's just taking you somewhere and you don't even have to think about it. And so right now in our product, we don't have any unlabeled buttons. Everything, there's no one-word labels. Everything is an action, like take a screenshot, record your desktop. And every single step of onboarding tells you what to do. Now create your first jam. There's no, like, there's no ambiguity. And that's because it's empathetic to the user. That is a great user experience. And I think as a startup, people are taking a chance on you and what you owe them in return is a great experience.
I love that because I think it goes back to the, Again, I don't know if it's a saying, you have to spoon-feed your users because they don't have time. You're like, literally you have to peel the banana and put it in their mouth, and sometimes you have to chew it for them. So all they have to do is digest, right? I like the way you're saying— in other words, I think what you said is when you talk to the users, you talk in human language. Your product should talk to your users in the same way. It's like it should really talk about— there is no hidden meaning or hidden, you know, buttons, labels. That is a great example. Take a screenshot. That's so no-brainer. That means you take a screenshot. It's like, it's like you don't have like a camera icon and assume the user will assume, oh, this is where I should take the screenshot. Make it so non-obvious. I really, really appreciate that. I think it should the product should talk to users just the way a founder should talk to a user. Like, no hidden secrets. Is that what you meant?
I agree with you 100%. And the way that we did this in practice is something that other founders can do. The first 5, 10, 25 even onboardings of the product, there was no self-serve onboarding. It was my co-founder Urdhva jumping on a call with the user and helping them get set up. And what he did in those calls is iterate on the script. He would iterate on the exact words and phrases he would use at every step until it was exciting for them because it explained the benefit of each step, but also clear for them what to do. And we recorded all those calls and over 25 onboarding calls, he got the script just exactly concise. And those became the words that are literally in our product today.
I love the, it's like you do things that don't scale. One of the tactics, right? You don't get to the end until you go through cycles of iteration. I absolutely love— I feel like you have so much to share. I think you should do— we should do another podcast just about product building. One thing, going back to your second lesson, software is eating the world where we live in a mobile-first world. I think if your product is not near perfect, is that what you're saying is people won't appreciate it? There's a high chance they just maybe use it and they won't stick to it. How much of it is on a surface level? Absolutely, yes. Because every smartphone is capable of running complex AI models right now at this point. Every smartphone's camera is Probably matching or even better than a DSLR camera. The software we're running should be perfect and it should deliver the promise you make. But on the other side, there is also like a set of people, I'm kind of part of it, where you have to ship fast and move fast and you break things so that you learn things. So I want to just dive a little deeper into that. It's not even a debate per se. Everything, everything has its own merits to it, and it's a thought process, right? Some founders think this way, some founders think that way. But I want to understand your take. Have you tried both? What is something that you settled on, or you advise? Like, I feel from my personal experience, you should meet certain expectations or else don't even launch.
In today's world, quality is everything. It's a hypercompetitive environment. There are unlimited alternatives. And because people's lives rely on software, things must work for them to use it, especially in SaaS. So, the quality bar is high. But as a startup, you have to do quick iteration cycles and learn. The mantra at Jamf became small scope, high quality. It's like, if we can make the scope really small, we can deliver quickly in a high-quality way. And I think that's really important. It's like, What is the core thing? One mistake we made in the journey for product-market fit is we fell into the one more feature trap. We had this idea that like, well, at some point, if we add enough features, this thing will be so useful, people use it every day. Or like, at some point, we'll add the feature, like, that's actually the killer feature. Let's just keep adding to this platform. But maintaining a platform with such a large surface area is very, very difficult because every time you add something, it may affect something else. Like, Your testing cycle is a lot broader. You're just, you're maintaining a lot of features. And so that was not a winning formula for us. For us, it was not about adding features. It was only when we started taking features away and saying, what's the one core feature that should be jammed, that we've started figuring things
out. That's kind of clever. The more scope you have, the more pressure you invite yourself. And, you know, you have to, I think you would be in a position where Again, it's, I think, going back to— I love your mindset, Danny, because it's always— I keep on hearing that you set an expectation and you meet it. I think you control the game by setting your own expectation for even for users and for yourself, right? I think that's another great way to approach problem solving. If you overpromise, underdeliver, that's when things go south. But if you say like, hey, I want to do this, and you you actually overdeliver, that's better. I feel that is something that people should— founders should remind themselves about. And you've— because of your working at Cloudflare and you went from, if I launch a feature or a thing, it's been used by, you know, 4-figure, 5-figure users, to right now, you know, as a first-time founder, how did that transition happen mentally as a founder? from a PM. And you've, you, it seems like you're a product-led founder more than anything else. That's what I keep on hearing. And that's what I think we saw Jam releasing so many products on Product Hunt, you know, launches happening. So how much of this product-led thinking helped Jam become where it is right now? Both of you.
So for a PLG company like Jam, product is everything. People say that first-time founders focus on product, second-time founders focus on distribution, but in PLG, your product is your distribution. If people don't use the product, they will not distribute it. And if they do use the product, they do distribute it just by the nature of it being a collaborative product that we're sharing is core to the experience. And I love this. Like, it is so incentive-aligned with your users. If you add value to their life, they help you grow as a company. And if you stop adding value to their life, they don't help you grow as a company. And so, what it forces us to do as a team is be as close to users as possible. And there are a lot of— at this point, we've set up a lot of systems to make sure that that's true. Like, every single week, our top power users from the week before hear from one of the Jam founders. Wow. We ask them how things are going, what they want to see next. Those answers get funneled into Like systems that we have in Coda to make sure that we're prioritizing the right things. The most interesting answers may get into a specific Slack channel called Users Say the Darndest Things.
Love that name.
Where we all discuss in the thread what they mean. And so, those conversations that we have over email become calls that we record, we clip up, and then we share in the team demos and we discuss as a team. And so, we're making sure we're always as close to the user as possible. And so that's the one thing from being a PM that is, that is like, so such a great mindset to bring into being a founder. One thing that's different is, is managing your own psychology. So when you're a PM, you work at a company that already has product market fit. If you work hard, you will achieve the things you want to achieve. And when you're a founder pre-product market fit, no amount of work
Hmm.
Like, it is not a linear progress. And so, you will be working very hard and there's nothing to show for it. And you can only do that for so much time before human nature kicks in and it gets really demoralizing. And this, for me, was a growing up moment. I was 26 when we started the company. I was very young and brash and felt like I could do anything. And being able to achieve was really tied to my self-worth. I was the type of person who took honors classes and That, like, that's how I saw myself in the world. And so it was a real growing up moment. And I actually, and I think that is the joy of building a startup, of being a co-founder of a startup, that it is not only the challenge of the strategy and the business and the product, but it is the challenge of growing up and taking on responsibility and handling that. And I'm really, really grateful for that.
Yeah, I think it's a life experience. That's why I feel, I don't know who said this, But someone said, I think Naval said this, everybody should build a startup because it not only teaches you about these tangible skills, which are very important, but it teaches about you more than anything else, right? Because you will learn about yourself more by doing things externally. I feel, I think sports is a great way to discover yourself, the hidden skills that you have. I literally I think it's Naval, if I'm not wrong, because I never sold a dime to anybody. I'm not a salesman. I'm more on the product side. I'm very passionate about building products, you know, building features. I was a product manager, you know, before. And because I built like a SaaS tool for myself, and I have to do it because you are— when you're a first-time founder, you have to do everything. Right? You have to do sales, design, product. You know, I'm not a coder, but everything else, right? So I discovered that I can sell because I had to sell for a product I'm building. So I think going back to what you said, it's a life experience. It ties to yourself. It is your— it's like your skin. It grows with you and you grow with it. Now I want to go back to Couple of things you mentioned in previous answers. One is about distribution is when a PLG company focuses on product distribution is blend to it, right? Have you learned anything new while building Jam about building a self-sustainable distribution system within the company, within the product? What I mean is that way it's like, oh, it's been discovered by itself. You don't have to do external marketing as such. Or external push. Is there— is that something that you discovered in your experience building Jamf for the last 4 years?
I think that this is a myth that people are highly incentivized to spread. So the story you hear all the time from founders is we never did marketing. But if you dig in deeper, you'll find that they did. In fact, they did marketing or had a channel of their own that they had grown over time. That allowed them to distribute their company and it didn't feel like marketing, but is essentially marketing. I think that it is an unhelpful narrative for startup founders. What you want to get to is you want to get to a flywheel that's working where one user brings in more users. And once you have that working, then you want to figure out how do we accelerate it. And for that, then you need external factors. So, For us, marketing looks like community events. We do a lot of developer events. We record our own podcast. We try to speak at conferences. I'm going to be speaking at SaaStr this year, like learning, sort of like sharing our learnings from the startup. Like we're in the business of helping builders. And so the things that we do that are marketing is like all about sharing what we're learning building Jamf. It doesn't, quote, look like marketing, but it is in fact marketing. And so I don't think it's a helpful narrative to say like, You know, it just, it should just spread itself. I think at some point you want to learn how to like pour gas on the fire or whatever. And I think that's actually a really helpful skill.
And you also have podcasts as well, which I love. I checked a couple of episodes where you dive deeper into how other founders build their products. It's a way to bring stories like how we both are talking right now on a deeper level. I love that. I think you have other co-founders join the call. I didn't check the names, but Talk to me about podcasting as a distribution channel that you recently started, right?
I'm so excited about this. So, the podcast is called Building Jam. It's on all the podcast platforms. And we alternate between 2 things. Either it's an internal team discussion, unfiltered, about what's happening that week at Jam. And if anything comes up where we're like not quite ready to share, we just bleep it. But it is unfiltered internal team conversation. Or, and then we alternate between that and bringing in someone who we're trying to learn from. And we do the advice conversation that like founders naturally, like, like there's so much startup knowledge sharing. We do the exact advice conversation that we would do. And we, we ask for advice for our biggest problems as a company. And then we just publish the episode. And so that the community can learn from us. And the inspiration is from, do you remember the podcast Startup? It's 10 years old. It's from 2014.
Startup, maybe. Uh, am I not, not, not getting into my head?
My all-time favorite podcast. So, um, a producer from NPR left NPR, started his own podcasting company and recorded, recorded the journey and published it on a podcast called Startup. And it's like his equity split conversations with his co-founder. He recorded like pitching to VCs and like what they were asking. It's raw and unfiltered, and it's my favorite podcast of all time. And it's so aligned with our ethos of like, we're building for builders. And so we decided to do our own flavor of it. So that's what Build With Builders is.
I'm sure, I think people love it. I checked your episode with Jason from Product Hunt. I loved the community-led growth strategies he discussed because I'm a believer in community-led growth as well. I will definitely link that to the podcast in the show notes. One other thing you mentioned quite a lot of times in this, in our discussion, is about founders thinking they should aim for 10+ years. I think Andrew Gastecki, he came on the podcast and he said this when he built Acquire. Before building Acquire, he asked himself, am I going to invest my next 10 years in this? If the answer is yes, just go for it regardless how long it'll take. So the longevity, the long-term thinking. I also heard recently from another founder that first-time founders should think about or ask themselves about, will I make it with this startup? And I think he says second-time founders should think about the longevity. It's like I have to go far. So yeah, talk to me about the longevity, long-term. play in your experience? You know, I think you are very intentional about it. That's what I'm hearing. So I want to— I want to— I'm curious about your thoughts on, uh, playing long, 10+ years, 20+ years playing the same game, uh, like NBA players, for example.
There's an amazing Paul Graham blog post called How Not to Die, and in it he says the number one cause of startup death is the founders give up. And, and he says there are all these reasons that people cite, like they couldn't raise money or like, you know, like there was a competitor or whatever. And he says if the founder doesn't want to give up, they don't. They do the dramatic thing, they pare down the team, they start from scratch and they go. But when the going gets tough, often founders give up and that's the actual cause of death. I think that when we talk about startups, oftentimes we're Over-indexing on the external forces at play and under-indexing on the founder's willingness to just keep pushing forward. I think the biggest risk to any startup is whether or not the founder wants to still do it. If you don't pick a startup that you are excited about, you know, on year 12, when the hard thing happens in year 12, I don't know that you make it to year 13. And so, the most risk— like, when you start a company, you are taking on People are trusting you with money, with time in their career, with time in their day. Like, your users are trusting you that you're going to be around, you're going to keep building for them. You are making promises to a lot of people, and I think the only gracious way to handle that is to pick something where realistically you will love it and you will give it your all for a very, very long time.
That's a, that's a great post. I just remembered what, when you said about how not to die. Paul Graham delivers bangers. You've briefly touched upon, uh, that's one other metric, right? Having low points. Am I still— am I going to wake up even at my lowest and still get going? Am I— do I have the energy? Talk to me about your lowest point in the last 4 years.
Every startup goes through hard times. The question is when, not if. For me personally, it was being a year in without product-market fit. We had I mean, we had this amazing team and they were making a bet that we could figure this out together. We had investors on board who I wanted to do right by, and I love our investors. And I had my internal pressure on myself as well. Moral obligation. Yeah, come on, let's do this. And being a year in and not having something to show for it is tough. And we all know that finding product-market fit takes a long time. So, Lenny has this great graph. It has like all the startups you've heard of on one side and then years on the other. And then there's like a time that they first felt PMF. And it's like all these companies that we admire and love, like Notion and Airtable and Slack, and they all took 3+ years to get to PMF. So, we know that it takes a long time. But when you wake up and it's like month 13, you're not there yet. It is— that is a psychological challenge. And so for me, that was the lowest
point. Did you find any way— of course you passed through it— any tips that you want to share, like how you overcome, or anybody who's going through the same thing, anything that helped really well for you? Like even mentally, physically, not just startup startups, but habits-wise, that really like, okay, this is what I have to do again. I highly suggest other people to do it as well, other founders.
I really admire Seth Godin. I like listen to everything he says and read everything he writes. I think he's just super smart. Seth Godin has this thing. He says, most startups fail. Your startup is probably going to fail. It might fail now. It might fail in 40 years, right? But at some point, companies fail. He says, assume it's going to fail. Now, what will have made it worth it despite that? And that helped me reframe. It was like, okay, we don't have product-market fit yet. I believe we can get there, but what if we don't? And for me, the what if we don't, what will have made it worth it was 2 things. It was getting the experience of working with this team. That will have been worth it no matter what. And so it was a good reminder for me, enjoy the moments. This is a special experience. And the second was, if in the process the team uplevels together and we all emerge knowing more, being better, being better at our craft than we were when we started, And that is still the case for me today. So no matter what happens 15 years from now, I think the experience of building with these other 17 people right now, and then as we add more, and also getting to see my teammates get better at what they do tangibly is so freaking special and awesome that no matter what, this has all been worth it.
That's awesome. And you've talked about your team So many times. You're the best.
We're so lucky.
Do you have, as a first-time founder, hiring is one of the hardest things, right, in startups. Do you have any, uh, I wouldn't call them as tips, but strategies that work for you to filter out great candidates and bring them on team? Again, sell promise to them, show them that we, we're, we're on, on the path to achieve something great here. Were there any recruitment ideas that you used? Because you seem very unconventional from what I've— in the last 1 hour, it's like very, very different. So I'm curious about how you hired these awesome people.
There were 2 things that we did that were really helpful that other founders can do as well. The first is, I remember we were like 6 people and I was so afraid to add a 7th because the 6 people, like, I loved that team so much, and I didn't want the culture to change. I was like, wait, it's perfect as is. And so, what my co-founder and I did is we jumped into a whiteboarding session, and we wrote down all of the traits and things that we loved about our current team. We loved that everyone was blame-free. We loved that people were kind and helpful. And if someone ever said, I need help with, or, I'm confused about blank, someone would just offer to help. We loved that people like cared about our user, and if a user was ever having trouble, they'd go above and beyond. Like, we wrote down all the things and then we came up with interview questions to screen for each one. And this was really great because then when we added the, you know, 6th, 7th, 8th, 9th, you know, whatever person, they also added to the culture that we really loved being a part of. The second piece of advice is something we learned the hard way is When you, everyone knows you should do reference checks, but every reference check is positive. Actually, something has had to have gone completely haywire for a reference check to actually be negative.
Okay.
And so all your reference checks are gonna be positive. So how do you suss out good from great? Well, imagine that I'm asking you about someone you know, like if they were good, like just fine, you're gonna be like, oh yeah, they're great. Like they did these things, you know, like you're gonna help them out. Yeah. Because you're a kind human being. If they are the top X percent of the people you've ever worked with, you are going to tell me, oh my God, I can't believe you've hired them. You are so lucky. I want to work with them again. They are amazing. Do whatever it takes to retain them. Like, there's just a qualitative difference in, in reference check when it's good and when it's wow good. And so the piece of advice and the thing we learned the hard way is listen for that second one.
That's very interesting. I think don't just ask basics, go deeper level, would you hire them back?
Ask the basics. You're gonna ask the same questions, but the difference in the enthusiasm of the answer will tell you so much. Good is not— good means bad, but excited for you to work with them is like, this person is going to be great.
That is a great filter. I, I never heard that before. That is a great filter. Wow. Danny, you've raised more than $12 million seed, Series A at this point. Curious about how you navigated to the path of venture. I think a bit of being an analyst helped, if I'm not wrong. Of course. But yeah, as a first-time founder, you know, I think you raised close to like $3.5 million seed and then close to $9 million in Series A. Yeah, talk to me about the fundraising process. Any tips there? Any experiences? Again, dos, don'ts that you want to share?
Absolutely. So coming from VC, I was really lucky to have seen hundreds of founders pitch and see like, what do the best ones do? When you are in sales, and especially when you are pitching, you are in the business of delivering a great meeting. Because what is the pitch meeting really? It's the VC is deciding whether or not they want to join your team for a decade, whether they want to be on this journey with you, whether they want to have this call again and again and again. And so the framework to think about is what would make this a great meeting for them? Of course, you're also evaluating, was this a good meeting for me? Do I want to have this conversation again and again and again for the next 10 years. Like, in some ways, VCs are like the most like permanent hires you will make. Like, they are with the company forever and you will work on the company with them for the lifetime of the company and, and till IPO. So, um, of course you're evaluating that, but thinking I am in the business of delivering great meetings is really, really helpful. So here's an example. Um, sometimes VCs will ask questions just to see if you've thought about something. Yeah. So, if they ask sort of like, how are you thinking about go-to-market? And you talk for 10 minutes, that's not a great meeting. You've totally disengaged them. But if you say like, I'm thinking about it a variety of ways, at a high level, I think the most likely looks like this, and I'm happy to dive into it. Now, it's a flowing conversation. Another is like, a lot of founders will screen share and present their pitch deck, but that's like webinar mode for the other person. It's like a signal that now they get to disengage and not really pay attention, right? Mm-hmm. Versus like keep it really engaging. And if you want to share something, say like, hey, I have like a 30-second screen share that will answer this question really well for you. Let me show you this one slide. Show the one slide and then go back to the conversation. But it's like all about a great meeting. Of course, your metrics matter, traction matters, all these things matter, but just the polish on top. Yeah.
It feels like you're suggesting to have a conversation. Don't— not a sales meeting. That is a great differentiating factor too. Once you have a— once you set your mind to like, okay, let me talk to these people, not sell anything, it lowers the pressure as well, you know, psychologically, and you just be yourself. That's awesome. Dan, it's been great. I can go on and on, but I want to respect your time as well. We have to definitely bring you again just to talk about The ins and outs of how you build Jam, as in more on the product side. I'm very curious about or learn more about that process. But it's been awesome chatting with you. It's been so fun. Like I said, your energy is kind of contagious. I can feel that. It's, you know, I don't know, there's something that's happening. The vibe is different. For sure. I've never had this vibe before on my podcast, at least. So appreciate you for taking time. Any closing thoughts before we wrap up?
This was so fun. It was so great to get to actually meet you. If anyone out there is building company and fundraising, our original pitch deck is still online. It's at deck.jam.dev. So if that's ever helpful to anyone listening.
That's awesome. We'll put that in the show notes. But folks, that's another great conversation for you and appreciate you for tuning in, giving us your time, and tagging along with us in this journey. Uh, more founders to come, so stay tuned. Cheers.
Thank you so much.
More from 5harath


Julian Weisser - Why ODF is on a mission of making things for people who make things!


Founders of Defang - Building the easiest way to develop, deploy and debug cloud apps in minutes!


Chrys Bader - A masterclass on the art of building viral consumer apps for the Internet!


Charlie Clark - How a solo founder took a side project from an idea to $300k+ ARR product!


Zachary Hamed - How using AI and design thinking made Clay the next generation rolodex!


Brendan Mahony - Why founders should look at building startups as a game and not a business!


Ryan Gilbert - How to master the art of building and scaling curation newsletters!


Chris Hladczuk - Tactical advice you need to know to build a fintech startup in stealth!


Derek - How to master the art of growing and monetizing newsletters from scratch!

