Capturing Ideas – Management Advice

Posted by:

|

On:

|

Wait a Minute

When you, your developers, or your staff develop new concepts, one of the first things that you may want to do is share them. This sharing usually involves peers, salespeople, customers, users, investors, legal, and others. Although this instinct is quite understandable, it is a good idea to consider the ramifications of sharing prematurely.

Also, many innovative ideas can initially be hard to explain, simply because of their novelty. It is important to take some time and capture these ideas so that they are easier to communicate. Prepare to record them as soon as possible!

Get it in Writing

Initially, there is an original concept or “eureka” moment when an idea is brand new. If you are an engineer or have engineering staff, this is when the design specification comes into play.

Understandably, these specifications are often too technical to be grasped by those outside of the designer’s specialty. Because of this, they must be “translated” in some way to communicate their saleable concept to others. We can be there initially to gather an understanding of the idea and suggest ways to explain it.

Consider Your Audience

Early formal written communication should only be provided to those who need to know. This includes company officers, program managers, and internal users.

At this stage, we can help review the design by meeting with your creators and preparing a suitable “disclosure” and technical documentation set. This material explains how it works and what it does to to someone knowledgeable in your industry.

There is also sales training and customer communications in advance of the market introduction. This usuially includes “how to” documentation that supports the development of training materials.

A final “doc set” is the general documentation needed to get the word out to the sales channel, customers, technical support specialists, and whoever else needs to understand your product/service.

Looking Ahead

We understand that technical document creation may be somewhat confusing and does not always promise a good Return on Investment. Despite this, our experience shows that it is essential to document a product, especially one that has many levels to its design.

A documentation plan should always consider the combined viewpoints of the installer, user, and maintainer to reach its full potential. Also, the contents of any doc package should be carefully organized to fulfill the current plan and those for future product releases.

We can support a living documentation process that remains effective for its entire product/service life cycle.