My #Agile #Pretotype experience

Two months ago I was introduced to the concept of Pretotyping. If I remember correctly, the introduction was through an excellent InfoQ article. The concept and practice intrigued me and I was able to apply it to a project I was working on recently. This is a recap of that experience in the hopes that is may assist others.


There is an excellent website that provides some great information on Pretotyping. The site is The definition of a Pretotype that is proposed on the site is:

Pretotyping[pree-tuh-tahy-ping], verb: 

Testing the initial appeal and actual usage of a potential new product by simulating its core experience with the smallest possible investment of time and money.
There are some excellent examples of how Pretotypes can be created using non-technical deliverables like paper or blocks of wood. But whatever the deliverable is, the concept is to create a deliverable that can be used early on to collaborate with the client on the Art of the Possible and then to confirm the high-level scope and functionality without needing to get drawn into the details.
There is a a quote on the Pretotyping site which I feel adds additional clarity to the concept of Pretotyping.
“We did not invent or discover pretotyping; it’s something that a small number of innovators do naturally. As a matter of fact, our concept and formulation of pretotyping was formed by reading and hearing stories about such innovators and the evolution of their ideas. But what these innovators were doing naturally was not exactly prototyping; it did not have a name and we thought it deserved one. We initially coined the term pretendotype because the most unique aspect of this approach was to pretend or imagine the intended functionality. However, since pretendotype was a quite a mouthful, we simplified it pretotype. The concept of pretotyping is also very close in spirit and practice to Eric Ries’ brilliant Lean Startup Movement and the practice of building the Minimum Viable Product (MVP.)”
In Many ways Pretotyping shares much in common with the Agile Practices of Paper Prototyping and UI Design studio. In fact I would argue that a Paper Prototype or the output from a UI Design studio session is a Pretotype. What I find interesting is the possibility of being able to create a Pretotype technical deliverable (more on what these can be later) that can give the client more of a sense of the solution.
And to be brutally honest, I don’t think some clients would be as accepting of a Paper Prototype as a deliverable. Although we know that the value is inherent in both, some people may see the Paper Prototype as being less professional. The ability to create technical Pretotypes allows for the value to be realized while also addressing any client concerns.

My Pretotype experience

So now that we can see the connection between Agile, Lean and Lean Start-ups, and Pretotyping, what was my experience with Pretotyping?

1. A Pretotype is an incredibly valuable tool to be able to design and perform analysis on the large rocks of value for a project and solution without having to get drawn into details. It was a great tool to stay grounded in what value the client would realize as opposed to the colour schemes, particular fields, and other minutiae.

2. It is difficult to communicate to the client and gain agreement as to where exactly a Pretotype will stop and where Prototypes and other deliverables will continue. Although we tried to state as clearly as possible the boundaries, people are used to Prototypes and find comfort in the detail that exists in Prototypes. My only suggestion would be to continue to over-communicate and continue to discuss the differences between a Pretotype and Prototype. My other thought would be to use the actual term Pretendo-type to more overtly communicate the purpose of the Pretotype. (Some people may assume a Pretotype is a Pre-Prototype, while it is a totally different animal)

3. Although the Pretotyping proponents talk about the ability to use paper and other deliverables for the Pretotype, our clients required a technical experience to allow them to interact with the Pretotype in a manner that is similar to the potential end state. The good news is that there are plenty of great tools out there to create Wireframes that can be used to create Pretotypes. Be careful though, the use of these tools can increase client expectations as to how far the Pretotype may go towards being a Prototype.

I ended up using Iplotz as my Pretotyping tool and I was very impressed with the tool. It was very easy to use and also allowed for the all the functionality I required. Iplotz has both an online and disconnected mode. Iplotz also allowed me to group all my Wireframes into a project and let people collaborate of the project. The suite of controls was also very extensive. I have heard great things about Balsamiq as well. There are a multitude of other solutions as well. I encourage you to review the options and decide for yourself which fits your needs the best.


Pretotyping has definitely found a permanent place in my Agile toolkit. It won’t fit for every project and client, but I believe it will be something that I will use more often than not.


Author: Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: