A few years back we went looking for a better way to work. Not because everything was broken, but because we knew we could be more focused. We were a good team doing good work, but something about how we organized that work wasn't clicking.

Priorities shifted every week. Teams started projects at different times. We'd be mid-build on something important and already getting pulled into the next thing. We tried the usual stuff: Agile, Scrum, stand-ups, sprints, retros. They aren't bad. They work for a lot of people. But for us, they added more process without solving the real issue: we never finished anything with focus.

Then we found Shape Up.

Shape Up is a way of working created by the people at Basecamp. Ryan Singer wrote a book about it. It's free to read online. No certification, no expensive workshop. Just a clear way to organize work.

You've probably heard of Agile, Scrum, two-week sprints, story points, velocity. Shape Up is simpler. Less jargon. And it actually makes sense once you see it in action.

The core idea: work in focused cycles with a clear appetite for each project. Appetite isn't an estimate. It's a decision. How much time are you willing to spend on this? Not how long do you think it'll take. That distinction changes everything.

Before a cycle starts, you shape the work. Define the problem. Sketch a solution (not design it, sketch it). Set boundaries for what's in and what's out. Flag rabbit holes that could eat your time. Then you bet on which projects make the cut. Not everything gets in. That's the point.

Once the cycle starts, the team works. No "hey, can you also squeeze this in?" No changing the plan mid-cycle. When the cycle ends, you stop, breathe, and decide what's next.

The book says six-week cycles with two weeks of cool-down. That's how Basecamp does it. But the whole point of Shape Up is that you adapt it to your team, not the other way around.

When we started, we did three-week cycles. It felt right for where we were. Over time we moved to four. Now we run four-week cycles with one week of cool-down between them. Maybe someday we'll land at six. Maybe not. The framework is flexible enough to let you figure that out as you go.

And here's the thing: you don't have to adopt everything at once. Don't try to. Pick one piece that makes sense and start there.

For us, it was appetites. We stopped estimating how long things would take and started deciding how much time they were worth. That single shift changed the way we talked about work, made decisions, and set expectations with clients. Everything else followed from there.

We don't just use Shape Up internally. We use it with every client.

When we kick off a new project with a client, one of the first things we do is send them the book. Before we write a single line of code, we ask them to read it. Most do. The reaction is almost always the same: "This is useful. Not just for working with you, but for how we run our own teams."

It's not always smooth, though.

The hardest part is explaining that once a cycle starts, we don't change the plan. Something new comes up? It goes into the next cycle. Not this one. That's uncomfortable for clients used to reshuffling priorities whenever they want.

Billing has been tricky too. We price by appetite, not by the hour. We agree on how much time a project is worth before we start, and that's the budget. It's a better deal for everyone, but it takes trust. And trust takes a few cycles to build.

The good part: once clients go through a couple of cycles, they get it. Projects actually finish. Teams are less stressed. Saying "not this cycle" doesn't mean "never." It means "not right now, and here's when."

We also end up speaking the same language. Appetite, boundaries, no-gos, rabbit holes, shaping, betting. It sounds like a lot of new words, but each one replaces a conversation that used to take 30 minutes and end in confusion. Now it takes 30 seconds and everyone's on the same page.

Shape Up is not just for software teams. The principles (focused work, clear boundaries, fixed time, shaped problems) apply to any team that builds things together. Marketing teams. Design studios. Operations departments.

If your team regularly starts more things than it finishes, this will resonate.

It doesn't have to be rocket science to get things done as a team. You need clarity on what you're doing, agreement on what you're not doing, and the discipline to protect the work in progress. That's it.

We're planning to share more about how this looks in practice. Real projects, real decisions, real tradeoffs. When our clients give us the green light, we'll publish specific examples showing what a shaped project looks like from start to finish.

For now, if any of this sounds interesting, go read the book. It's short, it's free, and it might change how you think about getting work done.

It certainly changed how we do.

-Jeisson