You can also watch it on YouTube.

Transcript

00:00 - Framing/Shaping terminology and assumptions

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.

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. 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. 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 second assumption is we want to have a kind of a commitment and alignment that after these six 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.

02:47 - What is Shape Up

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 Basecamp. 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.

03:38 - Basecamp vs. more typical real-world teams

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 was 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, frontend, designer, QA, different marketing, sales. There's a little bit more of this separation of responsibility. And you'll see how we pull that together in the case study.

04:49 - Simple kanban for framing/shaping checkpoints

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?

05:11 - A candidate from leadership with unanswered questions

Okay, so 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 C 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 trade-offs? 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 order to actually work on it and shape something.

I put this onto the Kanban 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 actually understand the problem and outcome here.

06:55 - Framing the problem/outcome with an SME

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 a 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 product for gym owners to run their gyms. It turns out that it's actually something that the company acquired and what they have learned is that all of the 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 because you were there yourself.

All right. So what's showing up on this dashboard, this is 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 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. It's 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. 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 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.

10:34 - Why I need to shape before jumping forward

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 harder 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 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 building phase. I want to 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.

11:35 - Shaping session with a senior engineer

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, 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 two-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, 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 missed payment live, you know?

And we dug 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 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 and 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, 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 hairball here.

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 surfaced some questions, right, about handling multiple payments that 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 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 six months, over three months, over three 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.

15:29 - Back to framing with the SME

So 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 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. This is funny, you know. So I actually 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 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.

17:42 - Shaping session with the senior engineer and SME

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 two-hour 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, 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 at the end of the two-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.

19:19 - Writing it up for kickoff

So this is actually the moment, I didn't, 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 at the candidate and framing stages. I'm sure that everybody's happy about this if we somehow carry it forward.

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 write-up, 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 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 you can see at the very end here, the breadboard where we landed.

20:57 - Kickoff with the team

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 a few days later, we kicked off by bringing everybody together on a two-hour call. Here's me, CPO, with back-end, 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.

21:30 - Mapping out vertical slices (scopes)

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. So like a horizontal slice is all the back end 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 back end 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 couple of days after the kickoff. This isn't from, I don't have a screenshot from exactly that moment. But here what you see, this is what we created 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.

23:54 - Wiring first, high fidelity last

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, 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 high fidelity 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?

25:17 - The launch brief

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 all the flows and everything is working nicely. So that's where we landed.

26:01 - Reflection: Roles involved, progressively getting warmer

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.

26:28 - Reflection: Long stretches of autonomy and spiky live sessions

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 sync ups, regular status meetings. We don't have to have those, what's going on? You know, how do we solve this meetings? I've 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 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 two 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.

27:53 - Misunderstanding about pitches. Shaping one thing per time box.

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 shape 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 because 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, it 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.

29:12 - Questions, Shaping in Real Life Series

Okay, so 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 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.

Timeline graph for reference:

Pitfall #1: Shaping without technical depth

The book says shaping is primarily design work. But everyone at Basecamp — including designers — was very technical! If you try to shape with only PMs and non-technical designers, projects will churn because of the unanswered questions that blow up during build. The #1 failure mode of attempted Shape Up adoptions is "undershaped" work.

Shape with technical people

Shaping sessions should involve senior technical people who know the realities of the code. Designers who shape should be of the "interaction" type vs. the stylist type. The main output is the wiring of how it works. Think the blueprint of the house, the walls and electrical wires, not the 3D rendering of the kitchen interior. It's where the sink goes and where the pipes go, not the paint or the tile.

Related: Rabbit holes are commonly misunderstood. Any rabbit hole that isn't solved during shaping is a time bomb that can churn the project.

Do high fidelity last

High fidelity design done too early will blow up. Build something raw and ugly that meets the functional and interaction requirements first, and style it last — literally in the late stages of the build cycle. This is like painting the walls and moving the furniture around after the construction is done. When the electricity is in the walls, you can still swap the fixtures at the very end.

Pitfall #2: Blurred framing and shaping

You will find that the recommendation to shape with technical people makes shaping harder to coordinate and more "expensive". Therefore, you will want clearer problem definition and more alignment up from to justify the sessions and make them productive.

There is a distinct work step to nail down the actual problem and outcome before shaping. We didn't have a word for it when I wrote the book. Now it’s called Framing. (It's implicit in the book. Ch. 3 "Set boundaries" is actually framing. Ch. 4-5 is shaping.)

When framing isn't tight, the shaping and build phases will go in circles or spiral out in scope. Fuzzy framing also leads to "shiny object syndrome" — when projects get canceled or swapped for other projects midway because there wasn't enough clarity about the outcome to create conviction.

Contrast framing and shaping

When you give these phases clear names, you'll find it easier to pull the right people together to have the right conversation at the right time.

Clearly distinguish these two types of work in all communication, including in live sessions. Are we working on the problem or on the solution? Framing is about the problem, the business value, the outcome, etc. Shaping is about the technical solution. Framing is what we solve, shaping is what we build.

In terms of documents, I recommend referring to the "frame" and the "shape." This avoids misunderstandings about "pitch." Be careful with terms like "one pager" where it's not clear what work step they belong to. "Frame" is clearer because it sets expectations for who reads it and what the decision is about.

Create frame and shape checkpoints

Have checkpoints (in terms of approval) for the framing and shaping steps. Framed means "we are aligned on the problem and outcome, and we understand this enough to shape it." Shaped means "we can give this to someone to build and they will know what to do."

I recommend standardizing the terms. Here is a suggestion:

• Candidate — A request or idea that hasn't been framed yet.
• Frame Go — Approved to shape. Problem/outcome are tight enough and it seems there is an idea worth shaping from both a technical and product POV.
• Shape Go — Ready to build. No material unknowns from both a technical and interaction standpoint.

Pitfall #3: Mixing in non-project work

If you don’t separate out the shaped project work from incidents, urgent issues, etc, the team won't be able to focus. There will be too much WIP all the time and it will be hard to understand what is priority and what the real capacity of the team is.

Create a separate process for reactive work

Create separate capacity (time, team, rotation schedule...) for reactive / on call work. Communicate this clearly so everyone knows what work they are doing and not doing. Make the allocation/capacity explicit so you can measure when you have too much or too little.

Track urgent work with tickets. Put them in a different place or tool from the shaped project work so that they don't mix together.

Separate small things from urgent things. A bug that is not on fire should be batched for a rainy day. A bug that is on fire with an upset stakeholder needs attention. 

Project work that relies on third parties is technically reactive work. If you are waiting for a response from someone else, you don't control the cycle schedule. Better to do that work on a kanban than Shape Up style.

This is a post in the Shaping in Real Life Series. Subscribe for more posts about how to make Shape Up work in real-world teams.

What do you want to know more about? Shoot me an email and I'll respond personally or write a post here.

Our product is 15 years old, with a lot of legacy code and outdated technologies. We also have four platforms, and every new feature needs to be implemented across all of them. Our engineers say that the minimum time they need to ship anything of real value (not just small things) is about three months — which is much longer than the six-week cycle in Shape Up.

How can we apply the Shape Up approach in a situation like this?

Yes, legacy code adds friction and makes things take longer. And yes, supporting multiple platforms adds complexity. But there’s something tricky going on here. Those words “anything of value” are extremely broad. They imply there is some general pushback from engineering to product. Usually, when that is happening, it’s because there isn’t enough sharpness in the shaping. There isn’t enough back-and-forth between product and engineering about the exact itch we’re trying to scratch and what trade-offs we’re willing to make.

Narrowing down the problem

I worked on a team that was asked by leadership to build “notifications” for their web-based intranet. The intranet was a kind of custom CMS that sprawled out over time. In response to the request for “notifications”, engineers sketched out a big project: it had different notification types for each content area, native apps for iPhone and Android, and what seemed like unavoidable settings and administrative screens. The concept covered everything you could reasonably expect “notifications” to mean.

But because the concept was so big, it sat for over a year with no movement. There was never enough capacity to take it on.  Leadership kept bringing it up with escalating urgency, but it was always too big for the small team to tackle. Eventually, they pulled me in to unstick the project.

The first thing I did was question leadership about the framing. Why were they so urgently in need of “notifications”? What were they doing without notifications today, and what was going wrong with that? It turned out the real issue was they had an ancient but critical mailing list that wasn’t integrated with the SSO. To leadership, “notifications” meant being able to send messages through their intranet to verified identifies instead of using the old mailing list.

This reframing enable us to shape a tight project under six weeks. We built a “newsfeed” feature on the intranet that surfaced updates according to the existing permission system and sent email notifications for each update. It wasn’t necessary to build other notification types, native apps, or complex settings. When we launched and shut down the old mailing list, it was a big victory.

Narrowing down the problem isn’t an either/or proposition — it’s not that you either get all the behavior you want, or just one small piece. Finding a foothold can solve a real problem, produce a meaningful win, and pave the way for more. In this case, narrowing down to the mailing list problem and building the newsfeed gave us a lightbulb for the native apps. After the newsfeed shipped, we shaped and built an iOS app that surfaced the newsfeed, sent push notifications instead of emails, and offered webviews to the rest of the intranet. This was another big win. The other notification types and settings that were speculated about in that first big concept haven’t been needed yet.

Slicing the segments

Another cause of monster scope is trying to address every customer segment at once. Is it really true that the solution must solve every case for every customer in order to be valuable? Often not.

A fintech I worked with wanted to improve conversion in their onboarding by eliminating a long form of financial questions. They discovered it was possible to pull data from their bank integrations instead of asking for it again. But each bank integration provided different data under different agreements. If they framed the project as “eliminate this onboarding step for all customers”, it would take too long to cover every case. So they sliced customers into segments by bank, and looked at the relative sizes. They discovered they could hit a meaningful target for the quarter by focusing on just two of the five banks.

Negotiating the rewrite

There will be times when legacy code and complexity in the stack are creating so much friction that all development slows down. I’ve seen cases where teams at small companies adopted tech created for large enterprises (eg. Kubernetes or GraphQL), only to find out later that it was always in their way.

Refactorings, infrastructure changes, and rewrites do earn their bad reputation. They easily get out of hand and block customer-facing progress. But they can be necessary.

If something really needs to get ripped out or redone, the key point is to negotiate it as a business decision. Rewrites go wrong when they are treated as something unique to the engineering department, exempt from normal business scrutiny. Engineering and product should come together, frame the problem, and weigh the investment against all the other opportunities on the table.

One under appreciated approach is to leave the existing system in place and build a new version on a new chassis with an upgrade path. If the entire old system has to move over, there isn’t room for trade-offs — anything that breaks will upset someone. But when you’re building a new alternative, you can do what is described above and be selective about the most valuable cases.

When the monster is worth it

Sometimes a project is a monster and that’s okay. When I was at 37signals, we did a giant rewrite of our user authentication system across multiple apps that combined different databases into a central SSO with unified billing. That was a giant effort that took months, and everyone felt satisifed with the time we spent.

If the thing can’t be done in under six weeks, but it’s still worth doing, then the approach is to slice the monster into head, tail, legs, etc. Frame and shape each piece as a separate effort to build in under six weeks. Slice vertically — into things you can try and demo separately. Don’t break the work into logical parts that are supposed to all come together at the last moment — they never do. 

Sequence is important. Tackle the most unknown slices first. It’s tempting to do the “knowns” first, to show momentum. But this is an illusion. You don’t want a smooth-looking project that blows up at the last minute when a critical piece doesn’t work the way we expected. Better to surface those unknowns as early as possible, when we still have time to change the approach.

Lastly, every slice doesn’t call for the same level of finish. Sometimes a stub is enough, in order get something routine in place (like auth) and move on to a more critical slice. Very often, it’s enough to wire the code with some raw UI to demonstrate the functionality works. Finishing all the way to pixel-perfect makes sense when we’re confident that the mechanics are correct and we won’t have to rip it up and redo it.

Question everything

If there’s a take-away here, it’s to never take scope at face value. Engineers are being completely rational when they respond to fuzziness with more time and scope to cover all possible interpretations. Nailing down exactly what is needed, what is possible, and negotiating to find the biggest win is possible. The more challenging the engineering constraints are, the more we need to shape. And the more we take the shaping as a collaborative challenge, the more energizing it is when we find a solution together.

The idea that we should involve everyone in everything reveals that we have more to learn about how to collaborate. It's like pulling everyone into a meeting. Nobody knew how to break the problem apart, so now twenty people are sitting around the table. Putting everybody in one room is the lowest denominator of collaboration. Same with asking everyone to take part in the same work.

Pushing people into areas where they aren't necessarily strong or interested is an uphill battle. There are lots of amazing engineers who love technical problems and don't like talking to customers. There are extremely good interaction designers who can't pick a font. There are incredible visual designers who elevate everyone's work and don't like negotiating the scope.

Real collaboration is when someone knows something deeply, another person knows something else deeply, and we put our heads together. We bridge the gaps, we fill in different perspectives, we add in information the other doesn't have. It's 1+1=3. More comes out than we put in.

A product person can deeply understand the customer. An engineer can deeply understands what's possible in code. And these two can have an incredibly productive session together. When the shaping is over, the engineer can go back to coding and the product person can go back to interviewing. Swap in any roles you like: designer, business analyst, front end engineer, SRE...

From founding teams to scale-ups to small squads in big businesses, I've seen this collaboration of experts work. But doing it requires more than throwing people into a room. The "product trio" doesn't work magically on its own. What we need to collaborate better is (1) appreciation of each others' strengths and (2) a common language to communicate with.

There are many, many ways to do that. But one accessible technique is breadboarding in a shaping session. A breadboard is concrete enough to see problems and surface issues, yet lightweight enough for a group to stay engaged and make changes on the fly. Here's a talk from Y Oslo where I gave a play-by-play showing how a product trio can make shaping decisions with a breadboard.

Of course, T-shaped people are important in some roles. And unicorns who can do it all are amazing. But we aren't all those, and we don't need to be. Being a specialist, being known for our expertise, and working with skilled people who we respect is a true pleasure. We just need to learn how to do it.

When PMs start doing the work called "discovery" — things like user research, user interviews, and voice of the customer — they're excited and hopeful. They're eager to understand what's truly important and how they can make things better for people.

The more discovery they do, the more ideas they get. The ideas, the interviews, the stories, the pain points — they all start to pile up. That's where the problem comes in. Now the PM has a giant portfolio of ideas. But the team can only build one thing at a time. How do they decide on the one thing to do next?

In theory, there are systems to rank and sort ideas. But we all know they don't bring you to a decision. You can't go into a meeting with leadership and say "we should do this because it's a 3.7 and not a 3.5."

Some PMs focus on the qualitative side and try to gather more stories. But they're disappointed when they go to leadership and the stories don't sell themselves.

The counterintuitive thing is, we often feel like our task is to get to a "yes." But what we actually need is a way to say "no." It's the ability to eliminate many, many things that aligns us on the one thing. It's the "no, no, no, ... YES!" that gives us the power to move forward and to stick with a project.

To help us to eliminate (not forever, but for the purpose of making a decision now) I've found one technique very helpful. The trick is to flip things around. Instead of describing the good that will happen by doing an idea, we look at what goes wrong when we don't do it. To make that flip, we can ask two simple questions:

1. Knowing the customer can't do what's in the idea today, What are they doing instead?
2. What's bad about that?

Let's look at an example. Say we have two ideas. One is "Customers need a way to upload archived invoices" and the other is "Users need a way to grant access so other employees can search past contracts." How do we compare these two and how do we decide which to invest time into now?

Take the first one. "Customers need a way to add archived invoices." They can't do that today, so we ask: What are they doing instead? We find out they are uploading PDFs of archived invoices into a Dropbox. Okay. Then the second question is: What's bad about that? In this case, the answer was "Well, it's working... but it's inefficient to have things in two places."

Now take the second example. "Users need a way to grant access so other employees can search past contracts." What are they doing instead? We learn that people who can't see the contracts are asking around, finding someone with access, asking them to search for them, and waiting. What's bad about that? Well, waiting for someone else to do it is obviously bad. But we don't know how bad it is. When I ask this question, I often start with "I know this is a dumb question, but..." In this case, we find out that a big customer almost missed a deadline because a team member couldn't access the info they needed and the person who did have access wasn't responding.

Having flipped to the "what's going wrong" side, let's compare. While the archiving story isn't ideal, it's not bubbling up to a bigger problem. The story about missing access, on the other hand, has meaningful implications for satisfaction, retention, and churn. Therefore we can say "no" to the archiving idea and consider a step forward on the access idea.

Whatever kind of discovery work you do, there comes a time when you need to turn all those inputs you've gathered into real projects. We call that work "framing." How to frame projects is a vast topic in itself. But the technique in this post is one that can get you started. As a tool in your toolbox, it'll help you switch from a conversation about "needs" — which are hard to quantity — to a more objective conversation about what's going wrong.

I like to keep in touch with our alumni. Last week I talked to a senior PM from our previous cohort who just got promoted to CPO. She was telling me about a project she just ran. She started off by saying "we didn't do it exactly as you prescribed..." and then went on to show me how she used each of the tools from the course to narrow down an out-of-control project and shape it together with her team.

That quote is music to my ears, because there is no "one" process. But with the right language and tools — and some newfound skills — we can take hold of the work that is front of our noses and steer it in the right direction.

Cohort 6 will take place October 7-22, with a Shaping Workshop on Friday, October 11 and Q&A session on Tuesday, October 22.

Once again, we'll have 20 spots available, and we expect them to go quickly. (All of the previous cohorts sold out in under two weeks.)

See all the details here: Shaping in Real Life, Cohort 6

Best,

Ryan & Katya

For those who know Shaping in Real Life, this belongs in the topic of framing. When we frame a potential project, we need to both define the problem and make the case for investing in it. Those different dimensions — money, buzz, morale, time — are about building our case. It's table-stakes that whatever we do should positively impact our customers and users. But to align everyone around doing it internally, it helps to know what this thing impacts and how, and when would be the right time for that kind of impact.