It’s pretty common to see application stories, where engineering software vendors try to demonstrate why their software is wonderful.

I find application stories interesting, but they don’t really tell me what I want to know: What is the right tool for the job? Or rather, what are the right tools for the job?

I started thinking this way maybe 28 years ago, when I’d see different types of manufactured goods, and ask myself if the CAD software I was using could handle that kind of design.

Even up to 10 years ago, the answer has too often been “no.” Fortunately, things have gotten better—but choosing the right tools for the job hasn’t gotten particularly easier. There are just so many options today.

In the sprit of understanding engineering software tools, I’d like to start a thought experiment: Looking at particular products, and considering what toolsets would be best for their design.

Not that I actually know what the best toolsets would be. I’m not that smart. But I do know a lot of smart people—on both the user and vendor sides of the markets—read this blog.  So, consider this a request for feedback. I’d like to hear from software vendors about their tools. And from people who have real-world design/engineering experience with a particular type of product and the relevant tools. I’ll gather what I learn, and write a follow-up article.

Inspired by an upcoming webinar, the first product type I’d like to look at is a golf club head.

Golf Lessons

This Wednesday (December 7, 11:00 AM CST ), Pointwise, Intelligent Light and the University of Tennessee at Chattanooga SimCenter are presenting a free webinar that illustrates the various steps of the complete computational fluid dynamics (CFD) process typically followed in aerodynamic analyses of realistic geometries.

They’ll be creating meshes with Pointwise, and with tools developed at the UTC SimCenter. Steady and unsteady CFD solutions will be computed on a distributed memory LINUX compute cluster with TENASI, a UTC SimCenter parallel-unstructured Reynolds averaged Navier-Stokes code. Post-processing will be performed using FieldView by Intelligent Light.

For this webinar, they’re using a pretty well-known type of geometry: a golf club head (a wood.)

I assume they chose a golf club head as an example because it’s interesting, and it lets them demonstrate what their tools can do—not because their software is the only (or even best) choice for analyzing golf club head designs. (I’m thinking it’s possibly massive overkill.  But there’s nothing wrong with that, is there?)

What tools does it take to design a golf club head (specifically, a wood?)

The USGA has a set of rules that govern the design of golf clubs (and their heads.) They cover all kinds of arcane details, including everything from the geometry of grooves to the volume of heads.

The goal of club designer is to work within those constraints, maximizing range and accuracy, providing as much forgiveness for swing variations and errors as possible, while making an aesthetically desirable product. (What, you don’t think golfers care about aesthetics?)

The fact that different number woods have differing face angles would suggest that that an ideal CAD program for golf club head design might have parametric capabilities. The USGA rules provide a set of constraints that also hint at using a parametric CAD program.

Still, not all CAD systems can effectively use the USGA constraints as parameters. For example, one of the rules is that a wood head’s volume must not exceed 460 cubic centimeters. For many CAD systems, it’s simply impossible to drive geometric dimensions using volume. It gets worse: The USGA limits the moment of inertia of a club head to 5900 g-cm2. See if you can plug that constraint into most CAD systems.

Woods are aerodynamic clubs, designed to be swung fast. While a wood’s face may be flat, not much else about it is. This implies that an ideal CAD system would have the ability to handle class-A surfaces. Certainly with G2, and possibly with G3 surface continuity.

With any product that’s aerodynamic in design, it’s a given that CFD should be in the design toolset. At least, if you want to compete with the market leaders. If you really wanted to complicate the analysis, you could optimize for under-water shots, for when players need to hit their balls out of  a water hazard. (Or you could add many-body dynamics analysis for when they need to hit out of a sand trap.)

It’s also a given that FEA should be in the bag of tricks, to optimize strength and stiffness within the USGA geometric constraints.

Modal, vibration, and acoustic analysis might make sense too (though these might imply analyzing a full club, not just a club head.) Modal response and vibration figure into performance, but sound figures into aesthetics. Guess which is more important? Karsten Solheim built a golf club empire based on the sound his putter made when hitting a ball: Ping.

Beyond CAD and CAE, there’s the issue of optimization. To do real justice to the problem of golf head design requires going beyond the “red is bad, green is good” school of static FEA thinking. It requires going to the Pareto frontier, to find the set of optimal design solutions. There are a number of interesting tools available to help you get there.

Chances are that, if you’re going to do a truly rigorous design of a golf club head, you might want to model a golf swing. For that, you’ll need a computer algebra system. And, since you’ll eventually want to do testing with physical prototype, you’ll probably want an instrumentation/data acquisition system, to capture and use test data.

And you thought golf clubs were simple.

Well, golf clubs look simple, at least. But they require real engineering, based on real science. That implies that they require serious engineering software tools. I don’t think you can get away with using SketchUp and AutoCAD LT. (As nice as they are for some things.)

The toolset for designing commercially competitive wood heads (which are not usually made out of wood anymore) includes CAD/CAID, meshing, FEA, CFD, post-processing, optimization, math, instrumentation, and probably a half-dozen things I’ve forgotten. I’m not counting manufacturing tools, because, at least for wood heads, most are produced by foundaries using investment casting.

While I could tell you, off the top of my head, what toolsets I think might work well for this design problem, I’m far more interested in hearing what toolsets you think would work best. If you have some thoughts, either leave a comment, or write me a note at evan@yares.com.

 

Autodesk, which has been running a teaser ad campaign promising that on 11//29/2011 “everything changes,” has announced their entry into the PLM game: 360 Nexus.

As part of their rollout, they’ve published a paper titled “Autodesk Extends Benefits of PLM to Everyone at Anytime, from Anywhere.” Volume 1. Catchy title – I’m curious if they’ve bought the domain name?

Of its 10 pages, the first 2 and the last 4 are marketing content. The middle 4 pages are a summary of some research from Gartner analyst Marc Halpern.

That’s the interesting part.

Halpern points out some things that big PLM vendors might not be thrilled about having said out loud. Here are some of his research findings:

“A growing number of Gartner clients are frustrated by the high cost of purchasing, deploying and upgrading PLM software. ”

“PLM software vendors do a better job providing technical support for their software than providing more general business- related advice and services. ”

“A Gartner survey suggests manufacturers pay substantially more when they contract PLM software vendors for business consulting beyond the technical details of implementations. ”

“Several of Gartner’s manufacturing clients have commented that software vendors often recommend the purchase of more PLM software as a routine part of service engagements. ”

“Transitions to PLM platforms such as Dassault Enovia v.6, Oracle Fusion, PTC’s Creo [I think that's a typo, and he meant Windchill], SAP’s ECC 6 and Siemens Teamcenter Unified are stimulating more needs for services that these software vendors want to profit from. ”

In short, the big PLM vendors are charging a ton for services, and customers are still disappointed.

Halpern’s recommendations based on these findings center around the idea that manufacturers should not use PLM vendors service organizations for anything but the technical details of deploying their software. He suggests manufacturers either do business process re-engineering in house (which Gartner, in the past, has said most companies lack the skills to do), or engage professional service organizations (which presumably won’t try to load them up with extra software.)

I’m guessing that Halpern isn’t getting any Christmas cards from SAP, Oracle, Siemens, Dassault, or PTC.

The Autodesk Approach

I’m guessing that Autodesk wouldn’t have paid Gartner for the right to use their research if it didn’t play into their PLM strategy with 360 Nexus.

I’ve not seen 360 Nexus. The best I can say is that I’ve read articles about it, including Al Dean’s article at Develop 3D, and Ken Wong’s article at Desktop Engineering.

My impression is that, with 360 Nexus, Autodesk probably has a really interesting SaaS cloud-based BPM system bolted to a PDM.

But, even if I give it the benefit of the doubt for its technical chops (and, remember, it’s not shipping yet), I can’t see it changing “everything” (as promised by Autodesk’s teaser ad campaign.)

Why?

First, because PLM is traditionally enterprise software. Trying to compete in the PLM space is like trying to compete in the ERP space. It’s not going to be easy — the big vendors are nearly impossible to displace (think: competitive lock-out.)

And, second, because Autodesk isn’t the only company that’s thinking out of the PLM box.   There are others.

Last week Dassault Systèmes announced their new CATIA Natural Sketch program.

Looking at the YouTube video they posted, the program looks exceptionally cool.

I sent an email to DS a few days ago, asking about the program, and got an answer back today from Derek Lane, the DS press-relations person.

I’d asked (among other things) if CATIA Natural Sketch will be sold as a stand-alone application, or only as a part of a larger V6 (or V5) installation.

The answer is that it’s not a standalone product, and is not available without a CATIA installation. Specifically, it’s available as part of the CATIA Industrial Design commercial product, CATIA Industrial Design PLM Express, the V6 PLM Discover Pack education product, as well as the CATIA Imagine & Shape add-on product.

This does make sense, since its value-add, according to Derek, is “its ability to generate sketches, and immediately make them part of [or the basis for] a CATIA model.”

This also demonstrates something that’s important to understand about Dassault Systèmes: that it is, first and foremost, an enterprise software company.

While DS does have divisions that serve other constituencies (such as SolidWorks and Spatial), the core of the company (including the CATIA, ENOVIA, SIMULIA and DELMIA organizations) is focused on delivering big enterprise applications to big enterprise customers.

If you become a DS enterprise customer, it’s not because of the specific features of any individual DS products. Rather, it’s because you’ve bought into the big DS PLM vision.

I’m not saying that individual DS enterprise applications aren’t impressive. In many cases, they are. But, they’re parts of a bigger system — a bigger vision — that, at its core, assumes you are going to use applications from DS and it’s authorized partners. Exclusively, when possible.

If you’re not a DS enterprise customer, and you’re not ready to buy-into the big DS PLM vision, then it doesn’t make sense to spend time evaluating the specific features of individual DS enterprise applications. As much as I hate saying it, that even includes ones as potentially cool as CATIA Natural Sketch.

Last week, on www.isicad.net, Dmitry Ushakov published an article titled Direct Modeling – Who and Why Needs It? A Review of Competitive Technologies. If you’re interested in CAD productivity, I recommend reading it.

The article includes one of the most cogent explanations of direct modeling I’ve seen. It also includes a thoughtful discussion of the drawbacks of history-based parameterization—the method used by mainstream CAD programs such as Pro/E (Creo Parametric), SolidWorks, and Inventor.

One of the small gems in the article is a reference to a 1995 article in HP’s corporate journal on SolidDesigner (which became CoCreate, and more recently Creo Direct.)

There’s a small footnote in the HP article mentioning “3D/Eye of Ithaca, New York and D-cubed of Cambridge, UK.”

That caught my interest. A quick Google search, and I found a note in a 1996 issue of Ralph Grabowski’s upFront.eZine, which quoted a reader as saying “3D-Eye wrote much of Solid Designer under contract to HP… They wrote the graphics, some of the UI, and a lot of ACIS husks to work around the limitations of the modeler.”

3D/Eye also wrote Trispectives, which was the predecessor to IronCAD. In 1997, the core development group at 3D/Eye was acquired by Autodesk.

It’s interesting to look back, and see where things came from.  Direct modeling is a big deal today — but its roots go back a long way.

Last month, Siemens PLM announced that it had entered into a partnership with Local Motors, a company that uses crowdsourcing for collaborative design and development of cars.

As a part of the agreement, Local Motors has adopted Solid Edge as the design tool for its recently launched Open Electric Vehicle project. Beyond this, Siemens didn’t really give too many details.

Today, they’ve announced the rest of the story. And it’s really interesting.

As a start, let’s talk about Local Motors. There are a whole bunch of “social product innovation” companies out there now. Local Motors is also a “social product engineering” company. Its 13,000 member community not only contributes to the conceptual design of Local Motors cars, they contribute to the detail design and engineering of those cars.

One of the challenges that Local Motors has faced is that not everyone who wants to participate has access to professional level CAD software. John “Jay” Rogers, the CEO of Local Motors, talked to all the biggest CAD vendors, asking them for a CAD product that he could offer to his community at a price they could afford. All but one of those companies blew him off (or, at least didn’t take him seriously.)

The company that did take him seriously was Siemens PLM.

Siemens has developed two new products, and is making them available through Local-Motors.

The first is a browser-based version of its JT viewer. JT is the most widely used lightweight 3D file format in the automotive industry. With this viewer, a community member can view, section, and measure 3D models from directly within the Local Motors website. For free.

The second is a special version of Solid Edge, called Design1. Solid Edge has traditionally been a feature-based parametric solid modeling CAD system. Several years ago, Siemens added direct modeling to Solid Edge, in the form of Synchronous Technology. The new Solid Edge Design1 product is a Synchronous Technology only version. It has no feature-based parametric modeling tools. Which is to say, no “history-based” modeling. (You can read a bit more about Design1 at the Siemens PLM blog.)

Given the likely context of use by Local Motors community members, a direct modeling CAD system is probably a better choice than a history-based CAD system. With a direct modeling system, users can edit CAD files no matter how they were created. Design1, incidentally, has the capability to read and write a wide range of formats, including Parasolid, JT, NX, ACIS, Pro/E, IGES, Inventor, SolidWorks, STEP, STL, and PLM XML.

Because Design1 is based on the same Synchronous Technology as the full version of Solid Edge, it has a capability that few (if any) other direct modeling CAD systems have: model reparameterization. In short, a user can add driving dimensions to a dumb CAD model, and when saved (in native Solid Edge format), those dimensions are persistent.

The only thing (other than history) that I can find that’s not in Design1 is support for class-A surfaces. That would be a useful thing for people who want to design car bodies, but given the end-user price that Local Motors negotiated for Design1, it’s not surprising that Siemens didn’t include it.

That price, incidentally, is $19.95 per month, with no long-term contract.

For the immediate future, Siemens is offering Design1 only through Local Motors. To get it, you’ll need to go to the Local Motors website, and join the community. For the next couple of months, the software is being offered only to a limited number of users. After the beginning of the year, it will be opened up to anyone who wants it.

The bigger picture.

While I think the Local Motors deal is interesting, what I find more interesting is the potential Design1 might have in Siemens’ (and its competitors’) major accounts, as a low-cost interstitial CAD tool for use by engineers and others who are not full-time CAD users, or who simply don’t need history-based CAD. I could imagine some companies (particularly large automotive companies) signing up for literally thousands of copies.  It could make things pretty interesting in the CAD business.

UPDATE:  Solid Edge Design1 native files are not compatible with commercial Edge licenses, and it includes no rendering, or adjustable component design.  Thanks to Josh Mings and Al Dean for pointing these out. (I don’t think these limitations are significant problems for most use cases of Design1.)

SECOND UPDATE:  I checked with Mark Burhop, from Siemens.  Here’s what he said: ”Design1 can use any Solid Edge files. However, Solid Edge cannot read Design1 [native] files without conversion. Having said that, Local Motors will convert all Design1 files to regular Solid Edge files when uploaded to their server. So, within the context of Local Motors it is fully open.”

The PDMA (Product Development Management Association) describes itself as “the premier advocate and comprehensive resource for the profession of product development and innovation.” The organization has been around quite a long time. Last week, I was fortunate enough to attend their 35th annual conference.

My goal in attending was to try and get a grasp of what the PDMA is about. To that end, I spent most of the first day in the New Product Development Professional (NPDP) certification preparation session. This session skimmed through a massive amount of information, derived from the PDMA’s “Body of Knowledge.”

What I discovered is that anyone who manages to get certified as a New Product Development Professional will have to demonstrate a comprehensive knowledge of the entire product development process—from the fuzzy front-end of ideation, through to product delivery. The only part of the process that doesn’t seem to be covered in detail is that bit in the middle that has to do with engineering.

Admittedly, in the session I attended, the presenters did mention a few terms such as “CAD” and “CAE” – but only in passing.

It took me a while to figure out, but the PDMA seems to focus on the parts of the product development process that are common to a large number of industries. Product engineering is not one of those common parts. While the organization does sponsor some events which discuss Product Lifecycle Management (such as one in Southern California, coming up on Tuesday, November 15), the subject isn’t core to the PDMA’s mission.

Here’s my take: If you are an experienced product designer/engineer, studying to get the PDMA’s NPDP certification will force you to learn the full gamut of product development, including strategy, teams and organizational structure, processes, tools and metrics, market research, and portfolio management. It will “connect the dots,” helping you to understand better why new product projects fail (or succeed.)

 

A curious thing that I’ve noticed about social product development initiatives is that they tend to leave out designers and engineers (except the ones on the payroll.)

I can understand this when design and engineering is at the heart of a company’s sustainable competitive advantage–but in many social product development projects, it isn’t the case.

I’m going to use Quirky as an example. I’ve watched a few development projects on Quirky, and felt largely unmotivated to contribute. Not because I don’t have anything to contribute, but rather because Quirky wasn’t soliciting contributions where my contributions would particularly stand out. Choosing product names or colors may be important, but my opinions on these sort of things are no more valuable than anyone else’s. Answering these sort of polling questions holds about as much interest for me as participating in the customer service poll advertised on Home Depot receipts.

Now, if Quirky (or any other social site) were to ask questions where I have some domain expertise, the story would be different. Ask me about trade-offs between stepper and servo motors, and not only would I have an educated opinion, but I’d also be willing to contribute it. I might even be willing to help with motor sizing and drive design. (Once upon a time, I used to design motion/logic systems for a living.)

Of course, Quirky attracts a lot of contributors. I suspect it’s not because those contributors feel compelled to share their domain expertise, but rather because Quirky has gamified the process of contributing. It seems rather akin to voting for your favorite performer on American Idol.

An example of a social help site that takes good advantage of domain expertise is Stackoverflow, which provides social answers to programming questions. Through a combination of techniques, including moderation, voting, reputation building, and pure coolness, Stackoverflow manages to attract heavy hitters to answer serious programming questions.

Stackoverflow has been so successful that its creators have expanded the concept to a variety of other sites, covering everything from mathematics to garden gnomes. Well, maybe not garden gnomes. But my point is, that, with the right combination of pixie dust, it’s possible to attract serious contributors who have deep expertise.

Two other sites that do seem to attract real expertise are Innocentive and GrabCAD. They do this by offering serious challenges, coupled with appropriate compensation.

In the case of Innocentive, the challenges are often “non-trivial.” Not quite as hard as “fix global warming,” but in the same general neighborhood. Challenges tend to be in areas that just happen to have corresponding Nobel (or other international) prizes. And the rewards offered seem to be inline with the value of the challenge—ranging up to $1 million dollars.

GrabCAD doesn’t offer such high rewards, but it does offer challenges that seem more up the alley of design engineers. One recent challenge was to design a triple-clamp for an electric racing superbike, with the winner to receive an iPad2. In a matter of weeks, site members had submitted over 150 designs—not just pretty pictures, but high-quality solid models. I can’t say that the design of a triple-clamp is a particularly challenging engineering problem, as these things go, but I looked at some of the photos of the submitted designs, and was impressed. This was pro-level work. The challenge sponsor got way more than their money’s worth.

Something I’ve noticed about CAD designers and engineers is that they consider some things fun, and some things not so fun. Solving design problems is fun–which is probably why GrabCAD can get so much participation from its community members. To engage designers and engineers in a social product development enterprise, you have to focus on fun things, and make the not so fun things as transparent as possible.

 

Is reducing variability in the product development process a good idea, or a bad idea?

It’s a trick question. Reducing the economic impact of variability is good. Reducing variability itself can drive innovation out of the development process. Hardly the result you’d want.

Don Reinertsen, a thought leader in the field of product development for over 30 years, says that 65 percent of product developers he surveys consider it desirable to eliminate as much variability as possible in product development. He also says this view is completely disconnected from any deep understanding of product development economics.

In his 2009 book, The Principles of Product Development Flow, Reinertsen provides a compelling economic analysis of product development, and makes the case that today’s dominant paradigm for managing product development is fundamentally wrong—to its very core. You can download and read the first chapter of the book here. I think you ought to do so right now. (It’ll only take a short while, and the rest of this article can wait until you’re done.)

Let’s look at a few of Reinertsen’s key points on variability:

First, without variability, we cannot innovate. Product development produces the recipes for products, not the products themselves. If a design does not change, there can be no value-added. But, when we change a design, we introduce uncertainty and variability in outcomes. We cannot eliminate all variability without eliminating all value-added.

Second, variability is only a proxy variable. We are actually interested in influencing the economic cost of this variability.

Third… we can actually design development processes such that increases in variability will improve, rather than worsen, our economic performance.

Reinertsen provides a number of possible solutions for dealing with variability in his book. An important one is flexibility:

In pursuit of efficiency, product developers use specialized resources loaded to high levels of utilization. Our current orthodoxy accepts inflexibility in return for efficiency. But what happens when this inflexibility encounters variability? We get delays…

Flow-based Product Development suggests that our development processes can be both efficient and responsive in the presence of variability. To do this, we must make resources, people, and processes flexible.

Resources—data and tools—are an important area of interest for me. So, the question occurs to me: how can resources be made flexible?

That’s not really a question I can answer in a short article. Maybe over the next couple of years on this blog, I could start to do some justice to the question. But, as a beginning, let me suggest these concepts:

  • Data must be consumable. What matters most is that you’re able to use your data, with the tools of your choice, to get your work done. The key thing to look for is the capability of your core tools to save data accurately, at the proper level of abstraction, in formats that can be consumed by many other tools.
  • Monoculture may sometimes boost efficiency, but it often kills flexibility. Figure on using engineering software tools from more than one vendor.
  • One size does not fit all. Different people and processes need different tools. You may need more than one CAD, CAM, or CAE program.

I’d be very interested in hearing your thoughts on efficiency vs. flexibility in engineering software.

Are you curious what the next-generation platform for social product development might look like? How about who it might come from?

Michael Fauscette is the lead analyst in IDC’s Software Business Solutions Group, and writes often about software ecosystems and emerging software business models. His thinking is that the next generation enterprise plaftorm has to be built on a foundation of people-centric collaboration:

New “social” collaboration tools must connect people inside and outside the enterprise but do it in a way that provides real time communications and real time access to supporting content, data and systems in the context of the activity. More over this tool (or tools) must support ad hoc work groups that need to reach beyond traditional enterprise boundaries and at times include customers, partners and suppliers, which protecting enterprise intellectual property and providing flexible security. Contextual collaboration also implies that the tool resides inside employees workflow and thus inside current enterprise applications. Embedded, contextual, real time, ad hoc, people-centric collaboration.

To date, I’ve not seen any PLM or engineering software vendors provide a toolset that meets these criteria. But that’s not to say I haven’t seen flashes of bits and pieces of it:

  • PTC’s Windchill SocialLink, built on Microsoft SharePoint, provides a more product development-centric social graph than other enterprise microblogging platforms (e.g., SocialCast, SocialText, Novell Vibe, Salesforce Chatter.) You’d expect that, since it is, after all, integrated with WindChill. PTC also put their money where their mouth is with SocialLink, and used it as the social backbone for the development of their Creo products. Yet, it’s still a young product. A new version will be coming out soon, so it’ll likely grow quite a bit in capabilities.
  • Dassault Systemes has a number of tools that fit in the realm of social product development. In the V6 porfolio of products, 3DLive is a 3D search/viewing and collaboration tool that’s integrated with Microsoft Communication Server. It serves as a foundation for a number of other “Live” products, including Live Collaborative Review, Live Fastener Review, Live Process Review, and Live Simulation Review.
  • Siemens PLM’s Active Workspace isn’t out just yet, but, based on previews, looks to be a seriously interesting tool.
  • SpaceClaim, though not explicitly focusing on social product development, has found that their software is getting regularly used by customers (in conjunction with gotomeeting and similar streaming tools) for digital mockup and design review.

I could probably go on for a long time talking about interesting tools that support social product development in one way or another. But what I can’t do is talk about tools that meet Fauscette’s criteria of providing embedded, contextual, real time, ad hoc, people-centric collaboration. Such tools don’t seem to exist yet.

One problem I see with existing PLM tools, in the context of social product development, is that they distinguish too sharply between first-class users, and those who are stuck in economy-class. While they provide an optimal set of capabilities for people inside the enterprise boundaries, they provide a far more limited set of capabilities for people outside the enterprise boundaries. They don’t do a very good job of connecting the voice of the customer with the voice of the process.

I do wonder whether the “next-generation enterprise platforms” for social product development are going to come from the traditional PLM vendors, or from new players—companies which have been built, from the ground up, as socially integrated enterprises.

“I am a lead pencil—the ordinary wooden pencil familiar to all boys and girls and adults who can read and write…

“I, Pencil, simple though I appear to be, merit your wonder and awe, a claim I shall attempt to prove. In fact, if you can understand me—no, that’s too much to ask of anyone—if you can become aware of the miraculousness which I symbolize, you can help save the freedom mankind is so unhappily losing. I have a profound lesson to teach. And I can teach this lesson better than can an automobile or an airplane or a mechanical dishwasher because—well, because I am seemingly so simple.

“Simple? Yet, not a single person on the face of this earth knows how to make me.”

Leonard E. Read wrote this essay, entitled I, Pencil, in 1958, a month after I was born. In it, he described the complexity of something so seemingly simple, yet requiring the knowledge and effort of thousands of minds to create.  It is an essay you must read.

Product development is not the realm of the lone genius. It is an inherently social and collaborative process. Commenting on Read’s essay, Milton Friedman said:

None of the thousands of persons involved in producing the pencil performed his task because he wanted a pencil. Some among them never saw a pencil and would not know what it is for. Each saw his work as a way to get the goods and services he wanted—goods and services we produced in order to get the pencil we wanted…

It is even more astounding that the pencil was ever produced. No one sitting in a central office gave orders to these thousands of people… These people live in many lands, speak different languages, practice different religions, may even hate one another—yet none of these differences prevented them from cooperating to produce a pencil.

Friedman was an economist, and the lessons he drew from I, Pencil were within this realm. I’m an engineer, so the lessons I draw from Read’s essay are different. Though I first read I, Pencil years ago, the question it raised in my mind has never really changed:

How can we give people better tools to help them work together, and create better products?

No, my question is not “how can we give enterprises better tools.” It is “how can we give people better tools.” Product development may be practiced within enterprises, but it is a people-centric process.