Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience.

Let the storm pass

Shipping can actually generate new work if you’re not careful. Feature releases beget feature requests. Customers say “Okay, that’s great, but what about that other thing we’ve been asking for?” Bugs pop up. Suggestions for improvements come in. Everyone is focused on the new thing and reacting to it.

The feedback can be especially intense if the feature you shipped changes existing workflows. Even purely visual changes sometimes spur intense pushback. A small minority of customers might overreact and say things like “You ruined it! Change it back!”

It’s important to stay cool and avoid knee-jerk reactions. Give it a few days and allow it to die down. Be firm and remember why you made the change in the first place and who the change is helping.

Stay debt-free

It can be tempting to commit to making changes in response to feedback, but then you no longer have a clean slate for the next cycle. Remember: these are just raw ideas coming in. The way to handle them is with a gentle “no.” Saying “no” doesn’t prevent you from continuing to contemplate them and maybe shape them up into future projects. Saying “yes,” on the other hand, takes away your freedom in the future. It’s like taking on debt.

Remember, the thing you just shipped was a six-week bet. If this part of the product needs more time, then it requires a new bet. Let the requests or bugs that just came up compete with everything else at the next betting table to be sure they’re strategically important.

Feedback needs to be shaped

Here we come full circle. The raw ideas that just came in from customer feedback aren’t actionable yet. They need to be shaped. They are the raw inputs that we talked about in step one of the shaping process: Set Boundaries.

If a request is truly important, you can make it your top priority on the shaping track of the next cycle. Bet on something else for the teams to build and use that time to properly shape the new idea. Then, when the six weeks are over, you can make the case at the betting table and schedule the shaped version of the project for the greatest chance of success.

We built Basecamp to execute the techniques in this book. It puts all our project communication, task management, and documentation in one place where designers and programmers work seamlessly together. See How to Implement the Shape Up Method in Basecamp.