[00:00:00] Introduction
Dani: we didn't know what a product would look like that would solve this. And so we tried and we got it wrong seven times.
We shipped seven versions of a product that we thought could solve this problem that didn't have product market fit. They just didn't work. And the eighth one did. And so I wish we had gotten it right on day one. It would have made the next 18 months a lot easier.
Andrew: Hello, welcome to the DevTools FM podcast. This is a podcast about developer tools and the people who make them. I'm Andrew. And this is my cohost, Justin.
Justin: Hello everyone. We're really excited to have Danny grant on. Uh, so Dani is the CEO co founder of gem. dev. we're so excited to have you on. and gem dev is like such a fun product, so it's, it's been exciting to watch that grow.
But before we jump into that, could you tell our listeners a little bit more about yourself?
Dani: Absolutely. Thank you so much for having me. I'm like a fan. So my co founder and I met as product managers at CloudFlare. We were the two PMs who were tasked with launching new businesses for the company. That would be huge risks to divert a ton of like company attention on, but like, gosh, someone's got to try this.
So we were the two PMs who launched CloudFlare workers, that launched 1.1.1.1 If you're familiar with CloudFlare and it was there moving. super fast that we realized how much time and energy was going into just PM to engineer back and forth in JIRA Commons. Oftentimes, when you report a bug to an engineer, you, the person who has seen the bug, you think you're giving the engineer all the context that they need, but in reality, they open the ticket and there's actually not enough information there for them to repro the issue.
And so they're totally blocked. And so you end up going back and forth in comments, you hop into screen shares, you go find them in the office. and it's super painful. It takes up a bunch of time. And when you're working inside a company, you kind of have to crawl through glass in order to ship stuff out the door.
Like you don't get to pause and be like, should we build some tooling to help us communicate better with engineers? And it takes a whole different company to do that. And so we left our jobs and that company is jam. Now we help more than 80, 000 people report bugs to developers in a way that's like one click for them and super clear and has everything a developer needs to actually action the bug.
Justin: That's really awesome. Uh, we've obviously all had this pain point before and there, it's interesting how the communication barriers between a company seem to be like where a lot of opportunity is. So the communication barriers between like product managers and engineers or designers and engineers, or, you know, everywhere else in the organization.
So this is a, like much needed product.
Dani: it's like the Google Translate problem. Like inside the organization, we all have very different backgrounds depending on what field we're in. And we all use very different language to describe things. So the, words the sales team uses to describe any particular page or component is actually different than the words the engineering team uses to describe that same page or component within a company.
Similarly, a lot of words we think of. As the correct word on like the product side, but on the engineering side don't mean very much. Like for example, a PM might write like this didn't work. What is didn't work? Like for an engineer, they don't know. Did the page crash? Did the button respond? But with the incorrect response, was it just very slow to react?
And so they thought that nothing was happening. Is it just missing a loading state? Like. Didn't work can mean a lot of things. And so it makes perfect sense that across different fields within a company, we just are missing words to communicate with each other.
[00:03:44] From Intern to CEO: Danny's Diverse Career Path
Andrew: Yeah, I can definitely resonate with that. I'm currently working through a few tickets where it's like, but what, how did you do this? Like, I need more, more to this. So, uh, I can definitely see the need for the tool. But before we go into the tool more, uh, when I was doing my research on this episode and doing my like Nardwar look into someone's background, I noticed that your early career was just like, you went from domain to domain.
So you were, uh, a business intern, a design intern, a software intern, an ad intern, and then you ended up as a project manager at CloudFlare. So it seems like you kind of like went through a work. At every part of a company gauntlet and then ended up as a CEO. So how did that happen? And do you think those experiences have, have helped you as a CEO?
Dani: I got so lucky. So when I went to college, instead of declaring a major, like most people do, I got into this program at NYU called Gallatin, which lets you create your own major. And what that gave me was. The flexibility to change my mind every semester as to what I was studying. And the other flexibility it gave me is because I wasn't super worried about, you know, needing to take like 10 computer science classes and three math classes.
I had enough credits to spend some of school time doing internships. And so what I would end up doing is, um, and being in New York city, like there are tons of companies there who would love free or cheap labor. And so I would. Changed my mind as to what I think I was studying. I would take classes in that new thing I was interested in and also go intern in it.
And so then I could verify for myself, do I actually like doing this? I think oftentimes we study one thing and it's very different to study it and to do it as your profession. And the first time we actually see it in practice is after we graduate. And if you end up in a field, you actually don't like doing day to day.
You're kind of stuck because it's really hard to restart a career and, and it sort of looks bad if you jump around in your early career, but that time in college is like freedom to do so. So I got super, super lucky. Now on the startup side, the place I actually wish I'd spent more time learning is on the marketing, community growth, distribution side of things.
I spent a lot of time on product side, but actually what I'm learning as a founder is that yes, product is really important, but the best products don't always win. Sometimes it's. It's, it's the company with the best sales team, with the best go to market strategy. And so I feel like I'm playing catch up on the job.
Justin: Yeah, we definitely can relate. Uh, Andrew's done a great job of like marketing in the podcast, but that's, that's a hard, hard thing to do well. And it is all about, like, if people don't know about your product, no matter how good it is, nobody's going to use it.
Dani: I think that when, when you start a company, one of the things that you don't always appreciate early on is that the thing you choose to start sort of dictates how you're going to be spending a lot of your time. People talk about like founder market fit. I think there is like a very strong founder company fit and the founder go to market fit.
Um. Where if I'd started a different type of company, like, let's say I started a company that was selling to schools, I would spend a lot of time with teachers, with principals, with admins, like in person at schools, but we started a company that grows PLG, like it's product led growth. And so actually it's very fitting.
My co founder and I are product managers for us. It's like. The more we can focus on the product and our users and building something that they will use every day and love, the more the product spreads itself. And so we lucked into this sort of model that really fits what we love doing. Um, but definitely something to think about when you're starting a company on day one.
[00:07:19] Ad
Andrew: We'd like to think our first sponsor of the week code crafters code crafters makes programming challenges for experienced software engineers. If you're looking for a weekend or really a multi weekend project that takes you to the edge of your programming abilities. You have to check them out. They have a whole bunch of really interesting challenges where you rebuild technologies that you use every day.
So far, I've tried to rebuild Reddis and currently I'm working on get. A cool part about it is that they have a whole bunch of different languages that you can choose from. So you can go hard and one of those languages and really start to learn it better. I chose to go for JavaScript, but you could use things like rusting go to.
And my opinion, it's way better than going on leak code or try and do any of those other coding challenges. Having a focus deep dive on something that I'm already using has been really useful for me to understand how that tool works.
As I've been going through the build your own kit challenge, I've been constantly surprised at all the unique ways that the get protocol chooses to encode data. Like for example, pack files, they are a buffer. And the buffer just has a much of a headers sprinkled throughout it.
And then portions that are compressed with zlib . So I've really gotten used to working with buffer streams and chopping up the data and thinking about code in ways I haven't really, since college.
Besides the content, even the user experience is targeted towards experienced software engineers. For example, instead of typing into a custom editor, they have on their website. You use the tools that you love, use your ID on your, use, your ID on your computer and your terminal to interacting with code crafters is as simple as just pushing.
Once you push, they run your tests and they tell you if you pass the challenge.
To try code crafters out for yourself. Vedas. Visit codecrafters.io/devtools-fM. There you'll get a 40% discount. And you'll be helping out both them and us.
If you don't want to hear these ads anymore, you can become a member of one of the various platforms that we offer it. With that you get the episodes a little bit early and you get a mad free. Another way to support the podcast is to head over to shop.dev tools.fm
where you can go buy some merch.
And if you want dev tools, FM in your inbox, head over to mail.dev tools.fm, where you can subscribe to our newsletter. You'll get weekly updates on all the cool things happening in the dev tools world and a few of our post show thoughts about the episode. And with that, let's get back to the episode.
[00:09:35] What is Jam?
Andrew: So now that we covered that, let's go into Jam more. So you gave us a little preview about what Jam is, but, uh, what is Jam and why would I want to use it?
Dani: Jam is the perfect bug report for developers. If you've ever reported a bug to engineers, you've probably had the experience where you like put all the details in the JIRA ticket and then they open the JIRA ticket. They write, works fine on my end, and then they close the ticket. So Jam makes that impossible.
Basically, it, you add it to your browser, it plugs into DevTools, and when you see a bug, you just click on Jam, it grabs an instant replay of what just happened. Not only the DOM played back like a video, but also everything in DevTools that The developer might need and all the metadata of your session and device and hardware and what's the user ID and it packages it all up into either a link to share with engineers or into a ticket and that way when the engineer starts working on a bug, they just have everything that they need.
There's no back and forth. They don't have to ask any questions. You don't have to screen share and find the console logs. It's just everything is right there.
Justin: We had Jason Lester on who's working on replay and, you know, debugging tool, different context. and well, I always thought that that like value of capturing the context is, I mean, obviously there's, there's a ton of value there, but you know, in, in their case, it's like, you're debugging a really hard problem.
You had the special browser that you use, you have to like go through a bunch of stuff. So I really love, how you just like integrated this, you know, directly into browser, browser extension. What is it? What does it take to like, make that work? Like, did y'all have to spend a long time just on the technical side of it?
Is like, figure out like what a good experience is there or did it kind of like. Sort of like naturally come together once you had the sort of idea of what to build.
Dani: I wish it had just come together on day one. We knew exactly what the product should be, but what actually happened was my co founder and I had seen this problem firsthand as PMs ourselves. The first thing we did is we did 45 user interviews, like right out of the gate, very like product managers start a company to validate that it's an industry wide problem and not like just us. And, but we didn't know. So from those interviews, we knew this is a problem we needed to solve and that there was a lot of like emotion and frustration behind it. But we didn't know how, like we didn't know what a product would look like that would solve this. And so we tried and we got it wrong seven times.
We shipped seven versions of a product that we thought could solve this problem that didn't have product market fit. They just didn't work. And the eighth one did. And so I wish we had gotten it right on day one. It would have made the next 18 months a lot easier.
Andrew: What were some of the failed iterations you guys went through?
Dani: So the first thing we tried was we thought, okay, we'll give engineers some JavaScript to put on their staging environment and that JavaScript will transform the staging environment into more collaborative surface. So everyone's looking at staging and now we can let you like leave comments on top. And PMs were super excited about it.
And you know what engineers don't want. Is for the PM to come to them and say, please add this JavaScript to your staging environment. So that, that was a, that didn't work. Then we thought, okay, well, great. So, um, what works is the collaboration part, but not the delivery. So what if we built a web app that wraps your staging environment and then makes it a collaborative surface in this app, and then you can leave comments on top. And that works for some subset of things, like if you're QAing a landing page, this is sort of a great experience for that. But if you're actually building like a product that has application state, when you hit an issue, you're not going to go and re login to your account in that, like in our app and then get to the Place that you were at with all of the repro steps.
It's sort of too much to ask. And so we just kept iterating in this way. the first time we launched a Chrome extension, it got a lot more usage. And so we like had this idea that we're on the right track. but the form factor that we have it today, where it's just browser extension, click on it, instant replay, capture a clip, like a link to your clipboard.
They can share with engineers, everything that they need. That was the one that really just took off.
Justin: That's, that's so fascinating. When did, this is a hard question to frame. When did you decide for each time? It's like, okay, time to move on. It's like, how do you, I mean, you made a lot of iteration. You said 18 months, 18 months might sound like a long time, but to develop essentially like seven different variations of a product and to like, say, okay, we're not going to continue here.
We're going to do something different. Like, how did you decide at every point? Like, Nope. This isn't, this isn't the right fit.
Dani: I think the hardest part was to keep going on the problem itself and to believe that we could find a product that would solve this sort of people problem, um, with a product solution. We knew from other startups that we admired that this is part of the journey, but it's one thing to know it. And it's another thing to experience it yourself.
So like, for example, I love the Notion story. I'm super inspired by Notion. I use their product every day. They had this amazing story where they were two and a half years in, they still didn't figure out product market fit, but they were running out of cash. They had to let the team go. The founders moved to Japan to like save on burn.
And they spent 18 hours a day, like working on rebuilding Notion from scratch, but using all the learnings they had learned over the last two and a half years. And that's the product that we like all use and love today. We knew that Figma took a couple of years to get to product market fit. Slack, we all know it started as a gaming company, but what many people don't know is even after they pivoted to Slack, it still took another two years to get to product market fit.
And so we knew we were in the iteration phase of the company. And we also knew like, when you build a company, you only get one chance. To invent the product. And after that, the rest of the company is just about scaling it. Like if you think about the products that you use and love, like zoom, like Slack, like Twitter, they actually haven't changed very much since you started using them maybe five or 10 years ago.
That's because once you hit product market fit, you don't risk it by reinventing the product. You just scale it. And so we were sort of excited about this moment in the company. We knew it was part of the journey, but also like very psychologically difficult to just keep iterating and iterating
Andrew: Yeah. And then you have to live with what you come up with. If you do hit product market fit and you don't like it, that's a good problem to
have.
Dani: That was one of the things that was very front and center for for us, one of the, you know, in startups, you hear all the time, like, if you ask your users what they want, they say, a faster horse and your job is to build them a car. And, you know, we built seven cars that failed. And the eighth is honestly, like, what did users want?
They wanted a browser extension that did, you know, what the Product does today. And we just listened to them for the eighth one. And it turns out they know exactly what they want. I, I think that, you know, we, part, part of like the narrative in my mind was like, no, we have to do something bolder and bigger, you know, like, I don't want to get stuck doing something that feels very narrow and, but now that we're in it, it, I see there's so much space to grow.
I think rather than the reality being like, you get stuck doing the thing that works. It's like once you're doing the thing that works and it's working, your customers start to pull you in a lot of directions and it gets a heck of a lot more exciting.
Justin: It's an awesome insight for sure. It is like, I guess if you have like a love of the problem space and you have just like opportunity everywhere, is it's like, there's all these, these different areas that you can just make things a little bit better, a little bit smoother, you know, solve this like slightly related problem, do all these things.
It's kind of a fun time to be
in.
Dani: It's it's especially fun when you love your user base. Like one of the other things that I wasn't thinking about on day one as a first time founder is like, whatever is the company you choose to build, that's sort of how you're going to be spending your time for the next decade. And we lucked into like, we get to spend time.
With our users who are all product people and engineers, and they're trying to change some corner of the universe with software. Like, like that's so fun. And so when you really like enjoy the people you get to talk to about the product and jam with them, um, then that becomes like very generative as you're talking about, like, where this go?
Is that where the idea for like hackathons came from? It's like, we're building for these hackers, so let's give them a place to hack and show our name too. And you know, it's funny. every single person who signs up for the product gets an email from my co founder being like, how's everything going? And people think like, this is like a bot or like, there's like a marketing intern behind it. But no, this is like the answer. You just start chatting with Urtifa, my co founder.
And what we learned from this is that our users are super chatty. They want to talk about how they're building and what tools they're using. And like, and. And so then we thought, well, what if we got them together and we started hosting events? The first one actually was not a hackathon. It was a night of engineering horror stories, completely off the record.
Engineers coming together, sharing how they've broken prod in the past. it was super fun. We got the idea from segment who used to hold events like this called segfault. Um, and so we did our own take on that, but now, uh, now every month we're hosting three or four events, bringing together engineers, PMs, uh.
Sometimes for hackathons, sometimes to share what they're building.
Justin: Yeah, that's great. It flows back into the growth and marketing aspect because it's like, I think. There, there's a thing about like building products that sometimes we can get to, like, there can be too much distance from the product that we're building and the people that we're building it for. And I think that there's something that like recognize the whole person, the whole, you know, Customer as like, you know, someone who's like, has, you know, similar pain points as, as you've had in the past.
I mean, I think you have to do this as a founder, but the hard thing is, is like, how do you get the engineers on your team, the people building the product, you know, to have that same level of like deep empathy and I bet like events like this are a good, a good way to do
that.
Dani: What you're saying about like recognizing your users as whole people is so true. One huge change we saw coming out of COVID is when we started the company, it was like lockdown time. And so we met all of our users over zoom. And then as soon as the world started opening up, we started meeting our users in person.
And the level of. The level of conversation was immediately transformed where, when you're on zoom, everything feels very transactional and, and the conversations were all about sort of, like, how they were using the product, or maybe we would ask a couple of broader questions, but they, it was sort of very tack, like, it. The conversations were very much like Q and A. When we started meeting our users in person, we started learning about how they use the product and sort of what it means to them at like a social dynamic. Like at every company, there are these sort of dynamics that happen within the team. We learned about like PMs who are working with a brand new engineering manager and like how Jam is helping them communicate,
Without having like this shared work history. They've like, they've never worked together before or like, um, we'll learn like, oh, it's a new PM. It's their first time in a tech job. And this is a tool that helps them, like, be good at the job and like, look like an insider, even though there's trying to like, figure things out on the fly.
Like. Once we started meeting users in person, a lot more of the stories came out, became really, really important.
[00:20:49] Exploring Jam's Features
Andrew: so before we move on to, like, asking more about, like, leadershipy questions, I want to drill down into the product a little bit more. So, uh, we kind of glossed over it, but you said when you click the jam button, it just, like, gives you what just happened. Uh, what do you guys call that feature and how does it work?
Dani: It's called Instant Replay because it's like instant replay in sports. It grabs the last 30 seconds of the DOM played back like a video, plus everything in console logs, network requests, all of the waterfall of timing. It grabs all of the session details, like what device and hardware and OS you're on, but also custom metadata like user ID and what experiments a user is in, and then packages all up into a link.
Andrew: Do you know how the, the, like, DOM replay works? Like, you mentioned a JavaScript library that had to be included on the page in version 1. Does the, the Chrome extension include, like, similar code in the page when you run it?
Dani: Exactly that. And then snapshots the DOM and looks for changes and then plays it back like a video. If you're familiar with tools like full story or hot jar, that's how they all work as well.
Justin: That's really cool. So, um, you also have a jam GPT. Uh, what is what's that all about? What does that
do for you?
Dani: So once, once chat GPT came out, we started seeing something really funny, which was engineers who were receiving jams were copy pasting the errors from jam into chat GPT and asking it how to solve them. Right. So we've, and so. We were like, well, that's silly. Why don't we prompt it for you? Like, let's just save you some time.
And so we brought chat GPT into jam and we prompt it with all the information we know about the web app and the errors. And then it saves you a search. It tells you where to look. And then if you give it some code, it will fix it for you. This feels like tip of the iceberg for me. Like it is so clear that two years from now, the way we do debugging will be completely transformed with AI. And like, isn't the dream you connect your repo to Jam and then it just proposes a PR and then the engineer can get the bug report, the proposed PR, maybe make some changes and the, or like just call it a day. So if anyone is listening and wants to be part of building that. We are, we are hiring go to jam.
dev slash careers. I would love to meet people excited about
that.
Andrew: And the name that you guys have, the domain name is perfectly set up for that jam space dev.
[00:23:06] Ad
Andrew: We'd like to thank our second sponsor for the week run me.dev.
When it comes to cloud infra, we live in a fractured and complicated world. It's 20, 24, and we're still storing off stocks in wikis and relying on a bunch of scripts and marked down and fractured repose. Run me wants to put the op stocks back in your repo, along with the rest of your code. With a run meet, you can empower your whole team to be in charge of your info.
With simple notebooks, create mission control, dashboards, interactive, external docs, or even operational runbooks to get started head over to run me.dev.
[00:23:39] Getting Investment
Justin: Yeah, that's so good. Um, so let's let's switch to talking about the company a little bit more. I'm super just like fascinated by your founder journey for somewhat selfish reasons, but also just like in general. So first I want to say congrats on the series. A that's a big milestone. That was super exciting to hear.
and you have some, some really, really good investors, on the cap table. So some folks from, uh, Figma, you got, uh, Guillermo was, was an investor. So this is all cool. so. Like, how was that journey to getting to series a I'm hyper interested in funding conversations now, but was it sort of like natural, like after you found your, you know, product market fit or you're like getting into that, that like the sort of investor interest, just like kind of naturally grew from there, or you're like really having to, you know, I don't know, preach the vision of like what we're doing here,
Dani: We, we are super, super lucky on the funding front, not only to get to work with like really incredible people, like even behind the firms that, uh, invested as part of the, eh, like they have helped the companies that we admire and look up to and hope to build a company like, you know, from. Beginning to IPO.
And, and we also really lucked out that it was inbound and, um, preempted and, and driven by excitement, for, I guess what we're building. But before starting jam, I worked at a VC firm called USV where I would do mostly like early stage and through this, I've seen. hundred something founders pitch. And so then being on the other side, there were like a couple of like tips and tricks that that I used from being on the VC side that I would use on the founder side.
I would love to share. With your listeners, when you're going out to pitch, like a couple of tips.
Andrew: Yeah, go for it.
Dani: I will say the funding market is like extremely tough right now. and so if you remember, like, do you remember the boat that was stuck in the Suez canal and then there was the meme of the little digger that was like trying to get it out.
So these tips are about as helpful as that little digger, like, like the actual roadblock is the market. And this is like nice polish on top. One thing that a lot of founders don't realize when they go out to pitch is they think it's a lot, or especially like early stage, like seed stage, especially, they think it's a lot about what they're building and sort of like how great of a business this will be.
Of course, that's a huge part of it. But what a lot of founders don't think about is what, what is the role of the pitch meeting? What do they need to deliver? And part of what you need to deliver is a great meeting. Like. If, if you succeed and you end up working with a VC, you're going to work together for like a decade plus.
And so both sides are trying to see like, do we enjoy working together? It's sort of like a hiring. call And so one framework that's really helpful for founders is to think I am in the business of delivering a great meeting. What's a great meeting. And if you have that framework, it can help answer a lot of the questions that you have about how to run the meeting.
Like if you're really good over zoom, then meet over zoom. If you're better in person, meet in person. If, if you're, if you're like an engaging person, don't screen share your deck because that takes you from being the center of the frame to you being this tiny face in the corner and like them feeling like they're in a webinar.
the worst part of every zoom is the first like. Five minutes where you like talk about where you're located and what the weather currently is, like, just skip it. Don't do it. Like, if you're in the business of giving a good meeting, come in prepared with something to say. So when they ask, how are you?
Like, tell them exactly what's happening in your day. Like, tell them the most interesting part of your day, like. We're building this new feature and I'm really excited about it. And I'd love to share it with you. Or I just got off a customer call and I learned something new. Can I tell you about it? And then like, so that way just get into the call and get into what you want to share and don't like make it this awkward start where you have to like transition over to like, can I pitch you now?
Justin: Yeah, that, that sort of natural conversation is, is hard to pull off, you know, especially if you're not used to doing it, but is. You can definitely tell, like you're, you're talking about interviews. This is something that you can definitely tell is like when somebody comes in and they're at ease in the interview, it just flows.
And, and you, you're this hard process, which seems like it should be really hard. A lot of times with somebody who's like, you know, good and confident and they know what they're doing and they have sort of been through the process before. You just feel like you were in a conversation for an hour instead of like, you know, really trying to dig down and it can make all the difference in the world.
So that's a great tip.
Dani: Another way to think about this is if you've ever been a hiring manager, like you've ever interviewed someone who's looking for a job, you can like, remember back to what made those conversations great. Why did you want to work with someone versus why did you maybe not want to work with someone? One thing that's very sort of delicate when you're fundraising is about timing.
So. If you've ever interviewed someone for a job and you're like, what's your timing like? And they're like, I don't know, like, I'm just kind of interviewing with you right now. Like, it's cool. It's just, there's no urgency. Versus if they're like, I'm in a, I'm in a couple like final conversations. I'll probably make a decision this or next week.
You're like, suddenly you're like, okay, wait, I've got to make some moves in, in funding, if you think about being an investor, like. You're sort of incentivized to get all the information possible before you make a decision. So if there is nothing like prompting you to be urgent, act right now, you're actually probably more incentivized to wait and see what happens.
And so it's really helpful as a founder if you can, instead of like fundraising passively and just see what happens, if you can just Actively, like put all your meetings in the same week, even if you schedule it a couple of weeks out, but you sort of do it as a fast process. That way, when you're on these calls, there's like a reason for people to act.
It's like, well, it's happening now. And so the question is, do you want to be part of it or not? Cause I've got all these other conversations going too you know
Andrew: so two tips are around like kind of just like being prepared and setting the environment for which you can get that investment. Uh, so like, do you have any tips for like, like when you're actually pitching, like what you should focus on or anything like that?
Dani: yes. And, um, I mean, you should talk about your business. you should talk about what, what it is you're building proof that it works. Why you're the person to do it. And, um, And, and you should like get those things sort of out of the way first. Like if someone doesn't know what it is you're building, they're not listening to, they're just trying to figure out, they're playing catch up, but the, like a pro tip on top is sometimes what you're building.
There's a lot to say about it and you can get really in the weeds, but oftentimes you'll be asked a question just to see if you've thought about something, and they actually don't need the full answer, especially when it's early and they know everything might change. And so one hack you can do is to keep your answer short by saying, by giving like a framework, like if you get asked about monetization, you can be like, we think about it in a couple different ways, most likely we'll do this, but happy to go into it more if you want.
And that way it's like all very concise.
Justin: Yeah, I think there is, um, there's something that I've like seen a little bit in the people that I've talked to is that if you're trying to get to the answer for everything, just like figure out what the correct thing is. it seems like you can, you can really go off in rabbit holes and you're. The worst thing that you can do is like come up with something as you're talking, you know, it's like you're in the middle of the conversation.
They asked you about the question. You're like, it's a good question. Um, here's, you know, kind of what we're thinking. So how do you, like, what is the advice that you have for people in a really early stage that are still trying to sort of figure out, you know, Maybe they know the problem that they're hitting, but the, the, you know, there's still a lot of questions about what the market is, like what the shape of the product should be like, you know, think back to yourself in some of those early product iterations where you kind of knew what you're doing, but like kind of still trying to figure it out.
Like, what do you, how do those people have the conversation?
Dani: Imagine I gave each one of you like a 100k. Um, I don't have that to give you, but imagine, and I was like, Hey, you get to invest in like, you get to use this and invest in early stage founders at the earliest stage before anything is working. And so you're like, great. So then you go out and you go meet with a bunch of early stage founders where nothing is working.
It's like, what would get you so excited that you'd give them a portion of that 100 K. And. And actually, you don't really need to see something working, because you know things are early. But you need, you need a cohesive story for why this is going to work. Like if someone showed up and was like, I don't know, I'm kind of like experimenting.
You're not going to leave very excited, but if someone shows up and is like, I'm obsessed with this problem. Here are all the things I've tried so far. Here's why it doesn't work. Here's what I'm going to try next. I am not giving up until we solve this and here's why it matters to me. You're like, whatever, let's figure this out.
Like, I'm in.
Justin: That's great.
Andrew:
[00:32:26] Rethinking Startup Advice: Quality Over Speed
Justin: Uh, so what are some, what's some advice that you'd gotten in the past for startup founders that you maybe tried to apply and just hasn't panned out?
Dani: One of the pieces of advice we had to learn the hard way may have not aged well with startups is there's this 15 year old saying, which is if you're not embarrassed by the first version of your product, you've shipped too late. Have you guys heard this?
Justin: Yeah,
absolutely.
Dani: Around the time Reid Hoffman was saying it, was about the time that Facebook was releasing its first mobile app.
Like a lot has changed, um, in the world since then. Like we have mobile, and we have remote, and actually our lives are pretty much running on software. And so while 15 years ago, if a software wasn't perfect, you might still use it. In today's world, you really cannot afford that. like I cannot afford social capital of bringing in a tool to the workplace that might not work for everyone.
Like I just can't, even if it's super cool. or I can't use an email tool if it sends 98 percent of the emails I think I sent. I just can't. And so the bar for quality is a lot higher today than it was then. So what I think the saying gets right is you do have to move fast and the way to do that with high quality is to limit your scope, right?
Like choose one thing and just do small scope, high quality, let's go. But the thing that I think it gets wrong is this idea that you can ship fast and messy and actually test whether software works. When we did the first seven iterations of Jam, the ones that failed, we were like ship things, see what happens, duct tape together.
We heard. You'll know you have product market fit if people are willing to jump through hoops and use a buggy product. but Nowadays, that just isn't true. And actually, one of the things that we changed, and I think one of the reasons why the 8th version of Jam worked, is because it was the first time that we didn't ship until it was actually kind of production ready.
Like, we didn't ship with bugs. We took a little bit longer. And that made for us all the difference.
Andrew: Yeah. Users have very high expectations of software this these days and, uh, a buggy prop products will make them quit. Uh, I've been recently going through similar things at the company I work at Descript and, uh, we're having to make a lot of changes culturally to make sure that like what production ready is has a very defined meaning.
Dani: Descript is such a fantastic tool, by the way. One of the other like things that we, that we kind of got wrong, I think around quality is, so we'd hear like, it's like standard startup advice, which is you don't know what's going to happen until users use your product. So we would ship early stuff and just like launch it on product hunt and then a bunch of users would come in.
But then chasing those users to get insights later was actually quite difficult. Like if you've ever used a product for like. One second and then stopped using it. You're not answering emails from the founder of that product. It's really hard to get in touch. And then if you do like, you don't want to disappoint them and you actually don't know that much.
You just, I don't know, you tried it. So it was really, really hard to get insights. One thing we changed for the eighth flavor of jam that we shipped. And I think one of the reasons why it worked is. We were the only first customers of it and we iterated on it for our internal use and we didn't let a single external person use it until it was good enough for us.
This sounds so counterintuitive because our customers are not jam sized companies like like they're large corporations. And, but it turns out that even within large corporations, there are jam sized teams. And so how we use the product wasn't that different than how they were using the product. And in those couple of weeks where it was just like for our own internal use, those iteration cycles were super fast because we knew exactly what was wrong with it.
We learned a lot more and made the product a lot better in that time versus every other time we had like shipped a beta out to users.
Andrew: Did you guys also do like user research stuff after that? Like to like verify what your learnings before we released it to the wider public.
Dani: So what we did for eight one we did for the wee didn't release it to the wider public for a really long time. Instead of like, let's see who uses it. We decided to be more focused and quiet and have a hypothesis to test. And our hypothesis was really basic. It was like people who work at companies that have these attributes.
Who do this type of role should find a lot of benefit with this product and they should use it every week. And so we posted on a couple of slacks and subreddits. We said, Hey, we're building this thing. We're looking for people who match this profile to test it. Like, let us know if you want to be an early tester and not that many people reached out.
But we only needed five and, and so we, we onboarded those five first testers and, and we just kept track of streaks. Did they use the product every week? And that was the only thing that mattered because if they use the product every week, then we have product market fit with them. And so, uh, from there we're like, Hey, we have five happy weekly active users.
Let's get to 10 and then 15 and 20. And once, once we're like, okay, there are 20 people in the world who are using this every week, we decided to open it up to the world, but we still didn't do like crazy product on launch. We decided to be able to like, just kind of quieter. But what actually happened was on that day, we swapped our join the waitlist button for a signup button for the product.
And just randomly, there's this like French YouTube show where they pitch other people's. Startups, it's called like Le Pitch or something. And um, someone pitched Jam. And so that night, like we woke up the next day and there were 200 French people using the product, which was so fantastic. And then the product started growing from there.
Justin: That's awesome. That's, that's such an exciting story. How did you decide, like, why five in the beginning? Was it just like to keep it like meaningfully small and so you could have a relationship with them and like actually learn? Or was it just like, this is just a starting point?
Dani: Well, the goal of the company was to have more than five, right? So it always had to be a starting point. But. It kept things really focused for us, um, and that we could be really, really close to those users. One, one thing that's funny is, you know, at that point, like the company had been through 18 months of pivot.
So they're kind of, it felt like there was like an established company from the outside and those users didn't realize how early they were. Um, but what they did think was really strange is every time they went on vacation or had a sick day, they'd hear from my co founder being like, is everything okay with the product?
Andrew: that's funny. a CEO. What do you think you should do to grow and facilitate like a culture like this?
Dani: So my dream for Jam is for the company to feel like if you've ever done musical theater in high school, you guys are nodding. This is awesome. Did you really
Justin: it didn't do musical theater, but I was adjacent,
so
Dani: just nodding?
Andrew: I know the stereotype you're referencing.
Dani: It's so generative. It's like everyone comes together and like brings together all these ideas and you're and like the whole focus is Is on, let's put on a great show for the people who have showed up. It's like, that's what the joy of building a product is, right? Like let's put on something great for the people who've shown up to use this.
and so that's, that's the dream. I think, uh, I think in reality there, there are two things you can do to make that happen. One is you hire people who think this way, right? And so, um, at Jam I'm so lucky. I work with these amazing, quirky, hilarious, kind, like just. Awesome. Hardworking people, uh, from all over the world, they rock.
But the second is, I think you really have to work on yourself because it turns out like like you, you as a founder can get in the way of a lot of that happening. The more you care about the company, like jam jam took 18 months of iteration just to figure out what we're building. Now we're building a thing that's working and growing every week. Most weeks are record weeks. And there's a part of my brain. That's like. Don't drop the ball like it's working now. Don't let it go, you know And so my tendency is to want to like be involved in everything and control everything But like what a terrible company to work at like that's not what anyone wants And so and so I work with an executive coach and I'm also constantly asking The team for feedback, because I want to make sure that I'm giving them space to go and run and build something that like they truly feel proud of and think is awesome without me, like interfering every second.
So yeah. So hire great people, get out of the way and work on yourself to do so.
Justin: that's great advice.
[00:40:50] The Future of Software and Collaboration: AI's Role
Justin: Um, let's transition a little bit and talk about the future. Uh, so you've, you've raised around, which is, is amazing. Um, so what's your next big milestone for jam?
Dani: We're just getting started. There's so much to do. Like everywhere, software engineers and PMs are going back and forth while building product. Like that is time. We want to give them back to build what's next. So. You should expect from Jam announcements around mobile debugging. That's a huge area for us.
Uh, one day for teams building desktop apps. Um, there's a lot that we want to do with AI. Uh, we're like watching to see LLMs progress and like deciding when it's the right time for us to build like code gen into the product. Um, but I'm really excited about that front. One of the really cool, um. Ways that our users have been sort of like hacking the product to do something it wasn't built to do is they're sort of using jam in customer support workflows, even though today it requires asking customers to install Chrome extensions, which like what a surprising experience if you're like in intercom chatting with a customer support rep and they're like, could you add this Chrome extension to your browser and report this bug for me?
So expect some announcements about how to do that a better way. Um, but yeah, so much to
build.
Andrew: That's interesting that people are using it that way. I could imagine you guys almost like labeling it like a white labeled. Sort of chrome extension where it's like, oh, here's descripts bug reporter.
Dani: Oh, that's so cool.
Andrew: Yeah. Um, yeah, it sounds like you have you guys have some cool plans I'm excited to see where you go with the the AI stuff There's a lot of stuff happening in that area right now And it's just so cool to see like everybody iterate and make all these cool things
Dani: It's what a time to like be in the software space.
Andrew: Yeah, I've, I've heard people saying like, you, you can see both sides of it where some people are like, Oh, AI is here. I don't have to learn how to code anymore. That's like a dead job, but it's like, it's the opposite. AI has enabled like software development to be easier. Like all those hard edges that were there when like we were learning like five, 10 years ago, they're kind of just melting away and you can now just like easily like run free with coding and like not hit any speed bumps.
Dani: It's really exciting. It also really changes. Um, I think who is going to be compelled to be a software engineer because once AI can do like within the file, then you become the architect of the files. If that makes sense. And so the focus of the engineer can be a lot more product driven, like a lot more like design UX and a lot more like architecting systems and thinking about how should, how can we build this to scale and be like reliable and performant and all these things versus like, I need to build a function that does X like, I think a different set of people will be joining software engineering than maybe what's
who's joining today.
Andrew: Yeah, like I can't even imagine doing coding back in like the 70s because it would be like I'd hit a bug. There's no internet. You have to go find somebody in like a library, I guess, to ask a question to like, it just seems so impossible. But now we have like a full human corpus of all knowledge on the internet that you can just query. It's crazy.
Dani: It's crazy. By the way, cool, like 70s, um, anecdote on bugs. So Bill Gates got his first career, like first job in software, um, reporting bugs. for deck, I think, and he reported them on
paper.
Justin: Oh, wow.
Dani: Industry has come such a long way.
Justin: Yeah. it is. I think it's continually amazing to see how far the industry has come. And like, it's just the other thing is like, so one of the things that I like about LLMs in general is just like, you can ask an LLM a question and you're not worrying about being judged. and that's like such a really important thing.
So there's no amount, there's like no number of stupid questions that you can ask an LLM and ever like, you know, get the judgment. But if you think about like some of the early days is like going on these, like. You know, heavy programmer centric forums or something. And, and, you know, even stack overflow, right?
You ask a question and people are like, you know, flaming you for asking it wrong. And you're like, Oh God, I asked him one question on stack overflow and never asked the question again. Right. So, you know, I, I like that, that the industry is becoming softer around the edges and I think tools like gem are the things that make it, you know, make it easier for us to get there.
Just like, so
it's cool.
Dani: That's super cool. One similar, like. Cool use of co pilot I heard. So, engineers at Jam using co pilot. And I was asking like, Hey, what's helpful? Like just curious as a non engineer. And one of the things that I heard is, so there are a couple of people at Jam that they speak English at Jam, but then with their friends and family for the rest of the day, they speak a different language because they don't live in the U S.
And so one of the like rather challenging things as an engineer, no matter where you live in the world is naming variables and co pilot helps them name variables in English in a way that's super like, uh, concrete and clear, and they don't have to like rack their brain for like, what would you call this in English?
I thought that's super cool.
Justin: That is a really
awesome usage.
Andrew: Yeah, so many cool things. Uh, so on the podcast, we always like to, uh, ask a future facing question about like the field the person is in. Uh, and so for you, that looks like collaboration. So like, what do you think the future of collaboration looks like for product
teams?
Dani: There's going to be a lot more collaborating with AI agents for sure. and a lot of AI agents collaborating with each other with no humans in the loop, which is going to be. Wild. but I think that if there are humans using the product, they're always going to be humans working on the product. and, and that, and, and with AI, we're going to be able to ship so much more that actually getting those collaboration loops between people to be faster and more efficient, less frustrating is going to be more and more and more important.
One of the cool things about working, um, in dev tools and like building for software builders is in our world today, software powers. Almost every experience. Like, even if you go to a brick and mortar place, like a hospital or a school, there's still software under the surface. And so actually the faster we can like build new features, the faster the world changes, which is really, really cool.
and so we're going to be able to ship a lot more things as an industry. And if that is true, then we need to be able to do a lot more feedback cycles, like very seamlessly.
Andrew: Yeah, I agree. There's, uh, there's always going to be room for humans. Cause UI, UX, it's not like a science, like even accessibility. It's not a science. You can't follow a formula and get a good experience out in the end. You still need like a person going, Oh yeah, that is good.
Dani: Totally.
[00:47:14] Tooltips
Andrew: Okay, with that, let's move over to tooltips. So my tool tip of the week is a project called classy ink. It is a way to add tailwind to your react ink apps. For the people who don't know, react ink is a renderer for CLI apps, uh, where you can, you can write a CLI app and something that looks kind of like react and it renders in your terminal.
Uh, styling those things is, was of course, relegated to the. The platform primitives for the terminal to style things, which are not, not the easiest things to work with. Uh, so they created a tailwind style approach that, uh, works for the terminal. And that's, that's basically it. You can add tailwind classes.
It looks just like normal tailwind code, but what it spits out in the end, in the end is a terminal app. So I think that's super cool. And I'm excited to see more stuff like this as we merge all the react runtimes.
Justin: That's super awesome. I love that.
Andrew: next up we have
LSD.
Justin: Yeah. So I've had a theme on the podcast of like replacing all my traditional tools, uh, with tools written in rust. Uh, and so here's another one. So LSD is a replacement for LS. it's actually LS deluxe is kind of what it stands for. Not the, not the drug. anyway, uh, it, it like gives a really nice experience.
One of the things that I love that it does is add these little icons that appear to the side, uh, for a file type. and you don't actually don't have to do anything like you can do a nerd font, but like they'll work without a nerd font sometimes. I think, uh, anyway, it's, it's a really nice experience. and it's compatible.
Like all the flags and stuff are compatible with regular LS. So it's not like you have to relearn the tool. Um, I love things like this. This is, this is great. Uh, more rust tooling is awesome.
Andrew: Yeah, hopefully it doesn't hallucinate what files
we have.
Justin: Hopefully not.
Andrew: next up we have the Google Calendar for Slack.
Dani: This one's just as niche as the two that you just shared. This is such a clutch tool. Most people, um, that I talked to don't know about this, but everyone should. You probably use Google Calendar and you probably use Slack and combining them helps your team so much. So if you have this app installed one minute before your next meeting, it Slacks you the Zoom link.
So A plus there. And the second is, if you're in a call, it sets your Slack status to, I'm in a call. And if you're out of office, it sets your Slack status to, I'm out of office. And oftentimes when you're working remote, like, just knowing when to expect someone to, like, circle back with you helps you plan your own, like, next move.
And so everyone on the team using this actually genuinely helps us a ton.
Andrew: It's a good tip. Uh, I've been like, I've been liking Slack's Tinder style approach. It's worked way better than I thought it
would.
Dani: What do you
mean
by that?
Andrew: They have a new feature called Catch Up, where you, instead of like, seeing a long list of posts and things you haven't read, you are greeted with each channel, the messages in it, and then you can swipe left or right to either keep read or keep unread.
And it seems like a silly idea, but it actually works really well for like, working through a bunch of different
channels.
Dani: Oh my god, I'm trying that next. I will report back.
Andrew: next up we have Typefully.
Dani: So, before we used Typefully, we drafted all of the tweets that, you know, like Jam would tweet in a Notion doc, and then we would put it into Twitter, about to hit send, and then we'd be like, oh wait, it's all wrong. It's like, Twitter's one of those things, you just need to see it, like, how it's gonna look.
And so now we use Typefully, it shows us exactly how it's gonna look, and then we can comment on it in line. And so, um, very narrow tool, but really, really awesome.
Andrew: Yeah, we've been using Buffer for the podcast and I, I, I've been liking Buffer and they're about to add threads and BlueSky support. So I'm, I'm a happy customer. I want Blue Sky to take over X.
Justin: Here's to
hoping.
Andrew: Yeah, it seems like a lot of programmers hopped on it recently. Like I've been seeing, like, Steve Klavnik made a post about it. And I've also been seeing some programmers I follow fork the repo to fix some bugs. So there might be
hope.
Dani: That's cool. So this is not a tool you use. This is a tool for thinking what one of the, um, fun and also challenging things about being a founder in 2024 is that the industry is changing around us and what's possible is changing. And so you kind of want to have a quick, good way to stay on top of the latest in AI, because if something's relevant to what you do, like.
Like you want to build something great for your users soon. Um, and so this is a channel that I follow where he does these great, like this week in AI videos. And I just think he does an awesome job.
Andrew: Yeah, there's, there's a lot of people on Twitter that are like, 10 best things in AI this week that'll take your job. And it's, it's fun to see people that actually give me useful tips.
Justin: Matt Wolfe. I don't think I'd heard of him before. This is a really good tip.
Dani: He's awesome.
Justin: I'll definitely check it out.
Andrew: Cool. That finishes it up for tool tips this week, uh, and the episode. So thanks for coming on Dani and talking about jam. Uh, you seem to have a really cool product on your hands and a very vibrant community. So, uh, good luck with
the future.
Dani: Thank you so much. And thanks so much for having
me on. This was
fun.
Justin: Yeah. Dani, just to repeat. So grant, so glad to have you on and jam is such a cool product. And I mean, I love your tips and I love your founder mindset. So definitely, you know, wish you all the best. I'm sure you'll be delightfully successful.
So good luck.
Dani: Thank you so much.