A better way to plan, build, and ship products | Ryan Singer (creator of "Shape Up")

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.

Generally, the more narrow you are... the easier it is to build a great solution for those people, because now you can actually hone in the product experience, the messaging, and everything to serve exactly those people.

Shape Up is a product development methodology created by Basecamp that uses 6-week cycles instead of traditional sprints.

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?'

Momentum is reflexive in that, you know, high momentum leads to more high momentum. Low momentum leads to more low momentum because there's this energy that goes through companies.

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.

One thing I've noticed among founders and just people in general is they tend to write like a PR person and not like a human... how do your customers or your users describe your product to other people?

I think it's super important that founders see a line of sight to work on this for ... I think my rule of thumb is a decade, just do you see yourself working on this for a decade?

We called it, not even a side project, we called it an experiment. And that framing I think, is for me, has always been helpful because an experiment is really not about success... it's really to learn.

"This" and "something different" refer to Shape Up, Ryan Singer's product development methodology that replaces traditional Agile/Scrum approaches with 6-week cycles and upfront "shaping" work.

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.

In this product development framework, "shaping" means defining a feature's scope and approach, while "empty spaces" refers to available time slots in a calendar feature they were designing.

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.

I would've actually tried to monetize and generated revenue sooner... we coulda been cashflow, break even, you know, maybe 2015, 2016, which would've just given us a lot of flexibility in kind of owning your own destiny.

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.

I used to write like a problem journal. Like just when things annoyed me or when things were less efficient, I would write it down as like a note. And I didn't try to solve it... I was just like, 'This is annoying.'