Taking the pyramid of quality a bit further

This software product quality pyramid has been reproduced from Gojko Adzic’s book Fifty Quick Ideas To Improve Your User Stories and as presented in Gokjo’s 2012 blog post Redefining software quality.

The five levels are a model for how to assess and perceive software quality ranging from ‘functional’ at the lowest tier where the software is good enough to be deployed because it passes unit tests.

The top tier is occupied by the likes of iOS, Adobe Photoshop, Atlassian JIRA (though that one is up for debate), Buffer and Evernote; software that transcends being just useful to popular (and not in the way that Windows 10 is ‘popular’ because Microsoft is forcing it on everyone).

Product quality pyramid

In his blog post Gojko makes a parallel with Maslow’s hierarchy, so ‘successful’ in this software quality pyramid roughly equivalates to ‘actualisation’. Software that is so good people love it.

But what if instead of a single scale that covers the entire product we look at evaluating parts of a product? This may be a bastardisation of the concept, but let’s just play with it for a second and see if this is useful.

Instead of an overall score of “Works well” or “Useful” let’s slice the pyramid vertically where each slice represents a feature, workflow or user task.

Pyramid sliced into columns


If we’re looking at an e-commerce site then those vertical slices might cover search, browsing categories, shopping cart, checkout, online support, warranty claims, paying with credit card, paying with PayPal, accessing from a mobile device, geolocation, personalisation etc.

Pyramid with overlay

It’s not just a way of evaluating different aspects of software but also a way of thinking about intentionally having different quality criteria across your product.

Perhaps a basic ‘functional’ implementation, a single iteration of a feature may suffice for a feature used infrequently by a minority of your userbase.

Frequently-used features need to be highly refined with several iterations and higher quality criteria (no known defects, performance etc) to be deemed satisfactory and competitive by your target market so they would need to attain at least ‘usable’ status.

I’ve overheard conversations between agile development teams and product owners to pare back test scripts because the high level of quality agreed on was overkill for some user stories.

What if instead of getting into the minutiae of which test scripts to suspend for a user story the team could instead ask:

  • Does this feature need to work well?
  • How often are people going to need it?
  • What sort of people are going to want to use it?
  • Is it just a shortcut or accelerator for something that can already be done?
  • What do users stand to lose if it doesn’t work well?
  • What do we stand to lose if this feature doesn’t work well?
  • How much effort is involved in making this useful?
  • How much effort is involved in making it usable?
  • What might be the ROI if we work on this until it’s useful?
  • What might be the ROI if we settle for ‘works well’?
  • If we aim for basic ‘just passes unit testing’ might that detract from the overall experience? For whom?

So where does MVP fit into this?

I’ve avoided using the term ‘minimum viable product’ in this blog post and I want to point out why. When iteratively developing a product it is considered poor practice to think of it in terms of this pyramid where you build the entire product to a ‘functional and deployable’ state and work upwards.

First, that’s a poor way to determine whether your vision is actually going to result in a viable product from a market perspective.

Second, it often results in decisions to ship overly basic, uninspired and me-too software that meets internal criteria for MVP but actually falls flat in the marketplace.

bottom-up approach like that is not agile, not adaptive, not open to learning and incorporating new information and assumes that the entire scope of what you envisaged from the start is both required and is best delivered in the way envisaged.

You’re likely to throw money away on features you could do without, money that would have higher ROI making other features usable, useful and contribute to a successful product.

When thinking about your MVP or Minimum Viable Experience you should slice the pyramid vertically. Pick one activity, one scenario, one user group and do that well. Test it with that smaller user group, learn from it and get a better feel for what might actually constitute a viable product:

Tiered pyramid with single vertical slice highlighted

There’s also this comparative diagram with different tier labels and slightly different intent to the quality pyramid presented above (author unknown):

MVP pyramid bottom-up and vertical slices

If you enjoyed this article please share it with your friends and colleagues.

Leave a Reply

Your email address will not be published. Required fields are marked *