As Andy Hertzfeld describes on folklore.org, early Apple employee Chris Espinoza drew a calculator for the Macintosh. He showed it to Steve Jobs.
Jobs’s response? “Well,” he said, “it’s a start, but basically it stinks. The background color is too dark, some lines are the wrong thickness, and the buttons are too big.”
Espinoza went back from the drawing board, giving Jobs a new version each of the next few days and incorporating his suggestions. But Jobs kept finding problems. So Espinoza took a new approach, creating “the Steve Jobs Roll Your Own Calculator Construction Set” to let Jobs change line thicknesses, button sizes, background patterns, etc. himself
Within minutes, Jobs had settled on a design he liked, one that remained the standard Macintosh calculator design for 17 years.
Why did that approach work? For one thing, it allowed Jobs to make changes in real-time. That’s an approach Jobs clearly preferred; he wanted to touch, feel, and use potential products. That’s why iPhone screens are glass rather than plastic; one day of carrying a prototype in his pocket, and seeing the resulting scratches, was enough for Jobs to insist iPhone screens be made of gorilla glass.)
For another, it ensured Jobs was invested in the choices we made. We all tend to prefer our ideas, our creations… things we see as “ours.”
The same approach has worked for me. When I worked in manufacturing, one of our sayings was, “Engineers ask you what you need, then give you what they think you need.”
It happened all the time. We would ask for a specific equipment modification, and what we got back was something very different. What they gave us was usually “better” from a theoretical engineering perspective, but what really mattered was whether the modifications helped us increase throughput.
And they rarely did, until we changed our approach. We came up with an idea that would let us adjust multiple conveyor guides together instead of individually. We asked the engineer to draw it up, we took his specs and used brackets, clamps, etc. to mock it up on the machine where the finished product would eventually be installed.
And then we asked him to evaluate it: not on the drawing board, not in his office, but in the real world.
He played with it, and played with it, and couldn’t make it work. It was slower. Less accurate. Less stable. Less everything we needed it to be.
But instead of walking away in a huff, he grabbed a piece of paper and sketchd a quick diagram.
“Think this will work better?” he asked. “It looks great,” we said, since his diagram looked a lot like what we had originally asked for.
From then on, that’s what we did. We came up with ideas, the engineer drew them up, and we would create rough prototypes so he, and we, could try them out. Sometimes the result was him giving us what we asked for. Sometimes — a lot of times — he found an even better way.
The “fault” in the original approach wasn’t all his. We knew what we wanted but sometimes struggled to describe it. Creating a semi-working prototype helped us not only determine what we really needed, but just as importantly, to be able to describe it.
Try it. The next time you have an idea, let the people who will actually use it give it a try: not in a conference room, not as a discussion, but in as real-world a setting as you can create. If you have a new idea for a sales approach, let people test it first. If you have a new idea for a cost-cutting measure, let people test it in a limited fashion
Not only will you see whether it works, you’ll also give them the opportunity to suggest ways to make your idea work even better.
Because the people who actually do a job are the best people to decide how that job can be done well.
The opinions expressed here by Inc.com columnists are their own, not those of Inc.com.
The early-rate deadline for the 2026 Inc. Regionals Awards is Friday, November 14, at 11:59 p.m. PT. Apply now.
Jeff Haden
Source link