How to take user feedback (the Cro-Magnon responds)

In a recent entry in his Coding Ergonomics blog, Ryan Eccles, made the following comments on the pretotyping manifesto: 

I tripped across another software Manifesto–a term I cannot stand as it emphasizes political or religious opinion– called Pretotyping and is written with the same structure as the agile manifesto:

• innovators beat ideas

• pretotypes beat productypes

• building beats talking

• simplicity beats features

• now beats later

• commitment beats committees

• data beats opinions

It is regretful that they chose this format to explain pretotyping because I think the usefulness of the concept is lost in such a simplified set of Cro-Magnon dichotomies.

Pretotyping is all about getting feedback, good or bad.  While I am not going to immediately jump in and replace the term manifesto with – say – cheat-sheet (even though I kinda like that term), I am going to give it some serious thought since I also think that the term manifesto is a bit too heavy and overused by now.

I like the way Ryan writes; "Cro-Magnon dichotomies" is a great description.  While pretotyping is a neologism, I have to believe that the practice has been around for a while.  Here's a Cro-Magnon pretotyping:

Unlike the feedback on the manifesto word, however, I think I'll stick to my Cro-Magnon dichotomies for now.  Yes, they are a "simplified set" but that's exactly what I was after.  Besides, I don't think that a Cro would use the "X beats Y" pattern.  Here's my interpretation of a Cro-Magnon dichotomizing the manifesto/cheat-sheet:

Here comes the REALLY useful part of Ryan's blog entry:

Their ‘what is’ section has better statements describing what it is:

Less formally, pretotyping is a way to test a product idea quickly and inexpensively by creating extremely simplified versions of that product to help validate the premise that “If we build it, they will use it.”

I think a traditional thesis statement would go much further to describing what Pretotyping is and why it is useful. For instance, here’s a refactor of their position:

Preotyping Assertion:

The most accurate way to discover the appeal and usage of a product is to observe opinions and interactions of users that have experienced that product. In the absence of an actual product–due to the fact the product does not exist yet–the next best approach is to simulate the experience with a facsimile.

A Corollary:

A facsimile that can be modified quickly and cheaply will produce more appealing products because a greater number of variants can be produced than a facsimile that is slow and expensive to produce.

Now we are talking. Ryan has a way with words.  I will take this feedback and wording and will probably integrate it in future versions of pretotyping material.  Which brings me to one of the key points of pretotyping: using feedback.  If you ignore feedback, or only listen to positive feedback you might as well go ahead and productype (i.e. skip ahead, build the product you are thinking of, and cross your fingers that people will actually go for it.)

One of the best indication that you are on to something with your idea or product is that people are willing to invest their valuable time to give you feedback.  Ryan obviously took some time to write his blog post and craft his Pretotyping Assertion and Corollary.  He would not have invested that time if he thought that pretotyping had no merit.  The not-so-implicit message I read in Ryan's post is: "There's something interesting here but, IMO, it's presented poorly.  Here's a way to improve it."

Thank you Ryan!

Alberto