Solve Product Development Problems With a Simple Adjustment, Part 1

Executive Summary:

We all strive to balance speed of execution against management of risk and assurance of product quality.  Make a simple adjustment to your existing product development process to solve a number of challenges.  Change the focus from tasks to purpose and watch your process execution improve with regard to both speed and risk management.

The Rest of the Story:

Product development methods vary from businesses with no process, that rely completely on the experience and judgment of their teams, to businesses with strict discipline to follow a rigorous, standardized process.  Regardless of where we fall in that spectrum, we all try to find a better way to develop the next product than we did the last.

As we make mistakes, encounter problems, or learn new skills, we adjust our product development methods to include what we have learned.  Unfortunately, doing so inevitably leads to added detail and complexity in our process.  Eventually, we can’t both be fast and follow the process.

We run into other phenomena as well.  With pressure from the business leaders to develop quickly, and an expectation to check every box in a process checklist, we often find ourselves checking boxes just to say we did.  The reason for the box may become forgotten or ignored and the value-add of the effort is gone.

In my efforts to improve product development, I have discovered a way to make some simple adjustments to the way we follow an existing product development process that solves many of the challenges we face.  I have found a solution that includes a relatively easy adjustment, but enables an existing process to be executed quicker, and with greater risk management.

The adjustment requires recognition of one fundamental trait of your team.  I ask you to recognize that your business selected and hired the personnel on your product development team based on their skills, experience, and intelligence.  To make the adjustment and improve your execution, you must allow your process to leverage and rely upon your team’s skill, experience, and intelligence.

If the thought seems out of place in your business, or if you are not comfortable with the idea, then I offer the following question.  Do you prefer, intelligent, thinking, problem solvers, or obedient drones for your team?  I’ve never seen a team made up of both.

A good process is one that enables good people to perform their best.  A good process is not one that does people’s work for them – that’s what robots are for.

With that recognition, or at least now that I have you thinking about it, let’s take a look at the adjustment I propose.  It consists of four small changes to the way you follow your existing process.  It does not require that you completely rebuild or re-format your process.

1.  Ask “how do you know,” instead of “did you do?”

Already, you can imagine the different answer you will get as you review the design throughout by asking the former question at your reviews, rather than the latter.  When you ask, “did you do?” you really only get one answer, “yes.”  Congratulations, you just learned what you already knew (sarcasm noted).

Take that thought a step further.  Did the team do it well?  Did it help the product development to do the step?  Was there any value in doing it?  To answer these questions, you must ask them.  What if you don’t like the answers?

Now consider the question, “how do you know that you have selected the best concept to proceed to full development?”  The answer won’t be, “yes.”  It will be a bunch of “we did” statements followed by what was discovered, learned, and concluded.  Now you have learned something.

What’s more, if your team is in the habit of answering the question, then they proceed with the design effort focused on proving the best case for the product and for the business, instead of just blindly following tasks.  Now the team of intelligent, skilled, experienced people, is proactively thinking about solving the problem of developing and managing risk, of making the best decisions.

2.  Separate your deliverables from your risk management activities.

Some of the tasks on our checklists are things that simply must be done in order to complete the design and make it ready for production.  Examples are the completion of design drawings, definition of interface requirements, contracting suppliers, etc.  These are your deliverables.

Some of the tasks in our checklists or in our process are inevitably those that grew out of lessons learned and are designed to manage risk.  These include engineering analyses, reviews with suppliers, supplier quality evaluations, failure modes analyses, and testing can be included in this list unless a certification of some kind is necessary to sell the product.  These are not deliverables, the project could still get done without them, but they are good ideas.

If your business utilizes a stage-gate or phase-gate style process, then you might have a list of deliverables and a list of good ideas for each phase.  Such is fine and good.

Once you have your different lists, identify them as such.  Keep your deliverables as mandatory elements of your process.  Save your good ideas for risk management for step three.  If you have deliverables that are necessary for some projects, but not all, then identify them as such. 

For example, definition of electronic interface requirements or CE certification testing may not be necessary for purely mechanical products sold in the United States.  Allow your teams an out if it doesn’t make sense to do that step for their particular design.

Congratulations!  You have just simplified your product development process down to the critical few steps.  As a general rule, simpler is speedier.  Also, it helps both reviewing managers and development team members focus on the critical tasks to complete the project and it allows for a cognitive separation of necessary from good-but-not-critical activities.

There is more to the adjustment, two more steps to be specific, and I’ll save those for tomorrow’s post.  For now, stew on what I have proposed so far.

What we are leading to is simple wordsmithing of your existing process and a change in your planning and review habits that drives a huge change in execution behavior.  Instead of focusing on getting things done, which often leads to sub-par execution of those things, we will be focused on what needs to be done to get the best product developed in the most expeditious way.

For the moment, we’ve discussed how to re-focus on what the team is learning by asking, “how do you know” instead of what the team has done by asking “did you do?”  We have also reduced our process map to the critical few necessary elements needed to call the project done.

Tomorrow, we’ll talk about what to do with those good ideas that help us avoid problems, and how to make sure that the appropriate level of discipline is maintained while we enable the team to minimize the activities necessary to execute well.

Until tomorrow…

Stay wise, friends.