In this two part blog series we will explore product development and some of the valuable lessons that could benefit your future design by studying goal definitions and managing hierarchical systems trade-offs. Development of products that involve firmware, electrical and mechanical engineering can get complicated. There can often be seemingly conflicting priorities related to hierarchical product requirements, cost, or development timeframes. This complexity is nothing new. In this blog, we will break down how to manage the tradeoffs between these systems, but first, we will review this process through the lens of the development process of the DEC-PDP-1 personal computer (circa 1960) as a history lesson in optimal product development.
THE FIRST PERSONAL COMPUTER
In 1960, Digital Equipment Corporation (DEC) released the PDP-1 personal computer. This machine was quite small compared with the “mainframes” of the day, behemoths that occupied entire rooms and were serviced by a “priesthood” of operators who fed in punched cards, mounted magnetic tape reels, and tore off reams of paper that came from the printers.
The PDP-1 by contrast was meant to be a “personal computer,” operated by technical folks directly interacting with its front panel and other peripherals. Many consider this machine the first personal computer, as it needed no special room, no special air conditioning, no special power wiring, and no specially trained operators.
In order for the designers to achieve this, constrained as they were by cost, size, power, time-to-market, and the requirements of the mechanical, electrical, and the software components, they had to be strictly disciplined to adhere to their design goals and also have an understanding of trade-offs between and among these competing needs. In studying this quintessential first computer, we can learn how breakthrough products are developed.
Many of the same basic truths will apply to your product.
Pictured Left to Right: The PDP-1 Computer bays, with console display, paper tape reader and punch; and the Type 30 graphics display alongside the console typewriter. (Source: Digital Equipment Corporation)
For additional images and content, download the full whitepaper here
WHAT?…BY WHEN?…FOR HOW MUCH?
When we examine the PDP-1, or any historically successful product, there are some common lessons we learn:
Every switch, every light, every panel of metal, every color, everything(!) was decided by people with the goals in mind.
The overall goal of the PDP-1 was this:
To produce a personal computer that could be used in scientific, laboratory, and communications sectors, which will take less than 1 year to develop and will sell for $120,000 or less.
In this exact sense, the PDP-1 was the “best that could be done” given the year (1959), the goal statement, and whatever sub-goals may have existed. The machine would go on to become a commercial success, selling 53 units over its lifespan.
From today’s point of view, we can ask: Why didn’t they have more memory available? Why wasn’t the machine faster? Why were the programming tools rather primitive? Why wasn’t it cheaper? To so many other questions like these, the answer is the same: Because it couldn’t be, given the goal.
That means that the goal was well specified, and the resultant product met the goal. This is the most important “ingredient” to a successful product: Knowing what it will be, within the constraints. A clear statement of the goal is the first piece of information that you will need on your path to product development success.
It is difficult to over-emphasize the need to clearly, and ideally succinctly, describe your product goal. And there are more questions that must be answered:
- What do you want? (goal)
- By when must it be done? (schedule)
- How much will it cost? (finance)
Once we understand the primary objective, the secondary objectives become functions of well-established product development conventions. That is, we can choose to focus on one (or possibly two) of the “what,” the “by when,” and the “how much.
”WHAT?
Clearly, the “what” is often a crucial consideration. You’ll need to answer the question, “How will I measure that my product has succeeded? ”Will you have sales of 10,000 units per month? Will your robot do a particular dull, dirty, and dangerous job well enough to pay for itself in 12 months? Have you limited your product’s complexity so that it can be completed quickly enough to have market impact? Do you only need to build 3 to show to potential investors? The more that we both understand about the “what” and how success will be measured, the more we can all bring to bear in realizing the success goal.
BY WHEN?
At times, the “by when” for the product is paramount. If you are launching a robot to Mars, you have a hard deadline to get a feature functional, or it’s not going to make it on that planned launch. And that may or may not be a mission scrub.If schedule is the #1 constraint, the other two components (“what” and “how much”) suffer. Yes, to some extent, more cash can get pieces of a project to accelerate, but infinite money cannot produce a successful 1-day product development. There are natural limits to how fast a product can be delivered.
FOR HOW MUCH?
So if “by when” is the main concern, “how much” can help, but the most common way to achieve the schedule goal is by reducing the project’s scope, the “what.” In the toy industry, reducing a toy’s scope is done all the time, as not-able-to-be-implemented-in-time features get sacrificed to next year’s product cycle.
What if you have a product idea, and only have a fixed budget to develop it? This, too, is possible when we are willing to modify the “by when” or “what” parts. To be sure there is a viable product, some schedule relaxation is often helpful. This allows different ways to accomplish the goal to emerge, to use lower-cost materials with longer lead times, use of common parts, semi-custom parts, and more strategies. But the “what” again becomes ultra-important. If the “what” can be fully specified such that there are no changes during development, then yes, fixed price will work. Fixed goal. Fixed price. Flexible time (“by when”).
DELIVERING ON THE “WHAT”
In the case of the PDP-1, the engineers had a stated goal: to produce a personal computer that could be used in scientific, laboratory, and communications sectors, and will sell for $120,000 or less. They also had a schedule: less than 1 year to develop. In theory, they could not control the development costs that might have been necessary to achieve their “what” and “by when.” Fortunately for DEC, they had a genius engineer named Ben Gurley heading the project. Ben and DEC management thought about how to reduce schedule. They decided to use a secret weapon, which was to make a computer from parts that DEC (and MIT) had mostly already designed.
The entire set of details of how to create the computer were up to Ben, and he understood that merely reusing old parts was not going to create a brand-new product category –something that is truly visionary. Recognizing that IBM’s mainframes required specially trained personnel to operate, Ben instead wanted to make programming directly accessible to the scientific community. The best way to do this was to create a new computing paradigm, using novel peripherals. What should these peripherals look like? In these high-uncertainty situations, although at first it may seem to take longer and cost more overall, a smaller, intermediate product should probably be produced. Sometimes, this would be an actual stripped-down product; other times, there would be enough developed to answer important “what” questions.
The PDP-1 project did just that.
Pictured: Mock-up of proposed PDP-1 product. (Source: Digital Equipment Corporation, 1959)
1The only piece of this PDP-1 mock-up that actually shipped with the real product was the chair. Yes, there was a console typewriter, display, light pen, cabinets, and more, but the real product was much more refined.
Join us as we continue to explore the past lessons learned in the quest for optimal product development in the second part of this blog series by Expert Systems Engineer Mike Cheponis.
Software: Design Complete
Hardware: Pre-production units for design verification
MFG. Readiness: CM schedule and budget, Unit build tracking