Subscribe
Share
Share
Embed
If you’re a product engineer, engineering manager or PM, we all know how it goes: you go through tons of meetings every day, and only when they end is when real work starts. PRDs, tickets, specs, follow-ups — all the artefact work nobody sees you do. And by the time you’re done, the next meeting is already starting.
One of today’s guests has a name for it: the infinite workday.
And that’s exactly the problem today’s guests set out to fix. Mark Barbir and Sanden Gocka are the founders of Earmark — an AI meeting note taker that turns live conversations into shippable work in real time. We get into how they actually use it day to day, how it helps product teams, where the new bottleneck of product work has moved, and what it looks like when an idea you just said out loud turns into a working prototype before the call ends.
If you’ve been hunting for AI tools for product managers that go beyond generic summaries, I’m walking you through them, and you can decide if it’s worth trying.
GUESTS
Mark Barbir and Sanden Gocka are the co-founders of Earmark. They previously worked together at Mindbody, a large enterprise SaaS company with a 400-person delivery organisation, and later crossed paths again at ProductPlan, where Sanden was an engineering manager and director. After years of watching product and engineering leaders drown in meetings and artefact work, they set out to build the tool they wished they had: an AI meeting assistant that generates the artefacts a conversation implies, in real time, while the meeting is still happening.
Mark’s LinkedIn: https://www.linkedin.com/in/markbarbir/Sanden
LinkedIn: https://www.linkedin.com/in/sandengocka
Earmark: https://www.tryearmark.com
TIMESTAMPS
00:00 The Invisible Second Shift: PM Meetings Problem
01:49 The Infinite Workday: Why PMs Work After Hours
07:49 Vision Pro Pivot: From Presentation Coach to Meeting AI
11:35 Why Vision Pro Failed (and What They Learned)
14:13 Engineering Translator Card: Understanding Technical Talk
16:00 Specs, PRDs & Code in Real-Time During Meetings
19:00 Make Me Look Smart: AI for Shy PMs
28:32 PMs Are Now The New Bottleneck
31:56 Dog Food Success: How Earmark Built Earmark
40:09 How to Get Started with Earmark
REFERENCES
Cursor: https://cursor.com
Linear: https://linear.app
MacWhisper — the local speech-to-text tool Sanden used in his early hacked workflow
AssemblyAI (referenced in the co-marketing case study story): https://www.assemblyai.com
CONNECT WITH PRODUCT ENGINEERS
Host: Peppe Silletti
LinkedIn: https://www.linkedin.com/in/peppesilletti/
Product Engineers:
Website: https://productengineers.com
Discord Channel: https://discord.gg/4sMtRNSgU4
Share this episode with a teammate who is still writing their PRDs at 10pm.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
Product Engineers is the podcast about the convergence of product and engineering in the AI era: what's breaking, what's working, and the craft of doing both well.
Real work gets pushed to the edges, usually early in the morning before people get on Slack, late at night when people go home, and on weekends. We, we describe it as this idea of the infinite workday. You never stop.
We'll be brainstorming about a new feature. Earmark will be gathering that context, immediately push it into Cursor, we'll get a prototype and be able to see it during that meeting.
We can't imagine now not having unlimited task agents running in the background as they converse.
What's really interesting is the new bottleneck is now moved from engineering resources to engineering time to actually back onto product for review. The Product Engineers Podcast. Wow.
Welcome to the Product Engineers podcast, where I explore the convergence of product and engineering roles in tech. If you've been working in a product team, we all know how it goes.
You go through tons of meetings every day, and only when they end is when the real work starts.
PRDs, tickets, specs, follow-ups, all the stuff that nobody sees you do, and by the time you're done, the next meeting is already starting.
One of today's guests has a name for it, the infinite workday, and that's exactly the problem today's guests set out to fix.
Mark Barbier and Sander Goka are the founders of Earmark, a tool that turns live meetings into shippable work in real time.
We'll get into how they actually use it day to day, where the new bottleneck of product work has moved, and what it looks like when an idea you just said out loud turns into a working prototype before the call ends.
I'm walking through it with them, and you can decide if it's worth trying or not. Enjoy. Welcome to the podcast, Mark and Sander. It's great to have you here. I'm very happy to be interviewing you today. Thanks.
Likewise. Yeah, thanks for having us, Pepe. So I've been thinking about, you know, what you're doing with, with Earmark, and everything brings to this, to this problem that product managers have, for example.
So they, they talk about this invisible second shift, and so they, they spend all day in meetings talking to stakeholders or, like, to customers and making decisions.
But yeah, then the real work actually starts after that because they need to build all, all, all the PRDs and tickets and updates.
So could you, could you take me back to a specific day at one of your prev- previous companies where, where you felt this pain the most, and what happened in those meetings and, like, what did it, what did you do at the end?
Yeah. So Pepe, like, for, for Sander and I, we came from a company called Mindbody, which is kind of like large-scaled enterprise SaaS. We had a delivery team of almost 400 people, right?
And, uh, that was just the engineering group. Um, like, the larger the enterprise scale, the higher the complexity, the higher the meeting volume, right?
That also requires a whole slew of artifacts that are created from them. Um, in, say, any given Friday, for instance, right, we would have portfolio reviews, right, in terms of how our teams are performing.
We would have feature kickoffs. We would have retrospectives. We would have incidents that we're managing, post-mortems from those incidents that we're managing, right? Um, and this is just any given day, right?
Sort of the state of the union of enterprise life.
Um, and in that, when you think about just, just pain, right, this idea of like, okay, we're gonna go through all these meetings, um, and we have to create deliverables from them, but we're gonna do this after these meetings.
But the, the issue is that, you know, the next day you're in the same volume of meetings, and the day after that you're in the same volume of meetings.
So what end- ends up happening is, uh, real work, right, gets pushed to the ends or the edges, usually early in the morning before people get on Slack, late at night when people go home, and often on weekends.
And the condition that, that, you know, the way we describe it is this idea of the infinite workday, right? You never stop.
You're just kind of, you know, state of the union is fight or flight, and you're just kind of going from one ceremony to the next, wishing you could execute the work that you have to execute. Right.
So the, the, the, the famous joke about PMs or, like, having the, the calendar full, like, they, they usually are very proud of the calendar, like, with all the, the meetings. Yeah. So it's, it's actually true, right?
[laughs] Cool. So I can imagine there was a moment, maybe a, a meeting that w- that went kind of sideways. What, what did you say, like, to each other afterwards? Because I know you've been working together.
You know, for- Sander, you wanna take this one?
For me, um, I was an engineering manager, um, and kind of like slash director at Product Plan, and this was kind of after our gig at Mindbody, and really trying to manage kind of the, uh, the maker/manager schedule, um, because I still had a couple teams that I owned.
I still had one-on-ones that, that I was doing, but I was also building at the same time, and that was just really struggling.
We went through some acquisitions, which, which also made, made things a, a little bit more, more challenging.
What's funny is, like, you know, we were kind of working through those motions and we were just like, "Hey, you know, with everything that we've seen with this AI going on, like, it has to...
[laughs] Like, we can't be, like, just kind of stuck in, like, kind of like drowning in meetings and, like, doing all of, like, this work after work."
And, like, Mark and I, we've always wanted to, to build something together, so we're like, "Hey, we've both been in software, we've both been in product for such a long time.
Like, we feel like we're just constantly [laughs] playing catch-up on a day-to-day basis."
Like, we didn't know what the solve was at that time, but we're like, "Hey, let's just try something," and then that's what we did. Nice.
So back then, I mean, e- even before starting to think about Earmark, have you tried, like, exploring other solutions, like, for, for your own work?
What, what did you try to, to kind of solve this infinite day that you were suffering from? Yeah. So solutions back in the day, Pepe, were, were, I mean, it, it, it's crazy how, how archaic it was, right?
But it would be pen and paper, right? Notepads.You know, analog solutions.
And then, you know, and then having that one text edit file, like always on your desktop, that's sort of this running scribe doc, right, that you would leverage. Um, and this is sort of pre-LLMs, right?
Where it's like, you know, like, like we're, you know... What are the data points of, of work, right? So that's like one body of, of, of activity.
And then, like, when we were in the enterprise, that's when Zoom started producing AI features, right, like generic summarization, and we would get emailed or Slacked these generic summaries, like, after these meetings, like, concluded.
But the summaries were really low value. You know? Like, oftentimes they were kinda tone deaf, you know, to whatever the requirements were of the project, right, the nuance of the project.
And oftentimes, since they're very general in terms of use case because Zoom has to support all teams, [laughs] like, they really didn't un- understand, like, engineering work, right? So, like, that was suboptimal.
So, you know, so you have, you know, analog artifacts to digital, and then the way we would solve it is just trying to will it after hours, right?
So this kinda goes back to what I was saying before where, um, you know, you, you, you would try to cr- the only time you could create those artifacts is when there was actual time for deep work or calm, and that was usually when nobody was bugging you, right?
And, and again, that goes back to the time box of, okay, if I'm gonna create a great requirements document, right, or some great go-to-market documentation, deep work has to happen in quiet, at quiet time.
And when is that? It's usually when work isn't happening. That was how we solved it.
I, I think, I think for me, um, what was really interesting, a- and kind of shared this with Mark, is at the time there was a, kind of an app that still exists today, it's called MacWhisper, which does local speech-to-text.
And I would actually run...
Like, I would create just audio recordings o- of meetings and run it through that process, and that process would take a considerable amount of time, um, like maybe like 20, 30, 30-ish minutes.
And then I remember running it through, I think it was like Claude, like 2.1 [laughs] at, at, at the time.
But those pieces just kind of like strung together and then having like bespoke artifacts that come out of that, like, that was really valuable, but I'm realizing, like, okay, there's a ton of manual work in terms of like, all right, now I have to move the audio files to then transcribe that and then take that and then paste it in and then paste all of the relevant context in there.
And that would still take like, you know, an hour just, just kind of like synthesize all those meetings still after the fact. And it was kinda like, you know, is there something here that can be automated?
Um, so th- I think that was kinda like the first glimpse. Yeah.
And kinda related to that, Pepe, um, like a lot of our, our customers and prospects we talk to have these really interesting sort of hacked workflows where they'll take a transcript from say, you know, a Zoom AI call, um, and then take that transcript, copy, paste it into their local, and then try to extract all the artifacts of work, you know.
So folks are actually doing activity that's very similar to this, but doing it in a way that's like less than optimal. You know?
Like, everyone has like this like workflow hack that they're all leveraging, and it seems that, like, most folks are using transcripts to, to create all sorts of things afterwards. Yeah, yeah.
Yeah, it's not, it's not very user-friendly, I can imagine. Cool. So, so you, you had, you've, you had this problem, and you started to look for a solution.
I was, I was reading that actually before Earmark existed, you, you were building a presentational coaching tool for Apple Vision Pro, right? Yeah.
And just, just if you could walk me through, like, what, what the product was, you know, what, what you, what you learned building it, and maybe most interesting, like the moment you realized you were solving the, the wrong problem, problem, yeah.
So this goes back to what Sandman was saying. We just wanted to build something, you know. And for both of us, we've had, you know, startup aspirations over the years, and we've kinda gone through multiple models.
I mean, like there's quite a few, right? Probably half a dozen. [laughs] And when the Apple Vision Pro first came out, like we were super excited, right?
Like, you know, AI, you know, b- basically Apple coming up with their interpretation of what a great AR or VR experience was gonna be. You know, we're both, you know, Apple aficionados, right?
You know, we love most of the hardware and the solutions they create. So the opportunity for us was like almost an, an intersection of like new technology, right? A new wave was coming.
We were really passionate about, you know, helping product engineering folks be- become better communicators, 'cause this is another problem at enterprise scale where you kinda realize like how inefficient we are as communicators often, [laughs]
or like how not so influential we can be. You know, it's kinda just how we're made as, as, as, as technical people oftentimes.
So one, one of the concepts we worked through was this idea of like a, a presentation coach, right, or a communication coach where, you know, with the Apple Vision Pro you could, you know, improve your skills and your communication skills, specifically product engineering leaders, by preparing them for rehearsal or for, say, any, any, any sort of pitch they're doing or any, or con- or any sort of communication that they have to, that they have to do, right?
So what we would do is we'd actually model like conference rooms, right, auditoriums.
There would be like, you know, Google Slide, you know, sort of, sort of widget where you could cycle through slides as you're giving presentations. The system would provide real-time feedback.
Um, as you're going through a presentation rehearsal, you know, it would prompt you to breathe, you know, or speak up or, you know, it'll... And it would provide feedback post, you know, your rehearsal.
Um, and we went through a lot of, you know, discovery with that solution. You know, it turns out that, you know, it turns out that like people don't really prepare for presentations.
[laughs] So, you know, so we, we kinda did this, this heavyweight lift, you know, created this wonderful solution, right? It was, it was, it was fully realized, you know, uh, in a lot of ways.
So, you know, we realized that that solution wasn't really gonna solve for much because if you think about daily use, right, people aren't... And, and that's one thing too.
If you're preparing for presentations, you're probably not doing it daily as a ritual, right? It probably happens for these high stakes sort of ceremonies. Maybe that happens like once a quarter, right?
Maybe once a month. So, you know, the frequency piece wasn't there. And that was a key learning for us, right? And then we, we- then we pivoted from there.
And I mean, I, I think also at a certain point, Vision Pro wasn't really also adopted by people. That probably that also was a problem. Correct. It was pretty expensive.
I remember in the be- in the beginningWhen, when we started, we, we, you know, we, we didn't know, right? So, so we actually, you know, like we were very early, you know, with, with the, the adoption curve.
And we actually spent a lot of time at, at, in Cupertino working with pre-release devices. So what we were doing was essentially we wanted to be part of the, the release wave, right?
So, so the TAM piece, right, the fact that the, the Apple Vision Pro wasn't compelling from a market perspective wasn't something that we understood until, you know, until, until it came out. So yeah. Yeah.
I, I've seen some videos on, on the internet, like there are people actually using it in, in public spaces, like on, on trams and things. It was fun to see, like, [laughs] that they're just moving their hands in the air.
Yeah, yeah. Or, or even go- going back a little further, you know, staying in the night, you know, or old enough to remember the Google Glass wave, right?
You know, it was the same sort of, of, a, a sort of, sort of phenomenon in the Bay Area where like, you know, these, like all of a sudden people are like wearing Google Glass.
You go to a conference, everybody's like rocking Google Glasses. And, and there's a, a term of endearment that we had for them. We called them Glassholes.
So I don't know what the equivalent is for Vision Pro users, but [laughs] So what, w- w- was there something you built for the, the Vision Pro that you ended up bringing into HearMark? Or was like a, a clean start?
You know, it was- Do you want to go for it? Yeah, it was, it was, uh, it was pretty much a clean start.
Um, what's really interesting with the Vision Pro solution is that we thought that prepping for meetings or being able to be prepped for meetings would actually help kind of with s- kind of the meeting problem that, that we had, just being overwhelmed.
Um, the elements that we brought in were just kind of the real-time feedback, so completely different. Like how Mark was mentioning in the Vision Pro, our real-time feedback was around your pace, your pitch, your volume.
Um, but we've been really into real, real-time feedback for a long time, and that, that's what we actually brought over to kind of the very first iterations of, of HearMark, where during, during the meeting you would almost get these kind of like these little prompts or like suggestions of things that you could say during that meeting.
And that, that's still something that has translated today. I would say that that would be kind of the, the one main thing that has kind of stuck with us this whole time.
What was the thread that connected these two products? Because it's kind of a big jump, right, from the Vision Pro to software as a service.
As Mark alluded to, yeah, we, we did a bunch of discovery calls with the Vision Pro, and
I th- I forgot who said this, but there was one person who gave us this feedback which really stuck with us, which was that we're currently building an unproven product, which, which was our startup, on top of an unproven platform, and those, those two are, are really difficult to, to solve.
So we almost were like, "Okay, like how can we take what, what we know, like is a problem, the, these meetings and this real-time feedback, and translate it to something that is, one, daily, and then two, can be used by anyone, anywhere?"
So that's kind of how we transitioned over to kind of focusing on meetings to start, um, as well as we just changed the platform completely to like, okay, what does everyone use? Everyone uses the web. Okay, great.
Can we build a solution that works both on Mac, on, on Windows, and also, also on the phones and then kind of like start broad and then kind of figure out a way to then kind of dial that in from there?
So that was our big turning point for that jump. Right. Okay, so let, let's get a bit more practical about HearMark. So you, you started building it, and now it's, it's actually live and people can use it.
Could you, could you kind of walk me through like a real meeting? So maybe you're a PM or an engineering manager, and I am on a call with my team. I'm talking about a feature spec or something like that.
Um, what's, what's happening behind the scene? How does HearMark works, and what do I have to do when, when the call ends? What's out there for me? Yeah. So I can, I can walk you through a, a, a typical case.
For one, we love to dog food our own products. We, we actually use HearMark daily. We think that's, that's also really important.
Plus, kind of our, our mantra is like i- if we could solve our own problem, then I think chances are [laughs] someone else might have that same problem.
So one, one of the ways, you know, that I like to use it is actually during the meeting I'll have a particular card open.
I like to call this kind of the engineering translator, where if I'm talking to someone that's really technical and maybe they say something that's kind of over my head, what it does for me is it, is it essentially it just kind of retranslates what was said into kind of language that I understand.
And what's nice about that is especially when I was kind of running these teams, maybe I'll have to like kind of like interrupt the flow or like ask a clarifying question, is that this would allow me to kind of keep on par or keep on pace with the conversation without having to interrupt or without feeling imposter syndrome.
So that's kind of an, an example of using that live. And then using it kind of after the fact, so say a meeting ends, we still do have kind of like your basic meeting summary that we'll output from that.
But going beyond that in terms of actually getting work done is we have these templates that can generate just kind of like engineering specs, uh, for you.
So essentially, okay, I've talked about a couple different engineering items in this meeting, so pull out those engineering tickets and then push those directly into, into Cursor or push them into Linear so I can get them into my issue backlog.
And if I take it one step further, like my fave use case is actually doing that step that I just mentioned after the meeting but actually doing it in the meeting. So we'll be brainstorming about a new feature.
HearMark will be gathering that context, and we'll immediately push it into Cursor. We'll get a prototype and be able to see it during that meeting, which is really cool because then we can riff on it from there.
Previously, that would've been like, "Okay, let's follow up-"Let's go into another meeting. This just allows us to get so much more done, like, in a meeting.
Mark, I'll, I'll let you highlight any, any use case that you want to. Yeah.
Well, Pepe, I think a lot of what we see is just, like, almost, like, behavioral change, you know, where one of the core tenets of Earmark is being able to have unlimited task agents running, like, as conversations progress.
Um, so one way to think about it is like, you know, so you have your, your PRD generator, your feature spec generator, your linear ticket generator taking place, you know, updating in real time.
But I can have as many agents as I want, and for our users, what's really interesting is they, they can't imagine now not having unlimited task agents running in the background as they converse. Right.
So that's really sort of, like, the big unlock, right? It's like I can just sort of delegate this whole part of my brain, right?
Have confidence that the system will, will, you know, make sure nothing falls through the cracks, uh, give me an artifact that has level of quality that isn't heavyweight.
But, like, the idea to Sandin's point is cycle time, right? Like, if I can execute that work in a 30-minute increment or an hour increment, that's a lot better than, you know, do the hour, right?
And then after my meeting workday is over, create those artifacts after the fact. Like, we, we wanna make sure the cycle time is, like, right there if, if, if that's... if, if, if possible.
So when, um, um, Sandin, you said about translating, like, this is very interesting. So for example, let's say I'm a PM, I'm not very technical.
So does it mean that while the engineer is talking about all this technical stuff, um, here Mark can, can help me understand what the person is saying, something like that? Yeah.
How does it work as translation in practice? Yes. That, that, that is exactly r- correct.
So maybe there's, like, an engineering term or phrase that, that is used during that meeting, and what's really nice is just, you know, almost seeing it, um, in a representation of a, of a card and seeing it stream in and it basically just almost defines what that is.
Of just defining it, I think where it really shines is, okay, since we know about your context, not only can we define what it is, but, like, this is how it's related to, to what was, what was discussed.
And what I found is, like, that, that enables kind of PMs, or even myself when talking to folks, especially if there's not something that I understand, to be able to, you know, contribute to the conversation. And y-
in a like, in a likewise use case, by the way, we do have one template that's kind of make me look smart, and almost like
maybe I'm more passive or reserved in the conversation and I need help kind of joining, joining in.
And so this one kind of gives me some questions, maybe probing questions that, that I can ask kind of related to that questions.
And this has kind of helped some people who might have that imposter syndrome, who are relatively shy speaking up, myself, just to kind of get out there and, uh, we, we've had, we've had some, some good feedback around that one.
Right. Yeah.
As, as an engineer myself, I think something that would be cool is, like, if I could l- maybe see more about the context behind what, like, the program manager is talking about, maybe like a customer decision or something like that.
Is that possible? Can you kind of connect external sources so that the information can be fetched from those sources? Yeah. That is actually something that we are working on currently.
Almost like connecting your Slack channel, say if you had, uh- Okay... your Feedback or Dovetail or whichever tool that you're using to be able to understand, like, hey, like, we're brainstorming this problem.
You know, is this really a problem? Like, as you're talking, can it pull in a bunch of customer quotes from this? So almost you can validate it right there, or does it be like, "Okay, no one, no one has mentioned this.
This is, like, brand-new idea"?
[laughs] So that kind of goes back to that real timeness during your meetings and, you know, w- without that, that's something kind of to, to Mark's point is, okay, someone has to actually do that work.
Someone has to do that research. Whether that's an agent or whether that's a human doing that, that's still gonna take place after the meeting, and that's still gonna require a follow-up.
But if that could be done within that cycle time, that could just help teams roll a lot faster. Yeah.
Well, there's one, you know, one exception where if, if, if, let's say those customer calls took place within Earmark, that conversational context is in the system.
So one thing that's really cool about the system is I can actually go back to any conversation and get instant recall or search any transcript and get instant recall.
So if I needed, like, a great customer quote, you know, from last Tuesday, I just wish I knew what this person said, you're able to, like, fetch those things just in time, just in need within the system today.
Oh, sounds very cool. So Mark, you were talking about the fact that the, we were saying during a meeting can already go to Cursor or Linear. Have you found any difference between
going directly to Cursor from Earmark to Cursor directly and building the prototype or going first to Linear and then building something from there in terms of quality of outcomes or usefulness?
Have you seen any difference there? It's a great question, Pepe. I think a lot of it just kind of comes down to, like, how the, the squad that you're in consumes work, right?
So Linear as a proxy would be, you know, if I have planning, right, at some point I need to delegate these things, and the cycle time might be a little more protracted, right?
Where it's like we have rituals, we have a two-week sprint cadence, right? You know, we need linear tickets in place in preparation for two-week sprints because we, we need to refine a backlog.
Like, that's a body of activity, right? But to Sandin's point earlier, like, if I want to see it right away, do it live- [laughs]...
uh, and push to Cursor i- immediately and then, you know, refine a prototype, you know, verbally, you know, I think to, to us, like, that's really the magic moment, and I think really the future of work where instead of there being sort of this interstitial stage, right?
Or there's gonna be less of interstitial planning, I think, and more sort of immediacy in terms of, in terms of artifact.
I think the other thing, and this kind of goes back to our thesis around, you know, context degradation, where the longer you wait sometimes the worse the outcome could be.
I think the higher quality outcome will be, like, immediate, you know? But that said, you know, if you want to make a production ready appRight. It's gonna require a few hands and participants, you know, and- Mm-hmm...
and you're gonna have to have real rigor around these things. They're not gonna be prototypical builds, right? And that's kind of like where the, the linear sort of path makes more sense.
There's one path that's emerging that is really exciting.
So we recently released a, a feature where we're actually will save your transcripts locally to your machine, and what this allows you to do is use any local agent of your choice.
So we have people who are using Claude Cowork. I'm using Codex myself.
And what that's really inter- what really enables you to do is I could be in Codex maybe working on, on a feature, and I'm like, "Okay, like I would love to be able to...
or like, I know that we talked about like this model that we wanna add, but, you know, I, I forgot what it is." So I just like be like, "Hey, like look into my meetings folder."
And Codex alone can just kind of run through an agent, go through and iterate through all of those d- different transcripts, pull out all the information it needs to, to like fully flesh out that, that, that body of work while I'm working on it.
Other folks who are using Cowork use it to kind of pull together like e- either their emails or, or their meetings to be able to send out status reports or whatnot to, to their, their internally or to their own clients.
So that, that unlock of using kind of a local agent with Earmark is... That's been huge so far.
Yeah, and we're the only voice AI solution that, that does that, like saves out to like local markdown in order for local agents to consume. Cool. So
I, I can imagine someone that is listening to the podcast maybe thinking, so we have now this real time, real time AI that is maybe producing all the tickets and the PRDs or, you know, all the things that we're going to write manually after the meetings, which sounds absolutely great also for, for the cycle time as you were mentioning.
What happens if it happens, then you, you can let me understand this, when Earmark kind of misunderstands the intent that people have during the meeting, and how, how often that can happen, and what guardrails have you put in place there?
Yeah, that's a great question. So one of the safeguards that we have is human in the loop. Um, it's, it's always been just, I think maybe something philosophically that we believe in, in that Earmark should not
complete the work for you end to end, and that, that might kind of sound a little bit weird. But we think of Earmark as more of augmenting you as a human versus straight on replacing the work that you do.
And what I mean by that is, say like we generate these artifacts, there's still kind of like an approval, a stopgap, or like, "Hey, here's, here's this email," or, "Here's like the Slack update," or, "Here's..."
whatever the artifact is. Take a look at it, you know, review it. If this looks good, you can, you can approve it, and then it k- kind of will continue to send on, on its way. It's important because, one,
we wanna make sure that, you know, what's introduced is still high quality, like it still has to have the human touch. And like my worst fears is introducing AI slop into any of your tools.
Like, you don't wanna have like a bunch of tickets that are nonsense and that gets put into Liria, Linear... I almost [laughs] How dare I con- con- conflate Linear and Jira right there.
But yeah, you, you don't wanna have that in your tools.
Plus, since you are the one using that and since it's going out probably like in your name, that's also gonna make the user look bad, so that's not, that's not something that we ever, ever wanna do.
So having that human in the loop as kind of that, that stopgap is, is what we have.
Um, we have done a lot of work around our evals that are the hallucination rate that we've seen and we can hear from our customers is actually quite low.
The more context that it has to work with, the better the results have been. But I, I can still, I can also imagine that... So l- let's say engineering manager or PM is, is going to use Earmark, and
what E- what Earmark is doing, from what I'm understanding, is helping also translating everything that we're saying d- during the meeting to something actually actionable that Cursor or maybe another developer can work on.
But, you know, I, I think a lot of, for example, PMs could think like, "That, that's exactly my job. I have to translate stuff, right? I, I have... Th- that's been my, my work all along."
What, what would you say to them? Yeah, I- Yeah, so Pepe- Oh, sorry, go ahead, Mark. You're right. You know, there...
I think there is a profile of, you know, PM or engineering manager who they, they kind of look at them, their, their skill set as like, "I'm a fantastic scribe, right?
I can generate documents like nobody else's business. I'm the best at it," you know. And a lot of their self-identity kind of comes with those things, you know.
But, but I think, you know, w- maybe this is our bias, right?
Um, that driving outcomes, driving strategy, vision casting, right, talking to customers often versus being an internal facilitator is really where I think the work of product needs to be.
And I think with AI, you know, for these, these roles where they're very much generalists, you know, and they're, you know, communicating with executives, they're communicating laterally with their peers, they're communicating to their individual contributors, right, and then different levels of fidelity in every channel.
For those folks, um, that just need more capacity to be more customer facing, to be more strategic, right? Like for us, that's really like what we're giving them, and that's what we hear from our customers all the time.
It's just like, you know, I mean, you know, for a lot of our customers that are working 60 plus hours a week, that's just state of the union. That's just product as a discipline.
So, you know, so they're already overtaxed, right? And, and but and oftentimes they haven't talked to customers in months because they're more beholden to internal teams and internal needs than customer needs, right?
And I think for that profile, that's, that's really where, where, where our sweet spot is.
You can say for engineers, there's a whole variety of different tools built like Cursor, Codex, Cloud Code that enable them to move 10X, if not more, faster.
But there really hasn't been a solve for PMs, and that's what we're trying to solve.With EarMark.
Is, it's not replacing the PMs, but all- but giving them that same superpower, that same augmentation that engineers have had, but for the PM role. Yeah, I think YC was calling for a cursor for product managers, right?
So- Yes... with EarMark here. They did, yeah. Yeah. [laughs] It's, it's funny, uh, we, we, when we applied probably, like, a year ago, that was actually our tagline for our YC app, was a cursor for product managers.
So, uh, you heard the, the band first, Pepe. [laughs] Okay, okay. So, you know, this podcast is about product engineers, right?
So, you know, the convergence of product engineering, and the problem you're solving with EarMark, I think really sits at the intersection of the two roles.
From your experience leading both product and engineering teams, why do you think th- this, this gap has been so hard to, to close? Yeah.
I think what's interesting, especially what's happening right now with the AI accelerating the engineering, is that what that's enabled engineering to do is work so much faster that
you can just kind of comb through your bottleneck, just kind of like, like that, like that, like in, in a, in a day.
And what's really interesting is the new bottleneck is now moved from, you know, engineering resources to engineering time, to actually back onto product for review.
Um, so it's almost like just because you can build all of these things doesn't necessarily mean that you should. Like, should we release all these features?
Like, they might sound good in theory, but does that actually make our product a lot more complex and, like, a lot more bloat?
And if you have an engineering team of multiple people, having that PM, [laughs] like, kind of sitting there and, and reviewing is almost kind of like the bottleneck to the engineers just pushing stuff out.
So that, right now that gap is how can we arm the PM to, one, really understand what's happening technically, but then two, being able to move quickly within those meetings to shorten that cycle time, to really keep up with that, with that throughput from, from the engineers.
To almost flip that so that that role can become more of a proactive role than a reactive role, which has been a reactive for probably since it, it was, uh, created. Yeah, I completely agree.
And Pepe, for, for, like, product engineers, you know, as a profile, when you think of folks that are, that are becoming more generalists, you know, now with the advent of AI.
If you have to own, say, the experience, right, the quality quotient, in addition to the actual, like, feature delivery, oftentimes, you know, I think product engineers are typically more customer facing than most engineers, right?
'Cause there's a natural curiosity there, a sensibility there, right, that makes product engineers a little bit more like PMs in terms of customer centricity.
Um, and I think for that profile, like, EarMark excels, right?
Because if you're in a conversation with a customer, right, to Sanen's point, if I wanted to synthesize a set of deliverables or a prototype from them, right, it's just as valuable to a product engineer, uh, in the same way that it's probably valuable to, you know, profiles like, like say, say forward deployed engineers.
You know, if I'm on site all the time, and my customers are barraging me with all sorts of requirements or asks, who's my proxy, right? Like, what's the triage? How do I synthesize these things in short form?
I'm just trying to build, right? And I think, I think for, for those profiles, EarMark does a really good job with. Yeah. Yeah, th- this makes me think about a story a friend of mine shared recently.
So he, he has a startup, and he said that his co-founder was in this conference, and he was talking with some, like, a p- prospect client.
And th- this client, th- th- this, this person said, "Yeah, we need this feature that you, is missing," right?
So he, he just called back the, the co-founder, and they explained everything that needs to be done, and they did everything, like, in, in three, four hours, and they could show the same feature at the same conference
the same day. So yeah, I imagine something like EarMark can really help speed up this process of gathering information and showing something immediately.
Yeah, because, you know, the inception for, for most of these concepts is conversation, right? Like, and, and that's really, like, I think why you think about where we could have started.
You know, we could have started with customer insights and ingesting those from, you know, a CRM, or we could have started with Slack threads and ingesting those, you know, and coming up with insights.
But, but I think the freshest context and the most relevant context will always be voice. Always. Mm-hmm. Do you think EarMark will work, would eventually also work in the background? Let's say,
um, I can imagine data has been, always been captured through product analytics and support tickets and Slack, you know, Slack conversations.
So I can imagine EarMark could be still there hearing ab- about all these facts and producing something to show to the, to the product team. Do, do you think this is the direction it would take? Yeah.
What's really interesting about EarMark is that meetings is just one source of data input, and kind of Mark was saying, like, we wanted to start with meetings because that's where
90-plus percent of the communication happens.
But there's still a lot of, uh, valuable information that does occur in your Slack, that does occur maybe in non-meetings, like in passing, or that does occur in, like, your emails or your documents or, or whatever.
So either being able to pull that information into EarMark or kind of like the other flow I was mentioning, where you can use kind of a local agent to use EarMark as a, as a source along with the other source.
Both of those, even though opposite, are, are kind of valid flows.
And I think taking that next step where we can have that more, like, holistic sense of your context is something that we're looking at, looking at exploring.
But now we're, we're really focusing on the meeting bit because what we've noticed is that-Our customers are really lo- loving the solution and how it kind of helps them navigate, navigate their day, that that's actually turned into a behavioral change, which has turned into a habit.
So almost, like, using that habit as kind of like the first step. It's like, great, here are your meetings. We're aggregating it. You're using it.
And then now, like, what is kind of like the next valuable data stream that we can, that we can add to that? That's what we're looking at now. There's one thing I wanted to ask you.
So you said that you are dogfooding your own product, so you're using it to build your market itself.
So, and i- it's funny that you came from this experience where you were managing hundreds of developers, and now it's just you two building Earmark.
So how, how does your day looks like now that you, you, you have actually no end off? So how does, how do other things change from the past? It's so different. It's so nice, you know?
So, you know, the contrast of every meeting being different contextually every 30 minutes throughout the day with different audiences and different artifacts, um, that's not our use case.
That's actually where the, the tool shines, you know? Like and this, the more complexity, the better. But for us, in terms of day in, day out, like we still have customer calls every day, right?
We still have prospect calls every day. Um, we try to limit our meetings 'cause we love deep work, 'cause we wanna really embrace, you know, the startup experience.
[laughs] 'Cause we could actually, like obviously we have to get a lot of deep work done.
Um, and one example is, you know, we have like a, a really large ceremony each week where we kinda go through sales and engineering.
It might be like a two-hour, three-hour sync, and we kind of just get a lot of the topics out of the way.
Um, but what's wild from, from that meeting is we'll derive things like, you know, we'll have like, you know, say three customer calls. We'll talk about it in terms of prospects.
We'll talk about the language that people use to describe the solution back to us.
We'll kind of brainstorm maybe social content ideas, or we'll brainstorm go-to-market or support ideas or support documentation, and you know, when, by the time the meeting's done, we have, we almost get a game where like every deliverable that we could create, we try to create like during that meeting, [laughs]
right? So oftentimes, like, it'll be, you know, new landing pages as an example in terms of experiments, right? With like re- re- revised language or, you know, you know, different cold outreach drips, right?
Because we're talking through ways to maybe talk about, you know, the, the product a little bit differently or support, like I mentioned, right, in terms of our Mentlfy site, right?
And having, you know, just docs taken from that conversation context and made into a Mentlfy page as an example, right? Yeah.
When we're meeting in that sync, I can see Mark typing away [laughs] into, into Earmark on the other end of the call, because as we're talking through kind of the, the customers, we're like, "Oh yeah, we should follow up with this customer in X," or, "Oh, we just released this feature.
We think this customer would really like that. Like, we should hit them up."
Um, you know, Mark will be typing into Earmark about like, okay, like we should, you know, talk, talk to, you know, mention this customer, and then we'll actually kind of come up with a first pass of either the Slack message or email for that customer.
So what's really cool about that is he's actually sending those things out with, during the meeting.
Otherwise that, that would just be like, okay, here's like a task list, like this agenda that I'll do after the meeting.
So like that's been great, but I'll say my favorite case is whenever we have to fill out like a, like a document or a form, what- whatever it is, we'll actually, we'll just take that.
We'll just upload it to Earmark, and as we're actually in the meeting, we'll just talk through it, um, and with the real time aspect, we'll actually see a representation of that form start to fill in kind of like in real time, and what's really cool about that is that it actually, by seeing it in real time, it shows us where we'll just kind of talk through that, have it fill in, and when we're done, great.
We'll do a proof pass, and then, and then we can send it out. But it's just like so, it's just so much easier just kind of just talk through stuff and then, and then get it done before the, the meeting ends. Yeah.
We had this, this case study with one of our providers, Assembly AI, and, and they gave us like this like case study document and literally like, you know, we just copy and paste it, tell Earmark like, "Please seed this, you know, document as the conversation progresses," and 20 minutes later we have like this awesome case study just self-authored with like pull quotes incorporated, [laughs] like, like perfectly formatted, you know, like, and, and you know, we copy and paste it, we send it back and like, you know, it's just, it's just like those, again, those, those work cycles, right?
Like if in, in, in our old lives, uh, if I was given a, a case study document from, you know, somebody who I'm co-marketing with, that's a big lift, right? I'm gonna spend a lot of time on it. Yeah.
I wanna do a good job, right? And then, you know, if it's actually better as a result of having three people in a conversation leveraging that context and then synthesizing an artifact, it's just, it's wild.
From the smile on your face, I can see you're having a lot of fun. [laughs] Yeah. It is, yeah. So before wrapping up the episode, I'd like to ask you one last question.
So let's say there is a PM or an engineer or, you know, an, an engineer manager listening to this right now, and they are just so tired about all the meetings and all the work they have to do.
So w- what's the one thing that you would recommend to them? Like, if they want, like for example, start working with Earmark, what's the first step towards simplifying their lives? Yeah. Just go to www.tryearmark.com.
[laughs] Download the app and press Start Capture and task.
I think, you know, maybe the pro tip for them is, is this, is a- a- almost a little, a little different where I think for folks who haven't explored voice AI solutions or haven't explored things that are beyond general summaries or haven't explored things beyond AI notes, right?
Like note takers are a big category that have gotten really popular in recent, in recent years.
Um, they're, they, I think it's really important for folks to understand that like if a deliverable is only as, only as good as, let's say like, you know, if it only serves me, as a great example, right?
AI notes is for me, right? Its utility begins and ends with me, right? I still have to do the synthesis after, and until people experience it, it's hard to explain what that value is.
Like just an initial synthesis versus actually getting something out of it, or an actual output or an outcome, that's the real unlock, right?
And that's something we encourage everybody to try because the future, in the future work is wild, right? It is not like the analog example, right? It is not like my text edit file.
Like, like you don't have to do those things anymore. Yeah, and, and definitely- Anything you'd add? Definitely reach out to us through our website. We love to get on a call.
One of the things that we, that we love to work with is we love to understand what your problem is and actually help create tailored, kind of bespoke ways of using Earmark, and we can help you essentially create these templates, and just make sure that you're really, really successful in, in, in this, in this solution.
I'll make sure to, I'll load, add all the links into the description so people can, can find you. All right. Yeah. Thank you very much, guys, for, for joining me today in the podcast.
It, it was very interesting to hear about Earmark and the problem you're trying to solve, and yeah, I think it's gonna have a lot of, a good impact on how we build products. Thanks again. Thank you, Pepe. Thanks, Pepe.
We, we really appreciate the time.