At our last company-wide get together, we had our first “roast” of 37signals products. We invited everyone there to get up in front of the room and rip on something in a 37signals app: a flow that was confusing, a form that could be streamlined, a UI that was ugly, copy that didn’t make sense, etc.
It was enlightening. In large part, that’s because it forced a shift in perspective. Instead of feeling bad about pointing out a flaw, it became your job. And that gave everyone an excuse to rip on something without worrying about hurt feelings, seeming too negative, or the issue being something outside the scope of what you normally work on. Everyone understood the spirit of the roast and felt free to take a jab.
For example, there was a Javascript bug that came along with importing Writeboards into Basecamp. It had been around for a while, but we hadn’t gotten around to it since customers hadn’t complained about it. But the pain of seeing it in action during the roast spurred us to fix it anyway. Without that discussion, it might have just lingered on.
If you’re looking for an honest conversation that might reveal things you’re not seeing already, try a roast.
jonezy
on 14 Jun 11what an absolutely fantastic idea that is. I do this to myself all the time but i’m gonna try this as a team exercise for sure!
Chris
on 14 Jun 11Definitely an intriguing idea – a fun way to take the defensiveness out of trying to find “issues” with products.
That said though, if customer’s hadn’t complained about the bug, was it really worth fixing? Do you just think it was something they were “living with”, in which case a fix is warranted? Or do you think they never noticed, in which case that time might have better been spent on something else?
Anonymous Coward
on 14 Jun 11Similar method i use – when i am working on a design, I ask other people, “what is the worst part of this design?” Instead of possibly identifying the parts that are working, it is a fast way to get to the bottom of what really ISN’T working. When you get to a point where it is hard for someone to find something they hate, or the things they find are very small, you can feel more confident about your work.
Al Pittampalli
on 14 Jun 11Amazing idea. Really flips the script on the normal context that prevents real criticism to surface. Really like this idea, Matt.
TJ
on 14 Jun 11This is a great idea – and is something that should be done all the time as part of product development. There is no better way to improve something than put it to a real, critical test.
Brandon
on 14 Jun 11How do you guys address fixing bugs versus deploying new features? I suppose that the roast could stir up a lot of “problems” (that aren’t really that big of a deal) which could distract you from new features.
Michael Smith
on 14 Jun 11I love that you guys have the balls to do that and the transparency to share with all of us. I think that is a PERFECT, yet clever, way to improve the company, the products, and frankly, give the peeps a VOICE. Good onya.
Andrew
on 15 Jun 11You might want to come up with a different phrase to “Roasting” if you have a UK audience. If you use it for a google search, you’ll find some work-unsafe links.
Matt
on 16 Jun 11Has 37 Signals grown large enough to hurt feelings within the team? David and Jason aside?
Interesting perspective here!
Michishige Kaito
on 16 Jun 11While an unreported bug might not be worth fixing in some cases, it will always make the developers feel better about their software. Functional software is a given, but well done software sets the real devs apart from the script kids.
Also, new features should not always be a priority. There has to be a balance between fixing old flaws, and implementing new features. After all, adding new code to a “broken” code base only makes matters worse, and eventually leads to a pile of code nobody wants to touch with a 15 feet pole.
Nathan
on 16 Jun 11I take the 6-7 band leaders at our church (Richwoods.org) to do this over a beer quarterly. Has made an enormous difference. Not just for quality’s sake, but for increasing morale, as strange as it seems.
Megan Tackett
on 16 Jun 11I LOVE this concept—definitely going to borrow the idea when consulting clients. Well played.
Robert Kelly
on 17 Jun 11The brilliance of this idea lies in its simplicity. I had not heard of this approach before and I think it is a novel idea, but I am sure that you will see many management consulting firms coining this approach and selling it to their fortune 500 clients if they haven’t already! It seems like a perfect approach to proactively fix issues that haven’t risen to the top of the complaints list. In the past few years, developers have eschewed a traditional systems approach to developing software, where they methodically design software and test features before rolling them out. Developers today quickly rush out innovative features but fail to spend as much time on design and testing. Sure, we benefit from using great new features more quickly, but it often comes with at the price of bad UI and bugs. Perhaps employing roasts more often will allow us to enjoy the benefits of rapid innovation while also quickly identifying and fixing problems.
This discussion is closed.