INSPIRED, 2nd Edition

CHAPTER 46Feasibility Prototype Technique

Most of the time your engineers will review your product ideas and tell you that they have no real concerns about feasibility. This is because they have likely built similar things many times before.

However, there are several situations wherein your engineers may identify a significant feasibility risk involved in solving a particular problem they are working on. Common examples include:

• Algorithm concerns
• Performance concerns
• Scalability concerns
• Fault tolerance concerns
• Use of a technology the team has not used before
• Use of a third‐party component or service the team has not used before
• Use of a legacy system the team has not used before
• Dependency on new or related changes by other teams

The idea is to write just enough code to mitigate the feasibility risk.

The main technique used for tackling these types of risks is for one or more of the engineers to build a feasibility prototype.

An engineer will create the feasibility prototype because it is typically code (as opposed to most prototypes created by special‐purpose tools intended to be used by product designers). A feasibility prototype is a long way from a commercially shippable product—the idea is to write just enough code to mitigate the feasibility risk. This typically represents just a small percentage of the work for the eventual shippable product.

Further, most of the time the feasibility prototype is intended to be throwaway code—it's okay and normal to be quick ...