Article
Don’t Let Process Get in the Way of Purpose
Process is critical to successful product development. But focusing on following a rigid process rather than leveraging that process to create a great product is a huge mistake. Learn how to spot process pitfalls before they derail your project.
New product development always happens within a process. It can be formal or informal, complex or simple, but there is always some form of process that teams use to work together. Process, in whatever form it takes, is helpful when organizing projects and essential for a successful result. The danger, however, is that your intentions for the product can become subservient to the process. Overly rigid reliance on these steps can focus the team on “checking the boxes” and lose sight of the objective: a product that meets requirements, delights customers, and can be sold for a profit. Everything should work toward that goal, using process only as a tool to achieve it.
Process That is Too Rigid Stifles Innovation
Process can become so structured that it improperly constrains new product development. This frequently starts at the very beginning of a program, when milestone deadlines are built into a rigid project plan. Clearly, some dates need to be set in stone, like trade shows or funding dates for startups, but others should be driven by development activities.
Allowing milestones to be artificially driven by process instead of actual progress fails to take into account the fluid nature of product development. It also presumes that the people generating the schedule were somehow prescient as to what would occur in development. Inevitably, this will result in your team making decisions solely to meet timelines imposed by the process. This effectively stifles creativity, particularly if investigating new ideas leads to more work and missed deadlines. Innovative solutions that could result in better and more successful products will be missed – all because the process has taken priority over the final product. Unfortunately, this happens more often than anyone would like to admit.
The corollary to rigidity of dates is that scheduling initial milestones is often based on a best-case scenario. In reality, the first solution is rarely the one that goes to market, so every product development process should allow for iterations. When your team reaches a decision point, everyone should be prepared to loop back and update the design. In fact, at least one iteration loop should be built into the schedule at each major milestone to ensure this time is accounted for. In practice, however, iteration loops are often forgotten or actively discouraged as market pressures and the urgency to get the product released weigh on the team. Don’t be fooled – iterating the design is always the right choice, and is, in fact, moving the project forward even when the team loops back and repeats some steps.
Create Multiple Prototypes to Meet Specific Needs Rather Than Overburdening One
If your team is designing a physical product, the development program should include physical prototypes. Prototypes are critical tools for design evaluation and new technologies have made prototyping faster and easier. Nonetheless, there is still pressure to get more out of every prototype dollar.
Well, maybe we should just add some more detail into the CAD and make that ID model also work as a mechanical fit check. Well, we’re doing a mechanical fit check, why don’t we take these out for customer evaluations? We need to do initial functional testing; why don’t we just tool up because I would really like to run a full battery of tests on 100 units?
Yes, these scenarios really happen. It’s natural to want to squeeze as much bang for your buck out of a prototype as possible. Prototypes are often tied to critical schedule milestones and gate the team’s ability to move forward. While multipurposing these prototypes seems like a more efficient way to achieve multiple milestones, it comes with risks. Primarily, a problem with your prototypes can affect your ability to meet the remaining milestones. Think of your prototypes in terms of functional decomposition. The simplest prototype that can answer a question is the most efficient path to a solution.
Higher complexity, larger quantities, and better finish quality all come at a higher price, so you don’t want to have all your eggs in one prototype basket. If there are any flaws in the design (there will be, remember these are prototypes), more time and money will have to be spent to modify or even fabricate new prototypes. Instead, make a variety of prototypes for different purposes, each designed to answer a specific question. Making multiples will mitigate the risk of trying to solve too many problems at once with a single prototype.
Artificial Milestones Result in Bad Decisions
Another common mistake is to establish artificial milestones. Prototypes often become such milestones. If you establish “Mechanical Fit Check Prototypes” as your milestone, it can be tempting to check off that box once the prototypes are made. This is really a false milestone. It isn’t building the physical prototype that is truly the milestone in your development process, but rather what is learned from that prototype.
In your Mechanical Fit Check Prototype, you need to determine if the parts fit together and then fix any of the problems with the design. It is only after that iterative design loop that you can move forward, not after fabricating the prototypes. Make sure the milestone or gate in your process is after the learnings from the prototype are incorporated. The milestone you need to cross is that your mechanical fit check is complete and successful.
ID freeze is a different artificial milestone that is often used. While it is beneficial to establish a point where the ID is stable, it should never really be “frozen.” An ID freeze milestone will often short-circuit ID development efforts and can artificially restrict downstream development. As the design progresses, challenges will be encountered that may affect the usability or the exterior shape of the device. Clearly, the team shouldn’t try to shoehorn the changes into an ID that is no longer appropriate. On the other side, the ID team shouldn’t be excluded from adjusting their design because it was supposedly “frozen”. In fact, the word freeze should never enter the vocabulary of product development. The goal for ID is to reach a stable point where the changes required are relatively small and updates can be made as the design progresses.
Focus on the Product for Better Outcomes
Throughout product development it is imperative that your team stay focused on the real goal: creating a great product. The process should always be in service of that goal. The team should use their process to ensure that the product will be successful. Have the design challenges been solved? Will this product meet your stakeholders needs? Have you accounted for all the relevant stakeholders? Will it be possible to manufacture this product at the appropriate price point? Will this product be a success in the market? If not, iterate! Never focus on that stage gate review. Focus on why you are going to that review. What problems will you have solved at that point?
Process is Not the Enemy
Don’t throw the baby out with the bathwater. A product development process is an important tool to ensure success. It just needs to be used appropriately. Product managers are often judged on schedule and that incentive can also roll down to the development team. As a result, it takes work to avoid prioritizing process. Don’t be afraid to stay in one stage longer, even if it means missing artificial deadlines. It will be shorter and cheaper in the long run. Money and time spent early in the development process is always better spent than trying to correct problems after tooling. Step back when necessary and justify those iteration loops with learnings along the way. Process is a tool. The product is the key.
