Opinions sans reputation or data can still be helpful when they identify the landscape and issues, e.g.,:
A main goal of design is to identify what's not feasible through logic. So much easier than prototyping. But still "can it be done?" is a far cry from "can we do it?".
The benefit of prototyping is to show that something is possible. There the key question is integration: can persons Pn make code C on system S that meets both goal X and constraint Y - i.e., a design as product development.
Leaving aside bad-faith behaviors, the real question is socialization: 1. how to gather collective wisdom in some relatively natural and encouraging manner to encourage collective deep consideration of hard problems to avoid waste and get things done. And 2. the same for motivation: getting everyone aligned, understanding their role and the quality/schedule risks.
Given the uncertainties and costs of product development, the prototype has significant advantage of seeming "real" relative to some "ideal" solution, and thus can bias teams to the concrete, particularly when issues are contended. Prototype-driven planning likely reflects lack of organizational cohesion (and ironically kicks that can further down the road).
So generally I see prototyping as validating designs, and try to make the design discussions lean enough to engage otherwise-prototyping engineers.
A main goal of design is to identify what's not feasible through logic. So much easier than prototyping. But still "can it be done?" is a far cry from "can we do it?".
The benefit of prototyping is to show that something is possible. There the key question is integration: can persons Pn make code C on system S that meets both goal X and constraint Y - i.e., a design as product development.
Leaving aside bad-faith behaviors, the real question is socialization: 1. how to gather collective wisdom in some relatively natural and encouraging manner to encourage collective deep consideration of hard problems to avoid waste and get things done. And 2. the same for motivation: getting everyone aligned, understanding their role and the quality/schedule risks.
Given the uncertainties and costs of product development, the prototype has significant advantage of seeming "real" relative to some "ideal" solution, and thus can bias teams to the concrete, particularly when issues are contended. Prototype-driven planning likely reflects lack of organizational cohesion (and ironically kicks that can further down the road).
So generally I see prototyping as validating designs, and try to make the design discussions lean enough to engage otherwise-prototyping engineers.