Chris Spiek & Justin Dickow on Shape Up 2.0 at Autobooks | Shape up Practitioners #s02e01

All right, cool. So yeah. Hey, everyone. Thank you so much for joining the event today. My name is David and I'm a product manager from Germany and one of the organizers of this meetup series where our speakers share their experience with putting ShapeUp into practice. I'm going to play the part of moderator today and my co-organizer, Juan, will be running the Q&A parts of today's session. So over to you, Juan. Hi everyone, my name is Juan, I'm co-founder of Adnolinga and I've joined here David as a co-organizer of the meetup. I think you will enjoy it, this will be great I think. So if this is your first event with us you can find all of the recordings of past talks on YouTube. And we've had speakers from companies like Slide, Meltwater, FundApps, UserInterviews.com and more. So check that out and also join the discussions on the Meetup.com group or the ShapeUp forum. If you don't know these places yet, we've listed the links here. But enough of that, because we have two very, very exciting guests today. And I'm beyond honored that Chris and Justin from Autobooks have decided to be here today. Many of you will know Chris as founder of the Rewired Group, where he formalized Jobs-to-be-done theory together with Bob Mester in collaboration with Clay Christensen. And after that, Chris was head of product at Auth0 and now CPO at Autobooks. And one of the things I'm personally grateful for is how much effort you've put into sharing your insights and knowledge with others since kind of forever. be it in conference talks and jobs to be done the demand thinking youtube series turned podcast with ryan and now most recently your experience in evolving shape up so thank you for that and also with us today is just justin uh director of product development at autobooks and i'm particularly excited that we have these two perspectives here tonight uh the product side and the engineering side so this is going to be interesting and i'm looking forward to hear how this collaboration on how you work has played out inside of order books and yeah now hand it over to you chris and justin so please give them a big round of virtual applause um i wish i could see everyone yeah uh uh thanks for having us guys we we uh i've attended some of these in the past uh just really excited to kind of get the group back together here and share um some of the latest thinking because i think you know those of you who have been following ryan on twitter and linkedin and things like that know that it's evolving and we're We're trying to kind of push the edges of what ShapeUp is capable of. So excited to share here. Let me find my share button. Just to everyone to be aligned, you can post questions on the Q&A below. And also the chat is available for you to post questions there too. The Q&A lets you also vote the questions and come up. That's it. Fantastic. We'll skip our intros. I think you guys did a great job of introducing us. Again, I'm Chris. This is Justin. We're hoping to make this as much of a dialogue as we can. So we want to give a little bit of a background of the ShapeUp, of how we've used ShapeUp at AutoBooks initially. uh we'll kind of go through that quickly because i think everybody here is pretty intimately familiar with what shape up is um we'll get through through a walkthrough of a project using um i know ryan doesn't like the 2.0 where he's been calling it shape up in real life so shape up in companies that are not base camp and do not have all the sort of unique qualities that Basecamp has. So we'll walk through a project that we did recently here at Autobooks using some of these new methods. And then I think the intent with the rest of the time, we're open to get through that in maybe 30 minutes, 40 minutes. I know we've got an hour and a half. We'd love to get into what's resonating, what are you guys struggling with, and really sort of get into some back and forth conversation and see what we can discover together. So hopefully that makes sense. Like Juan says, as things are moving on, feel free to post questions and let's get into the meat of it here. I definitely won't make this a commercial for autobooks, but just to get our feet on the ground, I've been at autobooks for about four years. Justin's a little over a year now. Basically, our company provides ways to get paid online to small business owners. So I always tell people, think of like the guy who painted your house. your plumber, maybe your attorney, small B2B, things like that. These companies in large part are using PayPal and Square and solutions that are similar to that to get paid. AutoBooks provides a solution that allows them to send an invoice and accept credit card and ACH bank transfer payments that is integrated into their small business checking account at their bank. So everybody here probably has internet banking at one institution or another. So you'll go in, you'll log in, you'll check your balance and you can do money transfers and things like that. If you bank at a bank that has autobooks, when you log in, you'll also see icons for send your customer an invoice and accept a credit card payment. So we sort of enrich the checking account with receivables capabilities. Obviously the benefits are, you don't have to do the little dance between, okay, you paid me into my PayPal account. Now I've got to transfer it into my bank account so I can use the money. We sort of consolidate it all into one. So any questions about that, I can answer downstream, but at least you get kind of a general understanding of the product and how we go to market. When I got to autobooks, this is back in 2018, we were very agile based. um you know everybody kind of uses this this language around the paper shredder um when i landed um i immediately applied jobs so the the task at hand was sort of what's working and what isn't from a product perspective, we were able to quickly find some low hanging fruit just by talking to a number of small business owners that were using our solution. And we were able to bundle those up and get them into the existing process. And we were shipping, we were shipping upgrades. And they had the feel that you would expect from this process, right? We do a bunch of design up front and a bunch of scoping and we sort of put it through. And what came out the other side is like, kind of squint at it and you're like yeah this is this is fine it's not we're not shooting the lights out but it's okay it'll work um around that time oh yeah go ahead before i yeah this is one of those things where um i'm hoping that people can like uh at the end here chime up chime in uh the paper shredder is something that i don't think i personally had language for uh before i got to autobooks but probably resonates a lot with the product uh folks on the call basically being able to have your like long form thoughtful writing taken and wanting it to be like the real like source of truth of the work that the team does and then getting it like chopped up and it loses its essence is a thing that I think a lot a lot of people struggle with because of this like this divide that Chris is going to talk about a little bit between some product and engineering teams. And I'm hoping that we do a good job of explaining kind of how we got rid of that. That's great. And while you were doing that, I got to keep our screen sharing and I really screwed this up. You screwed up our screen. Yeah. Give me one second and I will recover from this. So this looks fine. Okay. Play. But then when I do this, why does it show up here? All right. What screen do you guys say? You're seeing the presentation. Yeah, the presentation. Oh, great. Okay. The green bar moved on me. Sorry, guys. Okay. So that's great. So we now have sort of language for what this paper shredder is. So around this time, again, I was working with Ryan. Essentially, this is my first call to Ryan. Hey, man, I think there's an opportunity for an upgrade here. It's at this similar period in time where he was working on his first version of notes for the ShapeUp book. So he ended up coming in. We used a lot of projects at AutoBooks to do the first version of the book and sort of do away with the paper shredder and get ShapeUp implemented at AutoBooks. And for a little over a year, we had good progress. So we had a product team who was leaning into both the jobs to be done side of things, understanding demand, um putting together solutions writing pitches getting them onto what we call the conveyor belt over to the engineering team that was like happily consuming them uh and getting them out the door um so we um we went from like a handful of projects the year before to i think we shipped like 21 or 22 projects the year after like good meaningful um projects that we felt good about um so we felt like we had had sort of um leveled up and then the the thing that happened is um the business grew right so uh we were adding complexity to the product and to the business in terms of who we were integrating with and all the different partners and payment providers and things like that. And the defense mechanism that we sort of started to fall back on was drifting back into Scrum. So as more and more technical challenges came up, there's basically defense and you can see, you know, these are Ryan's drawings from a conference talk that we did for a while ago. Now things are sort of starting to burst into flames on the engineering side and you've got product managers. starting to back up around, hey guys, we've got these ideas, we need to get them out the door, and the engineer is starting to play a little defense. We got to a point where we were basically so piled up, looking at the backlog on the engineering side, trying to sort of make sense of what this... what this was going to add up to, right? So we've got all this complexity, we've got all these items in the backlog and everything piling up. And on the product side, we're saying we still need to move the business forward, right? So everything that's on fire and everything that's being worked on, how do we make sense of it? And how do we sort of come to the conclusion that a month from now, two months from now, six months from now, we're actually going to have something that adds up to something that moves the business forward. And this has started to create a bunch of contention across the business. Ultimately, what happened was we experienced a period where we call it the breakdown. So we had a group of engineers that was now managing the demands of the business that had gotten larger and more complex without growing tremendously in size, because a lot of times you don't have the luxury to scale capacity. It doesn't scale linearly with your growth, right? So you've got engineers who are doing a great job sort of managing all the complexity. And what happened was they went into a defensive mode and basically any idea that we brought to them was just met with like, guys, we don't have the capacity to do this. It's not a good idea. Like we've all been in these sort of defensive situations, right? Like go back and keep working on it. And, you know, we've got the closed sign here. Basically, we were closed for business at this point. The other thing that happened is we encountered a situation where we had the opportunity. to increase adoption of the product. We did some early discovery on the data side and basically learned that we thought there was an opportunity to increase adoption about tenfold. So this is like us monkeying around with conversion rates and funnels on the product side, basically evaluating where we were at and looking at it and saying, like, we think if we make these small changes, we're going to be able to unlock the business. Unfortunately, like it's a great opportunity. It adds even more pressure. Right. So now we've got product managers saying it's our job to work with engineering to grow the business. We have this idea in front of us that's going to be able to unlock this potential. And when we look at our engineering counterparts, you see the picture on the right. All hell is breaking loose. Right. They've got it under control. Nothing's crashing. But it's like, guys, we've got all these plates spinning and we need to keep this going. And we know you have this great opportunity, but like it's it's just not not going to happen. Yeah. Good. Yeah. So. This was my like this fast forward two years, right? This is my second call to Ryan around basically, look, we did shape up initial version. We had a bunch of traction. Things were good. We grew the business. And now we have so much complexity going on that like, how are we actually going to sort of break through this? And the interesting part about it was Ryan had been talking to you guys and talking to a bunch of other companies trying to sort of sort this stuff out. I got him on a plane from Europe where he was at at the time. He came over and spent a couple of weeks with us basically going through interviewing engineers, interviewing product managers and sort of doing the discovery work around, okay, guys, like what's actually going on with the technology? What's going on with the business? And how do we break this apart? Yeah, I can talk about this a little bit more. So when we started this, and I think this is really where the next version of ShapeUp comes from. the insight that we immediately had was the the shape-up version as it was written was not was not this like one size fits all thing and that we actually needed to do we needed to do the product thing on the way that we were working not just on the products that we were building so when we brought ryan in we did that we interviewed everybody we talked to engineers we talked to product managers we recorded the pitch meetings that were happening we were hearing you know live the feedback without intervening that the product management team was getting from engineering and we were uh really investigating why the engineering team was firing shape up and why uh the product team was like failing to get their work prioritized over all of the other things and all the other inputs in the business uh some of the stuff we saw was uh it was pretty cringy The teams didn't speak the same language. What sounded like simple conceptually and some of the documents that were being around had a, they were shrouded in technical complexity when you got them in front of the engineering team. Basically, every meeting between the teams was raising more questions than it was answering. And the more questions that we had that we had to bring back or that the team had to bring back just meant less product work was getting done. At the end of the day, I think that we'll get into now, the underlying problem was the interface that ShapeUp had given us to grow to this point didn't evolve as the company grew and as the company changed. Yeah, this is a great. So this is a great graphic. You can speak to this as well. So it took us a long time to. So like you have to peel back the social aspects of this. You have to peel back the emotional aspects of this, Greg, because everybody's pushing on the same direction on all these teams. And yet somehow we're not able to collaborate the way we could a couple of months ago. Right. And the thing we uncovered was what Justin described, which was. At a point where there is any semblance of calm, products could do all the discovery work with the customer, could come up with the boundaries of the idea. And Ryan has drawn it so great here. Basically come up with this light bulb and like, look, we have all this description about our idea and like, let's start to think about it. And the engineers would come in and they would unpack that with us, right? We've got the time to do it. We can come in and we can sort of work together to figure this out. that context is gone when the backlog is full and we've got all this technical complexity to manage. It just took a while to sort of peel that back and come to that understanding. Yeah, this is something I actually think I had a hard time grappling with this actually coming into autobux because we, in previous teams, I think were shipping fairly consistently, four to six week cycles. All the product managers were working on the same cycle, even disparate teams were working. you know like the conveyor belt was working um but i it might have been that the growth of autobooks at the point that we were taking it was like they were just disconnected like autobooks was growing way too fast compared to engineering the actual people that would be involved in unpacking these ideas with product management where now everything was competing for their time so there was there was no concept of like a engineer who was not in the critical path of like the day-to-day things that needed to happen in the code base. Everybody was. And as many great engineers as there were, there was just, there was no time for, I almost want to call it like hand-holding, like helping the product management team get their stuff over the finish line while the business team was getting their stuff over the finish line while the legal team was getting their stuff right the design team everybody um and so that was really like the uh i think like digging a little deeper into the into the problem one of the things that we were seeing yeah that's awesome the the way we went about so this is sort of like skipping ahead the way that we went about solving it was adapting the process so that we could approach the engineering team uh with something recognizable on on their side so we essentially had to change uh the input here the way we did it was we we introduced a new role essentially this is uh one of justin's creations here uh basically coming up with the title and a set of work for a specific person to do. We now have multiple people doing this role that we didn't have before that was going to bridge this gap. And then introducing, you know, we've always had shaping in shape up, obviously introducing this notion of framing that we're going to talk about and then being very deliberate about how we go about spiking. Yeah, I can actually a little bit about what does it mean that the inputs needed to change? We weren't getting the right inputs. Again, we did a lot of work into figuring some of these things out. So some of the actual work items that we found that were missing from the old version of ShapeUp as the work was being delivered to the engineering team in this, like in the growing company, they were missing like business context, like the stories and the anecdotes that would really rally. not just the engineering team, but everybody around the problem, right? Like what makes this thing more important than all of the other things that are going on? The language of the documents that were being passed around hadn't actually evolved with the system. So there was an old language being spoken by the product management team where the internal system that had changed in the code base itself had evolved, right? And so there was a divide between like who's actually able to speak the language of this thing. There was the level of technical detail in in these inputs to the engineering team weren't keeping up with other areas that were like purely technical work that was happening. Right. So it was a lot easier for the team to commit to doing a technical task because the technical task was understood versus product work that the business wanted done because it had such squishy boundaries around it. And then I think this is like actually really important. The way that they were presented was that there was no room for like incrementally improving the system during the project. It was as if doing technical work needed to be put aside and like done some or yeah just stopped and everything that was happening within the product work would be like a create technical debt and it was a that's kind of like a weird um everything is selling right but you have to like you have to actually sell that into the projects uh in order for the engineering team to buy those things yep i think that makes a lot of sense so the first thing we'll dive into is sort of the notion of this this product engineer i think the the core concept here is that we essentially, in order to bridge the gap, pluck somebody out of engineering on the senior side and embedded them into the product management team. So I think the goal here is twofold. And you should expand on this a little bit more. But the two things that we noticed right up front were, one, the language piece. So if we didn't have somebody that understood the system language, that can help us on the product side clean it up. And we'll give some very concrete examples here coming up. Like what's the actual name of this route? What are the different variations here? You can't just sort of put some big placeholder there. You have to be specific about it. And then the second one is just to add to the rigor around data and analysis and things like that of like what we're going to try to go do. Yeah, I think there's a number of ways to accomplish this from like an organizational standpoint. You might see, in some engineering organizations there has been a like a uh an imaginary barrier that has somehow caused some engineers to have the time to work with the product management team in our in our specific case we literally needed to like decommit people from like day-to-day engineering tasks and the best way to do that was all right guess what guys like you actually you're actually accountable to product now um I think that was what helped us there, but there are multiple ways to accomplish this. The other sort of step was... Can we stop there? We have a few questions. Yeah, let's do it. About the product manager here, Klaus is asking, do you rotate the role of the product engineering or is it permanent? We haven't yet. I don't think it's because it's a bad idea. I think it's because we're probably so early in this and maybe like enamored with the results that we're getting that we've probably got about a year behind us since we have all these changes. We've got a couple of people doing this role and it's still it's defined. But I think we're finding like they're getting their feet on the ground. They're getting good at this. It might not be. You've got a job description, but it's I do. He's got a formal job description, but it's still we haven't stepped into like rotating people through it. Okay, perfect. And here, Heiko is asking the organization size. What is it? How many engineers versus product managers? Yeah, we're at like 140 people total as a company, still very small. Three product managers, two product engineers, and there's like 30 to 35. engineers, not all of that is dedicated to product. There's some infrastructure things and things like that. Good question. We probably have around 10 engineers actually working on enhanced projects. What are your thoughts around the rotation of the product engineer? I think the way that we've define the role it's a uh it's something that could be permanent um i think there's like a path from like product engineer to like uh like product architect right like there's a there's a trajectory there that is like you're not necessarily responsible for like completing uh work in the cycle and like building out the projects but you're also not like doing the product product management thing you know i think um there's like i'll say like three verticals of things that need to be done one of them is somebody has to define like what problem are we solving that's like product management like talking we're talking to customers right there's a huge demand side component of that one is how are we actually going to solve that problem that's the product engineer role that i think there is a in our organization, at least a permanent place for. And then there's the engineering role, which is, okay, like who's actually going to implement the solution. And those are like really, even though they overlap in terms of like interfaces and collaboration are three distinct responsibilities that people need to be accountable for. Yeah, it feels like to get into this role, there is learning, right? So these are the kind of meetings that we have. These are the, um responsibilities of the different people in the meetings these are the two like we're big lucid chart people these are the tools and tablets and things like that you got to learn to set up spikes and do things like that i don't think i think rotation would be fine it's clear that we would pay a tax every time we did that right we would have to like ramp somebody up into that role and at our size and the speed at which we're growing i think we've just been unwilling to pay that tax um but it is interesting if you got a little bit bigger and you have the um the flex to be able to do it, it's probably a good idea. Yeah. I also say, too, I think we preface this with, you know, this is somebody in our organization who already understands they understand the system, right? They've they've actually done like the hard work to know the system language, all of these things. So the product engineer, even though it is like adjacent to both of these things, it was plucked from the engineering team as like a more of like an almost like an elevated position. like you actually have you know all of the things that you need to know to already be able to do very senior yeah yeah it's hard to do this yeah exactly yeah i have one more here maybe this is a bit uh a question more complex but from ryan hutch that he's curious about the organization structure sounds like the product team is separate from engineering team any reasons why they are they were they kept separate and not integrated earlier why they were kept separated. Yeah, I think that's right. So, hey, Ryan, it's been a while since we talked. Great to hear from you. So, yeah, I think it was a decision that was made early on as the company started growing, you know, past the first 20 or 30, I'm like employee number, I want to say 30 or 35 or something like that. I came in as head of product and essentially met with my counterpart who was, chief technical officer, chief technology officer. And both of us were basically at that point just drawing from our experience of when you do combine the roles, like the pendulum sort of swings, I guess, is it still swinging now, but it's just tough to have the voice of the customer represented when technical complexity goes up, when you need to wrestle with the system all the time. So combining them, it feels like you're always sort of drifting. towards the technical realm and away from the customer. So we made the decision that my role as head of product was going to be very outwardly facing, right? It's my background to implement jobs, to get the demand side down, to really make sure that we're steering this thing towards creating customer value and that we have good tension between us about you know, maintaining system integrity and security and all that sort of thing. We're in a highly regulated industry, so that stuff can't fall down. But we have sort of the two anchors pulling against each other. Yeah, I don't think there's anything like it's very contextual to, you know, make that kind of organizational decision. Autobux has a product-led growth organization. We talk to customers, right, where we have a product that we actually have to implement. Adam Finkelstein, Product Management Practices that go way external to engineering and that overlap is. Adam Finkelstein, Probably something that is important to keep separate if you're building a SAS product. Adam Finkelstein, Where your customers are engineers then you're probably going to have product managers that are engineers, you know the organization is probably going to make more sense to keep as one I think it's just really contextual yep yeah good question oh there's. There's a lot of good questions. There's a lot of questions regarding the product engineering, but maybe there are a lot of things to talk about, so maybe we can follow on. What do you want to do? If everybody's okay, let's dive into some questions. We can always come back and wrap up. The hard part about the presentation is Ryan and I gave it as a talk at a conference. It's unreasonable to ask everybody on this meetup. to have watched that. So we wanted to make sure we at least gave people opportunity, like here's the background. But if we're diving into the questions, it means that people know what they're talking about. So let's let's dive in. One of the questions here is that if you are not afraid that product engineers losing touch with the code base when they are not implementing larger chunks regularly, how do they stay up today with a code base if they are product engineers and not working? This is good. So even though their responsibilities are, and maybe we'll probably could get into a bunch of this stuff, but the responsibility is not necessarily like a, I'll say it's not like a software architect role, right? Where it's like, broader like whiteboard drawings about like what we think we should do and then like somebody goes and implemented this uh this role is like very very deep all the time in the code base but in a way that their customer is the product management team so like when when we're running spikes for example uh it can be a product engineer that is actually writing the code to make sure that you know something is going to uh is some is going to work a specific way in the future or answering a specific question about how we're going to implement something um and those types of details because of the complexity of the system that we're working in and really the industry and like the payments and banking industry for us that we're working in they are um they're prescribing almost in in the more important ways, how those things are actually going to work and be implemented. I'm going to go back to the deck here. If I can figure out the buttons to click. You did it again. I did. I did the whole thing. Okay. You guys can see. So this is one of the interesting things about framing, right? So we're getting back to the project that we talked about in terms of optimizing onboarding, right? So we've moved from... shaping, which would theoretically in the previous world end at, guys, here's a funnel, remove this step from the funnel, and we're going to see adoption increase 10x, right? Because we've looked at Google Analytics and full story sessions and amplitude and like, but now we've migrated to this session where I've got a product manager, we've got the product engineer in the room, and we're basically saying, okay, product manager is presenting this. I think I can take this step of the funnel out. Like I've done the work with the legal team and our partners and everything like that. It's fine. Now can we actually figure out what's technically feasible? And to Justin's point at that moment, we're, I always stress the point, like we don't need to talk about the work we need to do the work. So everybody gets the laptop open, share all the screens on the, on the big monitors and let's go. And then it would be the product engineers role to say, okay you're pointing me to this part in the funnel let's find that in the code let's find the data model that connects to it and let's figure out sort of what is what in terms of getting into the actual system and then no i can't advance the slides and then this is the thing that comes out of it that i think is the interesting part is like specifically in this project we looked at okay let's remove this stuff in the funnel And we ended up basically saying there's not one onboarding funnel. There's 10 onboarding funnels, right? Like there's complexity in this code. It routes all sorts of different places. But then we've got somebody technical enough in the details that are highlighting those things. And then we've got a product manager saying, OK, I can look at the data. And I know there's 10 variations. But if we just do these two variations, I'm going to get to 80% of my outcome. So we've got this dialectic going back and forth of. what's technically capable and what's good for the business. And I think that has a lot to do with the question that was asked, right? This isn't somebody who is sort of like drawing up charts and thinking about it in theory. This is somebody who is capable of actually going in and saying, I can uncover how the system works in this area that we're interested in, and I can have a conversation about it. Yeah. I think there's a big detail here where that's actually in contrast to maybe the original version of ShapeUp, which in the original version of ShapeUp, there was a lot of detail around the trade-offs that you make within the cycle, basically. And what we learned was there are a lot of trade-offs that can be made that actually impact the business outcome that we might be okay with. that need to be made before we even shape the solution to the thing. So in like Chris's example, you know, there's like all the if we burn down the entire onboarding problem right now, we're going to well, 25x our enrollments. But as we start to look at it and we realize we realize there are actually different ways to slice this problem, we can take out, you know, We can do a 10x improvement if we do it in this specific way and we ignore, you know, these things. And if we do that, maybe that actually gets us enough of the enrollments for now that we can actually ignore the onboarding problem and like move on to another problem and start slicing and bringing another problem. And that's, I think, well. beyond their question now, but I think we're back into what framing is. No, no, I think it's important though, because this is all of the, if you guys think back to the image of the light bulb versus the image of the triangle that the engineer could measure, right? We're now sort of clearly articulating what that contrast is, because to throw this over the wall in terms of guys, we're going to, to your point, 25X, before we get down to the scope, 25X onboarding, can you please make this happen? The engineering team is now beholden to like, okay, I've got to uncover every path. I got to find, is this really opportunity? And how do all these things work together? We've now sort of moved this up into the framing world. We've narrowed it to a point that the thing is concrete enough for the team to really, really understand what's actually going to change when we're done doing this versus... here's like the whole big problem. Here's some data that shows you that it is a problem. Like go like do some arbitrary amount of it. Yeah. That's huge. Yeah. There are more questions. Are you moderating this thing or is Juan moderating that? Somebody is. Are you guys moderating? I'm reading the questions. I love these questions. There is no question. There aren't any questions around the framing, but Ryan Hatch said he loved this. That's awesome. But maybe we can go on with the next slides. If you people have more questions, please make them. Yeah, there are two questions in here, but one's about cool down, which I think we can answer that later. One is, yeah, I'm moderating. One was about the product engineering that was before, seniority and certain skill set, what seniority the product engineers have and skill set. And in adding to that is how do the product engineer role compare with the technical lead roles? Oh, that's a good one. How does the product engineer role? Compared to the technical lead role. Compared to the technical lead role? I think you touched on this in the past in terms of... The product engineer is figuring out what needs to be what needs to be developed. And if it's technically feasible, working with the product manager to understand, like, this is worth doing. This doesn't have any sort of danglies that are attached to it. The technical lead is responsible for actually building it and implementing it. So how else would you distinguish? Yeah, I think these are other people are going to call the technical lead role. I think something a little different. But the. those two roles are very much in partnership, right? So there's not like a, in the same way that there shouldn't be a, you know, we throw the pitch over the wall from the product team to the engineering team, the implementation details that are like invariant to the solution success are not just like being thrown over to the wall to the engineering team either. Those are more or less developed in concert with that. technical lead role. And I think if we do get into like what the questions about cool down that all like how that collaboration occurs, we can get into more detail. But yeah, those are those are like partner roles, really. But in terms of like coordinating the engineers on the project, tracking things like we do use the hill chart tracking things on the hill chart. unblocking people from a technical perspective like that's all on the technical lead and then when it comes back to you know hey when you were framing this thing how did you decide that this was the thing to do or this was capable or that this was possible that's when they're pulling in the product engineer to to sort of provide clarity there um yeah i think so the way that we talk about the biggest contrast and then we can move on uh is the the product engineer is really uh does the majority of their like deep technical work out of cycle, which is a project has not been committed to yet, but they're working on the technical side on it. Whereas the actual technical lead does the majority of their technical work in cycle on a committed project that we're definitely shipping to production. Yeah, exactly on time. Every time. Every Tuesday before the leadership meeting. So we can say that it would shift. Sounds good. And regarding the skill set of the product engineering, do they have any different skill set than the tech lead? Do they have like a more product mindset or something like that? So while you think about that, just because of our, maybe just because of our stack, very, very strong from a data perspective. So being able to assist the product manager in confirming assumptions and things like that, just in our data model. and in our analytics uh sort of things like you said a lot of system knowledge so it'd be very hard to i think come into the the business and right away become a product engineer um it's a good question on like the customer side and the product side i mean um like justin was the first one so he came in and defined the role and he like you and natalie have product intuition and product background yeah i came from a product background but i don't think um i think this role is like more or should be coming from an engineering background. I think the criteria is going to be based on like where in the stack is the actual complexity, right? That's where you're going to focus on. Like for us, a lot of our complexity is in our data models and it's in our backend and it's in how we interact, like how our systems interact with our external partners and integrations and things like that. So that's where we need a lot of focus from the product engineer and it's a lot less for example on like our front end or our ui um you know and like figuring out what's possible there but others might have more complex you know ui and they do everything on the front end or something like that and that would be a good criteria for it what do you think about like um like personality type is not the right thing but like um the types of problems that people are interested in solving and and like putting that person in a product engineer role versus a technical lead or just a senior engineering. Because there is like a I get to start it and I get to figure it out. I can't finish it. Like I can't actually wrestle with all of the like nitty gritty technical complexity. Yeah, I think that's a hard one because this is like now we're talking about some like imaginary, like ideal person. Right. But the idea that you care. That that the. technical aspects of it are the means, right? And that you have like the ability to like let go of the thing and let somebody else be responsible for it. And like trust that you put your fingerprints on it enough that somebody else can get it to the finish line and you feel good about that. Yeah, there's like an enjoyment aspect to it that I think you really need to get right or you just got people that are like not satisfied in their day-to-day work all the time. And that might just come through experimentation because it's not imaginary. I mean, and then I guess at the end of the day, like some of the, even some of the framing sessions that we come out of, like the team is like really excited about the work that they did there because you can, sure, like you didn't yet ship code to production, but we just, you know, came up with something that the entire executive team is going to see. Yeah. Right. Like there's like proof on the table about the thing that we're going to do. And we feel really confident that we're actually going to achieve a business outcome. And caring about that, I think, as the product engineer is really important. So at the end of the day, that's what it's about. Yeah, I can't really stress enough about what was on this. I'd share it if it was easy, but I'm so bad at this. Why do you keep not sharing? Because I think they can see us better. Oh. And maybe that's not. I think they can choose what they see. I'm trying to be helpful. So I think the. The satisfaction of coming out of this cannot be understated, right? Essentially starting with something that is, wow, this is an amazing idea. We're never going to be able to pull this off. There's so much complexity that this is a mess. And then to be able to fight through that in a number of hours, this actually turned out to be a number of days, but two or three hour chunks to come to the other side to say, we don't have to do all eight variations. We're going to do one or two. which feel very at hand and we're going to get the outcome that we want, like that, that is a, it's a huge win. And if you're the type of person that geeks out on that, that's, that's big. So this is essentially on the, on the shaping side of things. We've got the output, right? If we can skip, skip onboarding for partner B, we'll get to a 10 X increase in enrollment. So we've now we've gone from all the variation. down to one narrow path that we've framed to. And now we're on to what does skip that onboarding step actually mean? Right. So now we're getting into what Justin always talks about in terms of speaking the system language. So I don't know. Do you want to speak to the product engineering work that goes into this? Yeah. So I think essentially what we did and again, like the project that we're talking about, I think was really like the learning project. So we were really learning while we were going here. And this is one of the areas where we immediately discovered when we pulled in, this was actually before we had an official product engineer role, when we pulled engineers into the sessions, what we call the shaping sessions, before we were ready to commit to work. So this was kind of like step zero we actually needed engineers before we even had them yeah when we started pulling them into these shaping sessions what we discovered was that the language that we were using to describe the thing that we wanted to do was not how the engineer described what the thing was and these are like examples abound right so uh you know we're saying we'll just like submit this we'll submit this form automatically right well what does that mean like submit the form automatically there's an api to submit the form and that happens to be one api at one route but there are in the ui there are three pages that the user has to go through you know to uh to submit the form okay well which which thing are we actually talking about you know well we're talking about the first page uh if we can just submit the first page then we'll get the improvement that we're looking for. Okay, well, you can't just submit the first page because all three pages are tied to the form, right? So this is like really digging into, you know, what we're talking about is pre-filling these values into those fields and for the specific circumstance for these partners. If we can do that, then we won't. auto submit the form we're going to send them directly to the second page so that they can finish filling it out and when it is submitted then then the values will be pre-filled and then when you get down to that type of detail with the engineering team and this is also something that um you start to like build trust around these things right you present that to uh the engineer that has actually worked on those components and he goes Oh yeah, like I actually know exactly what you're talking about. I can totally pre-fill those values. I'll skip it every time they're filled, right? And then we can like move on and ship the next project. Yeah, it's important. And you can feel like even how hard it is to come up with language to describe this stuff. Like we're talking about three pages to a form. There's actually names for each of these pages of the form in the code, right? So once we tease that out to say like, this is what these things are actually called. this specific thing is what we're working on. And we could like, it just takes it to another level. So this is sort of the whole, the goal, right? We went from a wide product opportunity to a narrow slice that is doable in the time that we want to spend. Right. So we haven't totally done away with the concept of appetites in this whole thing. And then on the shaping side, we worked out the main elements of what we have to do technically to make it happen. So if we can skip onboarding step for partner B and then in order to skip that onboarding step it's pre-fill step two we call it the primary demographic form that's like that one little slice of the whole onboarding flow right if they're in partner b using this api for this data source we've got it down to technically uh what we can do the other piece that's really important now is the spiking piece so what we've determined is um we can't go about doing the work until we carefully craft work for an engineer to do to basically go in touch the code and validate that the thing that we understood in shaping is is technically impossible here right so figuring out the assumptions the the most important thing that we do and I think so a lot of engineering teams have have a concept of spiking right it's I think in the in like Giro world it's like a little question mark and you like go answer a question and you don't necessarily need to ship anything. When we redefined spiking what we learned very very quickly was spiking failed every time we asked a yes or no question because it's very easy. for somebody to say yes or no to any particular question that you ask without proving that their yes or no has like the rigorous like information backing it. Not out of malice or spider. And it's like, is this going to be easy? Yes, it'll be easy. Is this technically possible? No, it's not technically possible. It's just we're just asking the wrong questions. Yeah, so like an example here. So we need to, you know, to make sure that we're getting specific data to pre-fill these values, right? So you could ask the question, like, do we get the user's email every time from this specific integration? And that's like a yes or no question that somebody could very easily say, you know, yep, we get that. What what we do instead is we go internally we'll go that's the question that we actually want to answer. But how do we frame that question in a way that somebody is going to be more likely to actually just send us the data so that we can answer it quickly or so that we can we can actually have that. Make sure that the rigor actually happens behind those those questions. And then 1 other thing about the spiking thing. So this was, I think. I gave an example of a data question. A lot of engineering teams have spiking as like an engineering, it's like an engineering activity. But what we learned was that spiking is something that happens in basically every aspect of our business. So there are engineering spikes where we need to write code to go prove something that something can work. There are legal spikes where we need to go, you know, talk to a lawyer to make sure we can do something. There are business spikes to make sure that we if we do do something that our partners are going to be okay with it. And so there are design spikes where we're going in not doing high fidelity designs, but we're coming up with a ton of different options to make sure that we can actually design the thing that we're talking about. we're not committing to a specific design, but we're proving to ourselves that we actually can do something. So spikes are not an engineering specific activity here. And the thing shared across them, right, is show your work. Like the culture is very strong around come back with your pseudocode, your actual code, your query and the data that resulted from it. It's just been something that over the past. whatever, eight months, 12 months, we've leaned in on. I keep talking about Lucidchart, dude. There's a lot of tools. We do use Basecamp for the Hillcharts and things like that. But we've gotten really accustomed to piling everything into one giant Lucidchart since it is infinite, where we can say, like Justin said, there's a technical spike here and you'll see an arrow to here's the code, here's what I figured out, here's how we'll solve this problem, or here's the database that sort of stores this thing. Here's my query. It's over the last 90 days of data. And here's what we were looking for. Here's the output. And then on the business and legal side, here's the email where I went back and forth with the attorney and how they said that we're going to, you know, this is the language to get around this. And we're able to very quickly see that, okay, we're moving through this. We've got this into a shape that we can start to sort of select paths and move forward through. I think we covered this. No assumptions or hand-waving. Prove it by showing the work. So essentially this is what we've arrived at, right? Framing from a big product opportunity into something narrow we believe is going to be feasible. Shaping that we worked out what we'll actually do technically in order to make it happen. And then solving unknowns. And essentially, you can see this. We do this as a loop, right? So we get product opportunities. We shape. We spike. We run into something that we can't overcome. We go back to a different shape. We might go back to frame something else. It's kind of an ongoing iterative. uh iterative process i just very quickly like the the outcome here is the interesting part right so the first time we did this this is coming out of the work that we did with ryan package built and shipped on time you can imagine the contrast right so we had gone from shipping quickly over a year period of time feeling tons and tons of project progress to things starting to pile up to total like blockage, right? We're not communicating, we're keeping the business alive, but we're not growing as fast as we can to now all of a sudden we have arrived at shared system language, we're framing, we're shaping, we were able to build. The interesting thing on this slide is we got this out, we did achieve. So like this is a year ago in round numbers, 30 signups a day to 300 signups a day through the course of one project. And we had an engineer that had just joined the business. who got pulled into this right as it was starting. And his comment was, I shipped code that got celebrated at our all hands meeting by our CEO before I finished my onboarding training from HR. And it was like, this was the elation from him of like, I wasn't sure if I'm coming into a business where, yeah, go work on this side project and that'll get you familiar with the code base. And then you can work on the real stuff. He's like, somehow you guys pulled me in, you got me right into the meat of it. And I was able to move the needle. legitimately on on day one and i'll say that the the projects like this are it's not always 10x growth but they're the norm not the exception uh from where we are today do you want to add anything about no that's great i think you know at a high level this is what we what we talk about so a product engineer and a product manager doing the framing pulling in subject matter experts contributors engineers to help shape and then and then do the spiking, this is really our cycle that we've kind of leaned into and leveraged. That's gotten us through the presentation. Juan, you want to dive into some? Yes, perfect. There are a lot of questions here. Regarding here, there's a question that is, are you using the appetite concept still? It feels like you are roughly fixing scope schedule. Is it indeed so? I guess you still have quite some flexibility in the project, otherwise you wouldn't look happy now about how much and where. Mostly the appetite there for the shaping, framing and spiking, is it involved the appetite there? Yeah. We do fixed time variable scope projects with appetites attached to them. I think the difference right now, in what I've seen in the past is the appetite, the appetite doesn't come at the beginning of like framing something because when we're framing, you know, like the example that we talked about is something that was like framed in a vacuum and wasn't like we didn't talk about how it was, for example, prioritized against other frames, but there are Once we get to the point where we're going, okay, we're going to actually like this is we're shaping like we're going to do a bunch of technical work to figure out whether there's a feasible thing that we can do. At that point, we're assigning basically an appetite because when we're coming out of the frame, what we're basically saying is in the example we gave it was like pure arbitrage, which was amazing. But in most examples, right, we have like a demand side thing that's occurring on the job side. We have like some, you know, some cohort that we're going to be solving this problem for. And so coming out of framing, we have a business outcome that we're actually going to try to achieve by doing the product, by doing a project. And out of that, we're going, OK, great. If that's what the outcome is, then here's the amount of appetite that we have for that outcome. and which I think has actually helped a lot. Yeah, yeah, I agree. So I think the other thing is, I think what we found, I've been talking to other people about this as well. It feels really important to be disciplined about the appetite when you're moving from the agile sort of constant two week sprint into um something where you're going to give people uninterrupted time like we need to like put off everything else this is the appetite and we're like really rigorous about defending their time and making sure that they hit the goal and they're comfortable peeling back scope and things like that um we i don't even know how many cycles we've gone through at this point but we've gone through so many that i think we've gotten comfortable all getting together saying This deserves this appetite. This is worth the commitment. And then we there's there's more fluff now. Right. So we will we'll miss a delivery by three days. Right. And we'll say, well, this person was out sick. This thing caught on fire and it took us a day and a half to put the fire out. And we've sort of like earned. the right ourselves to be able to say like this is a little bit flexible whereas previously um we would be looking at the calendar saying like there's one day left guys what are you cutting and circuit breaker is tomorrow um because i think you have to you have to get the rigor to sort of build the trust and build the system whereas now there's a little bit more flex if that helps Yeah, I think it's a mistake to actually like if you don't use Appetite right now or if you don't do fixed time variable scope projects and you are thinking about doing that, it's a mistake to go. We have three weeks on three weeks and one day like we're canceling the project is like not the emotional thing that you want to put on anybody. Yeah, there are everything. I think everything is selling. There's a way to. introduce that concept that has the accountability that has like a little bit of flex in it that people still people will everything is like these are all arbitrary barriers right time is an arbitrary barrier to project like shipping projects yeah so you have to sell it in a way that you know people feel accountable to that thing but not that you're gonna like straight up cancel a project and you also need to then do retros around shaping and spiking like if we got i can um reflect on the times that we've gotten burned. We had one six-week project turned into a 12-week project that eventually got shipped. And clearly we had missed an entire, we had an email service that we were going to need to be interacting with that, you know, we got to the end of this thing and it was, okay, add the transactional email, that'll work. And that was not the case. And we just got burned. Well, that's an unknown that, you know, in retrospect, we needed to burn down. Yeah. I think the, one of the ways to do that is like, when you're doing those retros is actually taking the accountability as the leaders of the product and engineering team. Hey, Bob. Everyone's here. This is great. As the leaders of the product and engineering team to... If it took six weeks and it was a four-week project, then... where did we actually mess up yes right not like oh the engineering team like didn't make enough trade-offs or you know the product management team like didn't fit the scope like correctly into the box we actually screwed up on the way that we like went about executing that thing and so like we actually need to iterate on the way that we work to make that better um Regarding the framing, here Christian has a question. How do you know if something is framed and passed to the other side to the shaping process? And do you have an output there? Yeah, it's framed. I think the test is, yeah, this is a good one. I think the test for me is a business outcome attached to a level of rigor that we all believe in. So I think that a lot of times things fail on, So we've got one idea that just keeps like ping-ponging around where I keep getting pulled. And it's not just my call, but I keep getting pulled into meetings where it's like, guys, like, I just don't feel like you keep having jobs conversations and you keep having customer conversations. But when we actually get down to like, here's the thing that we're going to go build. regardless of shaping like the actual technical details here's the thing that we're going to go build to go address this demand and here is the quantitative um upside of of what we're going to get out of it from a business perspective or here is the learning that we're going to accumulate through this prototype and through this shipping like i i i've probably been in and this is healthy right this is good because we're not expending engineering resources on this we're just like talking about this as a product team i've probably been in three four meetings about the same project And it's not just me, like where everybody is saying, where is the where's the meat here? Right. Like we know there's something here. We're hearing it from the customer, but we have not been able to sort of put our hand on what the upside is and what shape the solution will take. And it would you characterize it? It hasn't moved past framing. Like you keep messing around in the database, watching full story sessions, talking to people, like doing the doing the stuff. I have to go cancel a bunch of meetings that Chris doesn't want to. We're just going to do it next week. It's great. There's a so the answer to the question matters a lot, I think, in the context of your like specific business. So autobooks specifically like we have customers, we have small businesses that are being paid on our platform. We're actively growing like we have a lot of data that we can look at. We all know that, you know, correlation doesn't equal causation. But when we do jobs interviews and we find that. we have strong evidence that people are either firing our product for a specific reason or they're struggling to do something that we could help them with. That means that we should be able to find some correlation of that thing in our data. We have enough of it. We have all the full story sessions. We have all of the transactions and invoices and products and product details. every everything about how they're being paid through our product and so in like the example that chris is talking about sure we're hearing all of this stuff from the jobs interviews and anecdotally we're really excited about solving a specific problem but if we can't like bring uh any concreteness to what's going to actually change if we do try to solve that problem then we're probably not going to do it because we're missing something. Or we're missing. I'm glad Bob chimed in with his high because if you haven't listened to Bob's new podcast episode on prototyping to learn, that's the other side is that when we bump up against that and we can't find it in the data, do we need to learn something as a stop on the path along the way to get to where we're going? And that's the other thing that we will wrestle with in a framing session is what is the What's the button that we launched that doesn't go anywhere, right? That goes to a coming soon page or whatever that's going to allow us to learn what we need to learn. And again, if we can't come to terms with we're going to have this outcome, learn this, and then go build something else, then we're going to need to go back. And a lot of times you put this down and you go frame something else because there's so many opportunities, right? Yep. Aaron here is asking, is the product manager who did the framing and shaping involved during the building cycle? And also, I will add to that, the product engineering is involved there too, and how is involved during the building cycle? Yeah, so I think we touched on this a little bit with talking about who has a job in cycle, whose main... uh responsibilities are in cycle projects that are actually kicked off and we're committed to delivering and who has a job uh primary responsibility out of cycle which is like does the work to get us to a point where we're going to commit a team to building a project the product engineer's primary responsibility is out of cycle which is mostly working with the product management team to make sure that the work that we're shaping is uh concrete enough for the engineering team to deliver if we decide to build that thing. They are involved during the building, during basically the, we have more phases after shaping, right? So we have after shaping, if we decide to build something, we package it up and make every decision that we want to make. And then we kick off a project and we start building it. And at that point it's in cycle. They're involved on the in cycle portion when it comes to like basically making sure that the engineering team has the information that they need and presented to them in a way that they can leverage it. But besides that, they're not in the critical path. They're not going to be writing a bunch of code in the project or anything like that. And the product manager, I think, can be cast in similar light. So mostly responsible for out-of-cycle work, right? We're up to at least 10 or 20 jobs interviews per month. just on a regular cadence. So they're out looking for the next opportunity. They're talking to, they're not talking to small businesses. They're talking to banks and credit unions or other partners up and down the stack to learn what to do next. And then in every project, they are involved in the in-cycle work of, you know, hey, what did you mean by this? We've got a hard trade-off to make here. We didn't think of this edge case. Like, can you come in and help sort this out? So it's, it's common to see them every day like in the chat sort of like you know going back and forth but their actual work as the cycle is going on is finding the next opportunity and spotting the next thing here is another more from ryan hutch seems like product team is actually operating as both core feature value and growth any thought to creating a dedicated growth theme with dedicated engineering design PM that are aligned around the most important outcomes onboarding, retention, revenue expansion, et cetera? Yeah, that's a good question. It's probably the phase of the company in terms of just our growth that makes you feel that way. Like the most important pieces of our, the biggest investments that we're making to our product right now are all growth activation retention related. We have a marketing function that is sort of parallel to the work that we do that works on activation messaging, both in-app and across other mediums, product marketing. So anything that we launch, they're focused on sort of amplifying that message. But I think at the scale we're at and the the focus of the product strategy being on sort of activation and adoption and things like that. It makes sense for the core group to be focused on what we're focused on. I think like you're, if you look ahead a year, you look ahead 18 months, you're going to see maturation and you're going to see, you know, sort of the team split apart into what I think you're suggesting. Yep. Perfect. Let's see. Do you still use cooldown periods and how do you use it? This is a great one. Yeah, this is a good one. So we essentially changed the period between projects from a marketing standpoint. Instead of calling it cool down, we actually call it ramp up now. And it's a period. And I really because I think it describes. better what the actual what the period is for right we say it's not like for everyone to go play xbox while we figure out what the next project is it's time that the engineering team has out of cycle to be able to do the spikes that you know we need more technical expertise on to be able to talk to product managers to be able to work on either tasks that they didn't get to from a, you know, from previous projects that they're interested in, or like if there are like one off things that we need done as a business, we give, we put aside time for that. I will say before, like people ask us like what's our period length and our, you know, ramp up length and all this stuff. We're still in a phase where we're basically ad hoc. So We call it like single threaded we're working on, you know, a project at a time for each individual group. And then we're like trying to sync up that ramp up period at the end of that project time. But it's not like we have like a 6 week cycle and a 2 week ramp up a 6 week cycle and 2 week ramp up. It is something that we are trying to implement at the beginning of January, but we don't want to do that before it's actually necessary. Like, our focus is on. what's the next important thing that we need to do, right? What do we actually need to ship right now? Cool. How long did you answer that? Oh, how long is it? Yeah, it's ad hoc, right? So we're usually basing the amount of time that we give to ramp up. on how long we actually gave the project. It's typically not more than a week. It's not more than a week. Yeah, so it's a little bit smaller than what Basecrime prescribes. Yeah, but we've also, for example, like we've never run a six-week project. I think the maximum length of a project that we've actually tried to run is four weeks, and we've probably only done that two or three times now. Yeah. This is like a, you know, start slow, like get people into the rhythm of what it actually means to have two weeks set aside to ship a project. and then do that and then you know if we're shipping on monday we're going to kick off another project on thursday or whatever it is um here there's another question about the product engineering uh do the product engineering join the interviews i mean i think uh dogan can meant uh the customer interviews right uh no oh no they do not oh they have but not as like a not as like a mandate for them to do their jobs at all. Yeah, so we're really good, I guess, as you would expect in terms of like capturing insights. So the product managers will conduct interviews, transcribe. code the interviews, sometimes do clustering into actual jobs, and then come up with presentations to the team around here's my idea, here's all the substance, like interview snippets, audio recordings, here's everything that sort of like builds up to what I think we should ship. And then if others want to take the time to go back, listen to full interviews, read full-time inscriptions, like all of that data is linked together. So we do use a we use a tool called enjoy hq that does pretty good transcription and so you can go in and you can monkey around with the with the data so no it's primarily the product managers have to go do the research and surface it up to the to the team yeah when it comes to framing uh there's like a split right the product managers are responsible for bringing the qualitative context into the frame and the product engineer is primarily responsible for bringing the quantitative context into the frame. And then they work together to figure out how do those things actually correlate with each other. That might be sort of autobooks specific. Our data is extremely complex and the product managers will go to a certain level of depth around analytics and quantitative. But when we really get to the meat of like, okay, I mean, you can feel it in. eight different onboarding paths right if you really need to get down to like guys do i have a solid ground to stand on can i go kick this off okay now let's let's get into some more complex queries and really spend a couple hours getting into the data and building up that quantitative case um here's another question is the work engineering stood during ramp up work managed or is it up to each individual what do they do i would say it's it's fairly managed um we have And this, again, this is very specific to how autobooks operates, right? During our ramp up. So we have, so for example, right now, the like senior engineers on the front end that do most of our front end development are, they know that we're going to kick off, I guess at this point, that we're going to kick off a project on Thursday. Like they knew that on Monday when we met with like our like product development leadership team. So they knew that anything that they committed any of their team to, and this is where I think like the tech lead role comes in, anything that they commit their team to within that time span just needed to be done before Thursday because our kicking off of the project is going to take precedent over that. And that should, as long as I think you give them enough time to like figure that out, then they can do it. actually choosing the work that they're doing within the ramp up period is essentially a lot of the like shaping and spiking work that needs to be done is done by the more senior engineers and they know that they need to set aside time so they're not like committing themselves to anything ridiculous during the ramp up period but they are helping the I guess all the other engineers like choose things that can be completed within the time frames. And then we do have the, like our engineering team has a, like there's a DevOps team, you know, that there's like a product support team. There are teams that are not doing product work. So like that, like keeping the lights on, developing infrastructure, you know, doing all of these things. This would be an interesting, like in the discord, in the chat that we all have for the meetup, it'd be interesting to talk about different people's experiences. I know, you know, Ryan and DHH and those guys seem pretty adamant that the cool down is like a dedicated time for the engineers to clean up what they want to clean up. But I'd be interested in different people's perspective and how many, you know, truly go that far as to just like, we'll call you in two weeks sort of thing. Yeah. Are you muted, Juan? I think you're muted. Yeah, you're muted. Sorry. Sorry. Jill has another question. What do the technical handoff look like between framing, shaping, and spiking? Is there a more concrete pitch or are there key learnings documents with more technical in nature that get appended to the final pitch? So detail number one is we don't call it a pitch anymore because I think this was actually just maybe a broadly misunderstood thing at in the book, the pitch from like the Basecamp perspective was the thing that made it to the betting table, which was a thing that like Ryan and Jason and everybody were deciding on. From the point that it was committed, they were projects. So we've just like canceled the language pitch because every time we went into, before we started doing this, a meeting where a pitch was being presented. and the product team thought that they were committing to work, the engineering team might have thought that they were deciding whether or not the work was worth doing. And it was like not, it just didn't make sense. It had the wrong precedent. Yeah, it set the wrong precedent. But we do have, so every one of the projects we give like the full, we do give the full treatment. The format is not always the same. I think it depends a lot on what the, what the actual work entails and like how much work it is or what the appetite is. But we do have a document for every kickoff that is usually published like a few hours before, you know, our kickoff meeting schedule that goes over like, here's what the problem is. Here's what we framed. Here's the business outcome that we're looking for. So that's like the framing portion of the document is now in there like. not just like this is the problem, but here's how we actually know that we solve the problem. And then here's the solution. If it's design heavy, there might be higher fidelity designs. If it's, you know, back end or processing heavy, there's going to be like API documentation. Here are the new APIs that we're developing. If that's like something that needs to happen, if it's. if there's like complexity in the data model you know here are the queries that you can do to like see this data that we're talking about um it's all it's all contextual but it is i'll say it's uh everything is in there i guess i've only read like uh mostly pitches that uh i've had a hand in you know defining what the template is but these are more technical than um i think what i've like seen you know, posted on, for example, like the ShapeUp discourse forum and stuff like that. Yeah, I think this is the key of getting to ShapeUp in the real world, right? I just think we went into this where it was either Basecamp's reality, and this is tongue in cheek, but like stable code base that, you know, like the guy that invented the language worked on the architecture and like they were able to like shape this thing where you could leave a lot of latitude and know that people would not fall into pitfalls. or the reality of auto books in the early days where we just you know it's not like we had a ton of free time on our hand but we had the time to put something in front of a group of engineers it's the light bulb in the in the bubble in the cloud right and they would be able to go off and figure out what was required and figure i think the fundamental change here is what you just described is by the time we're writing that doc now which we don't call a pitch anymore it's like our kickoff doc it does have all of the shaping all the spiking here are the narrow boundaries of what we're doing here's all the rigor that went into it and here's sort of the technical things that we uncovered uh during spiking that is going to make this thing a success during the during the appetite yeah okay um I think it goes with this question. Heiko is asking that one goal for us with shape-up was to give builders more autonomy. With spikes up front, what remains to the builder team to explore and decide during the cycle? Will they still scope? Is there anything that they have to decide upon? Technology or something? There's a lot. This is still very much a variable scope. When we do a lot of the spiking, what we're determining is we're basically telling the team up front, not the engineering decisions that we're making for them, but the information that they need to know absolutely in order for them to make the right engineering decisions. So we're going and figuring out, here's actually how the thing works and how you can tell that it works this way, because you're going to go change it. I'm going to like center you in the code here. It's also important to note that I think during the ramp up period, generally what we try to do is we try to assign spikes either to the technical lead that's responsible for the team that's going to run the project or to the engineer directly that is going to be assigned the project. I don't think we really covered this, but one of the For technical spikes specifically, one of the things that we wanted that we want to try to accomplish is to center that engineer in the code base that they would be working on and to learn something about that portion of the code so that if they're assigned the project, they've already gotten the context and don't have to start from scratch there. Perfect. And for those more technical kickoff doc who is involved in writing it, is it just the product manager or is it the engineer involved to help with the more technical aspects of the doc? Who else is involved there? Yeah, this is an interesting question that I'm going to like semi avoid, but basically the point of the document, the kickoff doc is more informal because all of the actual rigor has like to that goes into planning what we're going to do has been done with the people that are going to do it. And so that document is essentially just solidifying the final decisions that needed to be made about the project. So for example, if we during the shaping of the project had three different ways that we could present some information to the user, The kickoff document itself is not going to go back to the Lucid in our example and talk about the three ways. It's going to actually pick one of the ways. And our litmus test for whether or not the project is actually ready to be kicked off is if while we're writing this thing, we're coming up with more questions about things that need to be answered and we're not comfortable answering them, then the project's not shaped. Yeah, I think all of us have probably seen like the RFC in confluence with like endless scrolls of code and comments and things like that. I'm actually kind of trying to figure out if we could share one of our kickoff docs like and hide enough to like, you know, make it shareable. Because if that's what you have in your head, it's like not, it's more technical than a pitch, but it's not as far as those highly technical. Just a small question that is related here. What tools do you use to do this issue trackers, tax management, is Confluence and Jira or something else? So Hillchart in Basecamp, like I mentioned, Lucid for framing, shaping, spiking, all the collaboration before the project kicks off. Tons of, so we're in Microsoft Teams, so similar to Slack. lots of chat, whole team in one channel we found works really well, like no little breakouts where things get lost. What else? What have I? Yeah, we do have, we've tried to structure it not like a backlog, but we do have like, things that come up that are like, not big enough to be, I would say, like called projects or anything like that do like we have a board in JIRA. Hopefully I'm the only one that looks at it. It's like a personal thing, but we use things to stay organized. But from a kickoff perspective, we're posting an announcement in Basecamp. There's a Hillchart set up. We're doing scopes. Figma for mockups and design. Postman for API calls. Tons of Postman. I don't want to see anybody writing code to make an API call if they haven't called it from Posterer first. There are some minor small questions here. One here is how do you respond to emergent issues that can wait six weeks for the team to be assigned to it? Do you have another DevOps team support that are in another line? Yeah. We, I think essentially, so this has happened a couple times. We've not yet seen an issue that has come up that is like weeks worth of work that people need to do. But essentially, we've built a muscle that we understand that there are production things that can happen. The leadership team is involved in the decision that we're going to actually divert some attention. to a production problem so that we can fix it and then we're going to flex the end of the uh the end of the cycle to be able to accommodate for that and we're just gonna and we're gonna deal with it that has i think a better emotional impact on like the engineering team to not uh have to go oh i'm i'm like i want to work on that but i'm not allowed or like some uh like some weird you know situation going on there yeah it has to be like a technical fire that breaks out like the other side of that is we're um you guys have probably heard me talk enough to know that we're really um deliberate about managing like our lack of a road map so we are an enterprise software company and that we sell the banks but we're never in a situation where we've got someone holding that over our head saying, you know, you need to, this is broken. You need to ship this feature, you know, by this certain timeline. And we would go interrupt committed work or somebody in cycle. So we've kind of narrowed the set of things that can derail a team to things that Justin, you know, described. There's something that like has really gone wrong with the system or the infrastructure of the code that we need to jump on right away and can hopefully wrestle to the ground in a matter of hours. And here's another. How do you manage leadership reluctance to use the circuit breaker because they worry about morale for the team building it? They worry about making them feel like they wasted six weeks working on something that gets canceled? Yeah, this has only happened once I think to us. We spent about, I think we probably, it was a four-week project that took almost six weeks actually. we shipped it to production and we had made an assumption because again like we're obviously not perfect uh we had made an assumption that was like not even remotely true uh about how an external system worked that we were interacting with and we pulled it from production immediately um how did you manage that yeah and we sat on that i'm i'm trying to think it was i don't think we really had a choice um but You know, I think it was like, like the project itself is sure something that we like pulled out of there, but the engineers that had shipped that project, right, have been shipping projects. You know, sometimes you take an L item. Yeah. I also don't think maybe casting ourselves in the light of being really good at pulling the circuit breaker is the wrong thing. Like I just, so before you got here, we had another one where a six week project went. 12 weeks, we shipped it, we retro it. It was very, very difficult to say we're going to not throw all this away, but stop all this, move on to the next thing. We still felt it was the critical thing for the business. So we doubled down. It was twice the size of the investment, which is hard to stomach, but it's not an easy thing to do to just pull the circuit breaker. Yeah, for sure. Cool. I think we are on time. So maybe we don't want to hold on a little more than what we scheduled. Do you have something to say? Maybe we can... David, do you want to... I'll just really... I'll go ahead. I'll just say if you can see the slide, we'd love to keep the conversation going. So email... follow connect on LinkedIn. If you do the LinkedIn thing, mention that you were here so we can separate you from the sales, you know, all the recruiters. But we'd love to connect. And then the last thing is we're toying with the idea of more sort of case studies. So whether it's a podcast or something else, we have an inclination to share more projects and sort of talk about how we framed, shaped, and ship them out the door. So let us know if there's demand, if you're interested in that, if you think that would help you. um ping us let us know uh we've been noodling it for a while we haven't pulled the trigger mostly because we don't know what the you know what the appetite of of other folks is um but uh you know let us know if you thought that'd be interesting and then uh feltpresence.com if you haven't heard already ryan is putting together an online course um to go really deep into shape up in real life i think he's launching it over the next couple weeks um so there's a form on feltpresence.com if you're interested you can fill that out um and and dive into that uh other than that yeah thanks thanks for having us guys this has been really been a blast no that was that was great to have you seriously this this was a great talk and i think all the questions that were answered were really helpful for the whole people um can you guys is there like an export of the questions can you email it to me you can answer them on the meetup thing like the discord the shape up thing yeah yeah i want to yeah but i will i will share them with you and also uh the the recording will be available for the uh we'll upload it to youtube and also i just wanted to uh hey that uh i will share through the chat a google form just for the meetup so that you can answer your feedback for the practitioners meetup for us to know how do you feel about this and maybe we can make them better for the next time also. David? Yeah, also just from my side, thank you so so much for kicking off kind of season two with us, coming out with a bang here. So really, really great stuff. I mean, if you're reading the chat as we are, lots of appreciation for your time. Really, thank you for doing this for the community. Maybe one kind of... one marketing a pitch from our side would be that we have the next meetup lined up for december 1st if you're interested to continue going we have klaus freyer who is an independent cto working with a team in the industrial iot space And he'll talk about how to implement and trial ShapeUp alongside an existing Scrum process. So I think this would be very interesting for teams who are trying to get their feet into ShapeUp, experiment with it, and take the first steps. So if that's a problem you're struggling with, be sure to join that one. It's going to be around a similar time. We haven't set up the exact invite yet, but just follow the meetup group or the discourse, and you'll get notified. And yeah, thank you so much, Chris and Justin. This was amazing. Yeah, thanks a lot. Thanks, guys. Really happy to be able to contribute whatever we can. Thanks, guys.

In this meetup, Chris Spiek and Justin Dickow are going to take us all one level deeper and talk us through concrete examples of the tensions that arose between product and engineering and how they've had to re-invent the way they work as a result of a phase of unprecedented growth of the business at Autobooks. 

EPISODE LINKS
Chris's Twitter: https://twitter.com/chriscbs
Chris's Linkedin: https://www.linkedin.com/in/cspiek

Justin's Twitter: https://twitter.com/JuJoDi
Justin's Linkedin: https://www.linkedin.com/in/justindickow

Shape Up: https://basecamp.com/shapeup
Ryan Singer & Chris Spiek at fintech devcon: https://www.youtube.com/watch?v=jnW0fAIpLbo
Shape up in real life: https://feltpresence.com/
Autobooks: https://www.autobooks.co/
EnjoyHQ: https://getenjoyhq.com/
Basecamp: https://basecamp.com/

MEETUP INFO
Shape up Discourse: https://discourse.learnshapeup.com
Episodes playlist: https://www.youtube.com/playlist?list=PLR82WV5TUKuT7p4_y86NFazeZAP2ruV-P
Meetup page: https://www.meetup.com/shapeup-practitioners

David's Twitter: https://twitter.com/davidarens
David's Linkedin: https://www.linkedin.com/in/davidarens/
Juan's Twitter: https://twitter.com/juanivillarejo
Juan's Linkedin: https://www.linkedin.com/in/juanivillarejo/

OUTLINE: 
0:00 - Introduction
3:24 - Talk Agenda
4:32 - Talk Background
5:57 - Scrum a.k.a the paper shredder
8:59 - Shape up and the conveyor belt
9:39 - The Pile-up
11:05 - The Break-down
13:03 - Second call to Ryan and Shape up upgrade
21:25 - The Product Engineer
30:40 - Q&A: Product engineers losing touch with the code base
32:41 - Framing Sessions
38:15 - Q&A: Product engineer role skillset and how it compares with a tech lead role
44:37 - Framing Sessions outcome
45:15 - Shaping Sessions
49:37 - Spiking
54:52 - Result
56:56 - Q&A: Using the appetite
1:02:28 - Q&A: How do you know if something is framed?
1:06:32 - Q&A: Product Manager and Product Engineering participation during building cycle
1:09:20 - Q&A: Product team aligned with the important outcomes
1:10:42 - Q&A: Using Cooldown periods
1:13:41 - Q&A: Product engineer and customer interviews
1:15:55 - Q&A: Engineers work during cooldown/ramp-up
1:18:37 - Q&A: Technical handsoff during framing, shaping and spiking
1:22:25 - Q&A: Spiking upfront and builders autonomy
1:24:21 - Q&A: Kick-off doc writer
1:26:21 - Q&A: Tools
1:27:58 - Q&A: Emergent issues response
1:29:51 - Q&A: Leadership and circuit breaker
1:32:12 - Finish