Steve Neiderhauser

Heavenly prototypes land new customers

Tom Peters shares 60 things he believes.

I want to focus on one -- one powerful idea.

He who makes the quickest, coolest prototypes reigns!
(Think: Demos. Stories. Heroes.)

Message: Plans do not make the world go ‘round. What does? Demos! Heroes! Stories! Tests!
Palpable examples! Experiments! Prototypes!

Prototypes help people experience the benefits of your idea and instigate innovation. Still, some managers lose their compass and wander into a thicket of procedures.

File this one under “What were they thinking?” About three years ago I was in a meeting where it was agreed -- we would build a prototype.

Then, after two seconds, an executive chimed in, “Who will write the requirements document.” “Oh yes,” another agreed, “we'll need a complete list of requirements.”

I glanced at one fellow known for his common sense, we rolled our eyes and looked skyward. We had a zealot on the top floor of the Requirements and Loan Building, threatening to jump.

For the next ten minutes we calmly tried to talk this well-intentioned procedure partisan back to earth. We wondered, where's his wife? Surely, she'd be able to talk some sense into him, “Remember our mortgage, our kid's college fund, and our family vacation next month to Disney Land.”

If he did jump, the prototype, the project, and the customer would crash along with him -- and his folly. In the end, we somehow convinced him that documenting a prototype that changed by the hour was a fool's game.

Serious Play, a book by Michael Schrage, describes the benefits of models and prototypes. He writes of a Silicon Valley company where the engineers' experiences inspired a prototype mantra -- “Never show fools unfinished work.”

Past experiences with senior executives showed that they would brush aside unpolished prototypes. The higher up someone is, the lower chance he has of making the connection between product ideas and customer benefits.

You'd think that creating a prototype would be easy enough -- and it is -- and yet I've been amazed by the actions some people take to guarantee failure. For their desire to hold fast to procedures exceeds their desire to succeed.

Here's three key principles that will keep your prototypes on track:

Min specs - If you don't have a solid understanding of how an idea benefits your customers, talk with customers and draft a short list of features (no more than seven).

At the speed of light, build the prototype, show it to your customers, ask for feedback. REPEAT!

Source tools and resources - Provide your team with the tools, frameworks, and platforms to build out-of-this-world prototypes. Tools should hide technical details and highlight product benefits. Where the tools meet the designers' abilities you'll be flying.

Periodic prototype - Once a week -- or some other period of time -- have the design team demonstrate the prototype. The result? Design decisions are made earlier in the process and problems are center stage.

And the masterstroke of demonstration?

Position a polished prototype so that executives discover the idea, support the idea, and visualize the connection between idea and benefits.

Little Company. Big Company. Go, New Products. Go!

Spark new product development by forming business partnerships between large and small companies. That's the message John Volpe, a founder of Incucomm, delivered last week during a product development presentation.

A large company, for example, could benefit from the R&D efforts of a smaller, faster company. While a small company could profit from the larger's markets and credit rating.

With some partners, however, you might find yourself balanced precariously on a knife edge of product development.

John shared a story from his days at Texas Instruments (TI) to illustrate the opportunities and risks associated with small-large pairings.

TI had formed a partnership with a small company (Small Company) located in California. TI coveted Small Company's R&D -- it would save TI $900K for this project. Small Company had the ability to deliver the project; however, they didn’t build the components to spec -- military specs were needed. Small Company asks for an additional $40K to finish the project. John considers suing Small Company, an action that would force it out of business. Instead, he flies to California and negotiates an agreement.

After his story, John listed some of the differences between large and small companies:

Time

Calendars vs watches

Consensus - who votes

Structure vs chaos

Assets

Little guy - his company

Big guy - just a job

Cash Flow

Little guy - slow payments can kill him.

Big guy - doesn’t understand the impact of slow payments to a small company. He blames the process.

Intellectual Property

A big company’s IP process can be unreasonable.

To me, these differences showcase the benefits of a powerful design concept -- parallel structures. If your organization's structure doesn't match your partner's, it becomes more important to monitor the project and make sure it's on track.

Then again, you could always talk about new partners with your Golden Retriever.

Should you share your business ideas?

Seth Godin's latest project ChangeThis presents several manifestos.

Guy Kawasaki talks about how to start a new business. Do you share your business ideas with your dog and no one else? That could be a problem on a couple fronts, according to Guy.

The only thing worse than a paranoid entrepreneur is a paranoid entrepreneur who talks to his dog. There is much more to gain -- feedback, connections, opened doors -- by freely discussing your idea than there is to lose. If simply discussing your idea makes it indefensible, you don't have much of an idea in the first place.

We've all heard of people so afraid of losing their business idea that they produce a 40-page nondisclosure agreement -- and then ask you to read it.

Dallas Morning News columnist Cheryl Hall writes of a business woman who takes a different approach. Karen Shelton freely shares her wisdom -- even with competitors.

You see, she believes her passion and energy creates the business advantage.

Unlock the door to high-performance teams

Once upon a time, a victorious army placed the captured warriors from a local village in a POW camp. Knowing that their countrymen were suffering in prison, several of the villagers stepped forward to help.

One villager heard that the prison water was bad and men were getting sick. He went to the people who ran the prison and asked if he could purify the water so the men would stay healthy. The guards approved his request.

Another villager discovered that the food was inadequate and asked if he could supply fresh food for the prisoners.
The guards allowed him to bring fresh food to the prisoners.

The next villager who visited the prison found that the men were sleeping on rocks and were cold at night. He believed that the men needed blankets so that they wouldn't shiver while sleeping. The guards granted that right and he brought the men blankets.

But the final villager to visit the prison was thinking at a higher level--he had another idea. He went to the prison at night, found the keys and released all the prisoners.

Many IT departments and their customers are prisoners, suffering in comfort. Yet, over the years, I've discovered keys that unlock the door to a higher level of productivity. I will talk about those keys in a minute, first let's explore the thinking patterns that have turned many companies into prisoners of mediocrity.

In the typical IT department, the CIO frames the problem incorrectly. He allows layers of procedures, systems, and managers to be foisted on his development team. And the development team often believes and acts as though they are software engineers. It's this thinking that disconnects developers from customers.

Remember, there's a world of difference between a .NET developer at Sears and a software engineer at Microsoft. The software engineer creates a product that produces revenue for Microsoft. On the other hand, the application developer takes the technology created by Microsoft and transforms it into a business model that supports business goals.

Under these conditions, the combined attitudes of the CIO and the development team constrain their company.

Hell, General Patton would have been proud. Congratulations, you've just executed a perfect pincer movement, on your company. Wait, there's more. If you're being fired upon, the ammunition has to come from somewhere. Enter the gang that couldn't shoot straight.

They've ushered in the era of shortsighted hiring practices -- a guarantee that your company will continue to receive a steady stream of narrow-focus professionals... because that's the way the game has been setup. And once we learn why we're rewarded... we respond, even though we all know the game is a joke. Unfortunately, HR isn't in on the joke.

With an unwitting plan of attach, is it any wonder that most IT departments perform far below their ability?

50% of software projects fail; these projects are over budget, or late, or don't work... period. Some management gurus claim we need more procedures, different methodologies, or layers of management -- the down comforter that will keep us warm and toasty even though we're locked in a dangerous thinking pattern.

This pattern could be called the “Hapless way of building” -- every nine months or so we change our design approach to the latest flavor, because the last one left a bitter taste. Have you ever wondered why so many people love methods? Let's turn to the elegant writing of Christopher Alexander in The Timeless Way of Building for the answer:

We are afraid, perhaps, that without images and methods, chaos will break loose...

That is why it is so easy for others to play on our fears. They can persuade us that we must have more method, and more system, because we are afraid of our own chaos. Without method and more method, we are afraid the chaos which is in us will reveal itself. And yet these methods only make things worse.

You see, administrators fear the unknown; they -- and their fears -- slow new products to a trickle. Truth is, the procedure police have failed to deliver the bacon, they will never deliver the solution.

There are keys, however, that unlock the prison doors. Let's talk about our first key -- product platforms. Product platforms corral chaos and surrender harmless a bookshelf of procedures. You can think of software frameworks (.NET, Java, Cocoa) as a kind of product platform.

I've been told the iTunes development team consists of about eight professionals. How large might this team be at another company? 20? 30 or more?

What made the difference at Apple? The team didn't have to build iTunes from scratch. They were able to use trusted software frameworks to speed development and spur innovation. Simply put, they framed the problem correctly. 90% of the solution resides in how you frame the problem. Winston Churchill believed that leaders should provide a framework for studying and solving problems.

Here's another key. The CIO needs to ignore the call for more method and more system. Instead, he'd do well to heed research by Spencer Stuart. The research suggests that the CIO role requires knowledge of business and technology. The goal? To position technology so it responds to changes in business. And since the CIO's staff is the means to extend his vision, they should also have business and technology skills.

I'm not crazy enough to think you will embrace every idea in this blog. One idea, however, will wash over your company even if you decide to swim against its current.

Technology is making it easier for talent to rise to the surface. Proof is as close as your blog or -- a blog you read. To start a blog, you don't need technical talent or a stable of HTML jockeys. All you need is your thoughts, your ideas, and the will to write.

About a year ago, someone wrote to me about an old website of mine: “Your website sucks. Look at it! It's ugly.”

But since I've been using Typepad -- and its design templates -- I haven't heard from this fellow. Perhaps he's lurking, waiting, ready to pounce.

The fear that technology -- or some technology guru -- will jump on you and drag down your business is fading fast. Why? Because many software products have reached the point where technical details are hidden, invisible, or non existent -- allowing you to focus on business.

As I write this, the latest Creating Customer Evangelists Newsletter arrives in my email box. It refers to several business blogs as models to explore. I venture a safari and discover...

Keiko Groves, a 19-year-old Florida college student, markets her creative clothing designs entirely through her LiveJournal blog. Executives, who feel at home reading The Wall Street Journal, may have found themselves reading a Florida journal. These button-down execs may learn a marketing lesson -- maybe even a fashion lesson -- from this college student.

Groves didn't need a hall pass from a technology monitor to run her business, instead she's the one handing out fashion passes. What's more, her talent prompted the Orlando Sentinel to write an article about her blog and her business. (You can read “Blogger does more than blah blah” at Groves' blog.)

Today, first time moviemakers get down to business by employing easy-to-use production software. So easy, they forget about software models and dream about story models. Indeed, Shane Carruth's dream came true when his first film -- “Primer,” a story involving time travel -- took flight and won the 2004 Sundance Film Festival's top award.

What's my point?

By now, the trend is clear. Software development tools will continue to evolve and simplify application development. As tools improve, the advantage falls to employees who understand business and technology.

Remember those wayward CIOs and their IT departments. Well, they're so tired from making everyone comfortable that they haven't awakened to the rays of reality.

Although, the University of Texas at Dallas has risen to the challenge. For its business school has crafted programs that produce professionals who have a blend of business and technology skills.

Look! I'm not messing when I say software projects that are incorrectly framed have as much chance as a rainbow trout on a cat farm. Because...you don't get a chance to set the Wayback Machine and fix the mess.

Backward thinking helps the prisoners suffer in comfort; however, thinking at a higher level unlocks the door and lets your team soar.

Supermarket for Apples

I've known several lucky software developers over the years. They chanced upon a customer who asked them to develop a software application. And, here's the lucky part: the customer provided all the business domain knowledge, paid for the software, and allowed the developers to retain the software rights. You couldn't dream of a better deal.

So you see why Apple executives might be pinching themselves when it comes to their newfound supercomputer success.

For out of the blue they received a call in June of 2003 from Dr. Srinidhi Varadarajan who wants to string together 1,100 G5s. To make a long story short: Dr. Varadarajan builds a supercomputer for Virginia Tech using Apple hardware. The supercomputer becomes the world’s third fastest -- creating buzz and credibility for Apple’s Xserve.

In the process, Dr. Varadarajan provides domain knowledge, buys 1,100 G5s, and hands Apple a new market on a silver plate -- high-end computers.

I’m willing to bet there’s a tight feedback loop between Dr. Varadarajan and Apple -- design ideas will continue to flow to Apple’s server line.

Did Apple have a marketing plan in place for its server line? I’m sure it did; however, even Philip Schiller, Apple’s senior vice president of worldwide marketing, was stunned by the audacity of Virginia Tech’s concept.

Draw a line in the plan? To Apple’s credit, nobody said, “Sorry, high-end computing is not one of our target markets. We can’t help you.” In fact, many companies commit a dangerous strategy error; they try to plan the future.

Do you? If so, you might want to follow Apple’s example in flexibility.

What enabled Apple execs to listen to one customer and make a nonlinear leap? They had created an option by negotiating a partnership with IBM to develop the next generation of PowerPC processors--the G5.

The G5 allowed Dr. Varadarajan, who had never used a Mac, to envision a new future for supercomputing which in turn created a new market for Apple.

This isn’t the first time an option has rippled benefits to Apple, and it won’t be the last. The future cannot be planned, the future can be imagined.

Unlocking the power of story

Winston Churchill credited his writing skills to a remedial English class he was forced to take during his early schooling.

His teacher coded each element in a sentence with a unique color, helping the students identify subjects, verbs, objects... The grammar gymnastics had a profound impact on Churchill as he later wrote, “I learned it thoroughly. Thus I got into my bones the essential structure of the ordinary British sentence, which is a noble thing.”

The structure of story is already in our bones, we simply need a way to unlock it. In “Unlocking The Power of Story Within You,” James Bonnet provides the keys.

Archetype is the key that opens the story door. There is the holdfast, the hero, the state of misfortune, the people who lure the hero into the adventure, and so on.

I think of archetypes as sentence diagrams for story. They help you understand story, and slow down the storymaking process to the point where you enter observation mode -- even when you’re watching a movie. Oh yeah, Obi-Wan Kenobi is the father figure archetype.

What's more, Mr. Bonnet provides six creative techniques that help you develop your story. Modeling is one technique:

With modeling, you examine the emotionally charged images you’ve selected and begin identifying and associating them with the archetypes of the story model.

To determine what somebody’s story is, you don’t necessarily have to ask, “What’s your story?” You can detect his internal story simply by watching how he acts. In fact, you can examine his emotions and select an archetype that fits.

Suppose, at work, you detect a holdfast in your midst. It wouldn’t be wise to go before a committee he chairs and suggest sweeping changes. Indeed, your ideas -- and you -- would be brushed aside.

Nooo! Instead create an adventure that lures the hero into your story. Then sit back and watch as Darth Vader and Luke Skywalker power up their lightsabres.

Story makes your life easier -- even at work.

For, as Mr. Bonnet writes, “That is the whole purpose of story: To guide us to higher, more desirable less problematic states of being. And one of the ways that it does this is by revealing the truth and nature of problems and their solutions.”

Cooking up new products

After reading Product Development for the Lean Enterprise, I was curious about Toyota’s chief engineers. So I sent the author, Michael Kennedy, a query: what business training does the chief engineer receive during his career at Toyota? Here’s his response:

While I don't know specifics, I am sure the Chief Engineer will be well grounded in the business aspects of Toyota. He is also the primary customer interface and often spends time in the field understanding the customer. His primary background will be technical. Remember, these are seasoned veterans that have primarily earned their knowledge through apprenticeship, not training courses.

It seems clear that Toyota engineers have opportunities to work with customers and learn the business. This is in direct contrast to the attitude some companies have about engineers and customer interaction.

Perhaps you're wondering, as I have, is there an analogy that describes the role of chief engineer? Let me share one from Michael’s book.

For years Donna, an accomplished chef, had collected recipes and followed instructions exactly. She grew bored with this approach, so she sought advice from her grandmother -- an incredible cook.

Donna started her own notebook, which didn’t have exact recipes, but was more about what worked and what didn’t. With this approach, all her energy is spent on creating new dishes -- every dinner party is different. Each meal is like a new product.

She never totally does a new dinner, just parts of it. When she started to build from her own expertise, she moved from a structural environment to a knowledge-based environment.

Unfortunately, some professionals still cook by the book.

Typically, HR sticks to an order-taking script. Using a cookie-cutter to hire employee cutouts from the dough of conformity, HR will be lucky if one of their gingerbread men springs to life and runs with the business.

You see, once a company becomes successful, managers tend to build kingdoms. To add workers to their kingdom, they divide labor, which requires more employees. Additional employees, increase the lines of communication. As the lines of communication increase, project times increase exponentially. So it takes longer to deliver products, and employees feel less satisfaction from their work.

That’s why I believe it’s easier for small companies to embrace the chief engineer role and knowledge-based development. What’s more, a small company is more likely to hire an employee who wears multiple hats.

Here’s a clue. Employees with multiple skills can make a difference for your company.

Picture a salesperson or program manager with little or no design experience. It’s unlikely this person will connect customer needs and technology. In fact, this person will skip over important customer details and insights when communicating with the design team. Look!

These gaps short circuit innovation and your company’s future.

Now, consider Toyota’s chief engineer who is the primary point of contact for customers. While talking with customers he discovers their beliefs, feelings, and desires. Moreover, he will understand the customer to the point where he sees the future and develops a vision for the product. Like a Venn diagram, the chief engineer’s skill sets intersect to shade the images of product innovation.