Episode Transcript
Speaker 0 00:00 <inaudible> welcome to the rogue startups podcast. We're two start up, founders are sharing lessons learned and pitfalls to avoid in their online businesses. And now here's Dave and Craig.
Speaker 1 00:20 All right, welcome back to another episode of rogue startups. Uh, this week on the podcast tab, Jordan galls, founder of Card Hook for those don't know Kurt Hook is in the ecommerce space, uh, with like a bunch of big integrations with Shopify these days. Jordan is, is running a big team and kind of big business. And someone I really, I look up to as someone who's kind of like that next step ahead in the journey, uh, as, as a founder and today Jordan are going to talk a lot about team and process and really like the product process I think is that that's a term we use. Uh, Jordan, is that the term that you guys use? Like for how you build shit?
Speaker 2 00:59 Yeah, product development process, right. That's the, the overarching, the umbrella of where all this fits in from the way engineer's feel, all the way to, you know, how our sprints are organized.
Speaker 1 01:11 Yeah. Yeah. And I mean, so you, you cohost the bootstrap web podcast with our mutual friend, uh, Brian Castle. And I love hearing you guys talk about process and, and I know Brian is a huge process guy and particularly kind of how you guys work. And I mean, we're finding two and a half years in to cast us being launched and almost three years of, of kind of really like breaking ground on the code that, I mean, this is, it's been something I've been, I feel bad at or like this has been a, something that I felt like we could do better all the time and we're doing a lot better at it now than we were six months and a year and two years ago. And it sounds from what you guys talk about on the podcast that, that you kind of feel the same way, that it's just always iterating and always improving, but
Speaker 2 01:59 as a long way to go maybe still. Yeah, it always feels like it has a long way to go. Uh, but there are these moments where discoveries are made. The painful part is when you make these discoveries. It always feels so obvious in retrospect that, what were you thinking doing it this other way? Yeah. Um, so that's painfully constantly feel stupid about it and then the nature of it is not static and so even when things feel like they're in a good place, you add two more engineers and everything goes out the window again. So it is, it is, it is a constant challenge and it's been a focus of mine over the past few weeks because I, I think I took a back seat to the process. I really wanted to be able to ignore it. Right? If I'm, if I'm being honest with myself, I, I w I took too many steps back from it and really just wanted to look at the person running
Speaker 3 03:00 the product department and say, you got this. I'll go face outward and talk to investors and partners and I did it for too long and I can order it for too long. And the fact remains that at this stage with a 25 person company, I still, I still need to be really, really involved. I was about to say I care the most about the product. I think that's questionable, but I still have to be a driving force on the prioritization and the process and also thinking about the individual people involved and how they are feeling through the process, which is, which is something relatively new and the uh, we're going to touch on base camps shape up inevitably may as well just start doing it now. Right. One of the things you find when you're reading that book is that there's a lot of attention paid to help people feel, it's not just about optimizing this perfect process.
Speaker 3 04:02 It is acknowledging that people are important. They're the key to the whole thing. Yup. And people have feelings and when you put people into these specific situations with certain expectations, you are going to have a resulting emotions from it. And those are really important to the success of the process. Yup. So that's one of the, one of the things that we've found as we're, you know, we're growing from like almost zero to one, you know, we're w two, three, five now we're seven people, you know, mix of full time and part time. And what we find is every time you introduce a new person, so we just, we introduced someone for kind of UX and design recently. Um, and then it's like <inaudible> big question is how do we take an offload the right part of that from my plate to where I can give and I feel like, you know, hearing you on the podcast, I feel like you're a bit in the same boat.
Speaker 3 04:57 It's like, how can I add my say domain expertise and an opinion about what the product should be two, the process and then let the people that are, that actually have the skill, especially in like in design and development and copywriting and it's all, it's all part of the process. Do their job, that they're better than me at that individual thing, but that I can then have my input on kind of what we're building, what it will look and feel like ultimately, and not micromanage every aspect of it. That's like where I'm <inaudible> this, this, this has to just suck for everyone else because I'm just like hovering. I feel like all the time and we're trying very hard not to let that happen. But, but that's, I think when you go from one to two to four to five to six, seven 25 people, that has to be, uh, some of you have to be really intentional about, right. So I'd like to commend you on two things. First that you hired for design end UI.
Speaker 2 05:58 So early on we still do not have a full time design UI person and it was a mistake. So we, we should've invested in that a long time ago. So I think you're doing the right thing by investing in that early. We've, we've worked with outsource people and freelancers specifically with the Jane from UI Breakfast and she has been a savior, but we still, we still need a full time person. The second thing I'd like to commend you on is the hovering is not necessarily bad. It depends on the way you do it, right? You don't want to hover and basically blackout someone's talent and turn them into someone that just does what you tell them to do that that's not good. But the the hovering is is what I was alluding to earlier in that I step too far back from the process. I, I should have hovered more, I should have cared more about how these individual things were going out and I really started to see myself as like, look, I, I need to be outside of that process.
Speaker 2 06:57 I need to trust other people into the process in there and I need to just be okay if not everything is coming out exactly the way I wanted to because I don't want to be that type of boss that I went too far the other way. And so I don't think hovering is necessarily bad. You have to do it the right way to make sure people feel that you trust them the way I put it. So we just hired someone new as a product manager here in Portland. The challenges that you're, you're, you're trying to hire someone as talented as possible and as confident in their craft as possible and as talented as possible. And then what you're telling them is all that talent and all, all of your brains and experience. I'd like for you to put that aside because you don't have the domain expertise.
Speaker 2 07:37 And I'd like for you to basically just be a project manager, be it be a sprint, a ScrumMaster. Yeah, but only for a few months. And as you become more familiar with the space and our customers and the needs and the market, then you can inject your opinion. So it's like, I'd like for you to walk in here and be humble enough to put your opinion aside because let's be honest, you don't know what our customers want. You don't know what you're talking about yet, but that's not where you want to end up in your role. And so just do that for a little while. And then as your confidence builds, start injecting your opinion. And in that, in between period, guess who guess whose opinion is required that that's mine. And in your case it's yours. So it's not hovering. It's, it's a, it's a baton handoff, but it's not all at once. How,
Speaker 1 08:27 how is that going? Cause cause I can imagine that's a tough pill for someone to swallow. That's a talented person that wants to come in and join a high growth startup, Portland area. Like those, those are really talented people with, with, you know, probably like a high opinion of themselves. How is that going to tell someone to come in, sit down, shut up and do this. And in a couple of months I'll, I'll, you know, take the training wheels off. So that's a harsh version of it. Right. But I mean that's
Speaker 2 08:53 the thing, this goes back to feelings.
Speaker 3 08:56 The way it needs to be communicated has everything to do with the outcome that it has to be communicated in an empathetic way that sympathizes with their situation and takes into account that they do have a high opinion of themselves and rightfully so and so. It's not about, hey, look, you don't know what you're talking about and I do so just follow me until I tell you otherwise. It really needs to be if let's set you up for success in this role. Yeah. Six stroll is not about the next three months. It's about the longer term and what's going to set you up for success in this role is that gradual intake of domain expertise and market knowledge and what our customers want and the expectation on my side is not that you're just going to do everything amazingly well and I don't have to worry about it anymore.
Speaker 3 09:40 That's not the expectation. Let's both set the right expectations from both sides that there needs to be a handoff and that we will, we will get there together and a year from today your opinion will have a much larger say in what you're doing then right now. So I think it was more about a let's set ourselves up for success here and let's set the right expectations, uh, that that's okay. That mean needing to do more of the opinion piece is okay. That's actually the plan. Yeah. Yeah. I think it's good because the, if you think about the other person's point of view, they're looking at me and saying, so what do you expect from me here? How am I going to set myself up for success in this new role if I kind of don't know e-commerce that well right now? And that's really what I'm, what I'm answering those doubts.
Speaker 3 10:28 Yeah, I can, I can relate. So this is the same approach we're taking with, you know, we hired a full time marketer, Denise <inaudible>, she's about three weeks in right now. And that's exactly the, the framing and the positioning of her inside the business. And inside the marketing kind of organization at this point is you have a ton of marketing experience. You don't have a ton of podcasting experience. And so I will set you up hopefully for success in bringing your existing experience over and applying it to SAS and podcasting with, you know, my experience in the business and what customers want and the kind of language that we typically use and stuff like that. But it's been great. And this is a tangent but it's been great too to let her challenge my assumptions about a lot of these things. And Yeah, we've been working really collaboratively and, and I, I can imagine that's what you're hoping for out of this new product person is like you rightfully know a lot of, you think you know a lot about about ecommerce and what your customers want and stuff. And this other person might come in and in a few months or six months a year, be able to, to really like productively challenge those and like push the envelope a little bit with, with what the product does and where the business is positioned. Yeah. And I think, you know, what I do is I have, uh, I have, you know, one of the things I liked so much about that notion is that ability to have this public documentation area and then also a one.
Speaker 2 11:54 And so, so we have a lot of our docs public so everyone can access them in. And I have my own private docs and that's where I keep a lot of notes for one-on-ones. And so when someone's new, I am ready for that fact. The fact that they're new and that this process was going to happen over a few month period that's in my notes. So every time I have a one on one, we're talking about that and acknowledging it and seeing how they feel in that arc. And so write an example. This morning we hired someone on the communications front. She is more than just a content writer. It's more about branding and positioning and language and keeping things consistent and along with content and all this stuff. So we hired her I think maybe two months ago now. And this morning when we came in, we have a new feature coming out, but it's one of these features that changes things for existing customers.
Speaker 2 12:47 And so before launching it, we need to communicate with everybody. And so this morning I came in and I realized, Oh, I don't need to talk about the details of this. I'm going to tell people that this feature is going to come out. And we used to communicate and then I'm going to point to her and say, and she decides what is required in that communication before the feature gets launched. So it almost felt like, hey, we've been doing this for two months and now it's starting the fact that they're comfortable enough, they've gotten their, they understand our customers, they know how all this stuff works internally. And now I'm, I'm just handing that off entirely because she's got it. Yup. But look, let's, let's take us, it's just time. It's a matter of, yeah. So let's take a step back. First of all, we went all business on this. Craig, let me say hi to everybody. Thanks for having me on the podcast. Uh, I love your podcast and, uh, and enjoy it. Enjoy your also getting your, uh, your monthly updates on Castro's, uh, very interested in the podcasting space overall. Uh, but thanks for having me on the podcast. Hello to everybody and that maybe that's a good opportunity for us to kind of like chill on that tangent and back it up and talk about, you know, product development process overall.
Speaker 1 13:54 Yeah, no, for sure. I know I am sorry I jumped right into the weeds. Uh, no, I mean it's, it is more and more my only like primary responsibility sounds like it's more and more years. Um, and honestly something I love, like I love product, um, because it touches all, almost all of the aspects of the business and arguably in like in SAS these days especially is like the most important. Yeah, I agree. So, yeah. Why don't I, I mean, as much as you're comfortable, I'd love to hear personally, I'd love to hear, and I'm sure everyone else would love to hear like, uh, what your product process looks like. When you guys say like, how do you decide what to build? How do you get the Dev team and design involved? How does marketing get involved and had a success get involved? Cause I know you guys have all of those groups.
Speaker 2 14:46 Yeah. So, so I think where I'd like to start is to talk about the, some of the problems we've experienced in that process and what, what led me to refocus on it and then we can talk about where we are right now in adjusting that process to make it better. Yeah. Sounds great. So over the past few months, what we have felt happening, so we have two teams. Uh, we have a Portland team that is what we call the customer team, a marketing success support product. And then we have our engineering team in Slovenia that's engineering and QA. And so our, one of our biggest challenges is coordination between those two teams and those, those main functions of we're talking to customers and we know what they want and what they're experiencing. Engineering needs to be responsive to that and drive the product forward. And how do we get a process between those two teams to make sure that we are building the right things in the right way for the right people.
Speaker 2 15:44 So that's our challenge. And what I, what I started to feel happening is we would speak to customers, we'd have our own ideas, we'd have customer feedback, and we would set that as priorities and that would head into the development process. And what would happen is when things came out of that development process and they were being released, we have, we have an early access process. So anything big, anything, even medium does not just get launched and put into production. It gets launched into an early access and then a handful of our customers are able to access it. And that also allows our support team to write documentation and our success team to experiment with it. And so everyone understands exactly what this thing is before it goes into production. And so what kept happening is that we would set a priority, let's call it a new feature, and that would head into the development process.
Speaker 2 16:42 And what would come back out would be, right. But it would be a few degrees off and it would be just a little different from what we expected, but off by just enough that it kind of wasn't useful. It wasn't, so it wasn't going to satisfy the customers because it wasn't about to match their expectations of the feature. And so what that led to was it led to no positive feedback loop either way. Right? The customer team would be, okay, we got this information, we have this idea, we understand what people need, we understand why, let's get it in. And then what would come back out of engineering would be a little off. And so the customer team wasn't happy and then the customer team wasn't happy and therefore then the team, the engineering team isn't happy and no one's getting any positive feedback. No one saying, thank you so much.
Speaker 2 17:34 You nailed it. This feature is coming out. It's going to make people happy. And the customer team wasn't pushing that to customers and the customers saying to them, oh my God, this new feature is amazing. Thank you so much. And that was, it's a little depressing. Yeah. So right. We're, we're back on emotions again. And what happened was I went to Slovenia, I go there every four months or so. Hugely, hugely important. Every time I go I'm on an airplane, you know, like eight hours into my 20 hour journey there. And I always think to myself, why am I going all this way to do a bunch of one on one sec could have done on zoom. And then as soon as I get there, within a few hours I realized that's why I come here because it's completely different. And so this last trip I went in with a lot of worrying, I went in and what, you know, what's going on?
Speaker 2 18:16 Exactly. Why are things coming out a few degrees off, why aren't people happy? What's happening? And what I saw was an environment that was lacking that positive feedback loop and they were working really hard and then they were pushing things out and they would finally get this thing out after working, you know, 12 hour days for, for two weeks in a row. And then they got no love back. Just nothing back. Just, Oh, it's a few days later. Oh, it's a few degrees off and okay, we'll push it. And it was like, you know, that red light was going off like this is not sustainable. This is not an environment where people are happy and stay for a long time. And so that is what led me to relook at the whole process and they'd hold on a second what, what is going on? And, and that's right when base camps book came out. Yeah. And when I write the books called shape up, w when I first read the title, I was like, these judging motherfuckers are gonna tell me to get better again.
Speaker 2 19:16 I thought, I thought that's what shape meant. Like get better. I'm like, yeah, I know I'm not as good as you guys. Okay, relax. But then you start reading and you realize that's not what they mean by shape up. What they're referring to is the shaping process. And the shaping process was this gaping hole in our product development process that barely existed. And so what we realized was that there's no wonder these things are coming out of engineering a few degrees off because we're not doing the work upfront before it goes to engineering to really nail what the customers want and why and then articulate and designing it enough to give the right roadmap for success of that feature. And then here we are, we're, we're, we're, we're judging the engineering team saying, hey, how come everything keeps being a few to resolve when in reality it was completely on us and on the Portland team side that we weren't doing the work required for success of, of, of that particular feature. Yeah. And so that's really what led us to, to this book, this focus now on the process.
Speaker 1 20:16 Yeah. I mean the, the shape up the whole, the whole book is fantastic. We'll, we'll link to in the show notes for sure. And everyone that even a failure, you're a solo founder building this yourself. I think you should read it. If you're a team or leading a team, you should definitely read it because I, yeah, it, it opened our eyes a lot to the, that the whole process. But really the why we're building this and like what is the, that really, I think that the question they ask is like what is the purpose of this thing we're building and the customer's eyes. And I, and I think that's like a simple question but a super complicated
Speaker 3 20:48 process to answer that as a team and have everyone understand why you're building something cause cause it talks to all like almost all the aspects of the business, which I think we'll get into like how everybody's involved in deciding that and communicating and making sure everybody's on the same page with, with the Y. Cause then it probably removes those couple of degrees of separation of what the port, your Portland team says and what the Slovenian team builds. Because the, the why is not super clear maybe. Yes. Yes. And Yeah. So that, that process clarifies for both sides. Uh, and one of the things that our CTO always tries to remind me and individual engineers to, they always remind me that someone else's process cannot be copied, pasted onto your team. Especially me, especially a business like base camp that's been around for what, 15 years, right? I mean they can do things that you and I can't dream of in terms of the maturity of the product and the team.
Speaker 3 21:53 And there maturity honestly is founders, uh, all of the different factors that are different for every company and every team and every size, every product, all these different things. And everyone is their own special snowflake of a combination of product issues and founder issues and market issues and whatever else. So I always have to caveat everything I'm talking about when I'm talking to engineering team and I'm, I need to always say I understand. We will need to make adjustments for our reality, right? For us right now, handing things off to a team of developers and designers like these smaller teams that base camp uses. First of all, we don't have the designers and second of all, handing off a feature with no task list and asking that team to come up with the list of tasks, the way base camp does it, like that's just not realistic for us.
Speaker 3 22:49 We just can't do that. Yup. So all of this stuff is with a grain of salt and it's all about the themes and concepts behind these individual parts of the process that you have to pick and choose. Base camp is not done iterating on their process either. So it's not about, oh hey, this is perfect right now, so let's just use it as that. Yeah. That, that's, that caveat is rightfully made by the, uh, by the engineering team every time we come across this. Yeah. I think it's worth pointing out too. We all love base camp and the, the transparency that they provide to all of us, but, but they're not the only ones. So we've, we've pulled some inspiration from a few others, um, that I think are noteworthy and we'll link to these as well. So, uh, get lab is a super, super transparent organization and they have basically their whole product process laid out.
Speaker 3 23:36 Um, at laseon <inaudible> notion actually a has a lot of their stuff laid out. And so we've pulled bits and pieces from each and each one of them and then, like you're saying, took the concept of it and like really distilled it down to our little whatever, five or seven person team because they're all, you know, these huge venture back companies, um, that, that we can, we can't do what they're doing cause we're not, you know, 105 hundred people. Yeah. Or Yeah. Or just not, not, not the same situation. Yeah. Yeah. But it really is the concepts of like you're doing this because ex and, and anybody can implement that I think if you take the concepts of it. Yeah. I mean, so what do you want to, do you want to give like a, a just of how we run our process and then like drill into some individual parts on where we find challenges and what's working well or what's not working at all.
Speaker 3 24:26 Yeah. I think that'd be really helpful for all, I mean, for me it'd be helpful to hear kind of what you guys are doing and what's not working. Uh, and, and I'd love to do the same. And for everyone listening to hear kind of both sides of, of each of those would be would be cool. Yeah. Yeah. And I, and I, I think from my side of things, it will be pretty general because admittedly I'm not that familiar with the process. Right. This is one of the issues that, that I talked about earlier. I, I backed out too much. Yep. Um, and so now I'm refamiliarizing myself and, and making sure I do have a firm grasp on it and I'm very familiar with Jira. So we do use Jira and we use confluence for a lot of the documentation that goes along with these individual Agira tickets.
Speaker 3 25:08 And what we like to do is have almost everything driven by customers. Uh, we have what we look at as pain points, uh, things that people are suffering from and we need to improve or fix, right. Those can be bugs, those can be uh, changing features or adding additional functionality to an integration that people really want. Things like that. And then we have what we want, like our, our desires. Like, Hey, I want to add this app integration and I want this new feature. And then we have our third category is like strategic and so in, in each sprint that we're running and we run six weeks sprints and we named them after, uh, after a rotating assortment of foods. A one time it's an American food, another time it's a Slovenian food. And we go back and forth and at the end of the sprint we cook up that food and both offices and eat it to celebrate the end of the sprint.
Speaker 3 26:05 I love it. Right? So more, more feelings. And so when we run that six week sprint, what we're trying to do is, before the sprint starts is, is take a look at this mixture of, of pains, desires and strategic. And unfortunately right now it's mostly filled with pains, whether it's bug fixes or improvements to existing features and integrations that people want. And then we have a few desires, right? A few things that we, that don't exist right now but we want, uh, and then the strategic has to have a place at the table. There are
Speaker 2 26:44 still some that are, no one's asking for, no one's even thinking about. But I'm thinking about and maybe another few people are thinking about and we're looking at six to 12 months down the line and doing these strategic uh, features, integrations, changes can make a big impact down the line. And so that's, that's a, the way I look at it is the customers have to have their say and then the product has to have it say, and then the management needs to have it say also, and you guys weekly as like items in confluence or I'm not familiar with like all the Atlassian stuff. So you just keep these as like individual <inaudible> cards all in the same area or how does like logistically, how does that work? So, so there's a dumpster fire of a backlog, right? There are whatever, 250 random ideas and tasks and bugs and whatever in the backlog, which we pretty much ignore.
Speaker 2 27:42 And at any point in time, if you ask the team what we should be doing, you will get enough feedback to fill the sprint. So there's, there's always the business priorities that are self-evident. They're just, they're just right there in front of you. People are asking about it every day. They're complaining about it or the day they wanted every day. And so what, what we've started to do in this last sprint as I'm refocusing on this, is I want to make sure that the direct feedback from customers is paramount. And so what we did myself, the product person in Portland, Jessica and our CTO rock is we sat down in a conference room, we booked it out for what it was, it four or five hours, and we individually interviewed key people from the team. And we just came in and said, all right, what's your wishlist for the upcoming sprints?
Speaker 2 28:31 And we give them a few days notice. So they knew that this was coming and people came in with their notes. Okay. Uh, from my point of view, I'm the one doing demos and from my point of view, the reason people aren't signing up is because x, Y and Z is missing. So now we got, okay, now we have the perspective of sales blockers. These are the reasons people are not signing up. Good. We have that list. Then we talked to the support team and from the support team we're getting a different perspective. We're getting this. These are the things people are complaining about. These things that people don't understand that people can't accomplish that isn't working. Here are the bugs that are most often cited. So then we got that perspective and then we'll talk to the success team and we'll talk to these individual people in individual teams that we were getting roundabout view. We don't want to just listen to support because what support will tell you is what existing customers are having issues with or want. Yup. If you then don't talk to sales now you're now you're, you're going to ignore the things that support never hears it because those people wouldn't sign up to begin with. So you don't want to leave that out. So we tried to get a full view and then we took that and we said, okay, here's this list of priorities. Now let's add our
Speaker 3 29:42 own layer to it of what do we really think is a priority. It's a bit weird to have someone come in for half an hour and talk to you and then just look at three out of the four things they talked about and just dismiss them immediately. But that's required. It's necessary, right? When it actually comes time to prioritize. You can't do everything. And therefore some things that people talk about that in their opinion are important. You're just not going to be able to do. So that kind of ends up in the wall. That's a backlog. That's a p two and a p three and a p four as opposed to something that's p one that's going to be lined up for the upcoming sprint. Yeah. Yeah. So, so then we have our priorities and then those get turned into cheer tickets or epics depending on the size, the scope of the issue.
Speaker 3 30:28 And then we start filling those in with these individual tasks. And a long with each one we're getting feedback. So now we're doing more work in that shaping process. So right now a lot of my tasks are Jordan, you want apple pay to look better before or we release it, give us all that feedback. Yeah. If you want this other feature, give the feedback. And so when I think give the feedback, I don't think, hey, my feedback is the most important thing. I'm going to add my feedback and then I'm going to go to the relevant people on the team and say, what would you like to see? How would you like for it to work? Or do we have this right? Do we have that? Right. So that additional work we're hoping, uh, before it goes into development leads to better outcomes. Yeah. I definitely want to touch on that cause that's the part is shaping up that we're really trying to implement is to, to let and kind of what you're getting at is to let the design and UI team and like the process or product lead work on the specs before it goes to development to speed up the process because then you basically have teams working in parallel.
Speaker 3 31:33 And I think that for me that's the point that we're hopefully going to improve the most on here going forward is as how we're changing our process. But I will give kind of an overview of how we run the, the part you just talked about, cause I think it's, it's really interesting, right? Everything I talked about is before development starts. Yeah. But that's super important, right? Especially when you're an existing app with customers. Then you have this push and pull of existing customers and sales and presales and then kind of like what the founder or the product person wants. Uh, and then like if that person is different than what the business owner wants in your case that that's even different. So I'll pick it back up after you talk about from that point on. Yeah. When development actually starts in and what issues we've had there and what we're trying to do to improve. But I want to hear your side of that initial process. Yeah. For so I mean it's, it's changed a lot, right? So at the beginning it was me and Jonathan or they developer and we were just in slack and everything was in slack all the time. And we've grown up a lot. So we use notion for
Speaker 1 32:38 everything.
Speaker 1 32:40 Uh, we used clubhouse for awhile for products based off and we kind of, I actually loved clubhouse for product based stuff, but kind of found that everything living in one place was really helpful for the entire team. Having visibility to what everyone else is doing. And so we have like five or six different sections in notion right now. And the one where all of the things start is called product. And in there we have a, a page called pipeline. And, and this is all stuff that I basically run. And, and for you it'd be kind of a combination of you and your, your product person. But in there are like the really big picture, you know, product cycles. We don't call them sprints, we call them product cycles. And like for us recently, we just released this week a no credit card trial process. Right. And this is a, a big deal to take the credit card form away when you sign up.
Speaker 1 33:35 Like it changes. Unfortunately it changes basically everything about the, you know, the first like 50% of someone's experience in the app marketing and onboarding all this crap. So this was a really cool like microcosm of a product sprint for us. It was about a month. Um, but it really let us hone in on like exactly what our processes and a lot of stuff changed in that time. And it was really cool. So everything that could exist in the next like six months of development goes into the pipeline page. And then within there, everybody, you know, each kind of big idea that would be a cycle. It gets its own page. And, and for us Dev cycles or product cycles are like between two and eight weeks. This goes to the maturity of our app. I think as, we can't always say it's going to be six weeks cause some things are going to be two weeks in some honestly like we're challenging the eight week thing on this, uh, this product or you know, this feature that we're, we're looking to build is it, it just might be three months and hit the kills.
Speaker 1 34:36 It kills me. It kills me. We're finishing one up now and it just kills me. But, but, but it might really, really, really be necessary. And if it is, and if we all decide it is, then we're gonna we're gonna suck it up and just do it. But so we basically, we, we have like the product page and the pipeline in each of those kind of get details about answering a handful of questions and from let go, why are we doing this one? The, the three questions that, that have to have a yes answer to one of them is will this get us more customers? We'll let our existing customers stay longer or will it let our existing customers pay us more money? And really like from a business perspective, if the answer isn't yes to one of those, then it's a little bit of an intangible like where the manager of an open source process, a open source project with our, our wordpress plugin.
Speaker 1 35:26 And we have some things we should do for that, that they don't have any real business impact but, but generally like the answer has to be yes to one of those four something to get like on the page at all. And then from there we have a lot of questions around like who is this for? Uh, why are we building this? What will the marketing approach beats roll this out? So Denise on our team is going to be writing the, you know, the press release or blog post for something before it gets shaped at all. And so she'll write, you know, we're building this and this is for this type of people and it lets you do this and that's great for your podcast because of this. Um, so she's writing the, the pros basically of what a feature is. From there it gets broken up into kind of big picture things within like a feature and and from there it will get handed off to the Dev team and hopefully they kind of get the, the big picture from the blog post and the kind of chunks of you know, it needs to do this and the API needs to be like this and then they can go dissect it down further too to kind of like specifically what they need to do and we're letting them manage all of that in their own dove <inaudible> like Trello kind of board.
Speaker 1 36:42 That notion has, so that's our process and we're just kicking off another cycle with it now and it's, it's working out well so far. I mean, it's always a work in progress and we actually date our product process document and update it, update the date, like it's a, a privacy policy or a terms of service or something like that because we want to and we should like version control it or something because we want to know like this is what it is today. It's probably gonna Change next time. But,
Speaker 2 37:08 but this is like the current status at least. Yeah. I mean that sounds, that sounds pretty evolved for, for the size and age of your company. Uh, that's, that's pretty good. And especially that there's something about being forced to write this stuff out that is so easily driven past. It's so easy to just not spend an hour writing out these thoughts. But without that you start to layer assumptions on top of assumption. Yeah. And I think that writing is key to the whole thing. Being forced to explain it and then having someone else read what you're writing and, and, and being forced to communicate the nuance in something and the reasons behind it forces you to organize yourself and yeah, again, commend you on, on having that level of working done in the process.
Speaker 1 38:04 Well, it's, I mean it's, I don't want to say it's selfish, but it is re hopefully results driven in that we spend a lot more time than I would like. I don't know if we spend a lot of time relative to other products, but we spent a lot of time tweaking things in staging, you know, so the developer puts it up and says, Hey, here's the thing, go check it out. And I look at it kind of like you're saying and say, yeah, but this is just not what I wanted. You know, and I'm sorry that we just spent two or six weeks or whatever it is on this, but we have to go back
Speaker 3 38:36 and do part of it over again. So for me, like the desire to do all this work up front is for them to be happier to say, okay, you told me what to build. I built it and it's right. They have to feel a lot better about that. Then for them to build it and we say this is not right and we need to do it again cause that that has to just suck. That's, that's really something. Send it to avoid speed. I mean speed of like if we don't spend two or three weeks in staging for every feature, then it's out the door that much faster. Yeah. And we get, we get into this, uh, we put ourselves into a bad position in the past where we are community Katie with the customers and telling them when we expect it to come out because they really want it to come out.
Speaker 3 39:19 And sometimes it's, we are, we are rescuing people from canceling by telling them. And then when it gets onto staging, there's so much pressure to release it from existing costumers that even if it's not exactly what we wanted, the, all the pressure is toward just just release the thing. Ready. We'll fix it later. And that's, that's a, that's a bad, bad habit to get into. Yeah. So once you guys get, okay, we're going to build this thing, how does the process go and your case from Portland to Slovenia. Okay, so now I have a, a bit less clarity on this, so I'm, I might misstate certain things. Um, so what happens is, right, so we have a, we have backend engineers and front end engineers and we have a backend lead and a front end lead. And then we have our CTO. Uh, and then we have our to do QA people.
Speaker 3 40:05 And so there, there are there different groups and different teams and things start to get distributed between the backend and the front end. And you know, one person will have more expertise on payment processors. So if we have a payment processing integration, like, uh, after pay, uh, then that person's almost certainly going to get it because they have that expertise. So we try not to go too deep into expertise to make sure everyone gets a look. But typically that's something that'll happen. And one of the big mistakes that we've made in the past is, is around estimates. So, so rock will get the features and the priority list and the bug fixes and we will start to map those to where they need to go. And then everyone will start to get pretty full up on the sprint and they'll understand, okay, I have a six week sprint, here are these four or five things that I'm responsible for accomplishing in the sprint, outside of, you know, fire issues that come along.
Speaker 3 40:59 And so a few mistakes that we've made in the past is we, we're not nearly as disciplined as we needed to be on that prioritization. And we were also making mistakes around estimates. So first let's, let's look at prioritization. What was happening was that in those four or five things that an individual engineer is responsible for during the sprint, the way we've run the sprint says it's not all released at once. At the end of the six weeks, we do releases every Tuesday and Thursday. So things are being released on an ongoing basis, but the sprint itself is contained within that six weeks. And so if you looked at those four or five things that an engineer was responsible for, it's usually one of those things that has a higher business priority than the other things. And so we didn't really attach that to the list.
Speaker 3 41:51 And so it's not coincidental that that thing would the highest business priority. Sometimes as the hairiest thing, sometimes that's the most difficult task. And so what engineers would do is very naturally say, well I have these four or five things that one thing that's pretty hairy, I'm not going to tackle that first. I'm going to bang these other things out real quick. So then I can focus on that. And then what would happen is the non business priorities, things would get worked on first. They would get released, I would start to grow frustrated because the thing I really wanted to I think get out, wasn't getting out and then as we got toward the end of the sprint and things came up and fire issues happened and bugs came up and things start to take longer than expected, guess what was the most likely candidate to get bumped into the next sprint.
Speaker 3 42:37 The business priority, most important thing, the most important thing and so so we are along with doing more work. It's almost like we have like a come to Jesus a few days ago between myself and engineering team and the customer team, it basically said, look, the customer team is going to take on the responsibility of doing more work before it gets to you. That's our responsibility. Your side of the responsibility as the engineering team is to acknowledge the business priorities in that order and to not allow that float to happen. So it's like we'll do more work. You employ more discipline and it will lead to better outcomes for both sides and so so that that was the priority problem. The other problem was an estimate problem. And so we have, we have in our CTO, a very talented engineer. This is rock. This is you know, person that I've been working with for, for four plus years on the product.
Speaker 3 43:34 He has this amazing characteristic of optimism. You know, he's always optimistic. He can do anything. We can, we can get it done. We can do it. Don't worry, we'll make it. Yes, we're processing $5,000 a day right now. And yes, we're processing $500,000 a day, a few months later, but we're just gonna figure it out. Don't worry. It's all good. Along with that, optimism is a, is a real problem when it comes to estimates because when you're doing software estimates, you really need to put your doom and gloom hat on. And Rock isn't a doom and gloom guy. He's uh, he's an optimistic person. And so we had this tendency to, uh, to underestimate how long things would take. And the biggest problem we had a long way with that under arrest, a underestimate is we were not acknowledging the surrounding dependencies. And so we'd say this feature is going to this backend engineer and that's going to take three days.
Speaker 3 44:27 What we didn't realize was that yes, three days, but then it's go into code review with another backend engineer and then it's going to require another day of work on front end engineer to help, you know, get this thing into the product. And we weren't really do a good job of factoring those into the estimates. And so take that and spread it across four back and engineers and three front end engineers and everyone's got dependencies and everything takes a lot longer than you expect it to and everyone's being disturbed by the them being the dependency for someone else's feature. And so we, we, we, we hadn't broken up into teams where for this sprint, these two back engineers are working with this one for an engineer and all the dependencies are within that very small group of people. Instead it was like this crazy web and it, it's, in hindsight, it's not a surprise that things were underestimated.
Speaker 3 45:18 So we, we've had to, we've had to kind of clear that up too, to avoid all that hatching and crosshatching between, between people and since moving into kind of more contained groups than I would imagine, like the communication and the estimates are, are more accurate and concise. Yes. A I hesitate to say yes because we really have focused on this problem over the past, you know, sprint and now coming into the another one. So I don't have the confidence to say, yes, everything's better and we've, we've nailed it. Um, but the first stage is it understood, acknowledging it and understanding that it's a problem so that that has been accomplished. Now we're in the process of figuring out what the right solutions are to that problem. But the most important part was alledging it and understanding why it was happening. So that was that, that underestimation had that same effect of working really hard and then releasing something.
Speaker 3 46:15 But if you tell the customer team that's speaking to customers every day, that something code is coming out on Monday and then you don't release it until the following Monday, you messed up their life by by a week. Yeah. And so even though you worked really hard on it, you don't get the love back that you really should because it's like, damn, now I'm real stressed. So it's, it's a mistake on the customer team's part to set the wrong expectations for the customers. It's also a mistake on the engineering team's part on, uh, giving the wrong estimate on timing and setting the wrong expectations there. So we've just, we've tried to diagnose like, okay, if these are the outcomes that are happening and these are the resulting feelings and issues, like how do we peel back enough layers to really understand what we are doing wrong to cause that, right.
Speaker 3 47:03 It's not just happening. Like one of the first big realizations was, hey, we want to go faster, let's hire another, another engineer. And then what happens? Everything slows down. Like that was the first, hey, hold on a second. We're, we're no longer in the stage of, you know, a three or four person company and everyone talks and everything's quick and everything's responsive and you know, about a problem way ahead of time. Like we're no longer there. We're now officially in the organizational stage of things and adding new people no longer speeds things up in now slows things down. And so we need to look at this with a completely different set of eyes, much more critical to the inputs into the system instead of just <inaudible>
Speaker 1 47:43 just being upset about the outputs. Yeah, I know. I think one of the things that I've been talking to rob about, you know, as part of tiny seed is we are just starting to see some of our marketing efforts pay off and this is coming full circle. Don't worry. Uh, so, so it's like, uh, when business is going well, everyone's happy. Uh, and it a little bit is the product is probably like the most important single thing. And when, when growth is slow or businesses are struggling, all of us look at product and say if the product was better we could do x or we could do y. But when you figure out a way to, to make marketing and sales and growth work with the product you already have, then the, the demands on the product team and the development team is, is a lot less like you're, I'm more okay with something taking a week or two weeks longer if we're growing anyhow and churn is low and growth is high, I'm, I'm more okay with, you know, you want to add more tests or we need to get UI involved and doing this thing and it's going to take two weeks longer.
Speaker 1 48:53 No worries. We're going to be over here, you know, knocking out the marketing side of things and when the product's ready, that's great. It'll give us more ammunition to go do more of what we're already doing. But I, I kind of feel bad. Jordan Lake, we're sitting here, we're not dogging on like the development cycle and the product cycle cause it's like a real thing too. Manage. Um, like manage expectations of internally and externally. But I do think that a lot of us lean on the product maybe too much with respect to like our ability to be successful. And I like I'm pointing that finger at myself because a lot of the times I say if we had this thing we could kick ass. Whereas the, the reality maybe isn't always that the thing is holding you back that the product or the feature or whatever is holding you back. It's our ability to, it's like get out there and market. So like our, I know our development team listens to this podcast and so like I know that as we are doing the job on marketing, they're more happy cause I'm less anxious I guess.
Speaker 3 49:58 That's fair. It's a tough balance for us. I assume for a lot of B to B software companies these days, the product really drives the thing forward on revenue growth and marketing spreads the Gospel but isn't the driving force the, the product is still the driving force but it's fair. It's fair to view it as like we shouldn't blame the product and look to the product to solve our problems. That's, that's still on us. I, I have no problem saying that I've, I've gotten us into stressful positions based on business decisions, right? So we've, we have flirted with profitability and so we get profitable and then we push really hard on hiring and we're unprofitable and that creates a lot of stress on the product and on me looking at the product to hurry up and get better. We just went from profitable to not profitable with the expectation of the product going faster and then the growth going faster because of it.
Speaker 3 51:02 And so there's something to that profitable confidence of another layer of patients. Right. Not full patients. It's never, at least for me, I'm never going to be 100% patient with things, but it's not fair to just stand around looking at the product and the engineering team saying, hurry up. You're, you're, you're holding everything back. Like that's, that's more of a choice on the business side. Yeah. What I'd like to look at and tell people is look at where we are. Look at our trajectory over the past few years. Look at our revenue, look at the number of customers we're servicing. In reality, we don't need anything new in the product. Look at all these people that have been staying for years. Uh, we have exactly what we need to sell the product right now. Anything else is an excuse. If there are people right now using it, paying every month happily, then we can find other people like that.
Speaker 3 51:52 And so it's a cop out to say, oh, we can't grow anymore. Or we're still, oh fuck, we're waiting and we're being held back by engineering and the product. Because you have, you have objective proof. People are paying you right now for exactly what you have in production right now. That means you can get more people like that. So remove the excuse of, Oh, when we have this, it'll be better. Yup. Yup. But to your point, if you had this other thing or this integration or whatever, then then the growth can really skyrocket. Yeah. And I think that, I mean this is, this is a big realization for me is like you as a SAS business and a SAS application, you need to spend the first probably two years just putting out the fires, right? Your app is going to suck for two years and then at two years you can start having the patients, like you're talking about it, say, okay, we have customers, the house is not on fire.
Speaker 3 52:48 We can take three months to build this thing and we probably will grow in that time. And then once that three months is up and we have this other thing, then we can really grow. But yeah, I mean I think it takes time for those folks who are kind of just starting to say like, Yup, I just have to put out fires for the first two years and then I can get more strategic and patient about things. Right. Or you can go really slow, make sure there are no fires and maybe run out of money before you get there. Yeah. So it's, yes, it's, there's a reason it's not easy because these things are tradeoffs. Uh, and people look to raising money as, uh, an elimination should I wait to those trade offs? In reality, you just creating a new set of trade offs. So this, there's no escape.
Speaker 3 53:29 It's just hard. Uh, and you want to just put the characteristics into <inaudible> the business, uh, that give it more chance to be successful. And by that I mean the pricing and the market and the nature of, of its growth and does it have expansion, revenue built in and all these things. Like that's what I'm convinced I could miss. All the lessons I've learned from this software company are based around, uh, the characteristics of the business have so much to do with its success. Uh, the market you're in and the pricing and the right, are you making people money or are you solving a pain? Like all these different things add up to making you much more likely to succeed or fail then than just the actions of the people involved. Yeah, no, totally, totally. I mean, there's those intrinsic things in the business that set it up for success or not.
Speaker 3 54:20 So that's a whole, a whole nother episode. We'd love to, I'd love to have another time, but I know we've been, uh, we've been going on about this for a bit, but, uh, Jordan, I appreciate you coming on and chatting through kind of what you guys have been doing and learning and kind of where you are with the product process at Cart Hook for folks who I don't follow you online and stuff, where's the best place to connect? Twitter is the easiest for me personally just at Jordan Golf. Uh, if you want more podcasts stuff, we have the bootstrap web podcast, what we call the, the low light podcast where we uh, ignore any yeah. Highlights and really just talk about what we're learning along the way. Uh, that's myself and Brian Castle. And then if you're in e-commerce, checkout cart, hook.com and thank you again for having me on. No, it's my pleasure. That was my pleasure, man. Thank you for coming on and chatting and um, we'll catch up soon.
Speaker 4 55:10 <inaudible>
Speaker 0 55:11 thanks for listening to another episode of rogue startups. If you haven't already, head over to iTunes and leave a rating and review for the show for show notes from each episode and a few extra resources to help you along your journey. Head over to rogue startups.com to learn more.
Speaker 4 55:27 <inaudible>.
