Product Development Archives

Product Development Page 11

We’ve been talking about system archetypes and will focus on that topic again in this post. We’re going to look at the system archetype called “Shifting the Burden.” First, a little review. A system archetype is a system that recurs over and over in many different settings and industries.

Shifting the Burden centers around shifting the burden from solving a problem to solving a symptom. It starts with the awareness of a problem. The awareness comes from the observation of some symptom of that problem. At the point of observation you have a choice. You can either choose to put out the fire and resolve the symptom, or you can do a more protracted problem solving exercise and get to the root-cause and solve the problem. Under the time constraints of modern business we oftentimes choose the former and put out the fire. We measure success using the fact that the symptom goes away and we can get back to our urgent regular work.

Shifting the burden from solving a problem to solving a symptom results in an addiction cycle. We treat the symptom and, because we haven’t solved the problem, the problem recurs as a fire. As we rely more on solving symptoms instead of problems, more and more fires recur and we find ourselves in perpetual firefighting. As we are perpetually firefighting we have less time to spend on solving problems so we’re more inclined to solve symptoms. As we do this, our ability to actually root-cause problems and solve them at their root atrophies. It is a side affect of the addiction cycle.

For example, say you have a customer service group. Let’s say that over the course of the last three months the number of calls into the call center has increased by 25% and the customer service groups is suffering low morale because of it–long hours and hostile customers. The problem at this point really is unknown. No one has investigated it. It could be as simple as an unclear instruction manual for a new product that’s been released. But, in the interest in getting the call center morale problem resolved the company invests in capacity for the call center. With more people in the call center morale improves and the symptom goes away, but the underlying problem remains…probably to recur at some point in the near future.

The “Shifting the Burden” archetype has an antidote. The antidote is to recognize when you’re applying Band-Aids–to recognize when you’re just solving the symptom–and to follow up that with a deep root-cause problem solving exercise. Of course, to be able to do this, you need a competency and capability of solving root-cause problems. This could be PDCA or, as EAC promotes, the LAMDA learning cycle.

Contact us to learn more about how Systems Thinking and the application of our Product Development Operating System can help your organization become more efficient, productive, innovative, and competitive. Follow Bill at http://www.twitter.com/systhinking

We’re habitual beings. We tend to do things the way we’ve always done them. I want to write about specifications in that context today. A lot of the organizations we work with utilize a specification sheet or template in to which a fill-in-the-blanks exercise is executed to create a spec sheet and communicate design intent to engineering. The problem with boilerplate templated spec sheets is they don’t distinguish the value that differentiate one spec from another —e.g. which spec is important, less important, arbitrary, etc.

A way of dealing with that issue is to divide your specifications into three categories: Musts, Coulds, and Shoulds. The Musts are those requirements that without which you don’t have a product. Without them you don’t have a competitive position in the marketplace. The Shoulds are the things on which your competitive advantage is built; things you’re trying to accomplish in your value proposition. The Coulds are things that would enhance the value of your product, but may not be worth focusing on and investing efforts to achieve.

These three categories still could be communicated as point specifications, but we can increase the value and information being communicated by expressing them differently. One way would be expressing them as ranges. Instead of having a point spec you then have a range of values. Hitting any of the points within that range would provide value as perceived by the market place. Those ranges can be communicated to the engineer and used to guide whether they reached sufficiency in their design effort.

You can take these ranges and enhance them further and make them communicate better information by placing them beside a graph to show how the market value will change over the range. That way an engineer can see that they’ve achieved the target, but with a little more effort they can achieve more value. It’s meaningful information to them for their design.

The third way of communicating the Should to engineering would be as goals, as word/statement based ideas of what you’re trying to accomplish with a particular design. The communication of goals takes this point focus defined by specifications and opens it up broadly — bounded only by conceptual boundaries defined by the goals.

The communication of Shoulds as goals allows the focus to shift from achievement of various points to the generation of new knowledge and looking for alternative ways of solving a technical problem. It allows us to rethink the very nature of how we manage engineering and product development. It also frees us from the pain and misery of testing to spec – pass/fail testing – to testing for knowledge and learning. And this knowledge that we gain from testing a full range of technology allows us to capture and apply knowledge as innovation within product design.

Follow Bill at http://www.twitter.com/systhinking

If you’re familiar with the world of Lean, then you’ve probably heard the expression “it’s a journey.” This expression has become a little trivial or trite. It’s become a little hollowed out, sort of like the term empowerment or win-win. I have a colleague who hates the expression win-win. He hates it because it is always used as a mask when he finds himself in a win-lose situation. But Lean really is a journey and I want to articulate the elements of that journey for you today.

First, you need to define your starting point, like a journey. Then you define a destination or where you want to go. Finally you have a rate of progress towards your destination. So, if you’re traveling from New York to California, you have your starting point in NY and your destination in CA. You have your rate of progress that includes intermediate states. You might stop in PA and visit some friends. You might only have enough money to get to IN. If that’s the case then you’ll need to stop and make some money for a little while before you pack up and continue west as far as you can go. California represents the ideal state and you have some intermediary states along the way.

In the world of Lean you define the current state, you consider your ideal state, you understand your limits, you identify targeted improvement states — way stations along the way, you go there and reach a steady state, then you prepare the next move on your continuous journey when the time is right. And that’s how Lean is represented as a journey.

Follow Bill at http://www.twitter.com/systhinking

In the 9 years that I’ve been in some type of a sales or sales support role at EAC I’ve noticed some common themes across the companies that I’ve been exposed to. One of which that continues to intrigue me is a correlation — companies with open minds that are willing to meet with a sales person seem to be doing better than those that don’t.

You may call me out on this but I’ve had exposure to several hundred executive level individuals and those that seem to do well are willing to let a sales person give their pitch. Part of being a sales professional is dealing with rejection. It happens daily and is tough, but you learn from it and get better. My experience has been that companies who reject a 20-minute meeting are those that are struggling to meet goals, have stagnant growth, are over worked, and generally have bad employee morale.

One positive example is an individual that is a VP of a billion dollar company. From our very first call he showed a level of interest and respect for me. It was refreshing to have him demonstrate genuine interest in what I had to offer. It all started with a 20-minute meeting and now EAC is significantly impacting how they bring their products to market. In the 8 months that I’ve worked with him he’s been promoted twice.

Another example that comes to mind is a VP of a 50 million dollar company that will take a call from me even when he is in a meeting. He is excited to hear what I have to say and values my input. What a way to make a sales person feel appreciated and important, and that naturally makes me go out of my way to help him out when he’s in a bind. He is a true pleasure to work with and guess what; his company is growing like crazy!

Now for the counterpoint…there is a company I’ve tried to work with for years. They offer a specialized commodity that is very sensitive to any type of economic decline. During the great recession they let go over 80% of their employees. Surprisingly they are still in business, but are struggling to provide enough work to support their overhead. While a VP was willing to take an initial meeting with me, he is very close minded to any type of change and has no interest in finding new ways to get better. “I’m too busy to make any changes.” And guess what, he’s pretty grumpy.

I often think of the cartoon where a polished sales guy shows up to a meeting with a soldier. He’s carrying a machine gun in his bag but the soldier carrying a sword responds with “No, I don’t have time to see a crazy salesman — I’ve got a battle to fight!”

Our world is changing rapidly, especially as we continue with the economic recovery. Our customers are constantly facing stricter deadlines, increased competition, and more complex requirements that are always changing. “We have to hit the deadline or we risk losing the customer.” Too often I see companies throwing money and resources at fixing a problem because that’s the way they’ve always done it. And then they wonder why they struggle with growth, profitability, and product performance issues. Well I have some good news…there is a better way. And the next sales person to contact you may have a solution to the problem that is keeping you up at night. Give them a chance.

We perform Product Development System Assessments (PDSA) for our customers. I’m frequently surprised by how many product development organizations still use email as their primary medium for the communication of information. Attached to these emails are test reports, marketing information, requirements, etc. Documentation that is critical to the performance of their product development!

I recently read a British study stating 38% of a knowledge worker’s time is spent looking for information. I can’t really believe that. We’ve run into organizations where it is that high, but not as a standard or average. But event if you discount that and cut it in half, that is about 20% of the time that knowledge workers spend just hunting for information. And this time spent hunting, this loss of efficiency, is invisible because it just gets buried with everything else inside the charges to project time within specific projects.

The other issue we have with email is that it’s open loop. It has no feedback. If the timing of the sending of some information is wrong, then the recipient will have to search through their inbox for the information after the fact and often times will ask for it to be resent rather than hunt for it. Also, you have various revisions distributed across the organization sitting on various hard drives – some of them current and some of them out of date.

When Bowen & Spears, famous researchers, talked about the need for a direct link between internal suppliers and internal customers, I think they talked about that connection as more personal, more collaborative, and closed loop. For your information flow, if you’re still using an open loop system, find a collaborative tool — PLM for instance. Help your researchers and knowledge workers take the pain out of their information flow.

Follow Bill at http://www.twitter.com/systhinking

I love basketball. In fact, my three sons all play. Two of my son’s teams have/had completely different cultures. One son’s team looked to win the game, but spend the minimum amount of energy they need to win. The other son’s team goes all out the whole game, fully investing in the game, in an attempt to win.

Product development is an investment. Although it is often managed and viewed as a something that needs expense management. In product development we have the classic tradeoffs. Phillips Corporation has a very nice way of prioritizing these tradeoffs. They call it QTF$. Quality — It’s the first tradeoff, but it’s not really a tradeoff. You have a quality threshold your product needs to meet, and there’s no negotiation about that. The other three, TF$, stand for Time, Functionality, and Cost. Time is the second most important of the tradeoffs. If your product is delivered on time, it positively impacts your entire customer base. If you withhold some Functionality to get the product out on time, it will negatively impact some small section of your market that relies on that functionality. If Costs are overrun; if the cost of the project or the build cost of the project itself fail to hit the target and go over, that effects you internally and doesn’t affect your customer base. So Phillips, from the standpoint of serving the customer, ranked order of the tradeoffs as QTF$.

Time is king and yet we get hung up on costs. We bring our classic business short-term focus to the system, product development, that’s concerned about growing our future. If you’re familiar with the work of product development guru Don Reinertsen, then you’re probably familiar with his theory of the cost of delay. On-time is the greatest lever for optimizing the return of investment in product development. Expense management in projects should be about measuring costs, not about squeezing them.

We recognize the investment nature of product development in our portfolio management where we require predictive ROIs. But how many of your companies follow through and actually check your investment by measuring the S-curve for your return. Very few, at least in my experience, because we are bound by linear process thinking, which ends as the project ends, as opposed to closed-loop systems thinking, which goes back and checks the results of our actions.

So of my two boys…the one who played on the team with a culture to conserve energy, they had a player who now plays in the NBA. None-the-less they lost as many games as they won. The team that goes all-out, they don’t have any NBA caliber players on that team. In fact, the best player on that team will play in Division 2 college ball next year, and yet that team wins five times as many games as they lose and they’re currently ranked #7 in the state.

When you make an investment, fully commit to the investment. The investment in product development is most carefully managed, and gives it’s greatest return, when you focus not on costs and expense, but rather on time.

Follow Bill at http://www.twitter.com/systhinking