AI Wants an Answer. Product Development Needs Exploration

One challenge SPARK has encountered while experimenting with AI is that the tool rapidly wants to move toward an answer. In many situations, that is useful. In early-stage product development, however, reaching an answer too quickly can work against the way creative ideation actually happens.

Summer Intern Will Knutson described another version of that problem:

“Often when people waste time with AI, it is simply because it doesn’t know, but it isn’t willing to tell you that it doesn’t know.”

AI is designed to respond. The challenge for an experienced designer or engineer is recognizing when that response is genuinely useful, when important context is missing, and when the conversation is beginning to narrow before the team is ready.

Holding Several Ideas at Once

SPARK Co-Owner Bruce Ferris compares a productive in-person ideation session to standing in front of a wall of Post-it notes.

“The team may drill down into one concept, return to the larger problem, set an idea aside, and later recombine one useful piece with parts of other concepts. The abandoned idea does not have to be entirely good to contain something worth keeping.”

That ability to leave ideas unresolved is an important part of product development. An experienced team can recognize that a concept may have one valuable feature even if the overall direction is not viable. Another option may initially appear less interesting but ultimately prove better suited to the user, material, assembly process, or manufacturing requirements.

Bruce sees AI behaving differently:

“AI has a harder time maintaining that same field of possibilities. It tends to keep drilling down toward an answer, and it can be difficult to return to one specific fragment from an earlier response without losing the surrounding context. That makes the tool useful for generating threads, but less natural as the shared visual workspace that a wall of ideas becomes for a product development team.”

The limitation is not that AI cannot produce ideas. It can produce them very quickly. The challenge is maintaining the broader field long enough to compare, combine, discard, and revisit those ideas without prematurely deciding which one should lead.

That distinction reminded SPARK Business Development Associate Kaity Myers-Davie of a concept from her experience teaching yoga:

“There is a well-known practice to observe without comment, notice without judgement. While humans are not always excellent at this skill, they do have the capability. However, AI cannot really possess this skill, due to the way it's developed and trained. That’s why it takes an experienced engineer and designer to notice when AI is offering a comment during the ideation phase or if it is providing an observation from data surrounding a certain idea.”

For a product-development team, there can be value in allowing several ideas to simply remain present before deciding what they mean or which one deserves to move forward.

Threads to Pull On

Bruce approaches AI with that limitation in mind.

“My mindset when using AI is that if I set up the problem correctly and ask good questions, it will likely give me nuggets. It almost never gives me the answer, but it gives me threads to pull on.”

That expectation changes how the tool can be used. Instead of treating AI as the engineer responsible for solving the problem, Bruce often treats it more like a junior designer or highly capable research assistant.

“It can generate options and introduce options, such as material choice. In one instance, AI reminded me of a material I had not used in a long time and resurfaced some of its key features. It did not replace my knowledge of the material, but it brought a useful option back into the conversation more quickly — much like a research assistant might.”

For tightly bounded questions, that can be particularly effective. An engineer might ask for several alternatives to ABS for an outdoor product, relevant design guides, or material information worth investigating further. AI can rapidly expand the starting point for that research, while the engineer remains responsible for determining whether any of the information actually applies to the product.

Bruce gave one example:

“In one exploration, AI introduced ASA, a material I had not previously needed to design with. The value was not that AI selected the material for the product, but that it placed a relevant option on the table quickly enough for an experienced engineer to investigate it.”

That is where the junior-designer or research-assistant comparison becomes useful. AI does not need to make the final decision to provide value. Sometimes putting a relevant possibility back into the conversation is enough.

Getting Back to Foundational Knowledge

Bruce has also found AI useful when revisiting what he calls “textbook” engineering theory.

“It is quite good at engineering ‘textbook’ kind of theory. So if you’ve forgotten the root physics or engineering, AI will often help you refresh those foundational principles.”

In one conversation, Bruce returned to the mechanics behind torquing a bolt. Rather than simply supplying a torque value, the discussion returned to what is mechanically happening: the bolt stretches and behaves like a spring. For an experienced engineer, the value was not learning the rule for the first time, but getting back to the underlying “why” more quickly.

That is an important distinction. AI can help retrieve and reconnect information, but the engineer still needs enough knowledge to evaluate what comes back.

Sometimes Expertise Means Not Answering Yet

Bruce sees one particular behavior as separating AI from the experienced engineer in the room: a senior engineer will often recognize that the question cannot responsibly be answered with the information available.

“In an engineering world, AI should spend more time asking clarifying questions. To act more like a senior engineer, it should not even attempt to give an answer until it has been given enough information.”

That senior-level judgment comes from context. An experienced engineer understands materials, tolerances, mechanisms, manufacturing processes, assembly, cost, vendor capabilities, and how the product will behave in the real world. That allows them to recognize when something sounds technically plausible but is missing an important constraint.

AI can still be an extremely capable addition to that process. It can introduce possibilities, accelerate research, refresh foundational knowledge, and provide useful threads to investigate. But Bruce’s research-assistant analogy keeps the relationship in perspective: the speed of the tool is most valuable when it is paired with someone who understands the problem well enough to challenge the response.

Sometimes that means knowing which answer makes sense.

Sometimes it means knowing which thread deserves to be pulled.

And sometimes it means recognizing that there is not enough information to answer the question yet.