Shipping Speed & Deciding What to Build Next with Benedikt Deicke
===

Brian Casel : [00:00:00]

Hey, it's Open Threads. I'm Brian Casel, it's my podcast. Welcome to it. Today I am talking to Benedikt Deicke. He is the co-founder of Userlist. They're the email marketing software aimed at SaaS company's. Really great product, really great company. And actually I spoke to Benedikt's co-founder Jane Portman in one of the earlier episodes on this podcast, so you might wanna check that out. And I think it's an interesting contrast here because Benedikt is the technical co-founder in Userlist. And so we talked all about the technical side of building and launching a SaaS product in these two episodes that I did with Benedikt.

So in this first one, we focused more on the early days of Userlist and the product and deciding which pieces to build first, second, and third, and how, Benedikt and his co-founder, [00:01:00] and very small team have, you know, gone about deciding what to build and most importantly, shipping speed.

We really covered this in depth because, Benedikt and I both agree that it is one of the most important factors in being successful with a SaaS business is the ability to design, build, and ship features very fast. Not only executing the features, but also deciding which features to build in which order. It's so critical and it's so deceivingly difficult. So had a great conversation about that kind of stuff here in this episode.

As always, today's show is brought to you by ZipMessage. That's the product that I work on every day. It's for asynchronous recording of messages, video, screen, audio, text. You can share them with your coworkers, with your clients, with your customers. I'll tell you a bit more about that later in the show. But for now, let's talk to Benedikt about product. Enjoy.

[00:02:00] Benedikt Deicke. How you doing, man?

Benedikt Deicke: Yeah, Doing good. How are you?

Brian Casel : Yeah, doing good. We, you know, we, we've connected a few times in the past and um, I think we've both been following each other's uh, SaaS journeys over, over many years. So it's been really awesome to see, you know, what you and Jane have been building over at Userlist.

Benedikt Deicke: Yeah, thank you. It's been fun to follow your journey as well. I think the first time, I mean I've been known you probably longer than that, but I feel like the first time we met wasn't at MicroCon Barcelona 2016 or something like that.

Brian Casel : Yeah. Yeah. I think I was there in 2015. That was-,

Benedikt Deicke: -then it was probably that one

Brian Casel : -yeah. Yeah. Awesome.

Benedikt Deicke: And you've been doing a lot of stuff since then. I, I think back then it was still, was it, it was Audience Ops at that point I feel like?

Brian Casel : Yeah, I think 2015, so I was probably just starting Audience Ops sometimes that year. And then I ran that for like [00:03:00] seven years up, up until last year. And I've, I've had multiple SaaS attempts since then. So, uh,

Benedikt Deicke: Yeah.

Brian Casel : One of the things, I mean, we're gonna get into the tech and and code side of things here, I think that'll be good. But I, I must say off the top, I've always been really impressed since the start of Userlist with you and Jane, how, how committed and you know, just, it's been multiple years for you guys and like the slow steady ramp up, like how committed and focused you guys have been. You know, it, it's been really, really cool to see, you know.

Benedikt Deicke: Thanks. Yeah, I, I mean there, there's the saying that uh, most startups don't die because of some weird problem external. That's pretty, usually because people lose energy or lose motivation and just stop working on it, and I feel like we're trying really hard to not do that. Just keep going.

Brian Casel : Yeah. I mean, what do you think it is about, about Userlist specifically compared to all the previous things that you've done? Is it the partnership, is it the product? Is it the traction? [00:04:00] Like, what, what do you think has kept you really motivated like year to year and, and I mean, how many years has it's been now? Like four or five, something like that.

Benedikt Deicke: It's been five years. Like Monday this week, five years ago, we signed a co-founder collaboration agreement with Jane, Claire and me back then. So we started out as a team of three.

Brian Casel : Yep.

Benedikt Deicke: yeah. And you're, I think all of the factors you mentioned play a role in keeping, it alive and like keep being motivated. Having a co-founder is actually a good thing, like in that situation. Because there's always some sort of progress. Sure, we work, both work on the on the code. But when I have a week where things are going slow, then maybe Jane has a good week with the marketing side of things and just seeing progress and seeing that there's someone else who cares about it. And also having someone else you don't want to let down helping through the tough parts.

Brian Casel : I could totally see that. And, and, you know, [00:05:00] I've been a solo founder on all of my companies to date, including now with ZipMessage. And I, I do think, like, looking back at all again, like all those multiple SaaS attempts and different product attempts that I've had over the years, I think one of the reasons why I probably moved on so quickly from some of them is because I, I was solo and I could just make that decision and it doesn't impact anybody else. And you know, rightly or wrongly you know, I think having that co-founder accountability partner probably helps you sort of stay committed in times where you might get shiny object syndrome or do this or that.

And, I've, I've tried to like, compensate for that with friends and advisors and, and I have very close mastermind groups who I actually report to. And actually now I have investors for the first time. So, it's a new dynamic-

Benedikt Deicke: Yeah, that would certainly help as well.

Brian Casel : -but .Yeah, I mean, having the co-founder must, must be like, you know, you guys are working together on this thing, right?

Benedikt Deicke: Yeah. Yeah. And I guess in the early days it [00:06:00] was mostly the co-founder, like by now there are other factors, like we have investors as well. We have customers who are paying us. We have employees or contractors that are working on it. So they are, it's all contributing. to seeing momentum, to seeing traction, to stay motivated, to also see things moving forward when you don't feel like working on it in a way. Like of course we're always working on it, but as I said, like sometimes you have a slow week or maybe a stretch of like two weeks where nothing really works or whatever, but things are still moving because everyone else is contributing and that, that makes it easier to jump back in find some joy again.

Brian Casel : Yeah, totally. So, you know, you've been the technical co-founder in Userlist since, since day one, and, I assume you're, you're still very much uh, in the code and, and directing that side of things, right?

Benedikt Deicke: Yeah, basically I was building all of it for the first almost four years. And [00:07:00] earlier this year or late last year, we uh, hired a front end developer to help out with the, the front end development side of things. So now we're development team of two.

Brian Casel : Oh, wow. Okay. I was gonna ask, so on the, on the dev side, it's literally just you and one front end?

Benedikt Deicke: Leo. Yeah. Yeah. Our front end developer. That's, that's it.

Brian Casel : And Jane handles the design and, and like mockups and UI, that, that sort of stuff?

Benedikt Deicke: Yeah. These days is a little bit of a back and forth, like in the early days she did a lot of like designs up front basically building the screens and then I'd go implement it. These days I feel like we have a big library of preexisting components and parents.

Brian Casel : Mm-hmm.

Benedikt Deicke: A lot of times it's the other way around that we agree on what to build. I build a first version that doesn't look super nice but kinda works and then she does a pass on it and maybe shuffles some things around makes things nicer. It's a new component if you need it.

And then we integrate that and do [00:08:00] a polishing round and then ship it.

Brian Casel : We do a very similar thing, handing it back, back and forth in, in ZipMessage between me and my developers. And I very rarely, actually, I just did this recently, but I, where, where I actually designed some new features, some new screens in Figma . Like 90% of things just get designed in the browser now. Now that most of the app is like established. But yeah, it, it's usually like I might do a very rough part of the feature then I handed over to my developers, they wire up most of the functionality, and then they send it back to me and I'll rearrange the front end and, and restyle it up and, and we go back and forth.

So before we get too, deep here you know, for folks who are maybe new to Userlist, you know, I, we don't need the life story or anything like that but, I am kind of curious how you describe Userlist today. I, I know that it's gone through a few iterations in terms of the, I hate this term, but the, the elevator pitch, right. You know, cuz we're gonna talk about the product. We're gonna talk about the tech side so [00:09:00] that people have some context. What, what is user Userlist as a product?

Benedikt Deicke: It's been a while since I did the elevator pitch, but like the, the way we think about Userlist is it's a marketing automation platform for software as a service applications. So in a way it's like every other email marketing platform out there, but it has the software to service focus where we, we try to solve some problems that are unique to B2B SaaS applications specifically. And that's what we are focused on and that's why like it's unique and does a few things a little bit differently. For example, traditionally email marketing tools would just manage a list of subscribers or people. And Userlist does that part plus it also manages accounts and relationship between users and accounts. And you can have like multiple accounts per user and multiple users per account. And everyone can have a different role in different companies or accounts. So that's one of the ways we try to be [00:10:00] a little bit more tailored to the SaaS use case compared to other tools out there.

Brian Casel : The account based model in Userlist is, it's really unique and it's such a big deal. Cuz if you think about SaaS tools today, like almost every, almost every SaaS tool that, that we tend to see, especially in B2B, has an element of inviting team and the billing is u usually built around an account, not a user. It's really kind of surprising how many SaaS tools are not modeled that way, around accounts, the way that you guys are, like I use.. I just recently started getting into using Mixpanel to track things in ZipMessage and like Mixpanel really has no concept of team accounts at all. I, I literally have to track the activity of accounts based on just tracking the owner of the account. It's really difficult. And I had to spend a lot of dev hours actually wiring it up in a way so that like, [00:11:00] Okay, when one account invites a team member, or when one account gets a respondent to a ZipMessage, how are those associated and how do we track that stuff in graphs and stuff? So it's, it's really difficult.

Benedikt Deicke: Yeah, it becomes really complicated and it also breaks down in certain parts because what if that owner suddenly has like two accounts, the owner on two? Like, how do you, how do you track that? How do you even merge that?

Brian Casel : Exactly. Yeah, we see that a lot too. Like people just, they have a personal account and a company account or something like that, you know?

And you also have that probably somewhat of a similar user model to ZipMessage because we have account members, so account owners and team members, and then they can have respondent users like people who just post a response to their conversation. So in your case, you probably have something similar where you have subscribers to a list, right? There might be an account owner and then they invite their team members of the account. They're like the SaaS company that has the Userlist account, but then that [00:12:00] Userlist account has email subscribers and different users, right? So you probably have like these different User tables that I assume?

Benedikt Deicke: Yeah, like we have a concept of.. That's actually one of the problems in the early days, which just like talking about stuff. Um, So we have accounts and users that are like actual people who created an account in Userlist to sign up for the company and invite team members and stuff like that. And then on another layer we have what we call tracked users and tracked relationships and tracked companies. And basically the tracked prefix indicates that it's people.. Like our customers, customers. Uh, That's how we think about it. And it's basically two separate things, but if you're not careful, it gets confusing.

Brian Casel : Yeah. Yeah. And we still haven't even, I feel we, we've figured it out from a database model standpoint, but we still have not yet figured out how to just communicate that to like users, , you know. Like, [00:13:00] I mean, we have a lot of users who are just respondents. we call them respondent users, people who just reply to a ZipMessage, but they actually don't own any ZipMessage accounts. Accounts are a separate thing. Right. Um, And that's, that's kind of tricky.

So I wanted to step back and I mean, another thing that we're gonna cover here as we talk about the tech side of things is shipping speed because that is so critical. I, I feel that's one of the areas, you know, in, in our SaaS circles podcasts, conferences. You know, people talking uh, on Twitter and slacks and, and things like that. There are a couple of like big areas I, I find that people spend a lot of energy talking about. You see a ton of stuff on like the marketing side and the growth side of SaaS, and then on the tech side you see a lot of conversations about tech stacks and tools and frameworks, right?

Maybe we can touch a little bit on that, but I feel like a lot of it misses a key component [00:14:00] and that is speed to ship. And, and this is so critical in the first early couple of years of a SaaS product because everyone in that early phase is in a race against time. Us usually like, literally like a financial runway. But also a race to get up to feature parity. And, and you with, with Userlist are in like email marketing software, right? So like it's a hugely competitive space. Ton of features to get just up to parity on with, with some competitors. I know you have a different take on some features, but like, how have you thought about speed in general in terms of like building and shipping and how has that like sort of changed over, over the last few years?

Benedikt Deicke: Yeah, I mean, faster is almost always better, I guess. You want to ship the features as fast as possible. Like in our case, we are still like five years in, we are still catching up in certain areas of the product, and I guess that will always be the case. There's always someone who's something [00:15:00] more or something else or whatever. So, and it's also like there's never ending stream of good ideas, right? You can't put all of them. So I guess over those five years, I think what we tried to do as much as possible is like keeping feedback loops as short as possible during product development. rather than-

Brian Casel : What, what do you think of as a, as a feedback loop? Like what, how would you define that?

Benedikt Deicke: In my mind, a lot of software develop development or maybe all of software development is feedback loops. You do something, you see something happen, and then you know what's the right thing or what's the wrong thing. On the simplest level is like you write some code, try to run it, and it runs or doesn't run. On a little bit higher level up, you maybe do some automated testing where you write a test, write a code, run the test, and if it fails, you know, the, the code is wrong and stuff like that. [00:16:00]

But if you zoom out, like the product development cycle or even like product development in general is also a feedback loop where you build something, deploy it, try to get some customers, and then listen to their feedback and they're saying, Yeah, this isn't, this isn't the thing that's solving my problem. Or this is great, but that part doesn't quite work, right? So there's always feedback loops where you do stuff and then you have to look at the results and then readjust.

And that's why I think shipping speed is so fast, especially in the early days, is you wanna learn as fast as possible and you wanna get feedback from your customers as fast as possible. So you should try to get a product in your customer's hands as fast as possible. And then with new features, the same thing. Like if you add a new feature that aims to solve a problem your customers are having, you want to get that feedback as soon as possible.

Brian Casel : Yep.

Benedikt Deicke: And that's where like shipping fast definitely helps.

Brian Casel : Yeah, for sure. [00:17:00] I, I feel like it comes down to a few different components that are really difficult to get right. Like one is just choosing the right feature to build at the right time, you know, um. Like prioritizing and, especially in the very early days, like just understanding like what are the core features that we need in order to actually have a product in the market. And then after that, you're established in the market and it's like, what's the right feature to build next? Like you said, hundreds of features that we could be building and we get these feature requests and it's like, How do you know which ones to pay attention to?

I want to ask you about that. But then there's the other side of it, which is actually executing a feature really fast . You know know I feel like this is where a lot of SaaS companies.. Like you see this with huge companies, they take like years to build like one feature. But I think that we see a lot of, you know, smaller indie bootstrap, you know, smaller companies probably taking way too long to build features, maybe spending way too much.[00:18:00] Whatever it's like optimization or you know, overbuilding a certain feature or you know..

And we also see this with like teams where the communication between the technical side and the non-technical founders or non-technical people are not actively communicating and really collaborating, you know. And, and I think this is where folks, frankly like us, who are both founders and technical. We can start to like navigate where we might get hung up and how we can like quickly work around technical issues to, to get something shipped. Whereas other teams that are not communicating so well, you know, the non-technical might let the tech team spend weeks trying to battle through an issue when, when there could be a much simpler work around, you know. Yeah. Like how do you think about that kind of stuff?

Benedikt Deicke: That's a very broad question.

Brian Casel : -question there, but like, Well-,

Benedikt Deicke: I, feel like I agree.

Brian Casel : Yeah, let, let's start with [00:19:00] the.. um, Let's start with the, the decision, this is probably the harder one, is just deciding what to build and when in which order. Right. So in the earliest days, like when you were just beginning Userlist, what did you see as like the most essential pieces that you literally couldn't even bring on first users until you built these?

Benedikt Deicke: Yeah, I think the first thing we built was, yeah, the first thing we built was providing an API where people can send us data about their users. Um, So when someone signs up in your application, you send us like an API call to, to add that user to our database. That was, I think, the first thing we built. And then on top of that, we built our automation engine, which lets you react to stuff like that. When someone signs up, you send them the welcome campaign and stuff like that. And those were the first two parts we built even before we built login, [00:20:00] sign up, all of that, like just the prototype was getting data in, sending email out.

Brian Casel : Yeah, I like that too. And, and that concept of like, work from the inside out, right? Like people think like, Well, I'm gonna need a login. I'm, I'm gonna need a sign up form, I'm gonna need this or that. Like, start with the core of the product. Like in, in my case with ZipMessage, the, the very first thing that I prototyped out was the ability to record a message into the browser and play it back in the browser, you know? and then building out from there. But-

Benedikt Deicke: Yeah. We, I mean, the, the thing you want to do is try to solve the hardest problem first, because-

Brian Casel : mm-hmm.

Benedikt Deicke: -if you can't solve that problem, the login page and the sign up flow doesn't matter because there's nothing to sign up for. And sure we didn't ship that first version without the sign in and stuff like that. It was just the local prototype and the thing we, we played around with ourselves to get like the first.. Well, the first version of the core of the product, right. And [00:21:00] before we, we were able to ship that, of course we had to do some more work, but at least we, we showed that we know how to solve that core issue. So that's always the thing I'd start with. And then-

Brian Casel : I I have another question about, about those earliest days, right? And some of the technical decisions. You know, what were some of the things that you decided whether it's like tech stacks that you decided to use or tools or frameworks or even like shortcut, like, like, I don't know, like, like libraries and tools and things that specifically you decided to do that because it would get you there faster or, it would get you to first users faster, right?

Like, I believe you, you and I are both using Ruby on Rails, is that right?

Benedikt Deicke: Yes.

Brian Casel : You know, there's a lot of debate around which tech stack to use, which frameworks to use. I mean, one of the big ones in my case in general is like, just go with, with what I know I'm the most experienced and fast with, even if it might not be technically the most optimal stack for what I'm trying [00:22:00] to do. I love using Rails. I love using Tailwind. I'm gonna go with those because .., And, and those are pretty standards still today, but then there, there are like other smaller tools in there, like anything like that that you decided to do like that could like kind of cut out a few steps?

Benedikt Deicke: I'm basically with you on this. Like a lot of the decisions for tools and frameworks and things we ended up using were basically because I was already familiar with them. Cause I feel like if you're serious about building a software business, you have so many problems at your hand; working with a tool or a framework you're unfamiliar with shouldn't be one of them. Because you're constantly figuring stuff out, like figuring hard stuff out as you go. You don't have to make it harder on yourself by working with unfamiliar tools.

Brian Casel : A hundred percent. Like, don't use your Sass company as an opportunity to learn some hot new technology.

Benedikt Deicke: Yeah,

Brian Casel : You know, [00:23:00] that's, that's what like side projects are for, or, you know, frankly, just let, let other people play around with the, with the hot new stuff and just, just stick with like the tried and true thing that you're fast with.

Right.

Benedikt Deicke: Yeah, exactly. And as I said, like it's of co I mean, we are in the IT business and it moves fast and you, you kind of want. stay up to date and stuff like that. But as you said, like then do a side project and focus on just learning and don't try to do all the things at once. Like if you want us to be a serious business, just use what you know. Or if you wanna experiment on in a very, very, very small scope where, you know, like for example, I've solved this problem a hundred times, but this time I'm going to use this new library that I found that apparently does it better than the hundred times I did it before. Sure. Then maybe, okay. Like the number of variables is low, yet you're basically just changing this one part. That's fine. But you don't wanna [00:24:00] solve a new problem with unfamiliar technology that you've never worked with in a program in which you haven't used before. Using a framework that's totally different from what you've used to and stuff like that. So just stick with what you know.

Brian Casel : Hey, sorry to interrupt. Can we hop on a call today and have a meeting about that thing that you're working on? Ugh. I know, right? Another Zoom call. Really. Here's a better idea - replace your next meeting with an asynchronous conversation using ZipMessage. It's the video messaging tool that lets you share a link with anyone to have a threaded async conversation all on one page.

Record, send and receive messages on video, screen share, audio messages, or text. Your customers, clients and freelancers don't need to download or install anything in order to reply to your ZipMessages. They just click your link and record their response. Reserve [00:25:00] your own link, like ZipMessage.com/ your name and share your intake page with anyone or embed it on your own.

Automatic transcriptions, Zapier integration, reusable message templates, and more. ZipMessage is made for the way that you communicate asynchronously with your team and your customers. Go to ZipMessage.com and use it for free as long as you want with unlimited messages and responses. And for listeners of this podcast, mention Open Threads and get 50% off your first two months on our premium plan.

Okay, back to the show.

On, on this, this note, I would like to sort of geek out a little bit in Rail's or Ruby World. What are some of the, the core, common libraries that you, you reach for and that you ended up using, like in the early days of, of Userlist? Like, are we talking about like, Devise and RSpec and any other like frameworks and things like that that like-

Benedikt Deicke: Like outside of core arrays, [00:26:00] libraries?

Brian Casel : Yeah. Aside from Rails itself,

Benedikt Deicke: That's a good question. We are using RSpec for testing, but again, for no other reason than it's the thing I was familiar with. And yeah, changing my testing library would just slow me down.

Brian Casel : I think that it also comes into play with like choosing big, popular, mature frameworks like that because when it comes bringing in coworkers, teammates developers, like, you know, most, most Ruby developers are familiar with RSpec, right?

Benedikt Deicke: Yeah, exactly. And also like one other reason for using like big libraries or like big project like that is you can be pretty sure they will be around in the future. Over my career, I've been very careful or turned very careful of like just using libraries that aren't well supported because they might save you time right now, but three years down the road, Rails [00:27:00] might have have like two or three major updates and suddenly that library doesn't work anymore, but there's no one around to fix it or adjust it. And then suddenly you're stuck with a library that maybe does like 1% of what you actually need like 1% of the actual application. But it's blocking Rails, upgrades on everything, for example.

Brian Casel : Yeah, a hundred percent. And we've run into this a few times where we need a small library for something that we're doing, but it hasn't been updated in over two or three years. So that's like deal breaker. Like we, we have to see it being actively maintained to, to use it.

Benedikt Deicke: Yeah

Brian Casel : Did you, did you use anything early on? One of these, like out of the box SaaS building frameworks for, for any pieces? You know, like gives you the sign up, the login, the, the user models, the, you know, all, all that kind of stuff out of the box?.

Benedikt Deicke: uh, We did not but mostly because I've been working as a freelance rates developer for like, [00:28:00] several years before that, so I kind of had my own version of this. So it wasn't something we bought, but it's.. A lot of the, like common stuff is just very similar to projects I did in the past. So it was either, but I didn't, I didn't copy anything from client projects that there would be a no-go. But like the parents are kinda, kinda known and you, you kind of know what to do with them. So, yeah, that part is pretty similar.

Brian Casel : I had a weird early experience with ZipMessage compared to my previous SaaS stuff. So when I started ZipMessage, it actually was sort of like a side project. Like, it was sort of like experiment and and just see, see if I could build something. And then, and then it sort of became like a real thing. And because of that, I did want to experiment with using.. I ended up using Jumpstart Rails, which is a, framework by Chris Oliver. It's very similar to Bullet Train, which is also, also very popular [00:29:00] and, and, and really full featured in terms of like building a SaaS. It gives you like a billing system built in and and, and like an admin dashboard and all this different stuff.

One of the things that attracted me to using Jumpstart in the beginning was because it, it already rolled in all the key tools and gems that I was going to be using anyway, you know, like Devise and, it had like Tailwind all set up and Stimulus all set up. Like, these are things that like, I just didn't wanna hack around with, like, like installing all, all these different tools.

So it, it was all there from the outset. But I did find, in the first six to 12 months of ZipMessage there were all these extra features that came with Jumpstart that we were not using that did add a lot of, like extra bloat and we had to like rip stuff out. We had to like rebuild certain parts and, and it actually ended up causing more time and messiness in the code that like, if I, if I did start clean, it would've been a little bit easier [00:30:00] early on. I think we've moved past some of that stuff now, but like, it was like fast to go in the very earliest weeks and months. But like once you get to like six to 12 months into a project, it, it did add some extra bloat, you know?

Benedikt Deicke: That's always a problem with like, with stuff like that where it's fine for the, for the beginning where like just stick with the defaults, but then down the road you're maybe, Oh, I kind of wanna do this differently. Or our use case is slightly different than I anticipated and suddenly you want to customize it a little bit. And then a lot of times those like libraries or like packaged things, just make it a lot harder because you're starting to fight it and therefore it's slowing you down and not giving you the benefit anymore.

Brian Casel : Yeah.

Benedikt Deicke: So yeah, it's a little bit of a trade off yeah.

Brian Casel : One of the things that I, I love to sort of like geek out on, especially with other product focused founders, is your [00:31:00] process from start to finish. And I'm sure like, between you and Jane and your developer and customers as well. Let's start for even from just deciding which feature to build next. And then the shaping process for that new feature, Like what should go into it? How should we design it, how should it work? And then building it and then testing it, and then you know, shipping it. What does that look like from start to finish? How, how are you guys sort of approaching that?

Benedikt Deicke: Yeah, like I feel like we don't have a super formalized process and maybe we should have one at some point, but as we're super small team, it still feels like adding a lot of, like artificial process on top of it is isn't really helping us at this stage. And I'm sure this will change in the future, but right now it's, it's pretty loose.

So the way we go about it is we have a rough idea. Like we don't have a roadmap, but we have a rough idea of high level things we wanna do [00:32:00] in the next couple of months to a year or something like that.

Brian Casel : Let's actually just pause on that for a second. Cause this is something that I, I constantly struggle with. Like, how do you even organize and where do you organize which tools..? Like, and new feature ideas, like future roadmap stuff can come from, you know, you and Jane and talking to customers, and then there's like actual feature requests from customers. There's competitive stuff that you might need to build in order to compete with certain other tools. Like where, where do you gather all these potential features to build in the future?

Benedikt Deicke: We, we don't. We did it in the early days. But just like I I, back then we were using Asana for, for like project management and I know we had like one board in there with just all the ideas and all the feature like requests and tons and tons and tons of stuff. And we kept coming back to it and always reevaluating every single [00:33:00] thing. And at sometimes at some point we realized we'll always be like, That's a really good idea. Yes, this is also a really good idea. We should totally do it this one. So just having that list doesn't, didn't really help us with anything. But by talking to our customers and like, not necessarily in a formal process, but like talking to customer support, like in customer support, listening to feedback, having conversations with, with people, you start to see a couple of patterns and trends of like the same stuff getting requested over and over and over again. And maybe not with the exact words, but the more you think about it and the more you hear the stuff, you're starting to see patterns. And that's usually what we have in our minds as like the big next level things.

Brian Casel : Yeah, I, I deal with a lot of that too. I get a lot of feature requests and there, there have been times where I was[00:34:00] too heavily influenced by the most recent feature request.

Benedikt Deicke: Yeah. that's the, the most recent one is always the most important one. Right?

Brian Casel : It's, it's always the one. that, that, you know.. Or if I heard something like maybe like two or three times and I just happened to hear it in the last 30 days it just shoots right to the top of the priority list. When like, really, that's, let's take a step back. And then the other thing that I've noticed is like requests for the same feature come in so many different forms. You know, like people describe it in completely different ways. And I, I still don't know that I'm very good at this, but I've started to really try to hone in on like, okay, over the past six to 12 months, what are people ultimately trying to do? And, and trying to connect the dots. It, that's that's a really difficult thing to, to nail down. But I, I think over time we get better it.

Benedikt Deicke: Yeah, I guess that's a point as well. Like people might request a feature, but it's not [00:35:00] necessarily the thing they want.

Brian Casel : Mm.

Benedikt Deicke: So it always, it's always worth asking questions at this point. When people request a feature, then ask them, Okay, sounds interesting. Tell me more of what you're trying to do. Like, why, why do you need this feature? act, What's the underlying problem? I feel like that helps to, take a step back and at some point, like notice the bigger patterns, like, not necessarily in like details, but they're all trying to do this one thing. And then maybe come up with a solution for that one thing instead of building 20 features they requested.

Brian Casel : Are there, like, looking back on Userlist so far, are there any features that you sort of feel like you, you built too soon or maybe didn't even need to build at all? Anything like come to mind like that?

Benedikt Deicke: Yeah. One of the features I'm not sure about, to this day, is our in-app messaging feature. So instead of just sending emails, we have a way to embed like a small JavaScript snippet inside your app and you can send like small, [00:36:00] like, notifications into people's browsers. And at the time this was something that people were asking for.

Like we had a couple people who were like, Oh, if you build this, I'm definitely going to sign up. And you might be one of them, if I remember correctly.

Brian Casel : I don't think so. Uh, not for in-app messages.

Benedikt Deicke: Maybe it wasn't you, but like-

Brian Casel : I'm, I'm actually curious to hear more about the text editor. That seems important to me, but we can get into that separately.

Benedikt Deicke: Anyways, like I also, no hard feelings. Just like we had people like telling us, Hey, you should definitely build this. I want to use this. So we built it, and I'm not saying it was a super bad idea, but I think we had higher hopes for this particular feature than ultimately turned out to be true. Like, the, it's kind of a checklist feature, but I feel like..

Brian Casel : And by a checklist feature, you mean like something you can promote and like maybe on the pricing page, on the website. Like-

Benedikt Deicke: Yeah,

Brian Casel : -feature that you can do? [00:37:00] Yeah.

Benedikt Deicke: It's on the website. It's nice to have, but I feel like compared to the amount of work that went into it, it's not like the, big selling point at all. mean, long story short, I think people don't sign up because of this feature.

Brian Casel : Mm-hmm. ,

Benedikt Deicke: It might be one thing on their list, but it's not like the game changer.

Brian Casel : Yeah, it, it also sounds like it's an expensive feature to build, right? Like-

Benedikt Deicke: It took a lot of time. Yeah,

Brian Casel : In terms of time. It also seems like really technically, difficult? Right? Like you're talking about like live notifications in, in the app and for all these different users.? Right. So did it also add a lot more stuff to maintain over time and maybe introduce like bugs that wouldn't have otherwise been there? Things like that.

Benedikt Deicke: Yeah. It took a long time to get it right and like to make it work well with everything else. And I think in a way it was worth spending the time to get it right.

Mostly, I [00:38:00] guess. So it's not a big problem these days, like it's not slowing us down, but it, the process was hairy and it took a while. Because it was basically a fundamental change to how we.. How you deal with messages and now we have two types of messages and two different channels of how we send those and it required a lot of work on the back end to, make a mess without making a mess, I guess.

Brian Casel : Mm-hmm. . Yeah, I mean, I've definitely had my my fair share of, of those things. One thing that we shipped recently, this is not one that I necessarily regret because it's a really good feature. And that's audio end, video editing. Being able to like, trim out parts of your recording and then reprocess and restitch it together and then, and then ship it or post your message.

So.. And this is actually what led to us having this, uh, podcast episode was cuz I was talking about how that took, I think we ended up spending about three months from start to finish on that feature. Which is.. [00:39:00] Some companies might see that as like a short period of time. For us, that's a really long period of time to spend on one, one single feature like that.

Like we, like, we try to spend one to two weeks, maybe three weeks on, on a significant feature at this point. But, and that was one where I was going on vacation in the summer, so I was gonna be away for like two weeks. I was like, All right, here's something good that I can let my developers sort of sink into while I'm away. And by the time I get back we'll be like, almost done with it, and then we can ship it

Benedikt Deicke: Yeah.

Brian Casel : Like you know, and, and it was, it was also like the kind of thing where the technical challenge was hard to predict, you know. Because the, one of the reasons I, aside from getting the request a lot from customers, one of the reasons why I green lit the feature was like, We did some initial technical research and technical analysis on like, is this possible? Like, how would we approach it? And he was able, like my developer was able to say [00:40:00] like, we clearly know exactly which tools and libraries we can use. We've actually prototyped some tests. We can split media files and stitch them back together. It's doable. We can do it. It's just a matter of hooking up these endpoints and then building an interface around it. And of course the interface part of it turned out to be the piece that really made it extremely like we, we did like multiple iterations. We designed it in like three or four completely different ways before we settled on the one that, that's actually gonna work really well. And it has to be snappy. It has to be like, and we're talking about seconds. Like If you're trimming a video and it's off by two or three seconds, like that sort of defeats the purpose of having like fine grain control over your edits. Right? So it took us a while to work through all that stuff. And then finally we smoothed out all, all those edges and got it, it shipped. But while that was happening, that was three months of other features literally piling up in the backlog -

Benedikt Deicke: Yeah,

Brian Casel : -that we [00:41:00] were not able to get to. And I mean, I definitely felt it like with customers, you know?

Benedikt Deicke: Yeah, for sure. Yeah. But I mean, sometimes, and I think the part that's hard to predict as well is sure, like knowing if it's technically possible is one part that's also kind of important. But you can do it in experiment and know. But the thing that's always, at least in my book, hard to predict is how, how is the user experience in the end? How does it feel to use this?

Brian Casel : Yep.

Benedikt Deicke: And that's almost impossible, at least I don't know how to predict how it's going to feel before you're actually able to, to use the real thing. And maybe you can like get some approximation by doing a isolated experiments. But in the end you don't know, like maybe as you said, like, it, it's too slow or it's not accurate enough and, and stuff like that. And you only know after you build it or when you build it. And then if you wanna ship it you [00:42:00] kind of have to polish it to a way or to a state where it feels good enough, let's put it that way.

Brian Casel : Yeah, Yeah. And, and like we have customers, both of our products have customers, right? So there's also like predicting how much customer support this is going to generate if we ship it in the current state, you know? Um, and not just like how to use this. There are bugs that we know are gonna come up with users, so we cannot let them happen. A) because bugs, you know, that's a poor user experience, but B) cuz we know that it's just gonna generate support, so we need to have that stuff handled.

Yeah. Um, exactly. like, so I, I guess like, getting back to the process of, okay, you know, you, you make whatever strategic decisions around like, okay, we're gonna build this thing next. Where does it go from there? Is it.. It probably varies by feature, but whose hands does it go to next? Is it going straight to you in, in code, planning? Like do you do any sort of like pre documentation and like [00:43:00] shaping? Like where does it go?.

Benedikt Deicke: Yeah. So once we know what we're going to build or what we are planning, we do a little bit of the shaping process defined by Shape Up by Basecamp. But it's not like we're not spending a lot of time on this. We're basically creating a document in our knowledge base where we outline the goal, maybe outline the problem a little bit more. Potentially uh, collect like customer support tickets related to that, and do some mining of like, what are people asking for with regards to that particular feature and list that all in there. And then we also try to like define limits, like things we are not going to try to solve in that process. And basically setting, defining the scope more or less. Like trying, Okay, we are trying to solve this and we know there are like 12 other things we'd like to do, but we are deliberately not doing them right now.

So we outlined that and then depending [00:44:00] on how much we know about this thing yet already, like we either do, if it needs to be done, like more customer interviews just related to that particular thing. Maybe talking to the people who requested it. Or if, the requirements are relatively clear but the solution isn't, we try to do some experiments. And that can be building like a super small version inside a product. Or even spinning up an ex, like an experiment in another code base from scratch, isolated from everything. Just to get a feel on what does this require in terms of technical challenges and and, things like.

Brian Casel : That's an interesting approach to like sort of like build it once as a practice run in a separate code base just to sort of go, I assume like semi start to finish on it and then sort of build it again, the, the real way in the Userlist, [00:45:00] code base. Is that what you mean?

Benedikt Deicke: Yeah, depending on what it is, that's, that's how we approach it. But like the experience are very, very rough. like it's not..

Brian Casel : It doesn't have to look good. Yeah.

Benedikt Deicke: it's not polished. Sometimes it might be just like a command line tool that just prints, but couple of things based on what you, what you input and stuff like that. So, but the idea is to get a feel for it and to learn about the potential problems very, very early on. And then only then go into the code and actually build it.

Brian Casel : How much like collaboration between you and your.. So you have a front end developer. Is it the kind of thing where you guys are working together on the same feature, or is that person working on a different feature while you're working on something else? How, how does that interplay?

Benedikt Deicke: uh, A little bit of both. Sometimes we do pair programming right in the front end code base. For example, if we're dealing with a challenging problem, we use tool pull to just like look at it together and spend [00:46:00] an afternoon just trying to figure out a good solution. And once we, we, we are past that part, he usually goes off and like actually implements it the proper way, does clean up, add more tasks and stuff like that. And then other times he'd be building the front end stuff. I'd be building the backend stuff and at some point we, we connect and just like try to get it together. Earlier this year we messed that part up a little bit where we built the front end stuff and the backend stuff and then it didn't, didn't quite work together.

Brian Casel : Mm

Benedikt Deicke: So we, these days we tried to do this like early in the process, at least, like hook it up somewhat. And then at sometimes I'm building something. Completely different in the back end, and building something completely different in the front end when there's not that much overlap in terms of Yeah. APIs to use and stuff like that.

Brian Casel : Well, that wraps up today's Open Thread. Hey, tell me what you think. I'm on [00:47:00] Twitter @casjam, and right after that, head over to iTunes and give this show a five star review. Really helps it reach more folks like us. I appreciate it. Talk to you next week.