(logo for Campfire a business group-chat application from 37signals)
Jason at 37signals has started a discussion about feature prioritization with his recent post. He describes the epicenter of software as the most important, must-have feature. He argues that this feature should always be the one that is built first, since without it you don’t have an application. This is the same approach we reccommended in our recent post about prioritizing requirements with Kano analysis. The epicenter, while critically important, isn’t sufficient to drive success for the software.
Epicenter == must-be requirement
Jason provides an example of a must-be requirement in his post:
But, what’s the epicenter? It’s the events themselves. Without those you don’t have a calendar. You can have a calendar without color coding. You can have a calendar without alarms. You can have a calendar without dragging and dropping. You can have a calendar without displaying a mini calendar of the next three months. You can have a calendar without a lot of things. But you can’t have a calendar without being able to add events. That’s where you start.
From our first post on Kano analysis:
These are the requirements that most people think about when they talk about requirements. These are the easiest requirements to elicit.
Stakeholders can usually tell us what they must have in the software. In our Am I hot or not? post on requirements prioritization, we see that 37signals focuses on this as their primary criterion for inclusion in a software initial release. They choose to only put essential, or ‘must be‘ requirements into the initial release of software.
Veto power
Jason points out that 80% of the value of the software comes from the epicenter feature. He’s probably right. But the must-be features don’t create a saleable product in and of themselves. They absolutely must exist, or the software won’t sell. They have veto power over success. Without these features, the product will fail. But product success also requires innovation, especially when we are entering a domain as second-movers.
Don’t forget innovation
Innovation, and more precisely, differentiated innovation sells software. It also provides a barrier to entry for competitors (for a short time). In Kano, these are the surprise and delight requirements. We should spend 80% of the first release on the must-have requirements and the other 20% of our time on differentiated innovations via surprise and delight requirements.
Innovation can take many forms, and we talk about different types of innovation in our post, Magic Square of Innovation.
You touched on something very important. I do agree with Jason that the epicenter is very important, but I am not so sure its simple identifying an epicenter in software targeted at different user types. Is the epicenter a usability paradigm? Is it a core set of functionality? A combination of the two?
The 80-20 rule, like in most areas is probably an ideal combination, and what makes companies successful, if they can sustain it.
Hey Deepak, thanks for the comment!
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).
I’m not convinced that epicenter design is really the same as Kano analysis. The way I see 37signals use epicenter design is more around how they design for a particular requirement, not how they prioritize requirements. In the example you site about adding a calendar, I feel that epicenter design comes into play after they decided on what their requirements were for the release. They decided they needed to add a calendar. Once they made that decision (which was based off of customer feedback – not epicenter design), they used epicenter design to arrive at the appropriate feature set to support that requirement.
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
Hey Andrew, thanks for reading and for commenting!
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