https://embed.notionlytics.com/s/VTIwd1ZVdFhiMk40U0hCUVRsVnJjazFVWTFBPQ==

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:

• Does the team have the required know-how and skills?
• Do they have enough time to build?
• Does the new product or feature require significant changes on the architecture and, if so, what is the impact ion other places?
• Are specific infrastructure components or even 3rd party services required? If so, does the team know these well enough?
• How will the new feature impact non-functional requirements, such as performance, scalability, or up-time?
• Once built, does the team know how to roll out and provision?

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.

Source: https://www.visual-paradigm.com/scrum/what-is-scrum-spike/

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.