Well it depends on what your building and its application. If you need various functionalities and interchangeable modules then its the route you'll have to take but if you can avoid using system on module architecture then I would say that you should. Why, because it requires more design effort for a degree of added flexibility. Also a lot more failure points and time spent troubleshooting. Added cost of PCB and components. Making sure that the module and base board connections do not introduce noise artifacts or matching issues. The breaking of ground planes reducing signal noise immunity. That being said, if your building a complex product with desired flexibility then you may not have much choice, but for simple consumer products I'd avoid the complexity.

So it depends. I don't want to say that its a remedy for everything. It works best if your developing a product. However, if your working in a consulting company and your client is Daimler who comes to you and say exactly what they want, exactly all the features they want, how long you have to make it and then hands you the money then I don't think its a useful strategy. Why, because they already know what they want, there is no iterative process, you probably will do a few spins of the board and that's it. The customer is already paying you thus there is no need to apply this methodology. Its more so for when your developing a full product from start to finish and are interacting with customers and looking for feedback along the way.

I think 3D printing is great for rapid prototyping in the early stages but not for mass production.

What you expect for product lifetime, and what is typical, may not be what you end up with. My company designed an SBC in 1993 that a customer designed into a product. Around 2010, we notified the customer that they needed to make a last-time purchase, because we were discontinuing the SBC. The processor hadn't been manufactured since at least 2004, and it and other parts used on the SBC were becoming unobtanium. They informed us that we had to keep making the SBC, because they had guaranteed to their customers that their product would have a 30-year lifetime. We managed to come to an agreement with them about how to move forward, but that blindsided us.

The length of lifecycle of a product would vary widely depending on the industry that your in. For automotive and automation industries it could be as much as 5 to 7 years. For customer markets its usually allot faster, like 1.5 to 2 years.

Good question. But the answer is very simple. Nobody really steals unproven ideas. Its a common fear that many people have starting out but its just not based in reality so much as it is based in Hollywood movies and TechCrunch blogs. We all have ideas, they all have potential but potential is nothing. People that you interview have lives and other things to think about, they generally don't drop everything just because they hear an idea they find interesting. And what is the worst that could happen? somebody thinks its a great idea and forks it. Well they still need to build it. They are essentially no further than you are. There is really no need to worry about this at the begging since it will just get in the way of you delivering great product.

Thank you, I'm really glad you enjoyed it.
The development cost of your product will vary based on features of the product and not really the industry your in (unless its something crazy, like space). The best way to estimate your product cost early is to make a rough design of the product like a POC or preliminary production design.

That being said...you don't need to spend days or weeks doing these. You can estimate costs on paper. list out the features, make a simple block diagram, identify major component(controllers ,coms , any sophisticated expensive components), which in turn will be driving the hardware cost.
The certificates needed will again depend on the components used and features of the product.

Thanks for the book recommendation, I'll check it out. I'd like to return the favor however. Take a look at Sprint, by Jake Knapp. Its geared towards software dev but offers very good insight that can be applied for any product and business.

Hi Erwin,
Very interesting question. I haven't actually considered the scenario of moving a (currently running project) in to this framework. I would think that its NOT IMpossible. It would come down to assessing at which stage of development your product is in and planning from there. That being said, its more of a shift in thinking. If your developing alone, its easy but when your working in a team, I can see how there might be issues. But...If you can get your team to NARROW down in focus, and decide which stage you can tackle next then it could work.

Hi Nico,
In order to minimize the risks of hardware component availability I would first of all look at the components lifecycle, just to make sure it will be available for some years to come.

Another tactic would be to find suitable replacement components on the market, with a feature set very closely resembling the one your current component has. Often times the package types are similar or close to similar, and you can add pads for the replacement parts in the PCB design, that is if space is not an issue. We did this same thing recently with an LTE module. We had concern it might be out of production in the near future. The same manufacturer was about to release a new slightly modified LTE module, with part dimensions and pad layout almost identical to the one we were currently using. Therefore we had a replacement in mind, and just by adding a few extra pads on the board we could future proof the product.