In traditional waterfall development, requirements are captured, cascaded, and developed at the start of the project until a determined “design freeze” date, at which time any new requirements identified are considered out of scope and may require additional time/cost to develop. Only after the design is frozen can a prototype be built, which creates a […]
In traditional waterfall development, requirements are captured, cascaded, and developed at the start of the project until a determined “design freeze” date, at which time any new requirements identified are considered out of scope and may require additional time/cost to develop.
Only after the design is frozen can a prototype be built, which creates a scenario where the success of the final product is driven almost entirely by the quality and thoroughness of the requirements.
This can only be successful for highly predictable developments, such as a design modification or update to an existing product, where significant baseline testing and customer feedback already exists.
However, for development of a new product there is considerable risk with the rigidity of this approach. If the frozen requirements do not fully and accurately reflect the customer and end user expectations, then the final product will miss the mark even if it meets the design requirements.
This potential gap between end user expectation and the design requirements can be reduced by introducing a prototype early in the process, which allows early experience with the product to shape design decisions instead of relying solely on analysis and assumptions.
Recently, we demonstrated the value of early prototyping firsthand when we built an autonomous cart for a factory. One of the design features was a “saddle” (or dip) in the center of the frame, which created a lower profile to allow for easier access to the maintenance area of the cart.
We reviewed the saddle feature with our customer and mutually agreed that it would be a great benefit to the end user for easier access.
However, when we deployed the prototype in its application environment, the test users determined that the saddle did not provide any significant benefit for easier access.
Based on this feedback, we updated the requirements and removed the saddle from the design, which reaped the following benefits:
If we had followed the traditional waterfall approach, then the design would have been frozen with the saddle included. By not freezing the design prior to building an early prototype, we were able to remove an unnecessary feature and develop a more robust product that better meets our customer’s needs.
At Treetown Tech, we employ rapid prototyping early and often as part of the design process to take advantage of the learning that can only come from having products in hand for people to use.
Contact us today to learn more about Treetown Tech’s “build fast, learn fast” approach to low-risk, fast product development!
You have the vision. We have the team and expertise to get it built. Let's collaborate to innovate, problem-solve, and de-risk every step of the way.
