Ryan Singer

What most teams are struggling with is that they don't have predictable repeatable shipping of things. At least from my experience, the bigger really widespread struggle is, stuff isn't moving, it's dragging. I can't see the end. I'm losing my... I'm feeling burned out.

What we see in Shape Up teams when they hit their stride is that the PM moves upstream. So the PM is less busy with, 'How do I get this project to not be in a bad state when it's getting built?' And they're way more in, 'How do I understand the business context? How do I narrow down the problem? How do I negotiate back and forth with maybe the CPO who brought this to me to understand where the core of it is?'

I often use this analogy of if you're doing a home renovation, you can have the most beautiful rendering of the new bedroom and we're going to have these lamps on the side of the bed that are coming out from the wall. But if you haven't checked if there's electricity in that wall there or not, it's going to drastically change the cost and the time and everything.

The dominant failure case that I see in the real world is always, again and again, not enough detail. And it's also the most common failure mode where the engineers run back to the product folks and say, 'I'm not getting enough from you.'

It's shaped if we can give this to a technical person and they say, 'Yeah, I know what to go build now.'

The amount of detail that the team is going to feel helps them is a dial that we can turn that depends on who's on the team. So, if you have a more junior person who's on the build team and then you have a more senior engineer who's involved in the shaping, they can make that junior engineer much more successful with additional detail.

I would say wait until it hurts more. If the unfamiliarity is the big problem with it, then maybe the things are fine. Because it's not like this is the only way. It's more like, changing is really hard, and if there's a good reason to do it and it's like, look, we've done it the old way. We've tried different experiments. We've even already churned through a new head of product, or we've got a different CTO in and we're still having the same problems, then there comes a point where it's like, I know that this is uncomfortable, and I don't know somebody who's done it, but I think we need to try something different because we can't continue this way.

What we need to do in a shaping session is we come out with some kind of diagram where engineers, product and design, they're saying, 'We understand that.' So the first thing is we are not going to start something unless we can see the end from the beginning.

Here's a good rule of thumb. If it's shaped well, you can usually describe it in less than 10 moving pieces. If I can say, 'It's going to have this, this, this, this, this, and this,' and that's how we're going to let people see the empty spaces, that's a good indicator that it's clear enough that it's shaped well.

We are not going to start something unless we can see the end from the beginning. We're not going to take a big concept and then say, 'What's the estimate for this thing?' We're going to go the other way around and we're going to say, what is the maximum amount of time we're willing to go before we actually finish something? How do we come up with a idea that's going to work in the amount of time that the business is interested in spending?

You can't put 10 pounds of crap in a five pound bag. So, it's a high academic statement and we can't just take any project, no matter how giant it is, and then throw it at a team and say, 'Figure it out and ship something meaningful in six weeks by cutting away scope.'

If we think of six weeks as a maximum, that's going to force us to ask some really good questions to ourselves about what piece of this do we really think we can land? Because if you try to say, in six months, we're going to ship this thing, you can't get your arms around all of the problems that have to get solved for an entire six-month chunk of work to actually happen.