How to Shape Up Client Work (With Ryan Singer)

Hi and welcome to the Digital Architect. I'm Bruce Van Zael. On today's episode, I am joined by Ryan Singer, who's the author of Shape Up and has been an inspiration to our team as far as how we work and how we organize projects. And so I reached out to Ryan maybe a couple of weeks ago. We just started kicking some emails back and forth and we're a dev shop kind of implementing Shape Up. He's the author of this and is years of experience in it and so we said hey let's have a discussion it's gonna be kind of casual i'm gonna ask him some questions he's probably gonna ask me some questions and uh we'll go from there so thanks ryan for jumping on here hey bruce thanks a lot for having me awesome awesome and if you guys are watching live drop comments below we'll keep an eye on that if you have questions that pop up i'll try and field those and maybe we get those um in the loop here so um yeah maybe just a good place to start um ryan just for those who are don't even know what we're talking about as far as shape up goes what just maybe a three to five minutes kind of just on what is shape up what is what makes it unique and then we can go from there sure yeah well um i wrote shape up when i was at base camp and i was there for nearly 18 years and uh we had experienced all kinds of the different pain points that other companies experienced too like from growing from three people in the beginning to nearly 60. And, you know, when you're just, if you have just a few people and they're, and they, you know, are quite skilled, then you don't need a lot of coordination. You don't need a lot of process. You can just kind of sit together and things just happen almost by magic. Right. But then as you start to, as you start to grow, as you start to bring in more people with different levels of skill and stuff like that, then it becomes a challenge of how do we actually kind of structure somehow what we do. And especially, how do we do it in a way where we can continue to get the results that we used to get when we were really small and everything was really tight? So we started to notice things like projects taking longer than they should, not being able to explain kind of the black magic of why the project would go so well when certain people were making certain decisions along the way. And so ShapeUp was actually kind of my effort to synthesize all the stuff that we had figured out through trial and error going through the years of adjusting our process into something that we could actually kind of explain to ourselves, you know, and also kind of walk people through as they came into the company so that we could say, this is how we work. And especially it solves the problem of not being able to get that focus where everybody knows the thing that everybody knows what they're trying to do. they're all concentrated on the same goal and from a we want to be able to actually set a goal from from the business side where we say like this is the thing that we want to ship this is the thing that's valuable to us and actually know that in six weeks which is the main cadence that we're working with inside the shape up method After six weeks, we're actually going to ship that thing and we're going to celebrate the fact that we got to that strategic goal that we wanted. There's a lot of companies out there who are kind of chipping away at things two weeks at a time and there's just no end to it. And there's frustration on the developer side because it just kind of feels like a treadmill of tickets. And there's a lot of frustration on the business side because it feels like, why can't we accomplish the things that we... Know are important to us, you know, so really it's all about kind of how to do that. That's awesome Fantastic and we now it's been out for a couple years, but we somehow only stumbled into it middle of last year and so I've read the book and I said, you know, this is this is kind of the way I think we should be moving forward as a team and so our whole team went through it we did a weekly book club and chapter by chapter just burned through the whole thing and it was fascinating to see how I think it's one of the few solutions that ties in the business side the kind of creative Side the product and engineering kind of all it's kind of the intersection of all of that because a lot of Workflows and processes that we've tried Working for clients doing development projects It's it gets so technical so fast that it's very easy for clients who aren't technical to make informed business decisions. And one thing I really love about the process is you basically are taking all the complexities and kind of taking the time, which is huge, taking a lot more time in the front end to organize, structure the project and get it simple enough. kind of explain it clearly enough that that clients can understand it and everybody on the team kind of has some buy-in we can all understand the constraints we can understand where this project ends what's out of bounds it makes it clear and um that just builds confidence from the clients and i think that's been a huge asset for us when we are taking a pitch essentially and then we have to sell that pitch to someone someone has to pay for that so we have to explain it to them and if the clients understand it and it's clear and they can see the thought process they're much more likely to um to buy into that to trust you to because they've got confidence now right that's actually a really key point you know the one thing that i always noticed i was always paying attention to different design methodologies and you know like ways of working and stuff like that since back in 2000 what 2003 when i started at base camp and i always saw this pattern you know like these big firms would have this like process like first we discover and then we i don't know ideate and then we you know and and and what i understood was that actually like all of these words they didn't really mean anything in terms of cause and effect what they meant was like we have really smart people and they come up with ideas and then they build them right and and the thing is that like when you are actually faced with making trade-offs of how much time can i actually spend on this how much money can i actually spend on this like what are we going to do in the next few weeks versus like this versus that like you you you can't just say we're gonna go do discovery and not have any idea of where it leads and and what it actually means you know and uh a lot of this is about for example so like you know flipping estimates into appetites and saying yeah what is it worth for us in terms of weeks to spend on this problem and um doing shaping up front meaning like do we actually know what the path that we're going to take roughly looks like. Do we actually understand what we're getting into here? Or are we just throwing hours at something kind of hoping that what comes out is going to be good? And I was actually really excited to get your message when you suggested that we could talk here a little bit about using Shape Up with clients because it's interesting because, you know, like with I think working with a client, the pressure is even higher. to somehow set expectations about what are we actually doing here? And at the same time, I never got to use Shape Up with clients when we were developing it. Actually, I've since been able to do that a little bit, but I'd love to hear kind of what, was there anything that you had to adapt or anything that you had to change in order to make it make sense in that world? Yeah, I think the difference, so reading the book, it was written kind of in the context of, on a full time team, you've got kind of leadership that is full time, we're all kind of and we're all building one product, right? Right. So the way that we kind of worked around it was, we now have multiple kind of leadership teams, right? That are these clients that are that are giving us kind of objectives and, and, and things to go tackle. And so it took us a while to figure this out, because we tried to take our team and say okay you know we'll all kind of serve each of the clients together and that that just didn't work in the beginning and so now what we've done is we kind of have these little micro teams it's a it's a developer a product person or kind of product manager and then not a project manager that's the key product manager um and then i'll kind of jump in to to help waste on time so it's kind of a small team, we only do a handful of clients at a time. And that that developer, that product, that's all they think about is that one client. So they've kind of got their own little mini team, right with the leadership that the clients kind of giving objective and we can kind of work with them directly. And it creates a tremendous amount of speed. That was one thing I didn't anticipate because it feels when you first start it and I'm a I'm a quick start. I love to just launch and just get into it and we'll figure it out. But it's a me taking time to write the ideas down to put all set it felt slow in the beginning But actually like when you look at it and you stand back a little bit We were able to get through a lot more work in a shorter amount of time So doing the upfront work of shaping felt like slowing down at first at first For someone who's like, you know, I could get an idea This is this is this is the bad habits we had before and I could probably speak to a lot of founders in the sort of tech spaces, you get the idea at 3am and go into Slack and you just start throwing over the wall to someone and say, Hey, now we're going to do this thing. And so, you know, developer wakes up in the morning and I guess we're working on this task now. Right. And it's kind of like straight to code too, right? The idea is that you're going to go from, from actually, it's like, it's like from shower to code. Exactly. Yeah, that's actually really interesting. That's one of the things I've been working on a lot lately is debugging problems that come from going to code too fast. Yes. Because a lot of the times too, what happens when we go straight into code is we don't have any kind of an overview about where the unknowns are and where the risks are. And then we're kind of like knee deep in a bunch of half written code before we start to realize like, I don't even know what I'm actually working on right now. And I can't see the bigger picture of what's important with how I spend my time. Exactly. Yeah. And I mean, my team's listening to this right now. So they may be saying like, I still have the bad habit of doing that. But it's caused us to think very deeply about these projects, like you say. And we use the analogy of building a house, right? If you just, if you had a contractor working on any part of your house and you just walk in on each morning, you're like, now I want to build this bathroom. Okay, now I want to build. this kitchen okay now i want to build a second you know i want to build out from the second story to the end you know and awesome developers just trying to like make it work and it just you quickly quickly quickly end up with all this technical debt um that you now at some point have to go and and undo um and so that's where we always take that step back and say okay Let's shape up. Let's create the room essentially for the house. Okay, so let's figure out, is this a bathroom? Is it a kitchen? Is it a bedroom? Because each of these require different plumbing, electrical. It needs different structural foundation. And so that's where we, and you're saying the discovery process. We actually, we do have a discovery process, but it is kind of walking clients through the shape of process. And we take about two weeks for a new client. It's a paid project. We just make two weeks with them. and we basically like try to isolate and summarize how many of these different core modules so we do take kind of a step back pull up like maybe two or three maybe four ideas we try to put those into small projects with the general is this two four six weeks never bigger than six weeks and then let them take a step back and now we have fixed pricing um for two four six weeks so they can look oh that's cool project and they say everybody on the team knows that costs x and the developers know what two weeks means the clients know what two weeks mean we all it simplifies everything we can all talk the same language and when you say that they all know what two weeks means is that because the thing is done after the two weeks do you know what i mean like because there are a lot of a lot of companies work two weeks at a time so how is this different um so yeah after two weeks it's completely like it's shipped right we're going to put it into the hands of clients which is a very big difference than I'm going to spend 80 hours, you know, 40 hours each week working on this project and then it'd be done. Because typically most development shops would then, after two weeks, hand it off to the client to start reviewing and start testing and QA. Whereas in ShapeUp, we're testing it early, early on, and we're doing QA and we're iterating on it, you know, within the first couple of days. So that's what makes it a little bit different. everybody is incentivized to keep to that two weeks. This is a little bit where I think it's a little easier for us than maybe for a company is that if we run over to three weeks, like basically the company pays for that, right? The clients aren't paying for it. That's the cool thing about working for clients. You feel the consequences of overruns in a way that product companies seldom do. But also, I mean, of course, the funding model is totally different too. If a lot of product companies have investment money and they are not very cost aware to begin with, and you're kind of on the other extreme, like very, very cost aware. I think that's great because that's the pressure that helps everybody. It's that enables people to make trade-offs and say, what do we actually want and what is important to us? It's actually having that wall of time and money around the effort that motivates the shaping. Yeah. i think you know some things we've introduced around that to create that hard wall is that um and this is even something we implemented in the last uh i'd say two months is we do track time right because we are it is gives us another measure of a unit of measure um for these projects so we will take a two-week project and call that 60 hours ish of work right and we're not working total 40 hours about 30 hours and that could be split between multiple people, you know, me, our product manager, our developer. And so we do track kind of at the end of the first week, okay, did we spend 30 hours? Did we spend 40 hours? And so it does help us because we do kind of these weekly check-ins with the clients and we'll just say, hey, here's two-week project. We're 40 hours in. We've got 20 hours to go. And it does help them say, okay, that's, we're... we've used up this much budget and because the worst thing they don't want to come and pay another batch of work to do the same thing we just agreed to do right x we don't want to now charge them x plus whatever and so that creates this this hard stop where we say hey look it's what we got 20 hours left you you know this little new idea or or um bug presented itself halfway through the project we could either go left we could go right we've got 20 hours each each way is going to take 20 hours, which way do you want to go? And so you have to, we have to kind of lead clients in this process. And the only way to do that, to make that, to help them, um, take it seriously, um, is to attach dollar signs to it. Totally. Yeah. Yeah. That's great. When you're working with founders, everybody gets real clear when, when money's involved, right? Yeah. That's excellent. Yeah. Yeah. And that's actually one of the things that I like, um, I've enjoyed so much about working with all of this is that it's about actually, it's oftentimes putting discipline onto the leadership more than it is, you know, because there's a lot of companies that can try to put discipline on their engineers, for example, by telling them that they have to report in certain ways, that they have to put certain attributes onto their tickets and stuff like that. And just pushing it all onto the programmers actually doesn't solve the problem. Actually, you get so much leverage out of having discipline on the business side of, what's important here how do we want to spend this time yeah i actually wanted to ask you a couple questions just to get some context like um can you tell me a little bit about like what what do clients come to you for and like what is an engagement with them like kind of what do they get at the end right so um this has been refined and has continued to get refined but uh we typically have uh clients come word of mouth to hear about us. We do an initial kind of 30 minute discovery call. So that's just free. It's just us getting to know them, see if there's something here. We'll find out what's the problem they're trying to solve. You know, everybody comes that they need an app, right? Everybody starts with the fact that they need it. Okay, everybody needs an app. Some people need a website. Some people just need to use a tool that's out there that they don't know. So we try to make sure we're not reinventing the wheel that we are doing something that's that that actually so we're already starting to think like is this even necessary right what what they're asking for um or is it just that they don't have anyone technical on their team and they didn't know that this other solution exists and so sometimes on those 30 minutes i'll just point them to a solution and say hey you know i think you could do this yourself by pulling these two or three little products together or services now we'll happily like entertain that and and build your own version of Trello if that's what you need. And sometimes the case does require it because there's constraints in existing tools. But I'm a huge fan of leveraging what's out there at the beginning. And so 30 minutes at the end of that call, I just say, hey, if you want to work with us, this is, you know, we have a discovery project. It's a fixed, fixed price. And we work for two weeks and we jump on some kind of Now we do everything kind of live right with the clients because we're trying to educate, shape up. We're trying to do the process and let them see the process kind of behind the scenes so they can get up to speed faster. So we actually jump on this like two hour Zoom call and we'll kick ideas around. We'll pull everything up. Full disclosure, we run our entire business in Notion. We tried a lot of different solutions. Notion just worked really well for documentation. and estimates and everything happens inside of this. We've built out some cool templates. If you guys are interested, I'd be happy to share like a link for you to duplicate our templates in the description. But so we pulled this in. They can start to see these modules start to appear. And we've just list everything sort of in an idea column. So this whole process is just kind of see like how big is this going to go? Like, because we're trying to just figure out almost like in the house analogy, how big is the property need to be? Like, is this going to be a high rise? Is it going to be a ranch home? Is it going to be a mansion? Like, do you need five acres? Do we need half an acre? You know, what's the, what are we even kind of looking at at this point? So just trying to get an idea and it helps. So we're sort of discovering how big this is. At the same time, the clients are starting to get an idea of like, okay, wow, this could be three to six. six-week projects, and that just translates to a certain dollar amount. And they know that kind of as we're going through the process. And so by the end of that first call, we kind of have a rough idea of what we're doing. We'll go back as a team and kind of flesh out any of those ideas. And that's where we really define the problem. We put in the solution, define some rabbit holes, out of bounds, what does success look like? And we've got a template flow. We put our fat marker sketches and stuff into that. and then come back a week later and present that to the client and say, hey, here's project A, here's project B, C. So at the end of this two-week discovery project, the deliverable is a set of kind of pitches of like potential projects? Yeah, so it's a set of pitches as here's probably the next few. steps we would take they're only willing to allow to pick one right you can't go pick three pitches it's one at a time and we try to limit the amount to no more than six weeks collected so it could be like one two-week project one fork as far as what they're paying for in a batch and one of the powerful things i'm just giving away all our secrets so if you're running a dev shop like this is some we should be running a mastermind for this but um we essentially we uh we take that entire pitch and we add it as an addendum to our contract. And so it locks everything in as far as what we're building, what's out of bounds, all of that. So we have a general standard kind of contract that we have them sign. But then as part of it, all the work and the scope of work and everything is defined in this pitch. And so we will sometimes do a batch of a collective of six weeks. They'll pay for that. in one batch. And then that way we, we like to get the money out of the way as soon as possible. I think the way that this works is clients, we get them to pay, everything's up front, by the way. Um, I know if you're dev, so there's a lot of creative ways to do that, but that's a game changer. Um, it's not a 50% deposit. And then when you finish it, you know, cause cause then you have a six week project and they're not really happy. And so then it runs eight weeks, 10 weeks, and now you're on the line for any additional hours. So. I love the logic of that. It's like you're paying for the capacity and then you're taking your, yeah, that's very good. Cool. And so, yeah, we have them. And then that way, because what happens is we want to dive into the work, right? We want to have that leadership. We want to have the developer. We want everybody kind of kicking these ideas back and forth and all being on the same page all the time. And kind of that shape-up process allows us to keep looking back at the original pitch and saying, okay, wait, was this one of the scopes, one of the features we had identified and kind of keep that as sort of the North Star through the whole process. And then we know when the work is done, right? Because it meets the success criteria, it meets the solution we presented and we can kind of stop. And so... uh there are some challenges in that so as you the original question was like what are the deliverables um we kind of go through this shape to process and then um we will do kind of the first couple projects and typically clients just keep working with us for four to six months as we develop kind of their whole solution we try to get it out in the hands of their clients within that first six weeks yeah yeah that's great and then you build you build that trust that you're capable of delivering stuff so then that feeds into future cycles right and it it's um you know because just because someone's willing to pay you for work doesn't mean you should be working for their money um so just just because so that discovery process is as much for us as it is for them Because like you said, the leadership component is critical. If we can, and typically we're working with small teams, it's not, and we actually define like our ideal client has, you know, five to 10 employees. And so we don't want to have this huge structure and teams going back to, you know, other stuff. You're just never going to. be able to implement this kind of sideways into a massive organization like that. We've been a part of lots of those. It's not fun. They move slow. It's hard to, they never change all those good things. But we tried to work with the, have the founder at least on a couple of those discovery calls or because they're the ones that if they don't get it, if they don't understand, okay, there's these different modules, here's how it's going to get built. Every time I have an idea, it gets, it gets thrown in. We capture it in the ideas. you know, we have this long, like, we do actually keep a backlog. I know that's probably one of the rules we, we break, but for the founder, they throw an idea at us like, hey, one day, I want to be able to have this, this one functionality, we throw that in a backlog, and they can see it. And sometimes we never go back to it, right? It's just there. And every time they mentioned it, we're like, hey, it's still here. Did you want us to shape this up for you? and then that's actually the perfect use of a backlog that's like backlog done right is a is a way to uh it's it's it's a way to act upon information that came on that came in you know and and as long as you have accurate expectations about it that we don't just draw from the backlog to fill in capacity right but that it's just it's a source of something that we could look at if we're having a discussion about what to do but that it there's no automatic conveyor belt from the backlog into uh resourcing you know by the way i really like what you said about um uh well i i what it made me think of was that really when you really understand shaping and it's what i'm seeing is that it's easier to see it in in the example of working with a client shaping actually should feel like a negotiation. Yes. It should feel like many different parties. Like what is the thing that we're trying to do from a product standpoint? What is the thing that we're willing to spend from a cost standpoint? What is technically feasible or even desirable from an implementation standpoint? Like all of those things have to come together into some package where like all these viewpoints are coming together and saying yes, before they make the commitment. And I also really like how it's interesting how like you You have this two-week discovery process and that basically culminates in a betting table. And they've paid for the time to do the shaping work to get to a betting table, but then you're explicitly kind of making a bet together about how do we want to use the time that we have looking forward. That's really cool. Yeah, and I think, and this is what's powerful about shape, that process is taking the time to To actually like produce a document that just that process is so powerful because it makes it forces you to think so much more deeply about the product the problem And and again, we've we've sold we've saved so many weeks worth of development Like you said the shower to code, you know, that's gonna that's that should be like a book title I think yeah, like shower to code is like the the easiest way to blow money in time. Yes, it's just like the it's It seems fast and it's unbelievably wasteful and expensive and risky. And you can continue. And, you know, the I'll say one of the clients object objections when we're in that discovery sales process and when they're putting their first money towards giving a development company is they have the fear is I'm going to just pour, you know, tens, hundreds of thousands of dollars into this project product and then still not be happy with what exactly is. And so and that's kind of where. clients have been burned they've outsourced stuff they're trying to totally save a buck here there and they do it the wrong way and totally anyway it's an interesting case where like actually a lot of the time as a client they'll go to they'll shop around and they're going to hear yes yes yes we can do that from a lot of people and here the conversation actually kind of starts with a no Like we're, you know, and telling a potential client, giving them a constructive no builds so much trust in the beginning because you're not just trying to get that money and, you know what I mean, and get a contract signed. You're really trying to shape something where you can kind of promise some satisfaction at the end of it, where you can actually have some common understanding about the outcome and the path to get there. but okay i want to ask you a question about this um specifically what what do these pitches look like what do you actually call them if not pitches and and what's the level of concreteness in that commitment you know like how much room is there for what you actually do to change from what's written there like can you paint a little bit of a picture of that yeah i think this is where um we have to speak the same language as clients, right? So the hour unit is phenomenal here because it just creates a finite amount of resources. And so if, let's say we're halfway in the project and something comes up and we want to change one of the features or one of the scopes of the pitch, that's where we could kind of take a step back and say, hey, look, let's look at what the budget allows. Okay, we have 30 hours. um you know we're and typically this wouldn't happen it's hard to say what happened in a two-week project it's pretty much in a four to six week project where there's yeah more hours um and so we we do allow some changes for that i think um we're very very quick to as soon as they start talk as soon as the client starts throwing out new ideas we're already making a new pitch and we do it kind of live for them in notion they can see the board of all the ideas and so that okay let me let's get that idea down so we start a new project and all of a sudden they start oh wait that's more money like he just created a new project that's that's a new bill that's a new contract um which is fine and that's why we we kind of validate those ideas um but we will typically like capture it some way and then we'll see if it will fit into an existing sometimes we start that process and say hey this is actually only a one week or two week project, it's pretty small. We have about two weeks worth of budget left in the six weeks. Do you want to swap this for that? We'll literally copy the scopes of or features of work out of that pitch and create a new pitch. So we can come back to that other idea. I see later. And so they're moving modules around. And I think as long as you can show that with integrity, and here's the exact hours we're spending, here's how much time it's, it makes it really simple, actually. It's very transparent track it. Yeah. Yeah, yeah. So that okay, so that's kind of from the standpoint of of the client having ideas about wanting a change in direction. What about kind of from the inside? Let me just contrast it with a lot of dev shops. They'll start a project with very precise, high fidelity drawings of what the final interface is supposed to look like. And then they treat the development work. as the realization or the like kind of almost like animating life into these very precise drawings yes and the expectation is that like this drawing that we saw at the beginning is going to become software at the end and the software is going to look like the drawing um how what's the level of detail that you're committing to in the pitch and how much room do you have to kind of creatively adjust what that final software looks like compared to the thing that you agreed on So this is where I think what is one thing that's very unique about us, like we are not the high fidelity design piece, like we'll use modules and typically, I mean, we may do some instead of a fat marker sketch, we may do just a little bit more of an elaborate sort of pencil drawing of what it could look like. We are not there to refine the shade of the color and this, we try to get it functional first. And a lot of our clients have to buy into that. They are. very much in sort of a functionality first kind of process. It's not, we don't, they're not shooting for this world's most beautiful UI right up front. And so I joke with our team that the way we really speed up this process is we just don't let designers on the team. So as an engineer, we know like, oh, that's quite refreshing. Like I can just look at the pitch, we can go build it. And then We will have someone go through at the end, right? And we talk about it, again, house analogy. We got to get the walls up. We got to get the door in the right place, the floors. It needs to structurally stand up. We can have a lot of conversations about what color to paint the wall. Yeah, you can do a lot of finishing. Finishing, yeah. We watch a lot of HGTV. That stuff comes at the very end. But it does, I agree, it does make it feel friendly. It makes it feel fun and easy to use. And so, but a lot of it, we try and think through what's the simplest way we can deliver this project. So, and that's part of that pitch process where we're iterating on paper before we are iterating in code and design software. And so we try to simplify, simplify, simplify, and we involve all parts of our team. It's not just me and the clients or, or, um, our product manager. We involve the developers, you know, in that process and they can kind of point out and. start to help us think about, okay, just adding this one little automation, that's actually going to add two weeks of work, you know, to the whole scope of the project. And, or it's going to add all this unnecessary complexity. That's, that's not, you know, that we can probably work around if we just simplified in here and here. And so, yeah, I don't know if that answers the question, but just really it's, it's, yeah. Yeah, that does answer it. So that's interesting to hear you say that because, This is something I've also been doing on some of the projects that I'm working with and I've been noticing that This is actually a difference from when I was at when I was at base camp there was a very kind of a strict idea of how a team works which is that there was a designer and programmer working in tandem all the time and I started working on some side projects where I was the designer and I had a programmer who was doing the who was building the the work that I was shaping and And I didn't have the time to be there along the way. Right. So I needed to be able to focus this as basically just a development task. And what I discovered was that like everything actually got easier because there was already a lot of hip bone connects to the leg bone type stuff in the pitch or like to use your house analogy, there's going to be a hallway between this bathroom and that bedroom. Right. And so there are basic relationships that are actually. design, they are actually kind of very much from a product point of view, you know, like this needs to be there and it needs to connect to this in this way. But there's no like measurements or, you know, specific dimensions of like this box needs to be this tall and be this shape and stuff like that. And what I found was that like it kind of freed up the programmer to take an approach to like, I'm just learning how to talk about this, but we've been calling it like a parts wired up on the floor approach. yes it's like when you when you buy a stereo system you don't like immediately take it out of the box and mount it on the wall like first you like plug you you you put it on the floor and then you you you plug you plug it in and you put the cables between everything and then you try and see like does this work you know and do i understand how this thing like turns on and connects and then when you're sure about it then you actually like do the fine mounting and stuff like that so i've actually been doing a lot more in this kind of finishing round uh you know instead of kind of integrating into the cycle and it's very much against the trend in the industry right now but i think we're going to see a return back to that i think um this is something that's helpful for clients you mentioned a little bit ago about saying no to clients right like that's something we say no a lot in that discovery process so that they get a sense of what it's going to be like to work with us now i mean you know what i mean but that like we're trying to We're not just saying yes to everything because the most I think developers look anything is possible if you put enough exactly money into it and you don't have like, you know, and so I just think, you know, what we were saying is, hey, I know you want to think about it this way. And a lot of times clients come to us and say, hey, in six months, we're going to do this massive launch and I want to work for six months and then get it, you know. build it all up and then let users in, in this big wow. And we immediately are like red flag. Let me tell you why that's a bad idea. We're saying, no, we're iterating on that. And, and, you know, because we've kind of niched down on who we're working with these smaller teams, they don't have infinite budgets. And so we're continually bringing it back to the dollars kind of conversation and saying, what's the least money you could put in to get the highest return as far as getting users to solve whatever. problem they're trying to solve um and and that conversation if the design uh kind of slips away very quickly right they that's so interesting yeah the the and and you know what i'm talking about that that kind of finishing ui i think ux and all that's important the graphic design element yeah we're huge fans of tailwind and tailwind ui so we use a lot of components um to solve and so it looks nice it doesn't look we don't want to make it look ugly um but it's not going to that like crazy custom design area which i think a lot of development teams because they start there they build these high fidelity interactive kind of prototypes and then they hand that off at the last you know part of the project to the developers and build this and and then you run into all the problems so um i think that's something that that has been unique to us is to keep bringing back to that that money conversation. And, and, and I think that's where I've found that being sort of the founder of our company and having done this for 11 years and then talking founder to founder on that side and saying, Hey, I, I, I know where you got, you know, you're trying to get, you got a certain budget associated with like allocated for this. How can we get this functional? Cause a lot of times it is either, um, hurting their bottom line, right? There's inefficiencies in their company. They need a tool to, solve some problem and now this is actually hurting them or keeping them from scaling so totally a lot of our stuff is we talk about building systems that scale um and we're helping them scale their business so they see that they need this tool to help go to the next level with their business and so we kind of talk in those terms like again the design and what shade of blue and all that stuff goes away very quickly um and it's such an easy thing to change um at the end and i think um that's where once you kind of do that with a client and they get it functional they get it in their hands quick and so we we always like sometimes have like a black and white ugly version that will literally white text black background you know ugly but working ugly but working and so um we had a tablet app that we did recently we just loaded all the videos they had a thousand videos um that had to be imported into this library. So we went ahead and started that on day one, built this ugly version. You could browse, you could search, you could get around all the videos. There was not one color on the entire app. And we literally gave the APK to the client, let them load it up, let them play with it. And they're like, you know, there's just this gut reaction, like, is this what it's going to look like? Is this, you know, I was like, but look how like everything works, right? We're solving bugs. Well, and that's where the risk is. This is the thing is that like actually getting all that stuff to work is the hard part. And making things beautiful is also hard. But for most software projects, actually, I spent some time on this because I was actually working on a product that's in private beta now. And we had to decide sort of how far do we go on kind of making it beautiful and rounding all the corners and doing color schemes and stuff like that. and i had to try and understand like what is actually important about this work why are we doing this finishing work and the conclusion we came to was that we need to do the the finishing needs to be good enough that it doesn't get rejected yeah but it it's not actually a differentiating factor unless you're unless you are literally in fashion or entertainment or something like that uh it's simply not a differentiating factor but it is a is something that can get you eliminated uh where someone looks at the product and they say oh this this i don't trust this because it looks so raw so and this is something where like tailwind is such an amazing thing because it gets you just to that level you know of like this looks respectable this looks like it was made by professionals uh but you're not like kind of inventing some kind of you know uh custom visual and it's so you know building on a flexible framework work like tailwind means that and when we do put that in the in the that first version there if it's black and white we are using tailwind to make it look that way so that when we do have a front end it's easy to layer in go in and we actually are if we have a designer sometimes that's me sometimes someone else they'll go in and design it at the code level that's fantastic so it's also very satisfying isn't it like when everything is when everything is already working and then you as a designer get to go like spruce it up and you you can also literally move furniture around because when the components are factored properly you know you can move things around on the views without breaking anything yeah and i love that moment because like that it's i mean it's just like a house right like the finishing is kind of where it all comes together and then you are like oh wow you know and it's really satisfying as a designer not to kind of just deliver these pieces and then wait and wait and wait but instead like have all the raw things working and then instantly get results on things. It's yeah. Cause then, and you solve so many problems without having real content or real functionality in. Yes. And so when you see, for example, you trying to load a thousand videos into a page, there's unique problems. Like what does that loading experience look like? How does totally, so you're, you're actually seeing the end result and then you, as a designer, you can actually, um, solve those unique like things because you could go off into design software make it look pretty send it back to the developer they make it look the way you want and then you go to actually use it and that end user experience is not great because they're sitting there waiting for all this stuff to load and no one ever thought to like segment this or break it down and and think through that final user experience um and now the thing about load time kind of reminds me about how i often think about ux in terms of both like space or time And like high fidelity mockups are all spatial. They're two dimensional, right? And every, it's like a colored dot in some XY position, but there's usually very little awareness of time and process in these mockups. And one of the things I've been thinking about lately with some projects I'm doing is like, there's certain moments in an app where if it happens too fast, it's actually bad. Like where you actually need to kind of have a moment of ceremony or a moment of confirmation or a moment of like, is this really happening oh yeah this is really happening now i think like turbo tax is like amazing at this like they have these different moments where they slow you down and they'd be like now you have this and you have that are you ready to move on or not you know and that kind of stuff like you can really feel it when the parts are already wired if you need to kind of put in that like if you have to put in a speed bump or not you know but you don't really feel that up front very well that's so true and yeah um yeah you can make definitely make things too fast um and I think that's where keeping that team shallow, not shallow, but as small as possible you can make it, it lets us iterate faster between that, going back to the leadership team, the clients who have this buy-in, their solution may be all about hosting your videos in this amazing, cool way. But if we're not taking that extra second, like those few, four, five seconds, We have a clear we're doing a decentralized video hosting solutions. Really cool. So we're working right now on like the loader, you upload it and then there's the video, right? That's how the that's how the design, the developer built it. It's super fast, super efficient. But now from a user experience, like I've paid this premium to have this decentralized hosting. for my videos. So we made a little thing that's like a little graph that just a bar, you know, as it's growing, it's saying, Okay, we're uploading to all these nodes, okay, we're sharing it, okay, we're encrypting it, okay, we're doing this and just kind of breaking that a little bit of what's going behind the scenes. And then saying, Okay, you know, your video is like, optimized and ready for, you know, or whatever. And it just made a totally fun thing. And it just reminds them like, Okay, yeah, this is why we're using this tool. Like, this is why it's those little interactions, but I know and again to go back to the clients part of this and design and kind of to kind of summarize the the design part when we do it in the code what we'll do is we'll ask for a lot of inspiration so we had the client send us like what do you think looks really good and then we'll put the two side by side so they may show us like for this video solution they show us a Netflix or discovery plus or one of these new streaming platforms And the changes they wanted were so tiny. It was that they wanted the video thumbnails to be rounded corners. They wanted to have the text the certain size. It was so small that on a six-week build, I think it was maybe two or three days at the end just changing the design. And then, of course, the clients, we had been telling them for six weeks, we can change it at the end, we can change it at the end. And I don't know if they believed us. And then on Monday, we showed them, hey, here's that ugly version. And that was all the bugs solved. We're kind of in the fifth week of the six week cycle. And by Wednesday, we're like, and here's the design. This transformation happens. They were like, whoa, you guys are amazing. That's so cool. That's really great. We told you, you know, and it happens like that, you know. Yeah. It's so interesting. That makes me think of something one of my mentors, Bob Mesta, talks about a lot is whenever we're trying to create satisfaction, we actually need to understand what are the things that actually cause the satisfaction? What are the things that signal to the customer that this is the right thing? and like when it comes to design a lot of times designers have their own ideas about like kind of what is important or right or the correct way and to hear from the client that they're like rounded corners are going to signal to them that like this is the way that they want it to be it's so cool to have like precise things like these are the things that they're going to see that they're going to tell them that this is a good design as opposed to that you know whatever it's it it it follows according to some trend or it follows according to some you know, whatever, something that the design police tell you that you have to do. Absolutely. Yeah, I think, and it's, it's those efficiencies that, again, it always comes back to like, the that hard deadline of six weeks, right? We only have that finite amount of time to do a certain level of design work now. And that may require the complexities of this six week project require five and a half weeks of just back-end development, front-end, making sure all the components are built. And the last little piece, that's all we can allow for that. And sometimes we will do a second project, a two-week project, a four-week project, where we'll just do UI and upgrade stuff, make that extra nuance, and we'll detail all that. But again, it's something the clients are investing in, right? Yeah, and then you also have to shape it, right? You have to figure out, like, well, so at the end of this two weeks, if we're going to do this UI round at the end of the two weeks, how do we know that we got there? And what does it entail? Like, I love that. I love like putting that as a as a separate thing that they're paying for, because then you get to define all the expectations around it. That's great. And we ask them to think about, okay, so you're looking at this, you're looking at that. Okay, what what do you want us to change in these two weeks? And so they'll they'll come up with something, okay, we want it to look like this. And typically on the fly, I'll kind of say, you know what, that's probably like 10 hours, okay, you've got 50 hours left. you know, how would you like to, okay, well, we want this. And the funny thing is most of the time the clients can't even fill that 60 hour gap because actually what they wanted was just like two or three things. And they, if they have to think deeply about it, um, and not just have these kind of gut reactions to things and just throw tasks at us. Um, it just makes us think deeply about it and makes us like articulate exactly what, what is going to be done ahead of time. So, um, there's so many different. Ways we could go as far as chatting. I do have like one thing I did want to touch on which I think is really unique to Clients is and I think you talked about this in a recent blog post about feature work first reactive work Yes, so maybe it's very different Yeah, if you want to define that for us for saying that I'll can't tell you how we have interpreted that Well, just the thing that I've seen is that When you have a limited number of people who are supposed to be working on a product, and I'll speak to it from the product side, not from the client side, that there's the work that comes from, you know, shaping and setting an appetite and having a business objective and having an idea about like, this is the thing that we want to go pursue strategically. That's very different from somebody is on the phone and something is on fire and we have to go do it now. You know, and there's always stuff coming up that kind of has that urgency to it. And when there's urgency coming from somebody else who needs something from you right away, that just doesn't fit into this ShapeUp universe, you know, because the ShapeUp universe is all about negotiating a package of work, lining up the resources to do it, and then delivering it further into the future, you know. And so the simple observation there is don't take ShapeUp as some religion of how to make software. but view it as a way to deal with your capacity to reach a certain type of strategic objective. And that if you have a lot of this kind of stuff coming up, which is driven from support or driven from somebody in some other department who needs fast results from you because of the way you're organized, whatever it is, like you actually have to reserve capacity for that. right you know because the only way to do it is to reserve capacity for it and to use it actually a different process something more like a kanban driven process uh instead of a shape-up process for that absolutely and that um so we read that blog post uh a couple months ago i think that you uh wrote that and um immediately our team was just like this makes so much sense to us because Most of the time once the it's when the product goes live when you put it in front of people's hands Then yes, the little quirky bugs show up and things we haven't catch it because it's not gonna be perfect Because it was built and there's going to be urgency attached to those things It's it's you can't just kind of say well We're just gonna pile it up and then do it in some cycle in the future exactly and we we so Yeah, and then you've got the left varying levels of this is high, you know priority, this is critical, you know, this is, and it just goes escalated into, you know, whatever. Um, and I think what we've had to do is we, you know, when those, those come in, we, we do use kind of a, uh, Kanban like board style in notion where we will track, um, we call it the client inbox column. So they can throw whatever they want to at any given point. And then we have a, uh, uh, like our, our Inovo, um, So if we catch bugs, we throw them in there. And then we actually have a column that says scheduled. And so in this column, this is where we actually decide of all the things we have and all the things you have, the client, like, what are we actually going to go work on? And only when it's in scheduled does our team react to that project. So it creates this buffer to kind of get rid of the urgency, the, you know, the crazy email that comes in at midnight, like that stuff. So we kind of create this buffer and then we can kind of look at, okay, we've got this six week product. Now remember, we only have the one developer, the one product manager for that client. And so the way we've solved this and we used your blog post that you did on this as kind of a framework for this is we have the feature work, the projects that people are paying for two, four, six week projects. It's the only thing we sell at our company. And then we introduced a monthly maintenance. subscription, right? Oh, very good. For 20 hours, you're just giving away all the secrets 20 hours, fixed price, it's attached to a credit card bills on the first of the month shows up, you know, so it gets paid automatically. And those 20 hours are just they're just the excess stuff. It's kind of like excellent, you guys work the six weeks, and then you work the two weeks, we basically do this two weeks kind of idea, but we just have it sprinkled in. And again, we have that conversation with the client, hey, we're going to take this developer off this. It may push this other wonderful feature that you had in mind to launch at this. We're going to take an extra day or two and just solve this issue because that's so critical and is an emergency. And then we can have that conversation. I would say for those types of, we've maybe had a handful of those in the last six months, right? Actual emergencies, actual times where it is right. Drop everything and fix it. Yeah. True crises are rare. True crisis. Yeah. And defining what that crisis actually looks like. um because sometimes it's just you know there's certain things we can do that's just a quick fix for it um there's work around sometimes it's just communicating better with the users it's not always throw it to the developer and solve it right exactly well this is a great point about how um when you have actually also reserved finite capacity for dealing with the reactive work It actually protects you from this, well, first of all, this problem where the developers are constantly pulling tickets of stuff that's broken because the conveyor belt of broken stuff is never ending. It's just that a lot of it doesn't deserve the time, right? So that's one thing. But the other thing that is a problem that happens is a kind of hyperinflation of priority flags. Like when there's kind of an open-ended amount of time to deal with bugs, then in order to get your bug, To go front in line it needs to be priority with eight red flags on it and then 15 red flags on it and then you know and but if you but if you only have a fixed number of hours on a rotating basis Then you can only manage to get the top five or ten or things anyway, you know what I mean? So it it brings a kind of a healthy market to the to the prioritizing process Absolutely and and we one thing trick we do with that is when the project comes in we will throw an hour estimate at it and it sits there so they have here's your crazy hot lava double red flag whatever project that's a six hour project and the way we put in the scheduled column it just totals up all our hours and says hey there's your 20 hours for the month are you happy for us to spend all of you know november i love that so there's a there's an element of negotiation also with the bug fixing oh everything's in negotiation that's fantastic this is yeah this is uh you know i hope this video is available afterward for a lot of people absolutely because actually i think this is a this this point of how work should be a negotiation is is is coming up again and again and it's such a fundamental thing i think it's a really good one absolutely um and i i think again it's this has taken us you know, I would say a full year and a half to kind of get it to this point. We're still working out bugs. We still, it's not perfect, right? But it's a lot better than it was. And I think, I don't think we could have had this conversation this time last year. I think it was still too new. We're still trying to figure out the actual constraints of the process. Because we have to basically build a business model around your book. Interesting. I'm not sure if anyone else is doing that. I think people have implemented ShapeUp. as a process, a product workflow, we basically turned and stopped doing every other project we were doing. And we only sell a two, four and a six week project. And then this maintenance package. Those are the only three things you can buy from us, four things. And it just simplified things tremendously. And I think it's really a service when you actually love and care about your clients, about the people you're serving. uh then that is something that you have to do you have to go to that next level of simplifying it breaking it down making absolutely understand and i think that that little extra bit of service to the client um in in the process in using this process we kind of have to sometimes drag them there kicking and screaming a little bit to get them to the process but i think I would say most of our clients, when they kind of grasp it, and it's typically in month two, three, four, right? It's not the first few weeks. It's the first few months. They grasp it and they're like, okay, I get it. So I can have these ideas. I can prioritize what I want this whole team to be working on. So I think when a founder or a leadership person basically sees that, it kind of puts them in the driver's seat and says, okay, you tell us what's priority. You understand. the costs involved you understand the time involved you make the best most informed decision now it's not um like i said just throwing hours at stuff it's not this kind of haphazard just you know keep building until we we decide it's done um and and i think that's that's like a way to deliver a high quality product with integrity to your clients totally i love the driver's seat point that's exactly the feeling uh that that i had with throughout trying to put the book together was like that's that kind of should be the theme throughout the whole thing is how do we actually feel like we're in control of what we're spending time on and getting what we vested into like getting out what we wanted to get out at the end absolutely that's cool um i had there's like one or two questions here i know we're kind of up on an hour do you do you want to take one or two questions from people oh sure yeah we could take a look at the questions sure so this was um question saying, are there any chapters or insights since writing the book that you would add if you were writing it today? It's a great question. Yeah, well, there's a lot that's not in the book. And the thing that I had to sort of figure out, I had to figure out also, like, where does the book stop? And how do I shape the book so it was something that I could actually write and finish and wasn't some never-ending thing, you know? And one of the things that I was telling myself for the book was, If it gives people language for a lot of things that they weren't talking about before enough, like appetite, like unknowns, like discovered work, like a level of abstraction, you know, like fixed time variable scope, like all this kind of stuff. If it gave people the language for that and it started to enable people to talk differently about the work that they were doing and just kind of understand it's different. to have this perspective shift then it would be a success and now what i'm seeing is that like i actually i'm quite surprised by how the book is spreading it's um i'm hearing from so many people who are using the terminology now there are so many companies now that use the word shape that didn't before and it's just been a word of mouth thing and then the the all the next wave of struggles are appearing now so uh companies are are there for example there there's companies who have adopted uh their shaping their writing pitches they're having a betting table uh but actually the process of breaking down the work for example into scopes and actually executing one piece at a time and getting getting the meaningfully hard things done first you know and actually addressing the unknowns first this is something that isn't really explained in the book like how do How did the teams actually take that pitch and turn it into work and sequence that work and surface the right problems in the right order? A lot of times it's funny because this shower to code thing, it's kind of like the shower part gets slowed down. So there's this slowing down into a thoughtful pitch. But then when the pitch goes to the programmers, they just go straight into code. And one of the things that I've been working on lately is I've been... iterating on a process with a few companies to actually kind of slow down that process of transforming the pitch into an implementation approach and catching a lot of problems there much earlier that would take months, you know, not months, that would take weeks to run into otherwise. So that's been a big thing. So actually, like, how to actually break down the work, how, like, what, it's funny, there's still a lot of struggle around what goes into a pitch. and how to make sure that the intent of the pitch isn't lost when it goes over to the team and how to kind of hand over that responsibility without losing the meaning of it, you know, because what can happen is a pitch can sometimes be too supply side where it's just saying like, build this and build that. And there's not enough of a kind of a problem and desired outcome wrapped around it so that when the team was programming. faces a trade-off that they can understand whether to turn right or turn left you know and so like getting that motivation in there and actually figuring out how to incorporate the demand side into the pitch is also something that people can struggle with sometimes so there's a ton of stuff about like how to actually do it you know basically like how do you actually do it and how do you actually transition from where you are to being successful with this there's just a ton to do there so um a lot of the work that i'm doing right now is kind of inspired by by finding out about those problems. And then I built some software actually to address it. And then there's also a lot of stuff that I've been writing that will probably find its way into some kind of a future book I could imagine, which is a much more hands dirty, step-by-step what to actually do, you know, now that the concepts and the language are established. Yeah. You need like a... shape up handbook or like a manual or something. Yeah, totally. Yeah. Yeah. Like, what does it actually look like to shape really, you know, like what, what are the tools in the, in the shed that you reach for and in what order do you reach for those tools and what does it look like for that clay or that marble to, to, to, to change over time. That's excellent. So that's a good segue into where's best place to follow you. If there are people wanting more resources, I know you're writing a couple of places. Yeah, best thing would be just to go to my website felt presence calm and from there you'll see a link to the newsletter and and You can sign up to the email newsletter and my writing is happening right now is through the newsletter If I if I bump into something if I answer if I get a reader question That's interesting and it prompts something that I'm kind of basically prototyping All the stuff that'll go into new tooling and a new book through the newsletter. So that's the main thing. I'm and I'm also on Twitter rjs and uh you'll see little bits from time to time there as well excellent well maybe one day we'll do a part two i feel like we just opened up a lot of different threads so you know i hope this was totally there's a lot there there's a lot there and i think you know um it's probably could be done over you know there's probably like a shape up boot camp or something maybe in the future of helping clients like take eight weeks or 90 days to like implement this so but um Thanks so much, Ryan, for jumping in here, just being willing. I know, I think it's almost midnight for where we're here at. So thanks for hanging out with us and just sharing some thoughts. This was super encouraging to us and I hope everybody got value out of it. So we will talk to you soon. Thanks. Yeah, fantastic. Thanks a lot. Very exciting to hear what you've done with it. Very impressed. So thanks for sharing.

A conversation about the with Ryan (author of Shape Up) and Bruce van Zyl (owner of dev shop) on the workflow of working with clients using Shape Up. 

Ryan Singer
Website: https://feltpresence.com
Newsletter: https://world.hey.com/rjs
Read Shape Up online: https://basecamp.com/shapeup

Bruce van Zyl
website: https://www.inovo.io
YouTube: https://www.youtube.com/channel/UCqSVVzdBknfHBvb3ph0sKOg