The SaaS Product Market Fit Toolkit with Dani Grant of Jam.dev

One of the first things you have to do as a founder that's very confusing is raise money. And like in a very concrete way, being on the other end really helps you do that. Like if you see it done a hundred times, when you go out to do it yourself, it's very much demystified. Welcome to SaaS Origin Stories.

Tune in to hear authentic conversations with founders as they share stories from the earlier days of their SaaS startups. We'll cover painful challenges, early wins, and actionable takeaways. You'll hear firsthand the do's and don'ts of building and growing a SaaS, as well as inspirational stories to fuel you on your own SaaS journey. Here is your host, Phil Alves.

Hi guys, today I have Dani Grant from Jamdev. Super excited to chat with her today. She's actually one of our listeners. And we're going to dive deeper into her company and how she got to product market fit. Welcome to the show, Dani. Excited to be here. So the first question I would like to ask you is, tell us a little bit about your backstory.

And how did you become a founder?

So my co-founder and I met when we were product managers at Cloudflare. And we were product managers on a really exciting and fast moving team. Our job was to launch brand new businesses for Cloudflare. And once we figured out if they worked and they were big enough, we would hand them over to the rest of the company to run for a long time.

And so our job was to move as fast as we could, launch things that were awesome, that worked right out of the gate. And the biggest bottleneck we saw to doing that was all of the back and forth and unproductive communication cycles about bugs and fixes. And so we needed a tool that would speed that up. And that is Jam. That's awesome. Cloudflare. It's the company that I like a lot.

I use their product. I follow their founder. And they definitely look like a good place for you to start and learn a lot and become better a product. It's an amazing company. And it was my first job out of college. I joined as their fourth product manager. There were about 100 people. I left at about a thousand. And it was the best first job I could have possibly hoped for.

And I see a lot of companies that start like that. You have a job and you're doing something, but you see a need in the marketplace. And you start to experiment that need firsthand. And then you're like, I want to solve this problem.

And that's pretty much how it went for you guys, right?

Exactly. And we weren't sure if this was a Cloudflare problem or if this was an industry-wide problem. So the first thing that Ertifa, my co-founder and I did, was we interviewed 40 other product managers across the industry, from startups to Fortune 100s. And we heard from everyone that everyone was seeing the same bottleneck in engineering that we were.

One of the things that's super unappreciated in product teams is how much time is taken up super ineffectively by engineers investigating unclear bugs, unclear tickets, having to follow up. Like instead of an engineer just receiving a bug ticket, being like, OK, I know it's wrong, fixing it, shipping the fix, and then moving on to the next, which would be a great case because then you get a bug-free product for your users.

Instead, engineers get a ticket, they don't have enough information, so they'll post a reply in the JIRA ticket, and they say, what user account were you signed in with?

What time did this happen?

And then they wait two weeks to see it again. And then when they revisit the ticket, they have to context switch back into it. Then they start to investigate. They realize they don't have enough information. It is probably one of the top one or two reasons why engineers are blocked.

Yeah, for sure.

And they're like, what computer were you using?

What browser were you using?

So I like what you said about interviewing 40 other product managers.

Did you do that?

Is it still working at Cloudflare?

Did you leave Cloudflare and then start to investigate deeper?

How was the process?

My co-founder was still at Cloudflare. I had actually moved on to be a VC at USB. So I was wrapping that up and had full time to do lots and lots of interviews, reach out to PMs, and he was still full time. So he was balancing, but I was fully on jam wanting to solve this problem. So you guys met over there. You guys identified the problem.

You moved to become a VC.

So for how long did you do that?

And how much of the experience as being a VC prepare you to later start your own company?

It was an incredible experience. So I was a VC at USB for two years. They have this great two-year analyst program. Every two years, applications come out. If anyone's listening, they should apply. It was the job of a lifetime. And it's interesting. One of the first things you have to do as a founder that's very confusing is raise money.

And in a very concrete way, being on the other end really helps you do that. If you see it done 100 times, when you go out to do it yourself, it's very much demystified. And it's like asking for a raise or something. You know you have to do it, but it's about money, which is not a topic that we talk about in society.

And it's awkward, and you don't know how people do it.

Are they supposed to be aggressive?

Are they supposed to be humble?

Are they supposed to be like, do they ask directly?

Do they go around it?

And just seeing it was truly, truly helpful.

And what are you supposed to do?

You post the questions.

But for the other founders that didn't have the experience that you had of being the VC side, what advice you give them when preparing to raise money?

So here's some of the advice I give all my friends who are going out to raise, to prepare them for how to do a great pitch. So just to level set, so as a VC, I worked on early stage deals. These are Seed and Series A. And we had Gem. We raised the Seed round. So this is specifically about seed deals.

And the other thing to say is that the market right now in venture is extremely tough. And so if you remember last year, there was that boat stuck in the canal. There was the little digger that was trying to get it out. This advice is like the little digger. It's just polish. And really, the market is just truly tough today.

So the first thing that I think is a really good framework to have when you're going out to raise is that you, the founder, the one who is pitching, you are in the business of delivering a great meeting. And understanding that helps you make all the other tiny decisions that go into how you are going to pitch, where you're going to pitch.

If you think it's a better meeting to be in person, you shouldn't be pitching on Zoom. If you think it's a better meeting not to show your pitch deck because you actually want your face to be front and center, you should not show a pitch deck. You should think about how do you want to start the meeting that is memorable, that's awesome.

Do you want to start and ask them where are they based, what's the weather like, or do you want to start by telling them about an awesome customer demo you just got out of that morning?

So that's all the preparation and how you can really make an amazing meeting, amazing experience for the VCs in the room.

And I like that, especially coming from a product myself too, like yourself, when I go to do something, I think, what's the job to be done?

What's the problem to try and solve?

And the job to be done in this case, you want as the founder, just help the VCs put together an amazing meeting.

That's why you're telling us, right?

Exactly that. And part of that is really tough to do in practice, which is sometimes VCs will ask you things just to see if you have thought about them or to see how you think about them. But you as the founder, you want to tell them everything. So you can show them how deeply you've thought about whatever it is that they are asking.

But actually, short and sweet and engaging is so much better than long answer. So one of the things I often advise other founders to do when they're pitching is when the VC asks a question to give a high level overview first and then offer to go more into detail. So basically letting the VC steer the conversation and giving them the meeting that they want. Amazing. That's great advice.

So I want to talk with you more about the timeline because it looks like you had the idea out of the way back at Cloud Fire, you met your founder, but you went and you were a VC for two years.

So how long until from the day you say, I'm going to do this, to the day you actually start going to raise money and go full time on the startup?

For us, it was right away. As soon as we realized that this was an issue that we not only faced ourselves at Cloud Slare needed tooling for, but the other at that point was probably 10, 20, product managers we talked to had. We just went out and decided, I decided I'm full time and my co-founder was now on a path to be full time as well.

The first thing we did was just keep interviewing.

In total, we interviewed somewhere between 40 to 50 product managers to make sure that this is a problem they all had. And at the same time, we were also raising money. It was at the very, very beginning of the early COVID work from home. And we were not sure what was going to happen to the VC market. So we felt in a time crunch.

Did you guys build a product at all before raising the money or you raised money first and then build the product later?

We built a very early prototype and we would start every pitch meeting by getting the investor in the product, jamming with us. And that made everything so much easier. We didn't have to sell like, here's what this possibly could look like. Here's why we think it will work. We just did it and people sort of got it. The original idea was we needed something like Google Docs comments for websites.

And every investor lives and breathes in Google Docs. And so they just sort of got it immediately.

How did you build that first version?

Walk me through the process of designing, prototyping, coding.

You come from product, is your founder a developer?

Walk me through the process of actually having that thing that you were taking show investors. I was really inspired by Dennis Crowley having a how to code in PhD book to build forceware. And so I bought how to write JavaScript web apps on Udemy and with my co-founder built the first version of Jam. One advice I would give. No way. It was awesome.

One advice I would give startup founders though, is once we had a prototype, we felt so much like, you know, fire in our guts to go and take it from prototype to production product. And we didn't really want to slow down and refactor or start from scratch.

Like, you know, as we were prototyping, we were building all these great features. We didn't want to have to redo it from scratch. This is advice I would give other founders is redo it from scratch after the prototype. There are decisions that I as a non-engineer made on day one of Jam, that our engineering team is still working on ripping out slowly but surely today.

And the reason is it's never a priority to refactor. It's always a priority to find a way to move forward. And so that beginning phase, like taking an extra few weeks, maybe even an extra month, like that way to anyway, I think that starting on a good foundation that allows you to move fast one or two years in the future is a good thing to do.

You always create tech that when you're building a product. I see that all the time. And a lot of founders say that. But also I would say don't be too hard on yourself because tech that's going to be there and you've got something to market. So you were not an engineer.

Was your co-founder engineer or none of you were an engineer and you built a version one?

Walk me through that. So Ertifa was. Ertifa was a developer turned product manager at Clubbler.

OK, so he had some background. And you were a product manager turned engineer. And that's how you guys built the first version of the product.

And what kind of traction did you guys had before you went to raise money?

Because I know that's also important for investors. So you had to have a little bit of traction before you went out to raise. When we went out to raise, it was still very much a prototype. There was no way to even sign up for a waitlist. We were super lucky that investors were willing to take chances on us.

Really, really grateful for that. I think that for founders going out to raise, when they're at that stage and they want to take a shot at raising money, I think that choosing the investors to pitch to based on who enjoys investing at that stage is important. Like there are different investors who have different focuses on stage. Some of them are pre-seed, pre-product.

Like they really want to be there on the ground floor and that's their investing strategy. Those are great investors to pitch on day one. Then there are investors that fund companies a bit later. And when you pitch them on day one, it can be very demoralizing because you're just not set up to succeed. They literally don't invest in that stage.

And so I think knowing which investors have that focus and choosing those to talk to first is really important. That's a great insight because it's like the most investors, I would say, or the stories that I hear, they want to see the traction. They want to see like a first for customers. But there is those investors, you that come from the field saying they are willing to invest early on.

So you were able to raise money without having any customer at all, just like your background. You guys were excited. You understood the problem very well. But you didn't have any customers at all when you made your first raise.

Is that correct?

Week one of this or week one and a half. So there was no waitlist. There was just a prototype. There was a bunch of research and it was the two of us. Congrats.

And how much did you raise like the first round?

At the time, we raised I think about a million and then we raised a little bit more later. So in total, three and a half. That's impressive. So you raise a million dollars with an idea. And of course, you guys come from Cloudflare. You have an amazing experience. You were a VC before. And you know, two investors, they are investing in you, not so much in the idea.

But that's still very impressive that you were able to raise that much money with so early on. Congrats. Thanks. And we feel really grateful. It's an amazing opportunity. So now walk me through taking the product to the first few customers and trying to actually take something to market.

How was the process?

We had such an incredible journey when I look back.

Well, we came from a big company and at a big company, you already have distribution. So you launch something and then there are literally millions of people who get the email. They are set up very well to go and try it. But when you're a startup, you have to prove yourself early on. And so there's this journey of finding product market fit that's very interesting and challenging. And it was so awesome.

And we learned so much. The problem itself, we always knew we needed to solve. The problem has not changed. And actually, the proof was in the pudding because it's Jam. And whenever we would talk about Jam in public, every PM, every designer was like, I need that. I have that problem. And people were signing up in thousands. But the product itself was not perfectly fitted.

So we kept iterating and iterating and iterating for 18 months until we found exactly the form factor to solve this problem that works. So walk me through how you would you figure out they didn't have product market fit yet. You're looking at things like Mixpanel. People are coming. They were leaving. And how did you know, OK, that didn't work yet. Let's try something different.

Could you tell me a little bit of the experience, the experiments that you've done until you found product market fit?

The experiments were always about how do we solve this problem for teams?

How do we speed up their communication cycle, make it super easy for them to crunch through a bunch of fixes and to ship awesome stuff fast?

We tried a JavaScript snippet on the page. We tried different versions of a Web app. Ultimately, the thing that works is our extension today. It is awesome. When you see a bug, you just click on it. It captures the last 30 seconds of what happened. Playback like a video for the developer.

Plus everything the developer gets in DevTools, console logs, network requests, all the specs of your device and your operating system and your browser, and it packages it into one link or one ticket. So the developer just has everything that they need. It saves them 80 percent of debugging time and then they can move on to the next task, which is awesome.

One of the things that we learned about how to approach this, trying to find product market fit, related to your question is two things. The first is, like you said, we treated everything like an experiment. We wanted the whole team to have the expectation that we are going to try many, many things.

And so it's actually good to treat everything like an experiment, have a hypothesis, try to look clearly and see clearly what is happening and to constantly be discussing what worked, what didn't, why, what do we think, what should we test next. Just having everyone sort of gathered around that was very important.

And the second is, you know, there's this advice that you get as an early stage startup, which is to ship fast, ship messy. Users will use a broken product if they have the problem strong enough. And this is old advice that hasn't actually aged to 2022 very well.

And the reason is, since software has eaten the world in the last 10 years, A, there are so many alternatives, like even a worse alternative, there is something someone can stitch together to solve the problem.

And two, in a SaaS environment, people rely on software to do their daily tasks at work. It just must work. And if it doesn't work, they're just not going to use it because they rely on it.

It's not, you know, old Facebook, I'll check back if it works later.

It's like, oh, my, you know, Airtable dashboard doesn't load or whatever. So one of the things we learned was actually the startup advice doesn't apply in today's world. We actually had to ship awesome stuff out of the gate all the time. Thank you. Thank you for bringing that up. I tell that to people all the time. But like everything they read online, it's about that. It's about move fast and break things.

That's what Facebook told you years ago. But in the B2B space, that doesn't work, especially like if you have and you are building, like you say, you don't have a distribution, but now you build a distribution. You have some followers, some people that trust you. So you put a product in front of them that's broken. And I feel like that does more damage than it does good for you.

And also another thing that building software now is so much easier than it was 10 years ago. It's a lot easier, it's a lot faster to build good stuff, even if companies like your company that you're building, making it easy for developers to understand what the problem was, replicating the bug with having to go do everything by themselves, click the play, see what happened. And I think that's what people have to understand.

Build software, it got easier. And the customer expects a lot more. The customer of today is not the customer of 10 years ago. And so what work for Mark Zuckerberg is not going to work for us, the founders of 2022. And thank you for saying that. And I think more people has to come out and say things like that. I think that's 100% right.

On that route, like all the advisors say that you have to move fast and you have to find product market fit as short as you can. And you guys took, you told me 18 months. How that worked for you and your team, how you guys kept your level ahead, like how you went back and talked to your investors, because 18 months sounds like a lot of time.

So how was the process?

The last thing I'll say on quality and product market fit is one of the reasons why having a great quality product in the early days is so helpful for finding product market fit is because the reason why it's so challenging to find product market fit is because you're in the search for clarity. Like it's a discovery process. It's sort of nonlinear.

And so you need to like have as many signals as possible that are good signals for you. And if your signals are muddled, it's extremely difficult to know what decisions to be making as a team, like where to focus next. So if users are leaving, you don't actually know if they're leaving because it didn't work or because it's not what they need. The two things look very, very similar.

And so just one of the great services you can do for your team is try to ship as bug free as possible in those early days to give yourself that extra bound of clarity. Let's dive deeper into that.

What are some of those signals and how you track those?

We spent a lot of time early on talking about how would we know if we got there?

Like obviously product market fit is the goal.

So how are we going to measure and make sure we're getting there?

But the best advice we actually got from Mike Adams, he's the co-founder and CEO of Grain, a tool I really love. And he told us, you know, there was a time at Grain where all they could think about was product market fit, like everything, live and breathe product market fit.

Then there was a time at Grain where they no longer thought about product market fit and probably somewhere in the middle, they reached product market fit. And we actually found the exact same thing to be true at Jam. There was a time when the whole team, everything we talked about was product market fit. And in today's world, we've sort of moved on to the next set of challenges.

And so somewhere in the middle, product market fit no longer was our main focus, main goal, main challenge. It's not quite measurable, I think, in that way.

So you don't think like something like churn or like were you tracking an RFI star and you're seeing people using your product more than before?

Or like wasn't anything down there that you look, okay, it looks like you're going the right direction right now.

Yes, indicators along the way.

Yes, we tracked retention and retention only. We cared so much about testing our hypothesis. And our hypothesis was for an initial customer that has all of these different factors about them, like type of team they work on, role they have, size of team, you know, whatever it is, that they would use this product weekly and stick with it.

And so we had an early spreadsheet that my co-founder made that had every one of our alpha users as a row. We had vetted them that they fit that initial customer profile because we wanted to test the hypothesis, which was not would anyone use this weekly, but would a specific type of role person team use this weekly.

And every single week we put in the next column of the spreadsheet how many jams they created with Jam that week. And we were looking for streaks. So we were making sure that there was not drop off. Like if you missed one week because you were out sick, like cool, but we wanted to make sure that you weren't missing two, three, four weeks.

And so it was when that spreadsheet looked all green, it was just green rows across that we were like, okay, something here is really working that we need to double down on. That's a great way to do. So you guys are tracking retention.

When you realized that someone dropped, what did you do about it?

So here's the interesting thing about chasing down user information, which is it is extremely difficult. So we would, you know, whatever means of communication we have with them, we often set up like a Slack connect channel, or maybe it'd be over email or text. We would ask them for their feedback, advice, let them know that like we haven't seen them in a bit is something going on.

But it's very, very, for whatever reason, I don't know if you've had the same experience building SaaS startups, but for whatever reason, it's very difficult to chase down bad news. And one of the experiments that we ran is we created an anonymous type form, which was like, I don't remember what the URL was, but it may have been something like bad news.jam.dev.

And we said like, I know it's tough to tell us to our face, we have an anonymous type form, we won't know it's you, we check at the end of every month, so it's fast. And so we had a place where people could just like give us their unfiltered, you know, advice for the company. That's awesome. That's a great idea.

And how did that work out?

We got more people replying to that than normally when you just are as lacking them and ask them what happened. It's interesting, actually, just having the link and letting them know that we want real unfiltered feedback made people more comfortable to just tell us to our face, which is great, because then we could have a conversation, ask them questions.

I think that for early startups, maybe all companies in general, companies that are more close to the truth win. Like the game is to have clarity so that you can make great decisions along the way. And so you want to set up an environment where people can really tell you what feels true to them.

And I think another lesson here is that people are generally nice, and they're just not going to tell you stuff unless you give that opening, unless you like do something about it, because people don't want to hurt your feelings. But by not hurting your feelings, they're not helping you progress.

Yes, yes, exactly that.

Okay, so what is the first old shit moment that comes to mind from the early days of your SaaS?

You can share a good old shit moment or a bad old shit moment. There are these little moments along the way when people who have come in as users and are using your product, believe in you and what you are doing. And you start to see it working and the changes made for their teams. And it feels so good that that's the whole reason to start a company.

Like I remember there are early moments where a user would tell us that their engineering team saw they're really hard to reproduce because they caught it with jams. They had all of the information about what happens.

Finally, they made this thing better in their product. And it feels so good. I feel like I'm buzzing. There were moments like that early on that felt that just were like, this is the reason we do this.

Yeah, and been there in that situation myself, I understand because sometimes someone's going to report a bug and you're just trying to reproduce the bug and you can't. And you're like, I don't know how that isn't real. And just having a tool that does that, it's super amazing.

So how does your team look like?

Tell me about your team.

It's you, your co-founder.

How big are you guys right now?

Tell me about your team. I love our team. Our team is awesome. We're a six person team. It's the two of us and four engineers. And it is a group of positive, optimistic, like can do, work hard, race fast, and humorous in that sort of goofy way. It is an awesome team.

Awesome, awesome team. We are so lucky.

And are you guys out racing to some place?

Are you guys all together?

How does that work?

We're all remote. And that has been such an interesting part of building Jam that I didn't expect upfront, given that we started it right at the beginning of remote. With remote, there is no playbook yet. Like we are all writing the playbook together. And with startups, what matters most is that you move fast together in a cohesive way. And if you're all moving fast, but it's not cohesive, things don't work.

Or if you're moving really cohesively, but it's slow, that doesn't work either. And the thing that's hard about remote is both being cohesive and being fast, because there are gaps in time zone and location. And so maybe unlike startups that were all in one room where they get some of the benefit just by default, we work a lot as a team about how we work together at Jam.

One of the things that we see, coming from product management to being a founder, the bias is always like, oh, we're building a product here. But actually, it's much more than that. We're building a company. And one of the things that a company is, it's a machine that knows how to execute fast together and do that really, really well over and over and over again.

I can tell you about some of the things that we do differently to make sure that we work really fast together.

Yeah, tell me about it. I'd love to learn more about that. So one of the things that you need to move fast is you need an arbitrary date that you set, and you need a forcing function to do everything in your power to get there. And so as a remote team, the first thing we do, a developer makes a plan. They figure out how are they going to build this.

They figure out what the timeline is going to be. And then they set it on the calendar. And they send everyone on the team a Google calendar invite to the date. So everyone knows this is the date. Then as we move up to the date, we're trying to have sort of an abundant amount of communication about how we're doing towards this date. It's really common.

Developers will give sort of a red, yellow, green update. Green is like 100% on track, no risk. Yellow is like, I think we're on track. And red is, I can tell you with certainty we are not on track. And you can't be like yellowish red. You have to pick one.

And we do that every day because it helps us as a team realize where we can jump in to help each other to make a date or realize where we need to prioritize. This has been really helpful for helping us move fast and ship quickly.

And you guys do that asynchronous or you do everyone at the same time?

How you do that?

Because like you say, there's different time zones. I'm not a huge fan of meetings and like getting, you know, having like blocks of time where you're just sitting there. But we do have one team meeting every day, which is standup. And often when people need to sync with each other, it will happen sort of on the bookends of standup.

And that way people have sort of a productive rest of the day to block out like, you know, flow time. So a lot of it is asynchronous, but a lot of it will just happen, you know, at standup or right before right after. It makes sense. And I think you're so right.

Remote, it's not as easy. And that's why we see a lot of the big tech right now bringing everyone back to the office. It's just because they fail to learn how to work remotely.

That's just the reality, right?

Like, okay, this is not working.

And, but you as a startup, you just don't have that luxury of not figuring it out. You have to figure it out. And I think that's going to become a advantage because really we, bigger companies move slower and they have a hard time figuring out stuff like that.

And it's just easier to go back to the norm instead of like just trying to figure out, okay, how can you run a remote team?

How can we be more efficient?

And you have a team of six people.

How many customers you guys support with that team of six people?

10,000. And our next goal, or there will be milestones along the way, but we want to get to a million.

10,000 people with a small team of six people.

Why do you think you guys are able to do that?

You know, when, before being a founder, I would hear other founders talk and they would say like, the thing I'm proudest of is the team. And I would always think that's so cheesy.

Why does everyone say that?

But you know, being on the other side, it is the thing that is the most true. The company is just people. It is just made of people. Everything we do, every minute of the company is just defined by the people who are in it and the people who are doing things. I think our team is just rocks. I feel really lucky to work with everyone.

And are you like optimizing to stay small, but be able to have a lot of customers and have a big impact?

Or are you trying to eventually get bigger size of like your team?

How you see that moving forward?

I believe that small teams are mighty. I believe that small teams can do many things that big teams can't do. I think that when something is important and you want it to go fast and well, you want fewer people on it, not more. I think that building a startup, it's like building the Beatles. Like every single person has to rock and you have to rock together.

And that's, you can't add 50 people to the Beatles in one year, but you can add, you know, you can do that slowly. My dream is to build a company like Instagram, be 13 people and be worth a billion dollars. I told that to our investors the other day and they all laughed, but I'm dead serious. I love small teams and I think we can do a lot with one.

Yeah, me too. I just learned last week that Craiglist had a 50 people team and they're like making more than a billion dollars in revenue every year.

And again, like the same way that you mentioned that the advice that we had in the past about let's go to market quick and people don't care about quality product. I also believe the advice that we haven't seen the last few years of keeping adding headcount, like people go to do a series A and they add a bunch of people to the team. It's not the best way to do it.

You should be adding like those headcount.

Really, like you say, you can't add 50 people to the Beatles team all at once. And I believe the companies that's going to win, especially as we come to the markets getting harder and as you see layoffs, it's going to be the companies that figure out how to do more with less. And they just have that team that really understand how to work well together.

That's where I believe the strongest company is going to be for for the next few years. And especially for B2B SaaS products. I feel like that's another thing. That's the space that I live in. It's B2B SaaS products. So you can take something from B2B SaaS and maybe try to apply someone else and say, that doesn't work.

But for B2B SaaS, I think that's going to be the way to go.

So could you share like a very smart decision that you have made in the early days of your company?

I think hiring is one of the hardest decisions you have to make. And it's really, really important. I think choosing a co-founder is one of the biggest decisions you'll make. You do it on day one and I couldn't have gotten luckier. My co-founder, Ertifa, is amazing. And one of the things that makes him outstanding, especially in startups, is he is can do as a spirit.

When in a startup, our roles as co-founders change every few months. And he inspires me in the way that he will figure out, okay, here's the new role I have to take on. Here are the 10 people I can talk to about who do this role well, who I'm going to learn from these conversations. And then I'm going to figure out how to do it myself.

He has done that so many times and it is really awesome to watch. And his enthusiasm for that is quite inspiring. I think choosing a co-founder, it's the first decision you make and I feel really lucky.

Yeah, for sure.

And do you have any advice for people making the decision?

You say luck, but if you try to think about how do you feel like you could help people think about that?

What they should look for in a co-founder?

Of course, at the end of the day, there's always going to be the luck.

But what can you do to increase your odds of success when you're making that decision in your opinion?

I think that the tried and true way to find a great co-founder is to have worked with a person. And that's because people are different at work, under a time crunch, under responsibility than they are in their social lives or family lives or any of those things. I think trying to work with people first is great.

I also think that talking to friends who are starting companies, a lot of people put a lot of pressure on themselves to find a co-founder early on. And I think that having a co-founder is awesome, but choosing the wrong co-founder is so risky and it will derail so much. It's a divorce in the middle of your startup that it's actually better to go slow and steady.

And you can bring in a co-founder late in the game. Even a year in, you can bring someone in, give them co-founder ownership, responsibilities, roles, but rushing it doesn't make any sense in my opinion.

Yeah, I think you're totally right. Work together, don't rush it. You don't need a co-founder from day one. That's great advice.

And again, you go back to what you read in the internet and people think that they need from day one. If it just happened that you have that person that you worked together before, that's great.

If not, it's something that you can figure out along the way.

And how about a decision that you made that wasn't optimal?

Yes, I'm thinking of a few.

The first is, I really think that once founders build prototypes, I've mentioned this before, when you're like, this is sort of right, this is the right form factor, that's a good moment to be like, how do we want to build this to enable the team to move faster later?

When you're pivoting around, you can just sort of duct tape stuff together because you're testing. But because quality matters so much to actually be able to test a hypothesis, you do want a solid foundation to build on. I think that was one. In hindsight, I would have changed.

Second is, our first iterations of Jam, we're really following that startup advice of ship fast, just get it out the door, see who uses it. It can be buggy. You'll know your product market fit when people use a buggy product. Like I said, I think that this advice just doesn't apply in 2022.

And in our latest iteration of Jam, the one that really stuck and works, one of the things we changed is we decided it would be quality from day one.

But the second thing that we changed, and I think that this was a huge lesson, I wish we had done that for every iteration, is instead of ship as fast as we can and see who uses it and how they use it and learn from the wild, we decided for this one, we would not ship unless we as a team could not live without it.

So we shipped an early version that we were the only customer of first. And because we are the customer, those iteration cycles are so fast. It is so clear to us what's working, what's not, how to improve it, what to try next. And so we made it a lot better really quickly first. And then only once we thought, yeah, I would miss this if this was gone, we brought in an alpha.

And I think that not doing that early is a mistake that we learn later, you should do. And if there's any founder thinking, how do I ship my first product, it's an advice that I would recommend 100%.

Yeah, for sure.

But I think that so as you go the route, we also have to be careful to not overdo, right?

You have to understand prioritization. It's about quality, but it's not about including everything in the version that you're going to ship. So you're trying to say you don't need to ship a buggy product, but you also don't need to develop it for five years because you want to add 500 features on this before you actually let an alpha in.

And I think that's also, I see mistakes done both ways, right?

Go too early and it's broken and you lose the trust of your customers. But there's also something about, oh, there's just this one more thing I can add. There's one more thing I can add. And each new thing that you add, it's one thing they have to make sure that doesn't break the other things that you built before. And that's also why we have to be careful. That is incredibly true.

It makes it very, very hard to be flexible and move fast and pivot around the more you add. One of the things that we've gotten better and better and better at, as we were sort of iterating around on the problem statement, is to define what's really critical and not do anything else. The mantra we repeated is small scope, high quality. Small scope, high quality. I love that.

And have you built something that you realize, okay, this doesn't make sense. Let's just remove from the product altogether.

Have you gone through the experience?

Yes. So we really cared about solving this problem and how we solved it didn't matter. We just knew we wanted to solve it. And so in those 18 months, iterating around, trying different ways to solve this problem for different teams, we had many moments where we added features, cut features.

If we organize it like this, does it work now?

If we remove these three things, does it work now?

We had many moments like that. Yeah. And that's, I think it's another skill that we founders have to develop because sometimes we build something and you get attached to the thing that we built. And you have to remove because, no, if I just add this other thing and they start using this other thing, but again, these are more things they have to maintain.

And then the one thing maybe it's not adding as much value to your final user. So you have to get into that mentality of I will add, if it doesn't work, I will cut off. And it is another thing that's hard for people to do that I see when I'm working with founders. A hundred percent.

So if you could go back in time and meet yourself from the day you start the company, what you to tell yourself?

What would like, what would you tell yourself?

So, you know, in most things you work on up until starting a company, it's very linear progress. So you can work harder to move faster towards progress. And so like, you know, when you're in high school and you're studying for the SATs, like basically the more you study, the better you will do. Or if you have a job, the harder you work, the more you will output.

And so I was very much of the mentality and I still am. I really enjoy hard work, but I was very much of the mentality of we can work as hard as possible to get to product market fit, grow the startup as fast as possible. But in the early days, especially things are nonlinear.

So you can work hard to ship the next version, but like it's a discovery process and you're sort of learning and you have to be open-minded and curious and, and sort of inquisitive and sort of creative and slow and have this like abundant mindset, which is sort of in direct opposite to, you know, moving really fast, sort of being really tired because you've worked, because you've worked, you know, 14 hour days, five days in a row.

And so I think that the advice that I realized over time and would have, you know, loved to have on day one is part of startup is that it's a mental sport. It is both strategy and it is endurance.

And so the way to approach it is maybe like how a competitive chess player might approach their career, which you have to think about what is the mindset I need to be in to make great decisions along the way and to adapt your lifestyle for that.

Like, it took me a while to realize like, oh, I need to sleep well every day with my decisions because I was just in a mindset of work as hard as we can because we will go faster than everyone else. And I think, I think you have to go fast.

I think also having some focus on like how to be in the right mindset to make great decisions is something I would have benefited from on day one.

Yeah, for sure. I love what you say. It's very hard to brute force this stuff. And if you work a lot, a lot of hours, your decision making skills, they just reduce. And at the end of the day, it's about making decisions. That's what being a startup founder is. And so sometimes you need more sleep. And you also have to trust our mind to process the information.

That's what I learned personally, right?

So if I'm working a little bit less hours, if I'm sleeping, or if I'm going on a hike, if I'm going to spend some time on a hobby, my mind is still working. My mind never stops working. And it's solving that problem that I can solve. And that's what I think something that I learned along the years, sometimes you're just working more and more.

You're not letting, giving yourself enough time to solve the problem. You're not trusting your subconscious to do the work, to do the processing. It's kind of like, again, I think in software development, I send something to the queue, the queue is going to process, and I have to wait. And I have to allow the queue to do the processing of the information that I'm trying to work with. Yes.

One of the ways that I sort of brute force this a bit is sometimes when I'm stuck on a problem, like how to do blank. I want to give my mind sort of an environment where it can sort of be thinking about the problem, but in a background process without it being the main thing it's thinking about.

And so what I'll do is I'll put on a podcast like yours, and where it's talking to another SaaS business or another founder in an adjacent space. And I'll just go on a long walk and listen to the podcast and just listen to the founder talk about their business.

But that sort of sparks new connections in my brain such that it unlocks new ways of thinking about whatever I was trying to solve. I find that often works. Yeah. That's a great advice of how to do that. And I think that's why we have to think about it. Sometimes we need the background processing to happen. And what's the strategy I'm going to use to allow that to work.

So how is the business doing today?

And how does the future look like?

Yes. Oh my God. I'm so excited. We just finished seven record weeks in a row. This might be our eighth. We're at 10,000 installs. I do want to get to a million. And it's growing really fast and on its own. We're just seven months into beta and super excited to launch soon and go, go, go. Go. That's awesome.

And what book do you recommend for every SaaS founder?

Yes. This is a book that I think every founder starting a company should download as an audiobook and just go on a walk and listen to right at the beginning. It's a book called The Mom Test. And basically user interviews are super helpful. We all know we need to learn from users and conduct great user interviews and do research that way.

But it's really easy to lead users to say the thing that they think you want to hear. And that's because people want to be nice and they're agreeable.

Like you mentioned, The Mom Test is a book about a strategy for interviewing users in a way that is so foolproof that you could interview your mom who, you know, wants you to be so happy and wants to tell you what you want to hear, but still get actionable insights from that. It is a great book. I love the book.

Actually, just last week I wrote something on LinkedIn about seven books I recommend every founder to read. And that was, I think, number two in the list. It is such an important book.

And again, another thing I love about that book is that it also talks about how you can build software by community. You have to understand your users. They have to give you the information. But at the end of the day, it's your job as the founder or as the product person to call the shots. And your user is not going to tell you exactly what to build.

They're going to tell you what pains they have. And then you have to figure out how to solve their pains.

I, it's just, yeah, if you read only one book, that's definitely a great book to read. I wish the book was there early when I started my career. They took too long to write it.

Dani, thank you very much for coming to the show. I love your energy. I love your story. I think everyone can learn a lot from you.

If people can want to find you, follow you, what's the best way to do it?

I mean, first of all, they should go and try a new way to report bugs with jam.dev. And then I'm on Twitter, the Dani Grant. Let me know what you think of Jam. Let me know any feedback, ideas. I hope it really speeds up your software development. Awesome. Thank you very much. Thank you. SaaS Origin Stories is brought to you by Dev Squad.

To find out more about how we help entrepreneurs launch new products and help larger businesses plug in a ready to go development team, visit devsquad.com. Add us to your rotation by searching for SaaS Origin Stories in Apple podcasts, Google podcasts, Spotify, or anywhere else podcasts are found. Make sure to click follow so you don't miss any future episodes. Thanks for listening. And remember, every SaaS hero has an Origin Story.