(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.
Latest Articles
Comments on all Articles
