Skip navigation
2012

I have been hanging out a lot with a friend (let's call her Michelle)  who is in the middle of prototyping - - let's just say I am frequently  reminded how difficult it is to actually turn an idea into a physical  product. . . That particular skill isn't really in my wheelhouse, so I am always  impressed at the gargantuan effort it takes to create a prototype.

 

Like most products now-a-days, Michelle's product is  electromechanical and super complicated in nature, so sourcing the  parts, getting the right team and equipment in-house, etc etc took a lot  of time and money.

 

One thing she said helped her get through the pre-prototyping process  was 3D rendering - - especially at the point when she was trying to  establish some partnerships and get her ideas across. By creating visual  images of the idea before it was a reality, she was able to get people  to buy in, and she felt like it was easier to explain her idea to  investors, etc.

 

Rendering software used to be really technical and complicated, but  there are actually a lot of options out there for people who aren't good  at coding to try. Rendering allows you to tweak a model at virtually no  cost, and share visual concepts with team members or potential  investors much earlier in the process, so it can be a much easier way to  prototype your prototype.

 

Three Reasons to use 3D Rendering in the Prototyping Process

#1. Rendering lets you evaluate the product before investing in parts or suppliers.

#2. Rendering is an easy way to test out the market.

#3. Rendering gives you more time to design better products.


Has anyone out there used this tactic during prototyping? (And if you want to learn more, we published this article last week that shares more details.)

There's a lot of give and take when it comes to  setting up a change process, and a lot of factors that determine if your  process should be highly formalized, or loosely managed.

 

A loose change process, where individual engineers have the  discretion to either expedite change requests or make immediate  revisions, exposes your product to unintended consequences - - including  costly scrap and rework at best and field failures at worst. But  excessive review slows down the iterative process and burdens team  members, making it harder to innovate and rapidly improve product  quality.

 

When thinking about your own change process, here are some things to consider:

 

If you're early in the product lifecycle and had a small engineering  team, the details of the design will be very familiar to everyone and a  looser change process might work for you.

 

If your manufacturing process is vertically integrated (meaning you  can generally go downstairs and see the result of a change immediately) a  loose process might work for you.

 

However, if you are a large company producing higher-volume products,  it’s important to follow a formal change process in order to minimize  the chance of decisions with unforeseen implications.

 

Or if you have several engineering teams in different disciplines,  and there are a lot of opportunities for one change to impact another  aspect of the product, you might want a more formalized change process.

 

Arena CTO Eric Larkin shared his experiences running 2 companies - -  one with a formal change process, one with an informal change process. He talks pros/cons here.

 

One thing that he said stood out in particular to me - -

 

"I also recommend that companies experiment with a less formal review  of changes in the design phase and switch to a tighter approval process  in production—when mistakes can have major repercussions. And no matter  how changes are handled, product data needs to be centralized."

 

Does anyone else have experience, thoughts on this subject?