I talk to Dani Grant, the CEO and co-founder of Jam about their browser-based bug reporting solution and how it improves the bug-fixing experience for all those involved in reporting, triage and development. We discuss what challenges that Jam has faced in growing their product to 15k users with a small team of just 7 people and what the future might look like.

We talk about Jira, enterprise bug tracking and continuous engineering improvement when it comes to technical debt. We talk about working as a start-up and the challenges it brings when it comes to legacy architectural decisions as well as ways of improving code quality.

LINKS

JAM website

A link I like about MongoDB:) MongoDB is Web Scale

QUOTES

[01:23] "What we found holding us back is all of the miscommunication and back and forth. Bugs and fixes with engineers." [DG]

[02:11] "A screenshot is such a low-fidelity way to communicate something happening on the web" [DG]

[02:41] "with Jam, We try to get all of the relevant information for a developer all packaged into one link so they have all the information they need to debug right away, no back and forth needed. So it's one click to screenshot or record a video or instant replay, a bug that just happened and we grab a crop screenshot that you take plus the full screen. So all the contact you may have missed, um, plus console logs, fully inspectable network requests, and all the specs of the device and the browser and the operating system and even what your network speed was." [DG]

[04:36] "the first thing we wanted to do was just validate that this was not only a problem that we experienced as product managers at CloudFlare, but that this was a problem people experienced industry-wide" [DG]

[05:51] "we were really inspired. The story of Foursquare, the CEO bought himself a Learn PHP book, taught himself PHP to build the first version, and so we, we loved that story and, and wanted to emulate that." [DG]

[06:31] "we were very excited about the new technologies we could use to solve this problem. So we chose things like Kubernetes and GraphQL, and let me tell you that a couple years later, if there's ever any issue in our product, it is caused by one of the not boring technologies that we chose, like Kubernetes or GraphQL." [DG]

[08:08] "Boring old SQL comes to the rescue again" [RB]

[09:27] "Small team of seven. One thing we learned at CloudFlare is when something is important and you want it to go faster, it's actually better to have fewer people on it." [DG]

[10:51] "to be honest, the product managers, the support team members and the QA testers who are reporting bugs to engineers are just as frustrated. It's a communication problem, so it really has to be solved on both ends." [DG]

[12:36] "actually what we're seeing is that a lot of teams are sending jam to their customers and saying, we can't reproduce the bug you just reported. Please log it with this tool and then we'll be able to action it" [DG]

[18:07] "there's a lot of focus on engineering teams about how to, how to improve productivity, and there's a lot of talk about tooling. There's a lot of talk about collaboration with other teams. These things are awesome but I think that the bug reporting process has huge inefficiencies" [DG]

[20:02] "we realized we needed to build something that would improve the Jira experience from the inside out" [DG]

[24:00] "we feel like we're just getting started. There's so much to be done and I'm really excited about the future." [DG]

there's a lot of focus on engineering teams about how to

improve productivity, and there's a lot of talk about tooling.

These things are awesome but I think that the bug reporting process has

huge inefficiencies and engineering teams, if they were to spend some

time improving that would see

Beyond the investment,

hi and welcome to Loving Legacy.

I'm your host Richard Bown, and this time I have with me Danny Grant from Jam.

Danny, thanks for joining me today.

Thank you so much for having me.

Absolute pleasure.

Now, perhaps you could, for our listeners, introduce yourself a little bit and tell

us what you do and who you do it for.

I am Danny.

I'm the co-founder and c e O of Jam.

We help people report bugs in a way to engineers that

is perfect for the engineer.

What's, what most people don't realize is that while most things in software

development has totally changed in the last 30 years, like is unrecognizable

to us in the nineties, the way we do bug reporting actually hasn't.

All, and it slows teams down and it's especially painful in

today's new remote global world.

Yeah, I'm really feeding that.

I'm nodding my head along as as you.

So you reached out to me because basically you said, I wanna come on

and, uh, you, you said you're a fan of the show, which is great to hear.

Um, so yeah, what gave you the inspiration for Jam and what was your

kind of journey, I suppose, for kind of getting to the situation you are now

Mike.

My co-founder and I started as product managers together at

CloudFlare and on CloudFlare.

We worked at, on a very interesting team.

We were this sort of this skunkworks team, and our job was to launch

net new businesses for the company.

So we had to move really, really fast and get great stuff out the door

right away, and time and time again.

What we found holding us back is all of the miscommunication and back and forth.

Bugs and fixes with engineers.

And in the in-person world, what we would do is we'd repro the bug on our

laptops and then we'd go run around the office until we found the engineer,

and then we'd give the engineer our physical laptop so they could debug

it there, because otherwise how can they see, you know, dev tools?

Um, but when the world went remote, uh, there was no way to do that.

And so that is why we started Jam.

We wanted to build the tool that we needed as product managers.

Okay.

Right.

So until then, yeah, either the, the laptop has to be there, or you could

copy paste, I mean, screenshotting a part of the application that you have now.

So Jam does that.

I understand.

So presumably before, that's another way that you could have made bugs

or you could have just screenshotted it, but it's just not as immediate.

is that, is that the idea?

A screenshot is such a low fidelity way to communicate something

happening on the web in cyberspace.

Uh, there's all this stuff happening in the background that the developer needs

that a screenshot does not encompass even.

Sometimes when people take screenshots, they don't even include

the relevant part of the page.

In the screenshot.

They include the error message, but the developer actually needs

what's around the screenshot.

Like what account are you logged in with?

What version of the software are you using?

What country are you in?

Like what is the language that is shown in like the experiments you're a part of?

Um, so with Jam, We try to get all of the relevant information for a developer

all packaged into one link so they have all the information they need to debug

right away, no back and forth needed.

So it's one click to screenshot or record a video or instant replay, a bug that just

happened and we grab a crop screenshot that you take plus the full screen.

So all the contact you may have missed, um, plus console logs, fully

inspectable network requests, and all the specs of the device and the

browser and the operating system and even what your network speed was

So you've been go going a while.

You've got plenty of users all over the place.

Um, My background is mainly in working in corporate land, and I know what it's like.

You got, everything's locked down, so how does it play in

that kind of scenario as well?

Is it a case if you have to be completely, fully open or

can you work behind firewalls?

Is there, is there even an on-premise solution that you offer?

there's no on-prem, but we do offer like advanced access controls

for organizations that need that.

And actually a lot of the.

People using JAM are at these large corporations because

the problem is exacerbated.

The more people you have on the team, the more countries

different people are working in.

Um, and, and the broader, the surface area of the product, which

more legacy companies just have a really broad surface area that

they've built over the last 20 years.

So an example of some of the companies using Jam are like

Dell T-Mobile, Autodesk, sort of these large corporations.

Okay, so backing up a little bit then.

So what got you interested?

So you like from a software engineering background in the first

place, what was your kind of path, I suppose, to where you are now?

I studied human computer interaction at NYU.

Oh, cool.

Nice.

And went from there to venture capital, became a vc.

Um, my co-founder is, uh, was an engineer turned pm and we met when

we were both PMs at CloudFlare.

So I bring the business side, he brings the engineering side, and

together we're tackling the problem.

Okay, cool.

How do you even start in a, from a product mindset, but

having technical understanding.

When we started Jam, the first thing we wanted to do was just

validate that this was not only a problem that we experienced as product managers

at CloudFlare, but that this was a problem people experienced industry wide.

And so having experience as PMs, we, uh, Said, let's, okay, let's

do a bunch of user interviews.

That's what we know how to do.

And so the first thing my co-founder and I did even before we quit our jobs to

start Jam, is we did 45 user interviews validating that this was a problem.

People faced companies big and small across the industry, um, and.

The emotion that people expressed on these calls, uh, was so palpable, uh, that

we knew we needed to solve the problem.

And actually, um, one of those first early user interviews tried to pay us and

set up a onboarding for his whole team.

And then we had to explain to him that there is no product yet.

We are just researching.

Um, so we really started from the product mindset, but.

Then we need to figure out, well, how do we build a product solution

to a problem that has not been solved yet with a product solution?

And both my co-founder and I, um, knew how to write code.

Um, he is a former mobile developer, so he took a React course

online to teach himself React.

And I was sort of a hobbyist developer, um, and had picked up some skills

and together we built sort of the first prototype of Jam just to

see if there were any legs there.

Um, we were really inspired.

The story of Foursquare, the CEO bought himself a Learn PHP book,

taught himself PHB to build the first version, and so we, we loved that

story and, and wanted to emulate that.

Yeah, because when you're launching a product from.

An engineering perspective, it's always about how, how we're gonna build it.

Um, and it's very difficult to kind of jump outta that mindset and say

no, rather than just exercising what we think is the, the important

muscle, which is building stuff.

How can we actually think about solving a problem ? And that's

seems to be the perennial.

A hundred percent.

And actually, you know, when we were early on the journey, we were very

excited about the new technologies we could use to solve this problem.

Um, so, and.

and, and so we chose things like Kubernetes and GraphQL, and let me

tell you that a couple years later, if there's ever any issue in our

product, it is caused by one of the not boring technologies that we

chose, like Kubernetes or GraphQL.

Yeah, exactly.

Yeah.

Non boring, I think is the, the operative words here because.

You have to think about scale, you gotta think about the future of your product.

So I think it's very sensible the approach you took, especially just learning,

um, a technical solution off the bat.

So do you still run on Kubernetes?

Is that a question I can ask or,

Still use Kubernetes, still use GraphQL.

Um, but it is, it is a constant conversation on the team.

One of the interesting things that I had not realized in our first weeks building

jam is that the technical decisions we made so early on before there was.

Team, uh, stayed for much longer than I would've imagined.

The last remaining of that is when I, when it was like weekend one and I built

a first prototype, I used Mongo DB because it's very easy, it's very flexible.

It's great for prototyping.

We ran on Mongo DB until a month ago, and it was causing scaling issues for

us at our scale because it's a great database and it's great for production

data for an app of a different type, but we just needed a sequel database.

Um, and so those queries were just taking so long.

And when we did that migration, gosh, immediately the app sped up three or

four times and it, it was awesome.

Users noticed it was.

anyway.

The, the Mongo DB hype cycle.

But it's interesting, isn't it though?

Yeah.

Boring old sequel kind of comes to the rescue again, so Yeah.

Obviously then you've got a legacy problem, right?

So you've got like stuff in MongoDB, you've gotta migrate it.

How did you cope with that?

Um, so two engineers took this on in our team.

, they spent six weeks, um, working on the migration they had and at, at the

time that they deployed the migration, they had a runbook of what to do.

They had practiced on staging, um, and they had a runbook of

what to do if things went wrong.

And they had, um, a list of scenarios that they thought could happen.

The whole migration took 20 minutes and there was not a

single bug report after, and.

It and watching.

I was on the slack huddle where the two engineers were during the

migration and they, they just, they worked with each other with such

respect and such like collaboration.

It was like a soccer team that's passing very well.

It's sort of practice for the bigger problems that may come along, and you're

learning how to execute on the smaller problems so that when you have to do

big and difficult things, you can, and I just felt like, okay, we did a big

and difficult thing together and, and.

and now we can do anything.

So it, that was a moment of pride.

And that was pretty recently.

Yeah.

That was one month and one day ago.

Okay.

Congratulations on that.

So how big is the team then now at Jam?

Small team of seven.

Uh, one thing we learned at CloudFlare is when something is important and you want

it to go faster, it's actually better to have fewer people on it, not more.

And so we really live by that.

We're very inspired by Instagram.

There are 13 people, they were 13 people at a billion dollar valuation.

Um, my dream is for a jam to be 13 people at a billion dollar valuation.

Okay.

So what does the future then look like?

So you're very excited to get almost to 15,000 users.

That's brilliant.

Are they all paying users?

Uh, how does the licensing model work?

we we're students of CloudFlare, so large, free tier.

Um, we love that.

We, we love that, uh, we can build something that everyone can use, um, no

matter their ability to pay and then build features on top that only companies need

and companies have the ability to pay.

Um, we are so determined to.

Bring bug reporting out of this sort of archaic manual, outdated phase that

it's in and change it, uh, modernize it, bring it to the 21st century of how we

do things in software development today.

Um, wherever there are bugs we.

trying to build product solutions for that.

So it sounds like yeah, you're very aligned then

with the developer experience.

I mean, obviously it's great from a product, um, experience as well, from

a, from a company's point of view, but the emotional words that you're using

there about kind of pain, it seems to be aligned very much with the things

that developers will feel when they are confronted with the bug report, which

doesn't have enough information in it.

Is that fair?

Uh, yes.

And to be honest, the product managers, the support team members and the QA

testers who are reporting bugs to engineers are just as frustrated.

It's a communication problem, so it really has to be solved on both ends.

Okay, so the fee, showing that feedback loop again,

which is the important part of any development or product process.

So what happens then with these?

Cause I've tried the tool out and I really like it.

Um, but I'm just on the free tier of course, but so what's the value add, I

suppose then for the, for the next stage?

What do you get?

Most of the value add, um, under the paid tier has

to do with access controls that companies of a certain size need.

We want to give the value add away for free, which is, spend less time

debugging for engineers, spend less time manually reporting bugs for PMs,

work together better as a productive, fast moving team for everyone.

Um, and then under the paid tier, we have advanced access controls,

privacy, security, um, that only corporations, uh, are really asking for.

Okay.

So yeah, that's the bit I'm interested in then.

So, cause I know there's a couple of sites, for example, won't

let you record so Google won't let you record stuff on it.

Is, or is that something that's configured within the tool itself?

How does that work?,

in the extension, we allow people to set all sorts of settings,

like, um, if they want to disable jam on any site, uh, for any reason or

if they want to do the opposite and enable it only for specific sites.

Um, engineers especially have all sorts of different preferences around

their browser and extensions that they use, and so we just try to accommodate

that and make everyone feel really like in control when they're using.

Okay.

But would this be suitable also for customers?

So would you.

Providing it to customers or would a, um, a solution provide it for customers?

When we started, Jam, we wanted to fix the internal

communication problems between like, Product support, QA and engineers.

But actually what we're seeing is that a lot of teams are sending jam to

their customers and saying, we can't reproduce the bug you just reported.

Please log it with this tool and then we'll be able to, um, action it.

And so we're really excited to see that happen, but definitely are excited

also in the future to build something more focused towards customers.

Okay.

And it integrates with other, other tools as well, so kind

of, can you use it with Jira or.

we integrate with all the major issue trackers.

So, for example, if your team uses Jira, we wanna make it really fast

to get all the relevant debugging information into a Jira ticket.

So Jira, Asana, GitHub, slack, uh, wherever you are reporting bugs, uh, we

want jam to make that faster and better.

We have this idealized.

Version of, of what might happen, which is like someone spots a bug,

creates a Jira ticket, engineer fixes it, but nine times out of 10,

that's actually not what happens.

Um, typically someone reports a bug and they want to get more information

before they create the Jira ticket.

So they put something sort of vague, um, into a Slack channel.

Like, um, login isn't working.

, the vagueness of any issue creates a lot of fear because it sounds like

a big deal without more details.

And so a lot of engineers will see that message and be like, okay,

I need to stop what I'm doing on and focus on the critical thing.

And because there was no sort of, um, orchestration, many engineers

will now stop what they're doing to focus on this versus being

like, one person picks it up as a.

From there, there's a lot of back and forth with the original bug reporters.

These engineers are trying to repro it on their machines.

They're not seeing it.

They're asking back and forth, what environment are you in?

What browser are you in?

What device are you using?

Um, like c can you send a screenshot?

And ultimately, um, if, if they're able to resolve it with that, great.

But then ultimately they usually need to hop on a call with the.

Bug reporter and everyone's busy.

So you're orchestrating schedules and maybe at the end of the day to

contact, switch back to this and get on a call with a bug reporter.

And then like, um, they share screen.

You have to help them like open up dev tools and click where it says console,

click where it says network and like guide them through something that's.

quite confusing, um, and reproduce the bug.

And at the end of the day, it could have been something like, oh, the person had

the wrong password, but that front end error wasn't bubbled up to the user.

So login wasn't broken, it's just a front end error was not bubbled up.

And so, and it's just the, and that's just one bug, and it's something that

could have been identified and fixed in five minutes and instead took

an afternoon for several engineers.

and for that to be the case in 2023 when we have amazing other technical tools

and software development has come so far.

Um, is, is, is bunkers.

Good word.

Um, yeah, I'll contend that a little bit because it depends where you work,

I would say as well, because sometimes.

You can't get a bug looked at by a developer without going via po.

You know, you can't look a a, a bug looked at even in the same day, week, or month.

No matter what it is, no matter how well it's reported, it's not re

because it isn't the process, right?

So sometimes it's a case of there will be a lot of information added to a ticket

maybe in, I don't know, ServiceNow, before it even gets to Jira, which will then have

to be translated into a separate tool.

So whilst I get that, it's great if everyone's moving at that kind of.

It sounds a little bit kind of chaotic, I'd say as well.

That kind of pace.

Then, then I can get there.

There's a real need for it there.

However, it might Yeah.

Where I've worked, it's kind of like you can't get something looked at a, a

developer because they're not available

the, the two things go hand in hand because of the intense amount

of time it currently takes engineers to solve even basic issues because

they're not given all the info up front.

Um, bugs are just taking longer to solve, which means you can solve fewer issues,

which means customers have to suffer with more issues in the product for longer.

And so by streamlining the process, you also are able to solve more

bugs, which is really exit.

Does it help you also categorize the type of bugs as well?

So is there anywhere or would that come in something like Jira or Azure,

Azure DevOps or something like that?

Oh, uh, this is something we want to build so much, um, which is.

, you use jam to record a bug right on the webpage.

So we have a lot more information than Jira has.

And so, uh, we've been thinking about ways we can help with de-duplication,

categorization, um, and also routing because a lot of the, um, inefficiencies

around bug reporting is like someone reports an issue and they just

like route it to the wrong team.

Um, anything that you can avoid to have de duplication,

especially in Jira, because that's what a lot of people's time is spent

doing, you know, is looking at either.

Content in Jira, which has not enough information, or it's something that has

been reported before or it's something that's been there for two years already

and should already been thrown away.

. Could you then also, um, Not just categorize, but also give like

a time series version as well.

Like kind of you, almost like an observability platform where you

could say these bugs are being pop, are popping up at certain times.

Is there any way that you can mine that information from the tool?

That's, that's so cool.

We're actually working on something related to observability, um, that

we'll announce in a couple weeks, uh, that I'm really excited about.

If the goal is give developers all the information they need upfront, then

doesn't that need to dig deep into the stack and, and help them see what the

error was across the infrastructure?

So we're working on something there

You know, uh, there's a lot of focus on engineering teams about how to,

how to improve productivity, and there's a lot of talk about tooling.

Um, there's a lot of talk about collaboration with other teams.

These things are awesome.

Um, but I think that the bug reporting process, uh, has huge inefficiencies and

engineering teams, if they were to spend some time improving that, um, would see.

Beyond the investment, like, uh, I, I just think it's, it's one of those neglected

areas that with a little bit of effort on, um, has a huge impact, um, both for

the speed and productivity, but also the collaboration and trust within the team.

Definitely.

But how do you fix that?

That's the thing.

I mean, because everything is so embedded, the way that we work things, we've,

the firms have spent a lot of money, billions, probably hundreds of billions

on digital agile transformations.

We've had Agile coaches, we have had Scrum, we've had DevOps, what all this

kind of stuff's been going on, and we ended up, we've got a fixed tool set.

You know, it is like this is the core of the problem.

We put things that put a sticky into Jira or into Azure, Azure, DevOps or

whatever, and then we forget about it.

So how do you kind of flip it around and.

A situation where people are kind of, yeah.

Cause I wanna say they're fast.

They're, they're solving bugs faster.

But that's kind of not the point.

We don't wanna have bugs in the first place.

We wanna have good software.

So how do you kind of flip it and like, not make it about bugs and

not make it about stacks of bugs, but make it about a good software?

It's, it's funny you say that, like the tools and processes are

stuck in place and, uh, we've already invested as an industry so much time and

effort and resources on, um, on Agile and, and these new practices in DevOps.

Uh, when we started Jam we started with a different solution to solve the same

problem, which we thought we were going to be able to replace some aspects

of Jira, um, with something better.

But what we found at that time is there was a lot of resistance to that because

it's like, well, you already used Jira, so why take a risk on something else?

It is good enough.

And so we realized we needed to build something that would improve the

Jira experience from the inside out.

Where at the, you know, whatever process you are using, um, to run your team, at

the end of the day, you get these tickets.

And the tickets are the things that you're working on.

And if the tickets are of low quality, uh, It makes the job much harder.

And so we wanted to build some, like something very lightweight anyone can

pick up and start using that would improve the quality of each one of these tickets.

Um, but what you're saying about it's, it's not about, uh, fix

fixing bugs so much as it is about having a great customer experience.

Um, . I, I completely agree.

Um, I think you have to do both.

As a, as a remote startup, we spend a lot of time thinking about how do

we move faster with high quality?

Because as a startup, speed is the biggest advantage we have against giants.

And so we really care about moving really fast and still delivering great product.

And so we've, we've figured out a couple things that work really

well for us, um, that I think could work well for other teams too.

Um, one is a culture of code comments.

, a lot of issues arise when an engineer is stepping into a file they have

never been in or a part of the code base that they're unfamiliar with,

and so they make a change without understanding what are the ramifications

across a complicated product.

But if, if there's a culture of code comments where engineers don't

approve PRS unless there's sufficient context given, uh, and each new part

of the code, um, that really helps engineers, uh, keep the quality.

And move faster because they can get context, um, really quickly when they

step into a new part of the code base.

Another is doing an on-call program.

Uh, we do it a bit differently than other teams.

Most on-call programs, there's an engineer who is expected to be

on-call in addition to whatever it is that they're currently working on.

We do it differently where when you are on call, you are only

on call, and so your job is to.

Make improvements that you want to see unless there is something

urgent that comes up or you need to help someone release some code.

Um, and so that way there's always one person on the engineering

team, which for us is meaningful.

It's 20% of the engineering team, um, that's working on sort of background

fixes, cleaning up technical debt.

And then the last thing is something we found is the.

There is a misconception about moving fast, which, uh, which people think

if you stop and take too much time to plan, you won't move very fast.

But the not moving very fast that we're afraid of is like

deadlines slipping by weeks.

It's not taking an extra day to plan.

and we found that if we spend about half to one day before starting to write

code on any project planning how it will work and give having a round of feedback

with the engineering team, what are some ramifications we may not have thought of

and half to one day at the end, cleaning things up, we found along the way, then

we don't have to stop and do a bunch of technical debt, clean cleanup later.

And that really helps us.

There will be bugs and having a streamline process to report and fix them is super

important, but also having practices that support that, um, is, is important too.

So would you describe then Jam or the mission of Jam then, as being

like kind of, not just supplementing the existing tools there, but hopefully

replacing them in some ways as well?

I mean, the.

We're, we're in love with the problem, not the solution, if that makes sense.

Um, and so, uh, we will do whatever it takes to modernize the communication

between all the different cross-functional teams of an organization and help

engineers fix and catch issues faster.

Well, I look forward to hearing about the journey as

well as you, as you go forward.

So sounds like it's been very exciting ride so far.

It's only gonna get more exciting.

So what are the plans for the next, so you've got something

exciting to announce soon.

Looking beyond that you've already touched on some potentially quite

exciting things for the future, so you're kind of, you have large ambitions.

Is it fair enough to say that?

Yeah.

Um, we.

Uh, we were talking as a team, uh, the other day and someone was

like, this, this is very ambitious.

And, and, and then we're like, yes, but everything we do is,

you know, needs to be ambitious.

Um, we feel like we're, I mean, we are just getting started.

There's so much to be done.

Um, and I'm really excited about the future.

We have, uh, a really special team.

Uh, they are awesome.

They care, uh, they work so well together.

Um, and, and they're so supportive of each other and I can't wait

to see what we can all do.

Awesome.

Well, I look forward to seeing it too.

Danny, thank you so much for joining me today.

It's been an absolute pleasure talking to you and best of luck in the future.

Thank you so much.

Thanks for having me on.

thank you for joining me today.

I hope you enjoyed this episode.

It was lots of fun to make.

If you would like to come onto Loving Legacy, then please

feel free to get in touch.

You can find me via social media bownrw on Twitter or via LinkedIn

or via my website, richardwbown.com.

I'd love to talk to you about anything to do with software delivery and or

something to do with legacy systems.

Of course.

Until next time, this is Richard Bown saying goodbye and good luck.