End-To-End with Shape Up: A Real-World Case Study

Here's a new case study, showing a project end-to-end. It's about 30 minutes, and you'll see every step from choosing the initial idea through framing, shaping, and building.

Pay special attention to how different roles are involved at different stages, and how we consciously target the unknowns we need to solve next at each step.

You can also watch it on YouTube. Here are timestamps:

00:00 - Framing/Shaping terminology and assumptions
02:47 - What is Shape Up
03:38 - Basecamp vs. more typical real-world teams
Case study:
04:49 - Simple kanban for framing/shaping checkpoints
05:11 - A candidate from top leadership with unanswered questions
06:55 - Framing the problem/outcome with an SME
10:34 - Why I need to shape before jumping forward
11:35 - Shaping session with a senior engineer
15:29 - Back to framing with the SME
17:42 - Shaping session with the senior engineer and SME
19:19 - Writing it up for kickoff
20:57 - Kickoff with the team
21:30 - Mapping out vertical slices (scopes)
23:54 - Wiring first, high fidelity last
25:17 - The launch brief
26:01 - Reflection: Roles involved, progressively getting warmer
26:28 - Reflection: Long stretches of autonomy and spiky live sessions
27:53 - Misunderstanding about pitches. Shaping one thing per time box.
29:12 - Questions, Shaping in Real Life Series

Unedited Transcript With Slides

Hello, Ryan Singer here with an end to end case study of a real life project done shape up style. So, before I jump into the meat of the case study, I’m just going to put a little bit of terminology and assumptions on the table here.

So first assumption is that when we dedicate time to build something, if we’re going to have a team of engineers, developers building something that we consider that time to be precious, expensive, something to be used wisely. Okay? So if that is our view, then working backwards from that, there’s going to be some things that we need to do in order for that to go well, no matter what methodology you use. Okay?

And we’re just going to put words on those things. So in order for building to go well, we’re going to have to be clear about what is it that we’re actually building from a technical standpoint, right? So we’re going to call that shaping. And in order to understand what to shape, like what is it that we need to figure out how to build, we need to have clarity around the problem that we’re solving. So what’s the business problem? Where is the value to the customer and so on. And we can call that framing. framing the problem, framing the business value, framing the project.

And of course, upstream from that are broader pressures or strategic things that are pushing us to say this is the project we want to frame and shape now as opposed to that project. Okay, so that’s a little bit of language. First assumption.

Second assumption is when we look at how we use time, you know, we have some time coming up, a team is becoming available, there’s a new cycle about to start and we’re looking at that from the leadership perspective. There’s a whole bunch of things that we could maybe do next, right? And we’re choosing something to frame and shape and put into that time box. The assumption is that we want to actually finish that thing. All right?

So, let’s assume that we also actually want to finish things when we say we’re going to do them. And we don’t want to have projects that drag on as open-ended efforts where nobody can see the end. And we also don’t want to have these little sprints and slices where in theory we’re making progress, but in actuality there’s nothing to demo and we still don’t see the end. Right?

So we want to have a the second assumption is we want to have a kind of a commitment and alignment that after these 6 weeks or four weeks whatever it is the thing that we said we were going to do is actually going to happen and we can celebrate that because we got there.

All right. So now if those things are true well that’s a good basis to talk about you know what shape up is all about. So this is what shape up is meant to solve. The book was written in 2019 and I wrote it describing how we were doing product development while I was at base camp and the key points are we were getting very high output. So we were shipping things that were valuable regularly.

The way we were doing that was by having more clarity upfront about what problem we were solving and what we were building. And then thanks to having more clarity, we didn’t need to have all of these pointless meetings or frustrating meetings where everybody feels like we’re wasting time and we’re talking about things but we’re not moving forward. Right? The teams were able to work autonomously with fewer interruptions and fewer meetings because they had that clarity about what they should be solving. Okay? So, that’s shape up.

Now, if you pick up the book, what you’ll see is it’s describing, you know, not how all companies should work or what works at all companies. It’s actually very specifically describing what we did at Basecamp at that time. And Basecamp is an unusual company. I mean, very senior people all across the board, very small, everybody very technical, every designer is hands-on coding themselves, founders very hands-on and close. Lots of people wearing multiple hats with a big overlap of skills. I mean, there was a lot of unusual things there.

So, what I’m going to show you now is a case study from a different company. So, this is a case study from real life. This is a project that shipped a few weeks ago. It was done by a team that I’m working with as fractional CPO. And that team has a little bit more of a typical structure that you’d see on teams today where there’s separate backend, front end, designer, QA, you know, different marketing, sales, like there’s a little bit more of this separation of responsibility and you’ll see how we pull that together in the case study.

All right, so let’s jump in. Now, when I came in as fractional CPO, the first thing I had to solve is how am I going to get us through these different phases of framing, shaping, and building in a way where everybody understands what we’re doing and I can communicate it, but it’s still lightweight. So, I just hacked together this kanban board in Notion.

And the first thing that I needed to do was to get a candidate. Okay, so these are different checkpoints. And a candidate is like what’s the thing that leadership thinks they want next that seems to be important that we might turn into the project that we’re going to frame and shape. Okay.

So, uh I asked leadership to get together and talk. And here’s what happened. This is a little graph we’re going to use through the case study. The columns are days of actual time of the project. And every little group of people there, those are meetings that happened or work sessions that happened. Okay?

So on the first day, what you see is that the C folks on the sea level, they met without me to come up with a candidate and then the next day I I’m the CPO bubble there. I met with the CTO and he brought to me what they came up with as the candidate. Okay.

So what happened in that session with the CTO? The CTO comes to me and he says, “We have this thing where we want to improve the dashboard in our OS product.” And when I hear improve the dashboard, this is something that happens a lot. You know, on the one hand, it’s kind of it’s very blurry. I don’t really know what this means. What does it mean to like what’s wrong with the dashboard? What would it mean to make it better? How would we know that we’re making it better? How would we make tradeoffs? all these questions are kind of unanswered. It doesn’t mean that it’s a bad candidate. Actually, it just means that there’s some detective work to be done.

So, there’s some reason why they chose that, right? But, I don’t understand it enough in in order to actually work on it and shape something. I put this onto the conbon as candidate. Okay? And my task now, this is what I’m thinking in my head is how do I get this to the point where I can say the frame is go where I reach a frame checkpoint where I would say I I actually understand the problem and outcome here.

So in order to do that, I asked the CTO, who is the person that knows the backstory of this thing? And he said, ’Oh, we have somebody in sales. We have a sales guy who is also a subject matter expert who really knows about this whole thing firsthand.”

So I said, great. Okay, now I know what to do. I’m going to have a session where I’m going to talk to that subject matter expert to try and frame this.

So few days later, subject matter expert and I get together and he shows me the current dashboard that we’re supposed to improve. Okay. So he’s showing me the dashboard on the current product. This is a project product for gym owners to run their gyms. It turns out that it’s actually something that the company acquired and the what they have learned is that all of their customers are very very small gyms with one owner and the owner knows everybody who walks through the door.

Now, when the original product was made, it wasn’t really clear what a small gym owner needs. If you’re a big gym, you might need to know about new members and new sales. But if you’re a small gym owner and you look at this dashboard and you see new users, meaning members, and latest sales, you already have met every new member. You already know about every sale cuz you were there yourself. All right?

So, what’s showing up on this dashboard? This is what I’m what I’m learning from the subject matter expert. This isn’t valuable to the small gym owner.

So instead of just asking, you know, what would be a better dashboard, I asked him, look, when you were running a gym and you know, firsthand, what were the things that you had to track that were really important for you to stay on top of? And he opens up his spreadsheet from when he ran his gym.

And the spreadsheet is all about the main thing that he was tracking was missed payments from members, making sure that you know this is typical recurring revenue business thing, right? So missed payments from members was the important thing. we’re not seeing that here.

So I asked him, is it possible to see that in the system today? And we dug through and it turns out if you click click click a few levels into reports and turn on a filter, finally you can see that. But it’s not it’s not surfaced.

So okay, we’re already making progress, right? This is not just about improve the dashboard. It’s actually about surfacing failed member payments. Very good.

I’m thinking, you know, sounds sort of easy to do. Is there more that we could do on the dashboard? Are there other things that are important to the small gym owner? And he also showed me on his spreadsheet how he was tracking class utilization and basically said if we were to replace another one of these panels, maybe we could show, you know, which classes are booked, how much, and what the trends are and so on.

So, we got somewhere meaningful here. So um it’s you know what is actually valuable to the small gym owner. It’s the missed payments and the class utilization. So I’m kind of improving my framing of this from just improved dashboard to let’s focus on the actual metrics that are important to a to a small gym owner.

Okay. So I went back to my kanban board, dragged the card over and said this is actually I’m going to call this framed. I feel like I understand this and this is something we can go work on now.

Why not just go build this? Sounds simple enough, right? We already have the data. We’re just surfacing it. Well, I know from painful experience that everything is more complicated than it seems. There’s always hidden details. And I don’t want those hidden complexities that we don’t see yet popping up in week three of a six week project or week two of a four-week project where we thought we knew what we were doing what we were doing and then all of a sudden it’s like oh this model is more complicated or there’s a dependency we didn’t know about or there’s extra scope here that we can’t avoid.

I mean I don’t want those things surprising us in the middle of a project. I want to surface those and detect those earlier. So where my head is going, what I want to get to next is this shape checkpoint where I can say very clearly I understand what is it going to take to build this? What are we going to have to do to make it happen? How is it actually going to work? So we don’t have those surprises.

Okay. So how did we do the shaping? So to do the shaping, I generally do this in live sessions with the people who have the right knowledge. So I went to the VP of engineering and I said who is somebody who deeply is familiar with you know this product who’s worked on the OS product who knows the code base here and he pointed me to one senior engineer in particular so my next step was here you see the the we passed the framing checkpoint we’re ready to go deeper into shaping and I’m having here a shaping session with the senior engineer this was about a 2-hour session where we’re working together on the whiteboard and what happened there.

I’m just going to show you the whiteboard from that session. This is the overall whiteboard from the project. And we started off where I just kind of recapped the framing, the problem outcome, and the key ideas. And after we were kind of on the same page about the problem we’re trying to solve, went into sketching.

Okay, here’s these panels on the overview. These are the new panels we want to populate with class utilization and missed payments. already when I start talking about missed payments you know we understand okay what does that actually mean we should dig into the model of this thing so you know there’s contracts there’s invoices there’s sales there’s customers there’s members how does this where does the data of a mispayment live you know and we dug into into technical things like that started to get acquainted with how the current system works and we got to a point where we could sketch our first pass here and you you know, it wasn’t this is a breadboard and I’m describing the flow here.

So, from the overview, we’re going to have a missed payments panel. On the missed payments panel, we’re just going to have a row of missed payments. But already, you know, now that we’re actually working on it, I say, well, where would I go to see the detail of a missed payment in the system today? And the current place to see that is actually this thing which is like the sale detail page.

And it turns out this sale detail page is kind of this legacy thing from the product that was acquired and it actually handles multiple sale types. We saw this by looking at it together. It’s not just memberships. It’s also retail sales and invoice sales and it has multiple tabs on it. It has all kinds of things on it. And the code is let’s say um not very friendly for a quick change. Okay.

So, I’m thinking of UX things I want to do in the header. I want to be able to say, “Here’s your unpaid invoice, and here’s the status of the invoice, and here’s a button to retry the payment or whatever.” It’s going to be hard to change that because of the fact that this is kind of a a a hairball here.

So, we actually worked on a concept until we got to a pretty good place. We had a new concept for how to deal with that. We kind of untangled it. We’ve got an idea of what we’re going to build, but along the way we surface some questions, right? About handling multiple payments that um were already went through an automatic retry process. What about multiple failures for multiple invoices in a row that weren’t paid?

Are there cases where the owner has to update the card in person and not just fire off an email request for something? So, some domain specific questions came up that we couldn’t answer as myself and the technical person.

We also dig dug into the class utilization question and just briefly what came out of that is we understood that we didn’t know the time scale. So do I need to see the trend over 6 months over 3 months over 3 weeks and this has actually major implications in terms of the query and the performance of this thing.

So here’s our takeaways. You know we made some progress. We got to a design but we had these open questions that we couldn’t answer ourselves.

So to answer these questions, I went back to the subject matter expert.

So um how did that conversation go? Well, first we talked about the class utilization and I got some very straightforward answers there about the timeline. No problem.

But then you know you start talking about things, you get into the specifics and you discover things that weren’t in the first conversation. It always happens, right?

So I’m asking him about these details about the missed payments and we discover that actually it turns out you know the current app doesn’t even really have functionality to retry a payment that failed because of balance issues where we don’t need to ask for a new card. It doesn’t actually have a good flow for the owner of the gym to request a new card.

And basically what happened is we started to see here this isn’t just surfacing missed payments. This is actually about solving them.

But here’s the thing. If if we’re going to shift the focus here and build new functionality around the retry flows and requesting cards, I’m not sure if we’re going to have time to do all the class utilization stuff that we talked about. And this is funny, you know, so I actually said to I I said to him, I said, you know, I’m not sure we have time for all of this. And he said, look, I only told you about the class utilization thing. Don’t get me wrong, the class utilization thing would be very useful, but I only told you about it because you said you needed more.

So, we were able to reframe this from to be 100% about missed payments. We actually don’t need to do class utilization. Right now, just solving missed payments is a huge win. We’re fully aligned with kind of the original intent. We don’t have to go back and change anything. But we have really found kind of that nugget of where the value is.

So again, now I’m kind of narrowing down the definition of what this framing is from small gym metrics to payment recovery. This is actually about acting and solving these payment issues.

So got new clarity around additional functionality that we want to do. Thought with one more shaping session, I bet we can figure it out. This time I brought the subject matter expert to join us.

Myself, senior engineer and the subject matter expert. We’re together in one. This was again about a 2hour live whiteboarding session. And the reason is I didn’t want to have to go through that loop again. It’s really best if we can have all those folks in the same session so that as the questions come up that we don’t know how to answer right on the spot, we can get an answer and we can revise the design and come to a conclusion.

So that’s what we did. If I jump back here, I can fast forward. These are my notes from that session with the subject matter expert, the takeaways. We opened the next session by calling out the issues that were unsolved from the previous design and we worked together until we got to a solution that made sense from a UX perspective. It we understood it from a technical perspective and it did everything that we need to do in order to satisfy the frame.

So this after the at the end of the 2-hour work session was where we looked at this together and said this is going to work you know this is something we can go do this is going to work. So this is actually the moment I didn’t it’s it’s it’s not now that I have to go write a document or create something. This is really the moment where I went this is shape go you know so I’m saying like we’ve got it.

So I go back to the kanban, drag it over to shape go and so where does the kind of you know is there a document or what comes next here? Well I don’t actually need to bring anything upstream to get alignment on this. We already got the alignment earlier when we were when at the candidate and framing stages. I’m sure that everybody’s happy about this if we somehow carry it forward.

What what I’m thinking about is how am I going to bring this into build? How am I going to give this to the team? And how are we going to have so much clarity together that you know in the first week we’re going to see something working that shows that this is coming together, right? And how are we going to kind of have that expectation that week after week in a six week project, everybody’s going to understand this and step by step we’re going to see demos and this is going to come together.

So, I actually created the writeup, the document, what’s called the pitch in the book. I created that document so that we could have a reference and a source of truth for kickoff for the team to have something to reference. Okay? And I’ll show you um what that looked like.

So, the document was really just wrapping up everything that we did so we had a reference. So, I’m summarizing the frame. You can think of this frame as like kind of the acceptance test for the whole shape. You know, what does it need to do? What is the actual sort of problem that we’re solving? And then here walking through the shape, everything that we designed. And then you can see at the very end here the breadboard the where we landed.

Okay. So I brought that to the team and how did I bring that to the team and how did we start? We had a kickoff session. So here you can see few days later we kicked off by bringing everybody together on a two-hour call. Here is me CPO with backend, front end, designer, QA, and subject matter expert. We all came together for the kickoff.

And what do we do on the kickoff? Two parts. First hour going through that document. I kind of gave a tour of it, answered questions, get everybody on the same page of what we’re doing. Second part then is planning out the scopes. So mapping out what are we actually going to build in terms of the major chunks of this thing.

So I’m not working with tickets. I’m not working with user stories. We already have a clear picture of the whole thing we’re trying to do. What I find works really well is to break the work up into at maximum nine separate scopes, different things that we can actually build and demo independent of the rest. And these are vertical slices. Okay?

So like a horizontal slice is all the backend works but there’s nothing you can click on. Or all of the Figma is designed but none of it is real. None of it works. A vertical slice is we’ve got the backend and the front end wiring you know and we can click on this and demo it for this particular subset of the functionality.

All right. So this is actually from a a couple days after the kickoff. This isn’t from I don’t I don’t have a screenshot from exactly that moment. But here what you see this is what we we created this together on the kickoff. And how did we do that?

We actually looked at the breadboard together and we found the places where we could make these slices and gave those names and then talked through what is the actual kind of implementation details or things that we should be thinking of in order to make sure that those things happen well.

All right. So that is kind of slicing into scopes into vertical scopes. I’ll also point out here you can see these different green dots and those are actually showing the sequence that we came up with. So we also talked about what should we be seeing working first, second and third and so on. So we have a kind of plan of attack of what we’re going to build and how this is going to come together.

So, as time went by through the project eventually, you can see here’s a screenshot from Slack. I’m pasting in showing, look, we’ve got, you know, the the we’re conquering territory on the map here. We’ve got some things working and checked off. This is what progress looks like.

And how did we actually do that? What did the work of those scopes look like? Well, here we can sort of see as days go by, the team was able to work asynchronously for many days in a row because they had that clarity from the kickoff and from the shaping work. We were able to go just back and forth in Slack.

And how did that work actually go? We didn’t need to create Figma or highfidelity artifacts first. We actually did those last. We did the high fidelity last.

The workflow looked like this. starting at the breadboard, understanding what it is that we need to wire, then back end and front end working together to get to an ugly but working prototype that we can actually test. So here they’ve just inherited the existing styling and components from the previous version of the app. And this doesn’t look like we want it to look like. Things are not in the right place, but all the functionality is there. you can click everything and it does what it should.

And then after everything was wired up and working, then we applied the paint and polished it and moved the furniture around so that it had that kind of final nice look that it should have.

So you think of it like if you’re building a house, you know, we don’t have to decide on the paint color first. What we need first is to understand where is the sink going to go, where are the pipes going to go, the walls, the electricity, and then later on, you know, we can move the furniture and decide on the paint color or the tile on the wall or the fixtures. Right? So, that’s what that workflow looked like.

Eventually, we came to a place where all of these scopes were done. And I can show you kind of what done looks like as a contrast here. You saw the shaping doc. So this is the write up with the frame and the shape that we had at kickoff and you see the breadboard.

Then when this was finished I wrote up a launch brief and here what you see is again a summary of the framing kind of what changed before and after. And now you see all nice screenshots of the actual working software that has beautiful nicely designed screens and all the different states and stages and and all the flows and everything is is working nicely.

So that’s where we landed. I have a couple reflections that I’d like to offer on this.

First is look at this kind of workflow here. We’re progressively investing. We’re gradually narrowing in. We’re getting warmer and warmer from, you know, it has something to do with improving the dashboard to specifically it’s about missed payments to failed payments to shaping exactly what that looks like all the way until we get to the point where we can kick this off.

And then in terms of the time spent on the project, have a look at this. You see long stretches of asynchronous work. We don’t have to have regular syncups, regular status meetings. We don’t have to have those what’s going on, you know, how do we solve this meetings. Got a few work sessions here with the designer.

And we, in this case, we had one session later in the project where we kind of did a review together and populated a punch list with, you know, little screws that have to be tightened and little problems that have to get solved. They’re all isolated issues. So one big sync up for this whole stretch.

So this means the team is in control of their time. They know what to do. They’re able to make progress just with async check-ins.

Then contrast that with what the work looked like upstream of that. We have very spiky intense live work sessions also with you know expensive people right. So this is a really nice pairing. The asynchronous the long stretches of asynchronous time actually mean that there is this kind of slack and margin in our day where if we need to go and have a session like this, we can go in for 2 hours, go really deep, come to some conclusion or understanding about something and come back out again and then get back into work where we were.

If you read shape up, you’ll see this word pitch, which is what we used at the time for that write up of the shaped work. And you can get a kind of a misunderstanding that you’re supposed to create a bunch of pitches, right? And then choose one pitch cuz what do you do with a pitch, right? You’re kind of selling something, right?

So, you see something different here. It’s not that we’re shaping many, many things and then choosing at the last minute. We’re actually narrowing down before we even shape. Right? So we chose a candidate got into framing then after the frame checkpoint said this is something we actually want. If we could do one thing it would be this. This is worth the time investment to shape.

And then when we got to the checkpoint that this is shaped there was basically a green light. We didn’t need to bet again. We already had the alignment.

So this is more what you see in real life teams is this kind of one to one. There’s a window of time coming. A cycle is coming. A team is becoming available. Let’s figure out what are the top candidates for what we might want to do. What can we frame in framing what has a really compelling convincing story behind it that this is the thing that we want to solve. Then let’s just take those one or two things into shaping and into build.

Okay. So that’s that’s a look at a real life project that happened recently end to end. I hope it was interesting for you. Usually when I show things like this, it stimulates a lot of questions. So if you had questions when you saw this, I would love to hear from you. Just email me, reach out on on X or LinkedIn or whatever. And visit the website. You’ll find that I’m starting to share more of this kind of what does it look like in real life under the Shaping in Real Life series. So you can go to the website and get more there.

So hope this was useful to you and interesting, and stay tuned for more.