A prioritization worksheet that..works

A have recently been called to facilitate a prioritization process for an upcoming MVP (Minimum Viable Product). A nice approach that presents formal results and works in real world is to use a prioritization worksheet as described in the book “A Project guide to UX design” by Russ Unger and Carolyn Chandler http://projectuxd.com/.

A created a more “automated” version of this worksheet in google drive.

Prioritization Worksheet (Google Drive Link)

where I used the following rules:

Worksheet rules

The worksheet was completed by 4 key members:

  1. Business importance: Product Manager
  2. User importance: UX Designer
  3. Technical feasibility: Software Architect
  4. Resource feasibility: Project Manager

Each member rated his field by the rating rules and then a custom formula applied:

(Business + User importance) – (Technical + Resource feasibility) = Feature score

Features are then prioritized by their score which is a 4 members opinion.

Implications:

Each member should have conducted the required research and rate based on validated knowledge.

  • business importance requires defined and clear business goals
  • user importance requires user research (at least)
  • technical feasibility requires technology knowledge and high-level architecture
  • resource feasibility requires knowledge of team performance and project planning.
Additionally the initial feature set has to be well defined. New feature ideas should then pass the same process.

The results are presented below:

Prioritization worksheet

We processed in implementing the features with score over 0.

Value: we decided in a formal level on what features we should focus for this MVP.

What’s next? Create a prototype and test it with real users.

Andreas Papaderos

3 comments

  1. Peter Boersma

    You wrote “We processed in implementing the features with score over 0” but I assume you first established which features belong together, right? For example: the feature “editing a thing” may have gotten a score of 3, but if the feature “creating a thing” got score 0 and was not included, there isn’t much to edit…
    The fact that some features work best when implemented together in the same release, is something that is hard to capture in formal prioritization models and usually requires a manual – and somewhat informal – step, performed after the formal step.

    Reply
  2. Andreas Papaderos

    Peter,
    it is true that feature dependencies are hard to capture. The solution I found is to first coalesce its feature in conjuction with other stakeholders views in order to create a robust set of high-level features. We tight up its feature with relative tasks that may pre-required in order for the feature to work.

    Reply
  3. Peter Boersma

    Andreas, yes (apart from the sesquipedalianism) that does sound better :-)
    In my view, grouping the features that “belong together” depends on the core concept that is selected for a solution. If the concept is “a community with some shopping functionality”, a profile and community contributions belong together. If the concept is “a shopping site with some community features”, a profile and the shopping history belong together. Different features may end up not making it into the release.

    Reply

Leave a comment