Bootstrapped Web

Alright. Welcome to Bootstrapped Web. We got a good one for you today. It's kind of a special episode. I am joined today by not only Jordan, but Ben and Rock from the CartHook team.

What's up, fellas?

Hey. How you doing?

This is

It's so quiet now, but, like, just before we were recording, it was, like, it it was crazy hectic in your room. Like, so we've got the three of you guys in the same room together in Portland, and I'm here on the other side of the country myself here. So like they're literally sitting in the same room, like they're kind of sharing one microphone here. So yeah.

Yeah. Why don't I do my best to set it up and then I'm going to try to go into the background. I'm just really going to talk when I need to defend myself. This is a special episode. It was just a great coincidence that Ben, who is our head of product and my co founder, who've been doing this for a few years together, is in town in Portland.

He spent a few weeks here for us to kind of really focus on our process and iron certain things out and kind of plan for the next phase. While he was here, we just saw a great opportunity to bring Rock who's our lead engineer, our VP of engineering and runs our Slovenian side of the company really. So they're both here. It's Friday. What do we usually do on Fridays?

We record this podcast. So we thought it was a good opportunity not just to make fun of me but also to dig into the technical and process and product side of Carthook. So that's who is on the mic. So why don't we do like a quick thirty second sort of thing for Ben to introduce himself and then Rockwell introduce himself and then we'll kind of let Brian's curiosity kind of lead lead the conversation. So Ben, say hello.

I'm Ben. Jordan's business husband. My background is in design and programming. So one of the funny things of when Jordan and I were first talking about working together in Cardhook was I was like, I don't want to be the head of technology but I will in the short term and eventually when we get big can shift over to more of a product role. And that's been an interesting part of just even having Brock.

Brock got involved really early into the business. That might be unique when you have a technical co founder. It was a part of our original conversation which was I'll come on and do this, but from a technical perspective, we really need someone who is an amazing engineer, whereas I'm dangerous at a bunch of different things.

I guess Ben, what we were talking about last episode is that full stack product person. You can go from design to marketing to sales to building a functional product. You kind of come at it with that sort of a five tool player kind of thing.

Yeah. We were saying how envious we were of people who can get a company off the ground on their own. Yeah.

I didn't totally know that about the history there. Like you came in intending to like not be so deep into the technical side eventually and just kind of focus on the product and design. That's cool.

I think it was literally probably a part of our first conversation in person. I remember us explicitly talking about it which was like in a two person company, it does not make sense to have so many just products and product. So I was like I know that this is my value.

Yeah. I

was setting expectations for it.

Yeah. So Rock, where are you from and what's your background?

Nice to meet you again.

And your role today at Carto?

So I actually started, I think it was about three or four months after Ben joined. Ben and Jordan followed me through a mutual friend. His name is Mate and Jordan was.

We did like a course, an online course together. So I I knew him and I knew that he like knew a lot of developers in that in that part of Europe. So that's that's who we first got to like help us find someone.

We first said that we're gonna meet that they were gonna work together for like three or four months as a short project where I would just take out a few tech issues. But then three years in, we actually never separated. It grew into a nice nice company.

So fixing a couple of small technical bugs turned into like building and then rebuilding a whole SaaS.

And your ownership of the business.

Yeah. That's right.

And in the process. Yeah.

Is one of these things that we've talked about, Brian. When when you're bootstrapped, everything's risk. And so anything that's unknown, like the relationship with an engineer is risky. And so what we did with Rock as well as all the engineers that we worked with early on is we set everything up with the expectation of it being a trial. We're going to give this a go for a month or two but there are no promises.

We kind of made sure that the expectations were set that way because everything was so risky to commit to someone for years, just a lot of risk.

That's that's kind of how

it started.

Why don't you give us like a view of what the company looks like today? Like how many people and how many people are on the tech team and all that?

We actually have most of our engineers in Slovenia. I think that about a good year ago, it moved from one person, which was me, to two. So our our second hire was a full stack engineer also that did a lot of a lot of difference and he helped a lot to scale the process. And only recently let's say four to six months ago we've upped our team to three and then four and now there's five engineers in Slovenia including me and we have an office there. We moved two times into bigger offices.

So there is a lot of interesting obstacles to go through around just coordination, how to manage process going from one person to five because that is basically 5x ing.

Yeah. I am curious about like like as the team grew from from just you on the tech side to now you're up to five engineers, so so you're a full stack guy, the the next engineer after you was also full stack. As you then added to it, did you start to hire like a front end specialist and a back end specialist?

It's always good to have a few people that are full stack so they understand the whole process and how everything is interconnected. It is always very, very good to have specialists in specific areas. So we actually tried to find a third full stack person but then after talking for a while and realizing that it is just better to go into actually like specialized areas. So now we have one front end developer. Her name is Tadeja and she's amazing in front end.

She can she can do anything that we throw her way. And we have two back end developers that do purely back end. I know they can they they're capable of doing front end too but they're both specialized in back end so mostly Jan and I take any additional front end work at this point. But the goal and the plan is to hire at least one more front end in the near future and then we'll see how it goes from there.

Got it. I guess this is a question for Ben. So like how about on the design and user experience, user interface kind of stuff? Is that is that all you or are other designers on the team or who who else is kind of in charge

of that kind of stuff?

We've had a couple freelancers working on us on a project basis. We have an amazing designer, Jane. You know Jane? Okay, Jane is absolutely amazing. And she does her work at A is like 10 times better than anything I could ever do.

So it's a dream to have a designer who loves design and is really good at it. Yeah. Early on, I did all I did all the design and the programming. And then as we had more resources, it was clear that we should start using those resources to hire specialists.

Cool. And so I guess when it comes to that design side of the process of of the interface and building features, you guys look at that as like that's something that you could hand off to a project based contractor. You don't necessarily need somebody full time.

We dream of it. We dream of it. We're the designers most valuable at our stage is establishing a style guide effectively. So we have a lot of assets. For example, we recently redid our entire admin.

What came out of that was really a style guide for our redesigned admin. We've built several pages that weren't in the original design and those pages were effectively me looking at the style guide that Jane established and then just translating it to other pages. One of the interesting things about the transition over the past

six months that we haven't touched on but is true of all three of us is that all three of us now do a lot less work that we used to do. Rock used to write every piece of code. Then he wrote half the code once Yam's there and now he writes a lot less code. Same with Ben, he's kind of gone into this more managerial process role and what we need to happen, who needs the information and I just don't do anything anymore, which is exactly what I mean. It moved around.

I know that we have some pretty technical folks in the audience. I know we have a lot of non technical folks in the audience too. Can you guys just run through what is the tech stack on Carto today?

Brian has asked me this before and I have butchered it. This is your chance to take out the actual truth here.

Let's start with some honesty. Our tech stack has evolved.

It's a complicated question.

There's been some wrong choices, some choices based on lack of experience.

See, this is actually really interesting to me. I want to dig into this, the choices because this is something I'm just beginning to get into myself and I don't even understand all the different things to consider. Why don't you tell us what is in the product today and then we can kind of go back of what the history was?

So for our main app, the the funnels app, the stack is as follows today. For our API, for our back end, we use Laravel. Then for our checkout pages, we use a combination of Laravel views and the Vue JS framework. Then for our admin dashboard, we use Angular. Actually, not.

It's Angular four or five. I think it's five something. And that is our core stack right now. For a checkup we've tried several different approaches.

And the editor itself is is it's angular at

this point? Oh, I'm sorry. I forgot about the editor itself.

Many many others.

Right now the editor is we're actually working on a new version of it but the current version is in it's a combination of angular and jQuery and some vanilla JavaScript. And it did the job, but now we're we're looking for something more powerful. So we're actually going to use an existing framework to get a good

head start. We're using an open source editor that will not be named and bending into our will.

Exactly.

So for the structure we have AWS, we are using CloudFront, are using SQS.

We are basically using the whole AWS or not the whole but we are trying to use as much AWS as possible because it's very easy to manage. We started off using DigitalOcean but our process outgrew DigitalOcean with the amount of people and time that we we had to invest into the infrastructure itself. So AWS did us it was a lot easier to manage compared to our initial setup on DigitalOcean. And we use CloudFront, we use S3, we use Elastic Beanstalk for server management, RDS for database management. So I I'm not sure if I'm getting too detailed right now or going too much into detail.

Only too detailed for me. Everyone in the

audience Yeah.

Mean, I don't know what half of those things are. I'm sure there's some people in the audience who who do. I'm curious, like, if you can, I don't know, dumb this down at all, but, you mentioned that you were on DigitalOcean and you moved to AWS? It's easier to manage and the number of people on your team had to do with that. What was the issue there?

Was it a cost issue? Was it a scaling or technology issue?

So it was mostly scaling issue because cost wise we're actually I think we three or maybe even four x our server or an infrastructure cost when we went from DigitalOcean to s three

sorry to AWS. We we have this funny thing in the company that in the beginning they kept coming to me and involving the word money in the technical decisions. And I was like, You fools, we're trying to build something worth like $100,000,000 Don't tell me we're going to save $100 a month. Spend whatever we need to spend. Eventually, they actually took that advice and now I regret it a little bit.

Just to set up the context here and what Rock's talking about, what Ben's talking about, and just to garner a little sympathy from the audience. We went from a complete MVP that barely worked to processing $5,000 a day to a year later processing up to a million dollars a day. So it was going to be messy no matter what we did. All of this was flying the airplane 500 miles an hour and me screaming at them to change the engines. It was gonna be difficult no matter what we did.

Yeah. And so the like the choice, the decision are on where you prioritize is like spend more, make it more reliable, fast uptime. You you're dealing with checkout, you're dealing with transactions, money, it just you can't be cutting corners. That's kind of the decision that you guys made.

Yeah, it's such a critical product that we couldn't afford any single points of failure and AWS actually solves that really well because our initial setup in DigitalOcean had it it was okay but it had potential failures which in a checkout product you can't afford. It needs 100% uptime or 99.9999% because something happens in a year that they just have to turn things off like you need to turn it off for two minutes. It costs money.

Like kind of going back into the history of Cardhook a little bit, well you mentioned that today it's on PHP, Laravel, like different components, some are in Vue, some are in Angular. What was it before this? Like was it always in PHP from the beginning or what else were you using the last

couple years? So the API side we chose Laravel straight right from the beginning so our recovery products already had the API built out in Laravel but the checkout app itself went through a couple of iterations. So one of the biggest issues not issues but challenges was how to make the app load really fast, how to how to remove any bootstrapping time so by iterations and new versions and learning new things and just through experience and and maybe some mistakes that could have been avoided with more experience but you know things like that are just reflections going like looking back now. We've actually managed to get the load time down for checkout pages in average from like seven seconds to about five hundred milliseconds. So it started off as an angular one app and then the angular two framework came out and we we saw that it it offered a lot of good optimizations like it loads faster, the files are smaller, you can do server side rendering, then we wrote it into Angular two.

It did a lot of good things but we still weren't there. So we were still just trying, we were just improving. Each month we were thinking about new things and then in the end we just said okay we need to get away from the single page application structure because it's gonna be slower no matter what we do and we just did a full rewrite a couple of months ago. I think that it's been released about three months ago now, two or three months ago.

Yeah. They all know

They the know what we

went through in the run of the release and then having to dial it back and then re release so that's what we rewrote. We went from Angular two to the Laravel stack that he talked about because a lot of the stuff, the interesting things are, it's not even interesting. It's just like you're just going to make mistakes because you can't know. So you can do your research.

You have to go through the whole

Yeah. Process. Technology based on what you know and then what you know changes and then you have to kind of go back. So ideally you don't have to go back.

One one thing stuck out to me, you mentioned that that it was a single page application and when you redid it you went a different way on that. This is something that I've been reading up on this past week. My SaaS Ops calendar has been it was built in Laravel and Vue and essentially built as a single page application from the beginning, I wasn't quite sure about that because I knew that there were certain pages and things that didn't need to be part of a single page application. But I don't know, my developers kind of pushed back and said, I was more efficient this way. Was like, All right, I don't really get it anyway, let's just do that.

That's literally the miscalculation we made.

Then I've worked with a couple of other developers over the past year on a few different features some separate products and still they're all like, should just use Vue and make it an SPA. The more that I'm reading up on this, and I'm starting to really dig in and learn to code applications myself now, I just feel like there's a lot of overhyping in using JavaScript frameworks, everything single page application, rendering things on client side, it doesn't have to be that way, and it seems like it opens you up to a lot more bugs and vulnerabilities, and if you don't have the resources of a whole developer team to support that for a year, it might not make the most sense. And I'm just starting to try to understand this. Maybe I'm overgeneralizing, but I'm wondering about that.

I would say that the best answer for this would be it depends on the context and the application and the use case. There's so many factors for us for example like the biggest problem to solve was loading really fast and make it very reliable and we knew that to achieve those two main pain points that we were experiencing we needed to go away from single page applications. But if you're trying not that worry worried about like the bootstrapping times and the loading times and all that then single page applications might be really good for you. They're also easier to maintain especially like with the new and I'm not trying to overhype angular right now but especially with the new angular framework and there's enforced structure and all that it's actually easier to maintain a larger app like a larger single page application because our admin for example which has turned out into a lot of code by now is pretty easy to maintain and to upgrade and to reuse specific components There is a lot of upsides to using SPAs and at the same time there are a lot of downsides to using them. A lot of it depends on the context and the usability of your use case in particular.

One of these things that I'm starting to wrap my head around now is the maturity of these frameworks. You look at something like Vue, they just recently went from version one to version two. I decided to try to dive into learning Ruby and Ruby on Rails. Part of the decision there is that's a mature framework, it's been around for over ten years, really popular. A lot of developers today would be like, Oh, that's old news, you should be using Angular or whatever.

But if you're going from version four to five, it's more backward compatible, whereas we recently upgraded from Vue one to two and it broke the entire app. And again, if you have the resources, if you have the developers on a team to manage that sort of thing and then fix all the things. You're just devoting all this extra time and cash to these younger frameworks when these upgrades happen. I know there's a lot of code quality issues that come into play there, but I'm wondering about these questions for folks who are bootstrapping new software startups. Maybe that should factor into the decision more than I hear it in the conversations.

I'm not hearing enough of, You should choose a more mature framework rather than the newest, hottest, trendiest stuff.

Well, as Ben will tell you repeatedly, a lot of our technical mistakes actually originated on my desk. Part of the decision making in using Angular is we didn't know what this product was. We didn't even know if people wanted it. We were taking this huge risk on building a second product when the first product was just starting to get traction. So I very specifically said, yes, we need to figure out if people even want it.

Just get it out the door in two months, not in twelve months, and you can see how that leads you toward frameworks, toward not building everything custom and everything perfect. Then we start to learn. Even if you listen just note what we talked about as our current stack, the admin itself, the app that people click on and build stuff in, it's still an Angular. It's fine. Our only real issue is that we have a second part of our product that interacts with consumers.

So our merchants are publishing something onto the web and there, all compromise goes out the window. You can't compromise on what consumers can interact with. It has to be perfect and fast and mobile responsive and everything has to be perfect as opposed to if you run a CRM app that the public never sees, only your customer interacts with, you have a very different set of decisions and issues.

Right.

Alright. Just getting into running an actual product here, one of the things I think would be interesting to hear is how do you guys manage road mapping and planning out what the next couple of features that you're going to uh-oh, I see some

Everyone's like, oh shit.

But how do you guys handle that? I'm not talking about the stuff that you're working on today, the issues on your plate today, thinking about, all right, what are we going to be building next month or next week? How do you guys think about

that kind of stuff?

Ben, I

think it's a good week for this question. It is a good week for

this question. I think we should

let Ben talk about where maybe some of the frustrations of us not running a process. When Ben and I first met, I was like, Yo, I'm just not that into

process. I That's fine.

I'm an anti process.

Like merit counseling. Ben can speak to how things felt in the beginning and then how we encountered a lot of pain because we didn't focus on process and kind of now what we're doing. Yeah.

Mean difference is that process matters only at a certain point and I think I would use the word framework instead of process because process just sounds inflexible. I think the biggest challenge for me has been like I am very much a creature of habit. So for me, process, like as Jordan alluded to, I love process. I love eliminating decisions. For me personally, what I realized, let's say like eight years ago, was that you need to have the right goal.

Like the goal needs to inform the process and just having a process doesn't necessarily, that could lead you the wrong direction. Like if you're driving and you think you're driving somewhere else but you're driving to the wrong location, it doesn't matter how great the process for driving is if you're going the wrong way. I think that's the complementary aspect of it. I've just been trying to figure out over the years at what stage, what processes or frameworks matter and at what stage are they more limiting than they are helpful.

Do you guys have frameworks today around like just deciding which features to build, which ones just not to build, which ones to push off to later?

We do. So I'll give you a high level outline of of and I'll say hell, I'm gonna laugh because I'm just gonna say theoretically how it should work. My challenge has literally been being like alright, empathizing with the rest of our team who isn't necessarily as process oriented. So I think that's been the biggest lesson for me is finding that balance between what is it about like I see this process and why can't we just do this process? And then realizing well it's easy for me in part because I just am very good I think at following processes and not everyone else is.

So part of that requires understanding how other people work to find a process that doesn't just work for me but works for the entire company. So without further ado, here's the process. We have effectively a spreadsheet of all the potential features we might build.

I think people would love to hear

the tools too. Okay. I actually

use Airtable which is a like smart spreadsheet. But you could do this in Google Sheets too, doesn't matter or Excel. I don't know why the hell we use Excel. So we have an Airtable that lists all these different features that we've considered. The goal here is to frame them as like job to be done stories where admittedly we have a lot of our features aren't phrased like that, but the goal would be like, here's the problem, here's what the person wants, and here's why it's important, and here's the context for why they want it.

So it's really it's focused on what's the problem, not the solution. The solution should come by understanding the problem and like what are people trying to accomplish. So we have this long list of let's say like a 100 different things we might build.

Just real quick on on that list, how much of that is coming from user feedback, user requests versus just what you guys vision of what this solution should be?

It's a combination. So I actually didn't even include another part because I didn't get want too far into the weeds. But before features go into Airtable, we actually have another product that we use called Shipwright, where our success team and our support team and even me, when we come across things customers are saying to us, either through like help chat or intercom or even in emails, we can tag things and identify what theme does this feature request or whatever relate to. So for example, Shipwright basically is an app that lets you store and catalog and categorize customer feedback. We go into Shipwright and you see a list of conversations we've had with customers for certain parts of those conversations are highlighted and then related back to a theme like, this is someone saying something about payment processing.

I can tell you that just me going through and looking at the different themes of what we have in Shipwright, I can tell you exactly how many customers or people have said, we want to use After pay for payment processing. And Afterpay is like a really popular Australian way of paying. Shipwright for all intents and purposes, we capture a lot of the raw is where we capture raw feedback from customers And then once a month or once a quarter, I will go through and I will just read through all these different things in Shipwright and then I'll try to capture some themes and I'll turn that theme into a record within Airtable. If a lot of people ask for Afterpay, as I mentioned in Shipwright, then when I go and I review and do all the categorization of our Shipwright insights, so to speak, I will then create a story about Afterpay. As a merchant, I want Afterpay because I live in Australia and a lot of my customers are in Australia and they need this in order to that would be one of the features in our Airtable.

And then quarterly as a team, we go in and the leadership goes through and says, Hey, of these 100 things, what are probably 15 or 25 things that we realistically would probably want to do in the next quarter or just consider doing. Then next to each of these features, we categorize we basically score the feature in three different categories, which is what's the perceived demand by our customer base? We'll say, Customers really want this or customers don't. Then the next thing we look at is, well, what's the potential business impact on adding this feature? Is this actually going to help the business make more money?

Is it something that might only incrementally help as opposed to like be a huge amount of value? And then the third category or theme is effort. How much effort will it require for us to implement this feature? That's technical effort, like how much effort will it be to build, but also that could include, well how difficult will this be for us to roll out? The whole idea there is just to get a general sense of what's the range of complexity and cost and value and whatever.

And that gives you a number. And that number is not supposed to be the truth. What the number does is it gives you general you start to be able to compare the perceived relative score of a 100 different things or 50 different things and you just use that as a for context, it's really focused on relative value.

Yeah. It's really just kind of like a data point but in terms of your actual final decision of what to build, you're not just going to completely adhere to whatever the data on the list is. You still have to make a gut decision.

And we ask people to store all the features themselves independently so that we can actually compare because part of this whole process is looking and being like, alright, Jordan says this is like a 10, this is super, super valuable and it could transform our business, whereas I rated it like a two. Looking at radical differences in how people have scored a fee is also to me a really important conversation in the company because it's like, well, why do I think this is a two versus Jordan thinking it's a 10? And so that can lead to, well, there's information I didn't realize that Jordan has about her customer needs that I didn't. So it ends up becoming, like, an actual useful tool internally to understand like, is the team on the same page in terms of who our target customer is, our ideal customer, and what's valuable to them and why.

It's kind of like a way to frame the conversation, really. Totally.

Yeah. Who's in this?

Is it like the three of you or is anybody else?

Ideally, it'd be a spokesperson from every department. So what we're talking about is like we have a list of 100 things. It doesn't make sense for 14 people to all go through and look at 100 things. So what we'll typically do is have one spokesperson representative from each department go in and they can be a part of that initial conversation where we whittle a 100 things down to 25. When we get to 25, that's when the entire company gets involved and we have a short conversation around where everyone will score of those 25 things.

We'll go over everyone's score for that just again as a talking point just to see are we all on the same page. I think it's a good opportunity for the tech team also to be more integrated on the customer side. That's a balance. Everyone's telling engineers should be good customer support and talking to customers all day long. That's great in theory.

The question is how do you do it in practice? And so this is one of those things where it forces engineers to to talk over the features and be a part of the success and support team.

From what I understand, you don't do that? Like, you guys have dedicated customer support people but the engineers are just focused on code, but then you guys interface internally.

We don't have engineers interact with customers directly, not at least not on the first level, yet, but the engineers, it's not like they don't email that customers when it makes sense, especially we've talked the eightytwenty for our high value, our VIP customers. When they send an email, they get to know us and so if they email me and Rock directly on an email with a question, Rock gets back to So there's some interaction, but we're we've never we've never seen it makes sense for us to have an engineer spend a full day per week on customer support. At least that's not how we've done it thus far. So we've tried it. We've tried here and there, but

The more we talk to people, the more they actually recommend them. Mhmm. We would start doing that, like investing a day per month at least where a developer sorry. A day per week where a specific developer is assigned technical support and to get on the guidelines just to understand any pain points and also to to feel the merchant side to to understand that it's not just him coding a product that that's not used anywhere that it's an actual product that helps people achieve specific goals it makes you think differently also when you start when you do the code because you're getting old, you're actually starting to realize that if you push bad code it's going to affect the people that you help that you help like a day ago

or two days ago. Right a real person?

Yeah a real person on the other end not just seven dots.

Right where Ben is right now in the process is when gets interesting.

So when we have the 15 things, we'll go over as a team and we'll talk about everyone's scores and we'll arrive at a conclusion of, alright, here are the three or maybe like two, three, four things that we're going to do over the next quarter. At this point, we've not committed to building those things. What we've said is that at this sort of level of specificity, we think these are worth exploring further. So for everything that we decide that we want to actually potentially implement, we create a product document. So with the example of Afterpay, for example, we would build, we would create a document in Notion, which is what we use for our internal docs.

We don't generally use Google Docs, we use Notion. And we'll create a product doc that effectively contains all the knowledge going forward about building this feature. It starts with what's a high level product summary, which again is the job is to be done framework, which is what's the problem that we're trying to solve by creating this feature? What's the research behind it? Meaning like why do we think this will actually be valuable to customers?

What's feedback? User reviews and stuff might go there. But the purpose is really just like a few sentences explaining what's this product and why should we actually build it. The next thing is that an engineer needs to go in and do some high level research. So the product team creates this product doc with the product summary, then an engineer goes in and does some cursory research to try to get a deeper sense of how complicated would this actually be.

After those two have created sort of like that high level document, every couple of weeks the team will go and they'll review all the docs that have gotten to that level of research. So as I said, we're going to build three things. So we could probably build those three product docs pretty quickly in like we'll say like an hour and a half. So the next time the team talks, we would do this thing called a party. Ahead of the party, everyone who has to go in and review those high level research docs and then come to the party with their homework, meaning that they've already gone through, they've reviewed it, they've added any comments or notes, They have notes themselves of what do they want to talk about.

The purpose of the party is effectively like we'll say a twenty five minute conversation of everyone who has an opinion to be able to talk about it and contribute it. If haven't done any work ahead of the meeting, you can attend it. You can't participate. From that party, that was when people like the support team might be like, Hey, I actually had some specific conversations with merchants about Afterpay. Here's a little bit more information that maybe wasn't captured or encapsulated in the Airtable record of that feature.

It also is where we start can start talking about, like, what are some of the like, what's the scope of this? Are there specific use cases that are most important that make sure that we have built from the very beginning and there's certain things that don't really matter? It's really where we get we're we're zooming in on the feature.

Yeah. You know, this is actually really interesting to me because it's like this concept of of of the party because I I haven't really heard this talked about before. I'm I'm sure other teams are doing it, but this idea of like, alright because everybody talks about the prioritization of features. Everybody's got some sort of list of a 100 things and everyone's doing customer requests and you want to build certain things, and then I see a lot of blog posts and talks and podcasts about that part of the process. But then after you go through that data and you do the technical research, you do the customer research, you document it all, it's like you're having this meeting, this party like one last time before you really start to dive in just to make sure that all of those assumptions are still correct and kind of course correct before you rush ahead into building.

Yeah. From a product point

of view, it's getting input and someone on the success team has different input from someone on the product team versus the marketing team versus the support, so you're getting institutional knowledge focused in on one thing. From a a management point of view, the other thing you're doing is you're getting buy in. You're you're getting everyone to think about it, talk about it together, be part of the process, not feel excluded, not feel like, you know, engineering just throws out a product and say, go support this now. Everyone gets to be part of it, and then a few weeks later it starts to make its way through early access and then all of sudden it gets to push production, and you were part of it. You are part of the living, breathing organism that creates these things.

It's not something to be underestimated because we've done it wrong and it feels wrong when you're just like, I guess this feature is coming out without me having anything to do with it. So then the party happens? After the party, it's the After party. After party.

So that's where the product owner and an engineer who's going to be building that feature, they break off and over the course of a couple days, the engineer will dive in and actually do all of the technical research. The goal of that is for the engineer effectively to come back with the lowest common atomic unit of what would be required to build that feature. So you should come back with a bunch of Jira tasks, which is how we manage our sprints and our engineering. To come back and with a series of Jira tasks. And in an ideal world, we should be able to just hand an engineer, any engineer, but it would be the engineer who built it, but we should be able to hand an engineer this list of tasks and they should be able to build the feature.

So basically what we've done is we've we've put this feature in a box and tied a bow around it. So everything involved in building this feature should now be collected, and it's all encompassed within this this doc in Notion. The doc has the product summary, it has the high level technical research, it has all the input from everyone in the team, and and we've defined the scope of what exactly is going be built. And then we move on to this step of like after we have all that information, now how exactly will we implement this? And part of that, that forces you to really think through the feature before you even start to build it.

And what you should also be coming back with is technical estimates of how long each of those atomic units take in terms of hours. We're still very early in this approach. I think it's great in theory, but a lot of this has you need to find a process that works for you. I think everything we've talked about seems pretty straightforward to me. The challenge turns into how do you do this?

It does sound like a very clear cut and well thought out framework and process, but I'm sure that in practice it's

I mean, my head, I've been like, I'm trying to this for a year, you know? And then, you know, we didn't ask me if we had a bunch of robots named Ben, it would, I think, be pretty straightforward. So

you break it down into tasks in Jira, they're all scoped out, technical notes all scoped out, ready to go. How long is each sprint? Is there a maximum number of days before you're like, that's too long, we should break it into two sprints? How do you think about that?

We do two week sprints. Most things should be able to be accomplished in a sprint or two, but I think part of what there's always caveats and I don't want to get too into the weeds. We did two week sprints and we've tried to inform our product process, a lot of what Keaton Shaw writes about on product habits, our approach to technical research and what goes into a scope document, a lot that's been informed with stuff that he's blogged about. I'd done the product workshop with him about a year ago and that was what informed a lot of just like the tactics and processes in our product development. Yeah.

He's definitely owed credit for a lot of this stuff,

as well as Dave Shanley who's a local entrepreneur here in Portland who runs a company called ran a company called Notion that was recently acquired, different Notion, but that was a product that helped technical teams manage their process. He's like a super process man, so I sought him out and got a lot of advice from him. Most of the advice he gave was really confirming that Ben had the process right and what we needed to do was figure out how to implement it. It was an interesting thing in getting advice of things we were already doing, but at least it gave us the confidence to say, Oh, we can really force everyone to go by this because we have a lot of confidence now that multiple people have told us we're doing it right. Just need to actually implement better.

As we get even more granular here, getting into do you have weekly meetings, daily stand ups, how do you manage progress from day to day?

One thing to add around the whole process and everything, one of our main challenges that we had to overcome or they were still overcoming is having the tech team also nine hours ahead on a different continent. The reason that our process is well thought out and has the party concept, the after party where the engineer and product owner kept to invest some time together is because there was not enough cross department communication so a lot of times the tech team released the feature and the support team might have been just is this already? We didn't even prepare support at all? What what happens? Or maybe we we it took us too long to deploy something instead of having a clear communication path.

There was some jumping around and and asking questions. Is this ready? Is this already deployed? This process that we're describing now helps us eliminate or minimize the communication gap between departments.

Yeah. That that is another thing I I wanted to cover here was like syncing up like the feature development and then and then staging and then getting that to to production with marketing materials, blog posts and support docs, and getting those things all synced up. I know I've fallen into this thing where it's like, all right, we finally built this feature. Oh, now I've got to go hustle and write up some support docs and stuff after the fact. But are you guys running on those things in sync or how does that work?

Yes. What we've talked about thus far, getting to the point where there is now a feature inside of a box with a nice little bow on it, that's before the sprint. We haven't even talked about the sprint. We probably shouldn't because it's another thirty minutes. The whole idea that we've bought into is that if we want higher quality output from the process, we're going to have to invest in better input.

That's what everything we're talking about right now is. It is input into the process which then leads to better output because we kept looking at the

output More and saying research, more planning, all ahead of the execution.

Yeah. We kept looking at the output and saying, But how come we're not communicating better? How come things aren't being released but they're not quite right so we have to go backwards? We kept focusing on the output when really we needed to do and we're doing a lot more now is just putting a lot more work on the inputs to start with. Having these features in a box with a bow allows us The whole experience is calmer.

It's okay. Now we've already done the work and now when a sprint begins, now we're starting to coordinate. Now, it's an orchestra. Now, it's multiple teams involved at the same time and then we use ClickUp, which is our project management tool. One of the big things we've done this week with Rock and Ben here and Aaron, our head of support who is very process oriented, is we built up our template for our project templates for the project management team.

So when we take that box and we start to open up the bow to actually start working on the feature, everything starts to be coordinated. Okay, now we move it from an upcoming project into the current sprint and then that triggers, okay, here are all the things that need to happen for every single feature and one is dependent on the other so you can't move to the next step until this other stuff is done. And now all of a sudden everyone look at it in the sprint and say, from the support part, I can see that this is an early access feature, meaning we want to be careful enough that this feature is going to go into early access, which tells me I need to start writing my docs. Success looks at that and says, Oh, it's an early access type feature, which means I need to reach out to my VIPs in my list of early access to let them know, ask them if they want to be involved in early access for this feature. That's when all the coordination starts to happen.

I mean when it was just the three of us communication the process that was easy, it's very easy.

It was a daily stand up of four friends talking.

Sure, are you already with that feature? Sure. Okay. But then you gradually you evolve into the process, Actually the process it kind of evolves with you. It forces you.

Yeah, forces you

to get some habits or some process in otherwise you get to a stop.

It's too painful. It's not, it's no longer worth. Yep.

It, like the way that you did things before does not work today. You have to actually change your habits in the process. Like, can you guys speak to that a bit?

I would say if anything, our employees that we manage wanted process more than we did. Well, except for Ben because he's always wanted. But we had to make the bigger adjustment because we were the ones used to just winging it and being totally fine with it. Now all of sudden you tell me that I have to get more strict than all this and I got to click this button before I can get to this next button. So it took us, but again, it was the pain that was just not worth it and now it's just tell me whatever to just make the pain go away.

If it's the doing more boring process, that's totally acceptable.

Like what did it look like a year ago? Were you shipping features slower? Were things breaking down? Like What's the difference now?

For us, we learned very quickly the nature of our product, and everyone who's building product out there will learn the nature of their product and who their customers are, where in the customer's business your product sits, all the sensitivity of it, all these different things. If you run the product that people are like, Hey, it's down. No big deal, then you just have one version of life and good for you. But one of the conscious decisions we made from a cart abandonment app that sends emails that at worst sends out an email by mistake or doesn't by mistake, we moved upstream. We moved closer to the fire.

So we took our little acro swings and went toward the sun, and we've gotten a little too close from time to time. Right? So what we did is we went toward the transaction, toward where the money is because we want to go where the money is. What that taught us very quickly was that the nature of our product is very sensitive. And so a typical type of mistake is we are updating a jQuery setting because we just had this big release and everything went great.

We're so happy and oh my god, everything was amazing. We make one jQuery switch and didn't realize, oh, our largest customer happens to have some funky custom jQuery on their checkout page and oops, we broke their checkout page for two hours. And oops, it happened to happen during an email campaign. We just cost them $100,000 in two hours, and then I get on a phone call with them, I hang up the phone, and I call these guys, and I go, Guys, that was one of the worst phone calls of my life. My day is ruined.

I feel terrible. The guy I'm talking to is worried about how his boss thinks of him. I'm spitting fireballs at these guys. They're walking around with their day ruined, and it's just that's the kind of pain that, you know, you if you do that for a few weeks in a row, you really want that to end. You want that to end as quickly as possible.

So it's this emotional pain. It's professional pain. You're embarrassed. It's this crazy mix of I want to be happy. I want to be successful.

I don't want all this negativity. It is abstracted. It's not your money that you're losing, but you don't want to lose people's money.

Yeah. There's a lot of technical pressure here because there's the pressure of, okay, your app is your customer's customer facing. Right? It's their checkout experience, but there's the other level of pressure that your app is plugged directly into somebody else's website, somebody else's environment, somebody else's shopping cart. They've got their own setup that has to interact with CartHook.

There are a lot of points of potential failure that

you have

to work.

Rock when we first met, one of the things in our little pre interview was like, I like a challenge. He got what he asked for. Yeah.

And there's so much knowledge I personally gained in the last three years since we're in Germany and then It's growth. It's growth, yeah.

What's kind of like coming up next? What are you guys thinking about like, you know, working on this year and not, not about like specific features, but just like improvements to how you guys run the company and all that?

I think we have a big test to see if a lot of this theory and a lot of this work that's going to the process, it's time to make that pay off. So we have some really big challenges that we're taking on over the next few months and those are going to be tests of the process. So it gets tested every week but there are some big features and products and much bigger things that are really going to test us. We're kind of doing our track work, putting in the miles before we go run the big race a few times over the next six months. Think generally speaking that's the larger challenge.

We have some strategic waters to navigate, but it's more just how do we consistently deliver in such a way where the pain is less frequent and therefore the growth is interrupted less often. So I know we're going to start to wrap up because we've been at this for a but I wanted to just say something. I first want to say thank you to Ben and to Rock for joining us. Thank you for not roasting me this entire time. I appreciate that.

The other thing I want to say, I think it's good opportunity with these guys here in this particular episode, is when you start off when it's one or two people, you get your joy from interacting with customers. That's the high. The high is this person is buying and they're paying me and they're getting value from it and I'm doing something right. Pretty quickly when you start to grow the team, the majority of your joy and fun and challenge actually starts to come from your colleagues, and if you choose the right colleagues, you can get yourself into a situation where you really enjoy what you do. That's what we're all trying to do, and so now we still love our customers, we care about them, the good stuff that we're all looking for ends up coming from the people that you work with.

So thank you guys.

It's a beautiful thing. Awesome. Great episode fellas. This was awesome. I mean, really, like, I I learned a lot in in the, in hearing about all this stuff.

So, yeah. I I know this will be a good one.

Cool. Thank you. Thanks,

Brian. Alright.