INSPIRED, 2nd Edition

CHAPTER 55Testing Feasibility

When we talk about validating feasibility, the engineers are really trying to answer several related questions:

• Do we know how to build this?
• Do we have the skills on the team to build this?
• Do we have enough time to build this?
• Do we need any architectural changes to build this?
• Do we have on hand all the components we need to build this?
• Do we understand the dependencies involved in building this?
• Will the performance be acceptable?
• Will it scale to the levels we need?
• Do we have the infrastructure necessary to test and run this?
• Can we afford the cost to provision this?

I don't want to scare you. With most product ideas that your engineers review in discovery, they will quickly consider these points and simply say “No problem.” That's because most of our work is not all that new, and engineers have usually built similar things many times before.

However, there are definitely ideas where this is not the case, and some or many of these questions can be very difficult for the engineers to answer.

One very common example right now is that many teams are evaluating machine‐learning technology, considering build/buy decisions, and assessing whether the technology is suitable for the job at hand—and, more generally, trying to understand its potential.

Here's some very practical and important advice for you to consider. Holding a weekly planning meeting where you throw a bunch of ideas at the engineers—and demand they give you some sort of estimate ...