When we talk about validating feasibility, the engineers are really trying to answer several related questions:
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 either in time, story points, or any other unit of effort—is almost certain to go badly. If you put an engineer on the spot, without time to investigate and consider, you are very likely to get a conservative answer, partly designed to make you go away.
If, however, the engineers have been following along as the team has tried out these ideas with customers (using prototypes) and seen what the issues are and how people feel about these ideas, the engineers have probably already been considering the issues for some time. If it's something you think is worthwhile, then you need to give the engineers some time to investigate and consider it.
The question isn't, “Can you do this?” Rather, you are asking them to look into it and answer the question, “What's the best way to do this and how long would it take?”
The engineers will sometimes come back and say they need to create a feasibility prototype to answer one or more of these questions.
Many of our best product ideas are based on approaches to solving the problem that are only now possible, which means new technology and time to investigate and learn that technology.
If that's the case, first consider whether the idea is potentially worth investing the necessary time in discovery. If so, then encourage the engineers to proceed.
One last point on assessing feasibility: I meet many product managers who hate any product idea that the engineers say they need additional time to investigate. To these product managers, this means it is already too risky and time consuming if that happens.
I tell these product managers that I personally love these items for a few reasons. First, many of our best product ideas are based on approaches to solving the problem that are only now possible, which means new technology and time to investigate and learn that technology. Second, I find that when engineers are given even a day or two to investigate, they often come back not only with good answers to the feasibility question but also with better ways to solve the problem. Third, these sorts of items are often very motivating to the team, as it gives them an opportunity to learn and to shine.
So many technology‐powered products today have a hardware element within them. From phones to watches to robotics to cars to medical instruments to thermostats, smart devices are all around us.
With hardware, the consequences of a mistake in terms of time and money are much more severe.
So how does adding hardware to the equation affect everything we've discussed thus far?
There are some obvious differences, such as different engineering skill sets, the need for industrial design, and of course, manufacturing still takes substantially longer than software, although it continues to improve.
For the most part, however, everything we have discussed thus far still applies, although there are some additional challenges as well. Moreover, when hardware is a part of the equation, the discovery techniques we've discussed are even more important, especially the role of prototyping.
The reason is because, with hardware, the consequences of a mistake in terms of time and money are much more severe. With software, we can usually issue corrections relatively inexpensively. With hardware, no such luck.
Specifically, there are more technical feasibility risks with hardware, and there are additional business viability risks. For example, with hardware we need a much more sophisticated analysis of parts, manufacturing costs, and forecasting. That said, the necessary prototyping of the hardware device has been helped dramatically with the advent of 3D printing technology.
The bottom line is that hardware products require tackling the value, usability, feasibility, and viability risks aggressively and raising your bar on the level of confidence you have before you commit to manufacturing.