grid style, no sidebar

What is Pretotyping?

If you have never heard the term pre-to-typing before, don’t despair, you are not alone. Most folks have not and hence are not familiar with the concept and approach it represents.

The term, as explained by its founders: 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.”

The basic theory, practice and tools for pretotyping were developed by Alberto Savoia while he served at Google (2008-2012) as Engineering Director and Innovation Agitator. Alberto set out to determine the cause of product failures. He discovered that products failed in the market most often because they were not the “right” fit, and not due to poor execution (of course this has its fair share too).

The purpose and intent of creating a product pretotype is to validate the product idea before putting in time and money building an actual “prototype”. So there is a key difference between a prototype and a pretotype. Alberto explains the difference beautifully by citing the example of Jeff Hawkins’ use of a pretotype of a Palm Pilot to validate the idea and determining a market need for a PIM (Personal Information Manager), a new product category that he pioneered.

Hawkins mocked up a Palm Pilot with wood and paper; he carried it with him to simulate (pretend) the experience of a “real” device. He showed the device to several people, explaining how it would work aod provided a (simulated) real experience of a product. His goal was to determine if people would actually buy such a device before building an actual “prototype,” which would be time consuming and expensive.

The key differences between pretotyping and prototyping are:

Pretotyping Prototyping
Would people be interested in it? Can we build it?
Will people use it as expected? Will it work as expected?
Will people continue to use it? How cheaply can we build it?
Will people pay for it? How fast can we make it?

The concept of pretotyping has close affinity and practice to Eric Ries’ high Lean Startup Movementand the practice of building the Minimum Viable Product (MVP).

Beyond commercial (B2C) product development, pretotyping can be applied to:

  1. Business-2-Business Products
  2. Internal Products (for employees within an organization)
  3. Government Products (for individual or corporate taxpayers).

Pretotyping helps eliminate the Bad Ideas from the Good. It helps Fail Fast and Fail Often, facilitating product idea evolution towards the “right” product with minimum possible investment of time and money.

Posted by Manjit Singh

What is the Difference Between a Use Case and an Agile User Story?

The user story originated in XP but is a key tool used in Scrum to build the product backlog. The user story, written from the perspective of a user role, is used to capture the business value or benefit (to be) achieved when the user role performs an action (funct.on) User Stories are comprised of 3 elements:

  1. a brief statement, of the form “As a ___, I want to ____, so that ____,” used for planning (commonly written on a note card)
  2. conversations that elaborate on the story
  3. tests that convey and document details used to determine (confirm) when a story is “complete”

Ron Jeffries has named these 3 elements: Card, Conversation, and Confirmation.

Details of the story do not appear in the brief statement; these are left to be developed later through conversations and acceptance criteria between the team and the product owner. User stories are not detailed requirements specifications but are negotiable expressions of intent. They are short, easy to read, and understandable to developers, stakeholders, and users. They represent small increments of valued functionality that can be developed in a period of days to weeks. They are relatively easy to estimate.

Use Cases became common within the context of the Rational Unified Process (RUP). A Use Case is a list of steps (possible scenarios), usually describing interactions between a user and a system, related to achieving a particular goal.

The main differences between Use Cases and User Stories are:

  • Use Cases are designed to get requirements elicited and recorded ahead of development (not necessarily *all* the requirements but enough to do a considerable depth of Analysis if required).
  • User Stories are designed to get the requirements “Just in Time” for development and record (on the “Card” part) just enough information to decide the sequence in which the stories will be addressed, who to have the “Conversation” with when its time comes, and what the conversation will be about.

The whole idea of Agile is to dissuade people from doing the work up-front. A User Story is an ideal tool designed to encourage minimal work up-front. Remember, don’t put the requirements on the card; the card is just a placeholder for a conversation to have later between the Product Owner and the Team. The card holds just enough information to allow the Product Owner to schedule the conversation by priority.

In summary, it helps to remember this statement:

One [User Story] is a value statement, the other [Use Case] transactional. ~ Steve Adolph

Posted by Manjit Singh