All products begin with an idea. Someone will think of a new solution to a problem, a new device that there may be a market for, or an entirely new market no one has thought to address before, and a potential product is born. How do you shepherd that idea through the conceptual quicksand to becoming an actual product?
Your biggest danger at this point is if your idea is vague. If everyone has a slightly (or sometimes greatly) different interpretation of what your product is to do, you are letting yourself in for a world of hurt in feature creep alone. At worst, your engineers will come back with something that is almost, but not quite, entirely unlike what you envisioned.
The standard approach to avoiding vagueness is to be specific; write a detailed product requirement spec, circulate it to everyone concerned and make sure that everyone is looking at the same glimmer on the horizon that you are. The problem with that is that it is easy to become too specific. At Kynesim, we prefer to steer a middle ground. You do need some kind of specification, but at the earliest stage of any project you need to be flexible. No one needs to argue about the exact shade of blue the case will be so far in advance of making one. (Having said that, if you do have a colour scheme you really want to use for branding it may impact on the cost. That “exact shade of blue” discussion has ruled out off-the-shelf casings before now.)
A related point that our AI prompter didn’t specifically pull out is that of hidden assumptions. When you know your market well, there will be things that go without saying for you that are not at all obvious to other people. If for example your idea involves periodically draining a tank so the water in it doesn’t become stagnant, it may be obvious to you that you don’t want to drain the tank if someone manually drained it recently. To a designer, that’s a requirement for a sensor that they may have never thought of until you mentioned it.
It works the other way round too. If you have never made an electronic product, there will be issues around manufacture and ongoing maintenance that you won’t be aware of. A designer may make assumptions about firmware upgrades, for example, that can come as an unpleasant surprise.
The solution here is to talk and listen. Kynesim’s scoping phase for a project involves us asking a lot of questions, trying to tease out the assumptions being made by both our clients and ourselves. We also encourage clients to ask us questions, both for their benefit and ours. Sometimes it is the question itself that reveals an assumption, and we have a lightbulb moment of understanding our client’s point of view.
Skipping lightly over the question of whether or not there is a market for your product (though you shouldn’t, some great ideas have been criminally underappreciated by the general public), we segue nicely into the question of how technically challenging your idea is. This is where you need experienced designers and developers to research and evaluate all the things you want your product to do. Sometimes this research will raise big red flags; a straightforward-seeming feature may have hidden complexity, there may be unexpected power constraints or even regulatory issues in some domains. Regardless, you will have a better understanding of how much cost and effort will go into the final product at the end of the process.
If you have red flags, address them early. That doesn’t necessarily mean that you need to change your product requirements; you should always keep your Minimum Viable Product in mind. Do however remember that “We won’t do that” and “We won’t do that in the first version” are entirely different answers with entirely different implications for costs and timescales. If you drop a feature completely, it has no more effect on your product. If you drop it hoping to revive it later, it does have an effect. Hardware and software design will have to allow for that feature, which may involve solving a lot of the problems that led to you drop the feature in the first place.
We often think of this stage of a project as a big discussion. Questions asked and decisions made result in research and investigation. The answers that come out of that research feed back into more questions and decisions, and perhaps the revision of older decisions in the light of new information. Estimates of costs and timescales are gradually refined. In some senses this dialogue never stops, just changes focus as development proceeds.
In short, all product development starts with talking and listening. Communications between ideas generators and developers are vital, both for capturing the idea and understanding the costs and complexities of turning it into reality.