
In this crossover episode between Evolving for the Next Billion and Founder Real Talk, co-hosted by Glenn Solomon, we chat with Dani Grant, the co-founder and CEO of Jam.dev.
Jam is a developer tool that streamlines communication between product engineering teams about bugs and fixes. Founded in 2020, Jam has helped nearly 15,000 product, QA, engineering, and design leaders ship bug-free software to customers including Unilever, Staples, T-Mobile, and Dell.
Prior to founding Jam, Dani worked as a product manager for Cloudflare and Union Square Ventures. Jam raised $3.5M in a seed round led by Union Square Ventures and Version One Ventures, with participation from angels including GitHub CTO Jason Warner and Cloudflare CEO Matthew Prince. Jam is a GGV portfolio.
Hans Tung 01:17
Hello, everyone. Today’s episode is a crossover collab between the Next Billion podcast and Founder Real Talk, which is an amazing podcast host, my partner, Glenn Solomon, Glenn will be my co-host for today.
Glenn Solomon 01:30
Hey, Hans, really glad to be here.
Hans Tung 01:33
I love to have you on the show. Today on the show, we’ll have also feature Dani Grant, the co-founder and CEO of Jam.dev. Jam is a developer tool that allows for faster communication between product engineering teams about bugs and fixes. With Jam, developers, engineers, designers and product managers can capture screenshots, and develop locks in one click. Founded in 2020, Jam has helped close to 15,000 product, QA, engineering, design leaders to ship bug-free software into customers include the likes of Unilever, staples, T Mobile, Dell, SeatGeek, StubHub, Ramp, Autodesk and On Deck. Jam is also a GGV portfolio company.
Glenn Solomon 02:17
We’re super excited that Jam is a GGV company. And prior to founding Jam, Dani worked as a product manager for Cloudflare before moving on to Union Square Ventures where she spent two years listening to VC pitches from startups and picking up tips along the way for when she and her co-founder Irtefa founded Jam. In late 2020. Jam raised three and a half million in a seed round led by Union Square Ventures and Version One Ventures from Angela Tran participated alongside angels such as GitHub CTO, Jason Warner, Cloudflare CEO, Matthew Prince, and former Robinhood VP, Josh Elman, whom I think made the initial introduction between Hans to Dani. Dani, welcome to the Founder Real Talk and Evolving for the Next Billion. You get two for the price of one. Great to have you.
Dani Grant 03:06
It’s great to be here. Thank you for having me on.
Hans Tung 03:09
Welcome! Dani, please take us back to the very beginning. Before Jam you had experience in both working in a tech company as an engineer, and then also on the VC side of things. What was the shift for you from going to working at a tech startup, to join the dark side on VC. Then what eventually led you to do the right thing to start a startup of your own?
Dani Grant 03:32
In my first job out of college, I was really lucky to join one of the fastest growing startups in Silicon Valley, CloudFlare. I joined when the company was 100 people. It’s now a $20 billion public company. And there I got to see an amazing management team at work. And I got to work with such an awesome, incredible, hardworking, smart team. I joined as the fourth product manager, and then when the company hit a certain size, they wanted to explore what are the new greenfield opportunities for Cloudflare. And I was really lucky to be given the opportunity to join that team that was enabled to figure that out. So my now co-founder Irtefa and I were the two product managers on that team. And we worked with 30 engineers, and our job was to launch net new businesses for the company. And if they worked, we would like spin them out into their own org. And if they didn’t work, then we would just quickly sunset and move on. And we got to launch amazing products on that team. Like the last product that my co-founder and I worked on there was 1.1.1.1, which is a secure way to access the internet. And I think now more than 10% of internet traffic goes through it. So it was an incredible experience. And I met my co-founder there and much of the early Jam team. So that was amazing too. And I loved the job at Cloudflare. But I knew that if I wanted to one day be a founder. I also needed to see the early startup side of things and the venture side of things. And so when the opportunity came to join USV I knew I had to go and do it though I was of course sad to leave. And it was so inspiring to get to work with these early-stage founders, who they all saw some corner of the world that they wanted to improve. And rather than wait for someone else to do it, they decided to take matters into their own hands and go start companies to go and change that little corner of the world. And I really admired that in the founders that I got to work closely with. And that’s why I teamed up with my former colleague Irtefa to solve the problem we used to face trying to ship software fast at Cloudflare. If you’ve ever reported a bug to engineering, you’ve probably had the experience that an engineer picks up a ticket writes, it works fine on my end, and then closes the ticket. It’s super frustrating. And then you have to go and figure out together how to reproduce the problem. So an engineer can spend half a day or even a whole day just trying to figure out how to reproduce a bug so that they can even just start debugging it like it’s so slow. And what we would do in the old days at CloudFlare, and I have just found a picture of this, that I can send over. We used to run around the office until we find the engineer we’re trying to work with, and we hand them our laptop so they could debug live. Because otherwise, how do you share the state of your browser. But we also worked with engineers remotely Cloudflare had three offices at the time. And so we needed a tool to be able to do that in a remote setting. And that became even more important with COVID and remote. And so, we wanted to build the tool that we wished we had to be able to move faster. And that is why we started Jam.
Hans Tung 06:29
Do you think you’re able to do that without spending some time on the VC side to see how solvers get started and what kind of problems they will go into?
Dani Grant 06:38
I think, in a very real way, one of the first things you have to do as a founder is validate that what you’re working on has a real future, like you’re embarking on a path that’s worth embarking on. And the other thing you have to do as a founder is you have to raise money. And both of those things, I don’t think I had the right perspective and the right experience without the time in venture.
Glenn Solomon 06:55
Dani, digging in a little bit more on you know, I like how you said when you were at Union Square, you got to meet lots of people focusing on their little corner of opportunity. For you and Irtefa, this is like a lived experience, right? You were running around in office with your laptop trying to find the engineer to show them the issue. Obviously, that doesn’t work well in today’s world that has gotten increasingly virtual and distributed. And so maybe, you know, you realize the opportunity for a product like Jam there and then, but in the formative stages for startups, one of the big challenges, one of the big questions, that founders need to answer is like, how big an opportunity? Is this just my problem? Or is this problem really pervasive? Is it widespread? What did you guys do to convince yourselves that there was a big enough little corner for you to start Jam?
Dani Grant 07:46
The first thing we did was we did 45 user interviews to validate that it’s not a Cloudflare problem, but that it’s an industry-wide problem. And, you know, what we heard in those initial 45 interviews was so emotional. People have real frustration about the problem. And, you know, one of those early people we interviewed, he tried to pay us and schedule an onboarding for his whole team. But there was no product that we were just getting started. And so, we knew from the beginning, this was something we needed to solve. It was a day-to-day frustration that kept teams from being productive, and from honestly enjoying working with each other.
Glenn Solomon 08:21
That’s a good sign when someone wants to pay without a product.
Hans Tung 08:27
You have described the problem well. Can you explain a little bit of how Jam solves the problem? How do you deal with these unproductive communication cycles around bugs and fixes? And what kind of impact have you seen Jam make now that you have launched a product for a year so now?
Dani Grant 08:42
In real life, when you want to communicate about something that you want change, often you say, let me show you. Jam is “let me show you” for software development. So when you have Jam installed on your browser, and you see something go wrong, in some application, you just click on Jam, and you get an instant replay of what happened. So 30 seconds as a video, plus all of dev tools, console logs, the Network tab, plus all the specs of the device and the browser and the operating system. And it’s all automatically and immediately packaged into one link that you can send to a developer or paste into a ticket. So the developer right away can just see what the issue was and start debugging. They don’t have to spend an afternoon wondering how to reproduce the problem trying to investigate that. We’re really excited about the feedback that we’re getting from users. So at this point, actually, we just crossed today 15,000 people using Jam, which is so awesome. They’re from companies that we really admire, like amazing, fast moving product companies like Peloton and Rippling. One fun fact is that most of the major car companies now use Jam. We were just looking at our logs. And we saw a Ford, Maserati, Mercedes. And what they are telling us is that with Jam, their teams are a lot more productive and frankly, happier because they’re not running into the frustrations of having difficulty explaining and reproducing what are the quality issues that need to be fixed in the product. For example, before Jam, a lot of bugs just get dismissed because the engineer thinks, oh, it’s an internet issue, you just didn’t have enough network bandwidth. So we added a feature that shows you what was the network bandwidth of the bug reporter. And that way real bugs don’t get dismissed.
Glenn Solomon 10:15
That is awesome. Love that you have the car companies, we know they want to move fast. And “let me show you for software development” as a great visual and way to understand Jam. But you know, you guys had this vision, right? You did a bunch of customer interviews, and you really convinced yourself that there was a problem to go solve more universally than just that Cloudflare. But one of the things, you know, certainly Hans and I have really remarked about you, and Irtefa and the team you’ve built is how frequently you’ve continued to iterate really seeking to like nail the product market fit. And it’s been amazing to watch. And now with 15,000 users, clearly, you’re onto something, but like, you didn’t start there, right? You’ve had to iterate and step through the process. So maybe it’d be great to hear from you how you think about that process, how you think about when to start something new, like when to stop? And know that you need to iterate again. Is there metrics or patterns of behavior that you’ve been looking for? Really curious to dig into that process for you.
Dani Grant 11:18
Yeah, it’s been such an awesome journey. We knew from the beginning that we hit a real pain point. But what we didn’t know is how to address it. We’re trying to build a product solution to a problem that had never had a product solution for it before. And so we had to figure it out. And it took a lot of experimentation and iteration to get right. The metric that we tracked was retention. That was the most important metric, and Irtefa, my co-founder, really spearheaded that he kept a spreadsheet with, you know, all of the Alpha users for any one of these iterations in a column. And then each week would fill in whether or not they use the product and like what color in the next cell green if they did, and would keep it empty, if they did not. And what we were looking for was streaks that they kept coming back. And they were really engaged. And they were using the product every week. And they stayed for a long time. And I remember, in our sort of final iteration, the one that is Jam today, I remember we were 19 weeks into this product. And we had two teams with 19-week streaks like not a single, missed week. And we just thought like, there is something here that is working that is solving their problem. And that was so exciting. To this day, retention is our most important metric. Most companies track weekly active users, we track something else we call high frequency users. These are users that have used Jam three out of the last four weeks. And so the reason why we track this is not just weekly active users, it not only measures user growth, it also measures engagement and retention. So, it’s a harder metric for us to grow. And that’s why we like it, we really care about that. That’s the North Star.
One thing to add is there is bad startup advice out there, I believe. There’s this old startup advice from the “move fast and break things fast” 10 years ago, where Reed Hoffman said, if you’re not embarrassed by the first version of your product, you’ve shipped too late. And I do think you need to launch fast. But people have taken this advice to mean that startups can afford to have sort of a janky product. Because people say, you know, you’ll know when you have product market fit when people jump through hoops to use your product. They’ll use it even when it’s broken. And it’s janky. But that may have been true 10 years ago, but today with so many alternatives out there. And in a world like now we have mobile, remote, and a world that runs on software, you really need the tools you use to work. And so when people pick up, especially a productivity tool, and it’s janky. It doesn’t save them time it does the opposite. They’ll leave because it doesn’t work well enough. And when you’re searching for product market fit, what you really need is clarity. And if people are leaving because the product doesn’t work, you don’t know if it’s really that they’re leaving because the product doesn’t work, or if they’re leaving, because you don’t have product market fit. And so bugs in that early stage really obscure clarity. So actually, it was one of the things that we did later on is we started keeping the scope much smaller so that we could ship a bug free product. And that gave us a ton of clarity that we needed to find product market fit.
Glenn Solomon 14:26
So it wasn’t so much get it out fast. It was restricting the scope of the product in order to be able to move quickly but not have a janky product in the market.
Dani Grant 14:35
“Small scope, high quality” is the mantra at Jam.
Glenn Solomon 14:39
Got it. Do you guys use Jam on Jam? Hmm?
Dani Grant 14:42
Oh my god. It saves us so much time. It’s awesome. So we have a class of bugs that we can use Jam on which is like anything in our dashboard. And whenever we have a bug like engineers just see the issue. See what went wrong. Fix it. It’s so pain free. The Jam extension, it cannot Jam itself. And so that class of bugs is three to four times more painful for us as a team, I wish we had Jam for it. But you know, another learning searching for product market fit is we really care about dogfooding, because we’re the best critics. And while users may not want to give us all the ugly feedback, we will for ourselves. And so we dog fitted really heavily. And I think one of the mistakes we made early on is we overly dog food, we used our product more than we would expect a user to in replacement of other tools that they have in their stack. And so this led us to misunderstand how users might be using our product, like it sort of clouded our vision, it obscured clarity. And one of the things we did later on is we tried to dog food exactly as a user would use. And this really helped us improve the product quite quickly.
Glenn Solomon 15:47
Love that I was gonna suggest, like, I think, you know, this phase of getting the clarity on Product Market Fit feels like you’ve done an amazing job getting there, and now have confidence that you have these highly engaged users. And you’re seeing, you know, great uptick from, you know, amazing organizations and really seeing like the metrics you want to see. And so it feels like you’re starting to step on the gas and think about moving from getting the product, right to getting the company, right, and building like the commercial apparatus around the product. And curious, what are the new skills that you’re trying to add? And how you’re thinking about making this transition?
Dani Grant 16:24
Yeah, we’re so excited. The product is growing every week, like recently, almost every week is a record week for us. And we now have more than a handful of users who have created more than 1000 Jam, which is awesome. When you’re a founder, you think very far. And you also think very close, right? So we’re very focused on, you know, the next hour, the next day, but then also then Irtefa and I will take a break, and then come back to the conversation of where do we see the company in two years. So we’ve moved from a mode where we need to prove the product market fit to a mode of how do we scale, and our dream is to help a million teams be more productive and work more enjoyably together. And up until this point, we spent very little on marketing. It’s been all product lead growth, people just told their friends about it, or someone saw someone else using Jam. It’s also very common for an engineer to discover Jam and realize like, that’s how I want bugs reported to me. And then they just asked their teammates to use Jam. That’s actually how we were brought into some very large enterprises like Deutsche Telekom, the German arm of T-Mobile’s. An engineer was like, This is what I need in all the tickets, please use Jam to create tickets for me. Glenn, like what you said, when you’re starting a startup, you’re building a company, not a product. And then up until now, it’s been very much focused on product more than the other aspects. But now we get to sort of lift our heads up and figure out how do we build the other parts of the company. And that’s very exciting.
Hans Tung 17:50
I’m still quite curious of how you and Irtefa navigated during the product iteration phase, which took you guys almost two years to go through. A lot of people just see overnight success, see the popularity of Jam in this in the big companies? But don’t know what are the key steps you took to get there? If you have to take the journey down memory lane and figure out what are some of the key decisions you guys made? You can geek out a little bit about this even if this is a bit more technical, it’s okay. So what are some of the key decisions you got to make along the along the way key changes that help you to get to where you are right now, with product market fit?
Dani Grant 18:25
It’s been so awesome to just develop the product and get to figure it out. I love puzzles, and I love escape rooms. And this just felt like one. When we started, we thought, well, this problem never happens in Google Docs, because Google Docs has commenting for “let me show you”. So the first version of Jam was JavaScript, you could embed in your staging environment, that would turn it into a collaborative surface like a Google doc where you could leave comments. And what we found is that, you know, product managers and designers were so excited to use it. But engineers were hesitant to add new JavaScript to their staging environment. And so instead of spending time on getting user feedback and developing product, they’re spending a lot of time on sort of compliance, and it felt more enterprise than what made sense for this business model and product. So that didn’t quite work. And we realized what we needed is a way for product managers and designers to sort of just run ahead and and use the product without having to get buy in from their engineering orgs. So we built this web app where you could frame your website and leave comments on top so that anyone could just sort of start framing their website, start leaving comments, and then engineers can receive the link in the comments were right there. And this one looked like it had a little bit more traction and promise. So we kept developing it. But what we found is that people used it heavily for the month leading up to a launch, but then in their day to day. It was too high friction to go to a web app. So our usage was really spiky, which we didn’t like so we had to keep thinking. Then we tried a Chrome extension. And it was very different than the Chrome extension we had today. It was like it was more for designers and product managers, it was more for just pointing in the right place in the product than getting all the developer info. And this one was much closer. And we could tell from the usage, but it still wasn’t right there. And so what users kept telling us is, they kept saying like, this is close, but it doesn’t solve the problem of, you know, an engineer being able to figure out what happened. And so we realized it really had to sort of connect to the dev tools of the web application. And that became the current iteration, like the current flavor of Jam.
Hans Tung 20:37
Along the way, what are some of the biggest lessons that you can take away? If you do it again, what can you do differently to speed up this process? Or is this something that I just have to, you know, try and see and learn from all the iterations and mistakes?
Dani Grant 20:50
One thing we’ve learned is, in the early days, while the popular advice is to launch and get people using the product fast, so you get feedback, the more people in there, the noisier it is. And actually, one thing that helped us later on in the iteration cycles is keeping things small and quiet. So the first thing was, could we build a product that even our own team wants to use, and we would miss it when it’s gone. And that’s the fastest iteration cycle because you are the customer. So you’re right there. And it’s counterintuitive, because you think like you shouldn’t build for yourself, you should build for your user. But it turns out, even a small startup isn’t so different than a small team at a large company. So doing that as the first step was really helpful, which is, it’s not going big and launching, getting people in it’s iterating, internally and making sure it even Wows you, which is a high bar to meet. And then instead of then going to launch and bringing in users having a targeted alpha, where you have a hypothesis you’re testing, so instead of saying like, well, people use this, if it’s live. It’s “will people who match all of these initial customer profile aspects to them, use it every week”. And if you can pre-screen those people, and only bringing people who meet the criteria can really test a hypothesis. And it’s not noisy, because if the people don’t retain you know that the experiment failed, and now you have to figure out why and move on. So that’s one huge takeaway for us, instead of keep launching, keep announcing, keep bringing people in, keep trying in public. It’s stay small, stay quiet, stay focused,
Hans Tung 22:28
Very good advice. This reminds me of Slack in the early days, Glenn and I did the investment for GGV. And Slack started in the previous version of Slack is inside a gaming company, leaving the bell pools for people in four different cities to work together, the communication is not easy. And that’s how the first iteration of Slack got started. We also noticed that even though you’re a young company, both you and Irtefa are quite active on social media, and you produce content to engage with your users in the broader community. And that was one of the first thing that impressed us about you guys, that you have a voice, you have a perspective. And you mean well. How do you guys decide that there’s something that was important to you that you want to do and engage in early on?
Dani Grant 23:11
I love our users, you know, when you pick what company to start, one of the things that I didn’t realize when we started is you’re picking how you’re going to spend your time, who are the people you’re going to meet? What are the conversations you’re going to be having. And we’re so lucky, our user bases are all people who are builders, they’re trying to improve the world in some way. And, and Jam is a tool that helps them do that faster. And that is, I mean, it’s an honor, it’s so cool. And so we love hearing what they’re working on hearing how they’re working about it. It’s just awesome. One thing we’ve been really excited by is there seems to be some excitement about the Jam brand in public, which is something that we don’t really put a lot of time into, but hear about a lot from our users, which, you know, we’re flattered by it’s it’s, it’s awesome. The dream, of course, is to create a startup culture that feels like, you know, when you did musical theater, in high school, where everyone is working hard to make something amazing together. And it’s fun, and it’s exciting, it’s collaborative. And there’s this sort of special energy of coming together to make something that you’re also proud of, that feels awesome. And so you know, the team, we’re all very serious about the product and the mission and the users. But we’re not very serious about ourselves. So we work very hard, but we also can be quite goofy as a team. And I think that’s what comes out in the brand, in our copy, in the Jam tweets and the blog posts we write, in our emails, it’s just goofy moments when we work that can shine through.
Glenn Solomon 24:35
It’s awesome. You know, it does shine through and I think makes the brand super approachable. And one thing I think Hans would agree you as well know, you and Irtefa feel super approachable. It was easy to get to know you and as we’ve worked together like you know, you’re super transparent. And yes, we see how serious you are about the product but also how you don’t take yourself too seriously which is, I think, a refreshing and nice way to be founders. We’ve seen a lot of, you know, particularly in the current environment, you know, strife between founders, it’s difficult to start companies. And it’s taken a while. And sometimes, you know, people’s interests diverge. And there’s, you know, founders can find that they’re not maybe meant to be together long term. And that clearly doesn’t seem the case for you two. And so curious how you realize that Irtefa would be a good partner and co-founder for you. And you know, what advice you’d have for other founder would be founders looking for their co-founders as a result,
Dani Grant 25:37
I’m so lucky to have a co-founder like Irtefa. He is awesome. We knew we worked well together, because we had worked together. And I think that’s the only real battle test. I think when you know, people socially, you don’t know how they show up at work. But people are very different in their workplace and in their personal lives. And so I think that is, you know, one true test. One of the attributes of Irtefa, that really helps make things work, like it’s so awesome and admirable, is he really has growth mindset. As a founder, your job is constantly changing. And Irtefa has such a healthy and positive approach to that where whatever is next up the next thing we need to tackle. He’s sort of excited to see like, how can he learn that as fast as possible? What books does he need to read? What lecture does he need to watch? What does he need to listen to? Who does he need to talk to, and so he’s constantly learning. And that’s not only very helpful in building a startup, it’s also infectious and makes me feel inspired to keep learning and growing to, which is definitely something that you want in your co-founder is to push you to be better. The other thing, I think that is really key for good co-founder relationships is to have very open culture of feedback. Your job as co-founders is to support each other’s growth and help each other be the best possible leaders you can be. And you need to be able to give each other feedback for that are really brought that for us. So we sync every day for at least a couple of minutes. And every time we sync, he ends by asking if there’s any feedback for him. And then of course, it gives me you know, permission and a trigger to ask for feedback as well. And if you do that every day, it really normalizes feedback, and it gets you into that habit. And it helps you both really improve. And so I suggest that every co-founder who wants to improve their co-founder relationship, you know, be the Irtefa in the partnership and start asking for feedback every day.
Hans Tung 27:29
Wow, that’s a very helpful feedback and suggestion. Well, Glenn, and I both find you guys very authentic. And, you always, both of you are very positive. Both of you have that growth mindset. And that’s one of the things that attracted to us about you guys. And quite frankly, when Josh, and I need to thank Josh for this, made the initial introduction, I just find the two of you just mean so well and capable, and so smart, that you’re going to end up doing something interesting. So it’s easy for us write that initial check to be part of your journey. You guys also sort of by default became a remote first company, you guys were found Jam a few months into COVID. As you build up your team, how did you guys think about who to hire and add to the team, so that you can maintain that growth mindset positive culture you guys have, even though the two of you or working and living in different cities? How do you think about hiring the first three, four or five people to build that culture?
Dani Grant 28:27
First, that’s so kind of you to say it’s so good that this is audio only because I’m blushing so much. So on the remote side, we’re part of the first batch of startups who are figuring out the remote startup playbook. Like, of course, there are examples from before, but we started in March 2020. And there was no default playbook for how to build your remote startup. And, you know, one of the awesome things about remote is that there is no limit to who you get to work with. So I wouldn’t give that up for anything. I love working with our team. And I’ve gotten to work with awesome people who I otherwise may never have met who live all over the world. And, you know, like, startups go through ups and downs, but the thing that’s constant is the team you get to work with and the experience of getting to build it. And that aspect of remote is priceless. One thing we had to figure out is how to move fast in a remote setting. Because speed is really the only competitive advantage you have as a startup against the Giants. And when you’re figuring out product market fit if you don’t move fast, you just run out of money. So you gotta go. And so the we figured out a couple of things that we do as a team to help us move fast in a remote setting. The first is, you know, the best ideas and the best motivation to keep improving comes from when you see new things in progress. Like you need to see something new to spark the best ideas. And in the office, you have sort of a turn your laptop moment where you can show the person next to you what you’re working on. And then suddenly you’re ideating about where it can go, what it can be and and you get excited to do that quickly. But how do you do that in a remote setting? So we have a Slack channel called What’s cooking, where people share in progress work rough drafts, and it just gets the conversation going and the excitement going. Another is nothing creates urgency like setting a date. So we commit to dates. And often we just put them on Google Calendar. And then leading up to the dates, we do really frequent check ins of like, you know, red, yellow, green, or are we on track and having that visibility for the whole team of this is the date. And talking about it at a daily cadence of are we on track helps us be ruthless and prioritizing how we get there. Like, it brings up the important conversations about speed and trade offs that may otherwise not come up until the last minute. So that’s been really, really helpful. And then the last thing we do, or third thing here is, you know, when you’re building a company, you’re building a machine that knows how to tackle challenges together, and you’re building this machine that works really well together, that whatever is the next challenge in front of it, it can handle gracefully, and execute well together as a team. And so we do really frequent retros. They’re like 15 minutes long, anytime a new project goes out, like a project is over, or anytime there’s some sort of incident, we’ll just do a retro, but it really helps us reflect on what works well, for us to move fast with quality and what does not, Dani.
Glenn Solomon 31:13
Look into your crystal ball for us. Where do you see Jam three years from now, you know, three plus years from now, what does the future hold?
Dani Grant 31:20
We want to make it productive and enjoyable to develop software. And we want to make it enjoyable and not frustrating to use software. That’s our mission. And that’s how we want to contribute to the world. And we will run it that in every way we can. Anywhere someone is building software and needs a let me show you. That’s where we need to expand Jim, you know, software today runs everything like AI, hospitals, schools, everything is just software underneath rocket ships, cars. And progress today just happens at the speed of software development. And so it’s really important to be able to deliver great software faster, because that is the speed at which people’s experiences can improve. And so that’s, that’s why that matters to us, we’re just going to keep at it. And we’re going to keep finding ways to contribute to making product development more productive, more collaborative, more enjoyable.
Hans Tung 32:10
Well, you and Irtefa are exactly the founders that Glenn and I like to work with him very early stage. And you know, over the last two years, both of us have a lot of fun in to work with you. We’ll wrap up this interview with the final section, which is a speed round where we ask a few questions. Glenn and I will alternate to ask you that question, then just don’t overthink it. Just share this with the first answer to popping your head and then see how it goes. The first question I have is that what books or articles have you read would you recommend to founders starting up on their own?
Dani Grant 32:46
Paul Graham has a blog post called How Not to Die. Every founder should read it. It’s so motivating. Hmm.
Glenn Solomon 32:52
That’s a good one is thinking along that theme. What’s a piece of advice you’d give to a young Dani?
Dani Grant 32:58
Oh, early on, you know, I was so focused in, you know, what are the skills I need to start a company and I neglected distribution and marketing, I think learn marketing take on an early product marketing role. If you don’t figure out distribution, it’s game over. When you start a company, it’s the most important thing, products with better distribution that are worse products win. So you know, over good products with worse distribution. So it’s just critically important. And one of those things I wish I had paid closer attention to while at Cloudflare was to spend more time with the marketing sales teams.
Hans Tung 33:28
Great. We love the name Jam, so many different meanings. What is your favorite flavor of Jam?
Dani Grant 33:34
Spicy Jams are the best Jams. If you’ve never tried a spicy Jam, you will do yourself a service by going to try spicy Jam. We recently as a team, we played a Jam taste test game when we were all together a few weeks ago, where we had to match the Amazon review to the flavor of Jam. And while we were not very good at that, everyone will tell you spicy Jams are the winners.
Hans Tung 34:22
Sounds good, great answer.
Glenn Solomon 34:24
One of the other companies Hans and I had the good fortune of working together on and backing is Airbnb and they made they’re famous for the cereal they made around the election that helped them ultimately get funded long story behind that. You can dig deep in the archives to find an interview that Hans and I did with Nate Nathan Blecharczyk, one of the founders there he tells that story. Maybe you guys will have a similar mythology coming up. You can make some Jam, Jam Jams that you can give out to your customers. I bet they’d love it.
Hans Tung 34:53
Slack, Airbnb, and Jam. That’s amazing. Love it. Thank you so much for being on our show. I love that. That was a lot of fun. Thank you, Dani.
Dani Grant 35:03
Thank you so much for having me.
I would like to receive news and updates from GGV.