Feasibility is about whether a team can actually build the intended solution planned which, for software products, will in most cases have to be addressed by the engineers.

Feasibility: Can it be built?

Whether or not a team is able to build what is planned will depend on a number of questions:

Of course, for most new product ideas engineers will know the answer to these questions and indicate that they are not a problem at all. If engineering teams, as suggested, have already been involved during the complete Product Discovery, they will relate such topics back to components, products and features they built many times before already while ideas emerge and are discussed and, hence, can quickly give a green light.

Feasibility Prototypes

Sometimes, however, engineers will come across a new topic, a new architecture to be considered, a new API they have never worked with before, performance requirements that are much more strict than before or similar aspects. In that case, a feasibility prototype is a great option: just as UX will create prototypes to validate usability (as discussed in Usability Testing), the engineering teams will get their hands dirty and try to build a quick solution to understand what the impact of the new requirement is and to gain confidence in building it.

There are different ways to organize such a feasibility prototype. For example, Scrum has so-called spikes:

Spikes ... are a special type of user story that is used to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.


Whether it is called a hack day, a proof of concept, a feasibility prototype or a spike — what matters is that the engineering teams are allowed to investigate around a certain topic in order to reduce the technical risk. The objective is not shippable code, teams most likely will not cover all edge cases, will not follow coding guidelines and the like. In fact, teams should even be encouraged to produce throw-away code — because, as said, the objective is to learn and reduce technical risks. Once this is done, the team will know how to build the feature properly.