I think we’re both right.

You’re right about 37signals in specific, and therefore “more right” than me. I think my point applies more generally to other teams when put in the requirements perspective.
If the requirement is “add a calendar people can use”, then I completely agree with your point. Epicenter is their approach to designing the appropriate feature set to support that requirement.
If the software is the calendar module, and the requirement is “support recording of events”, then I think Kano (as applied to requirements) is the right way to interpret their process.
You’re absolutely right that it depends on the team, as to which labels (requirements vs design) get applied at what level of decomposition. 37signals seems to take a “light” approach to requirements documentation (my conclusion from reading other blog posts of theirs), and captures requirements more in a way that integrates the “what” with the “how” – more along the lines of ‘pure’ interaction design.
Personally, I think “add a calendar” is not sufficiently precise to be actionable (as a requirement). The word calendar is so symbolic that it means different things to different people, and is therefore ambiguous. As you point out, with the team involved, that may not matter much.
Imagine, however, that 37signals was outsourcing the calendar project. If they just asked their outsourcer to “implement a calendar” there is very little chance they would get what they want.
So, I agree with you that 37signals is using it as a design tool, given the skills and dynamics of their team. But I believe framing it in the context of requirements definition has more relevance for most teams, and most of our readers.
This is the point in the discussion where other readers tell me I’m wrong in my assumptions…
Thanks again, and please keep commenting and reading!
Scott

Epicenter design feels like an excellent tool to keep lots of good ideas from muddling the execution of a requirement. The business need (requirement) in the case of 37signals was to provide a calendar. After that, they used epicenter design to stay focused on only what was needed to support that requirement in the best way for their users, and epicenter design seems like a powerful tool for that.

Clearly, this conversation is affected by the continuum of requirements/features/interaction design. Increasingly, I wondering if the right breakdown of that continuum depends on the individual teams involved and their strengths.

-Andrew

I’m not sure exactly what the ‘epicenter’ is – I had never heard it before. From Jason’s description, I interpreted it as a special case of Kano analysis – build software around a single must-be requirement. This limits the scope of the software, in exchange for providing great clarity around what the software should accomplish (and when the dev team is complete).

The 80-20 rule, like in most areas is probably an ideal combination, and what makes companies successful, if they can sustain it.