Unless you have all of the resources you need to create and develop your product, you are more than likely interfacing with a technical consultant or engineering company.  The more effectively you can communicate with the technical team, the better your chances of getting what you want. 

Writing it down and describing all of your ideas and how they will work together will be a very effective task for moving your idea forward with your technical team.  You will begin to see holes in the logic, stumble upon new ideas, and begin to document what is in your head.  Writing it down will also alleviate the constant ruminating of an idea in your head.

But you say, “I’m not an engineer!  I don’t know how to write a specification!”.  Well, both statements may be true, but if you want to pave the way to a successful product development venture, you’ll need to learn to communicate your ideas effectively to the engineers who can write a specification.  And with a few helpful tips, you too can write a basic specification.

An item of note, this list is for a somewhat validated idea.  This list assumes you’ve already performed the basics like validated a market, created a tentative business model, and you have performed some level of prototyping.

1. Brainstorm.  Your first step is to just get all of your ideas down on paper.  White boards, drawings, and short lists are a good place to start.  You want to focus enough on this so it is all out of your head and on paper.  You can move things around later, but now you have your concept documented and you can begin to refine it.
2. Strong and weak words.  Inventors tend to get very tied to their ideas.  Try to break away from that and begin to describe what you need done using some special words.  If you use a phrase like, “The device shall be made from titanium,” then the reader will expect that you are the expert in this material and there is no room for variance.  Other strong phrases are: must have, required to, and will.  Does it need to be made from titanium or is it that weight to be minimized?  There are weak words to use like may or should or can.  Think about what is absolutely required and what would be nice, and the real goal you are hoping to achieve.  Then write that down.  Keep in mind that opposites can also be valuable in your writing.  Phrases like cannot, shall not, and should not are equally useful.
3. Sketch.  As you have heard, a picture is worth a thousand words.  You may be amazed at how effective a simple block diagram in Power Point can be.  Show how things are connected.  Show the logical flow of operation.  There are great mock-up tools for software/apps these days you can also use.  The more you think and articulate your idea, the more effective it will be conveyed and possibly become a better product.
4. Write what you know.  You are probably not an engineer if you are reading this, so don’t try to be.  Yes, you should educate yourself in the technical field of your idea.  You should not spend your days looking over websites for microcontrollers and then specify the use of one in your project.  Describe the features and functionality you require, don’t try to engineer the product unless you have that skillset (before you had this idea).  An experienced engineer will have just that, a lot more experience.  Take advantage of that and let them do what they are good at.
5. Iterate.  A specification is a living document.  It can change as the market and business input is uncovered.  As you learn more about your idea, do more research, and develop your product and business, it will constantly evolve.  Now with that being said, once you engage a technical team, there can be costs associated with change.  You will want to get close enough to start engaging your technical team, but once you hand it over to them you should have a good assurance it’s right, and only make changes that absolutely have to be done.  Inventors tend to like to ‘tinker’ with their ideas which can keep products from ever reaching the market, so iterate until you have something to sell, then stop.  Let the market drive your iterations.  This is a subject for another posting.

What I’ve described above is generally referred to as Functional Requirements Specification or a FRS.  The engineering team will then likely create several documents from this which could be a Design or Product Specification, Test and Validation Plans, etc.  Those are beyond the scope here. 

Don’t worry about making it perfect.  From a non-technical perspective, you should put down the things that you care about.  However technical and non-technical that is.  If you care about the color, put that down.  If you care about costs, put that down.  If you don’t care what material is used, let the engineer figure that out.  In any case, your technical team will start to ask you a lot of questions to help flesh out your specification.  After the ground work is laid, then everyone can be on the same page for what needs to be done.