Ahmad Ghabboun spent about six years as a UX and product designer before starting Foster’s MSIS program. AI wasn’t even on his shortlist of post-graduation career interests — he was looking at security, program management, data analytics. That changed in his third quarter, in an AI-focused class, and what he built afterward — a tool called Synapse that won Best Business and Tech Product at Foster’s MSIS Demo Day — says something specific about where design experience transfers directly into AI fluency.
We talk about this and more in our conversation for my AI Ready series (find the full episode here).
The vocabulary advantage
Ahmad’s clearest insight from our conversation: prompting well is closer to writing a design brief than writing a Google query. “If you have a background in product design, user experience, user interface, you’ll use some technical words within the design world that other users might not have.” He gave a concrete example — most people don’t know that the empty fillable space on a form is called a “placeholder.” When he prompts Lovable or Claude using precise terms like placeholder, wireframe, padding, margin, the output comes back noticeably closer to what he actually wants, instead of the generic template the model defaults to.
The general version of this: your prompt is only as specific as your vocabulary. If you already have technical language from a previous career — design, finance, operations, law — that vocabulary is leverage the moment you start directing AI tools. Most people are prompting with a layperson’s vocabulary because that’s all they have. If you have more, use it.
Building Synapse: automation with a deliberate gap
Synapse grew out of a habit Ahmad had before he ever took an AI class: he’d ask Gemini a question, take that answer to Claude for a second opinion, then sometimes take both answers to a third model when he wasn’t confident. It worked, but it meant manually juggling multiple tabs and contexts.
With guidance from Professor Leo on the strategic side — not just the technical build — he narrowed the idea into something specific rather than building “another AI chat platform.” Synapse is built for technical product managers doing governance and audit work on their own documentation. It pulls artifacts from one model, runs them through two more for independent validation, and uses a fourth pass to act as judge — flagging where the two validators disagree, scoring completeness, and surfacing gaps the TPM might not have noticed in a long document. High-confidence gaps can be pushed straight into Jira or Azure DevOps as tickets, and it syncs with GitHub.
The detail that matters most: Ahmad built this deliberately incomplete. Synapse identifies gaps and flags them — it does not auto-resolve and auto-execute. “I purposely did not automate the whole process,” he said, “because TPMs still need to read between the lines so they are aware of what’s going on.” If a TPM clicks “solve everything,” they lose the context they need to speak intelligently about the project in their next meeting. The product’s most important design decision was a refusal to remove the human from the loop, even though removing them was technically possible.
What design training catches that engineering training might not
I asked Ahmad how his product design background specifically shaped the build. His answer centered on models’ underlying behavior, more than anything about Synapse’s interface. “Some AI models, they tend to agree with you all the time,” he said. “In the real world you just need someone to tell you, ‘this idea is good, but the execution needs more.'” His fix is to explicitly instruct the model to play devil’s advocate — to poke holes rather than validate. That instinct, to actively seek disagreement instead of confirmation, is closer to a design-critique habit than an engineering one. Designers are trained to solicit critical feedback as part of the process; that habit transfers directly into how you should be prompting.
The advice he gives as an MSIS ambassador
Ahmad meets prospective students regularly, and his first piece of advice to them is consistent: use AI, but don’t let it finish something you haven’t looked at yourself. His own workaround for dense reading — upload the document, get a five-page summary instead of reading 20 to 30 pages — is a legitimate time-saver. But he draws a hard line at execution: “I won’t let it execute or finish something that I didn’t look at.” The assignments, the documents, the decisions exist so you build judgment. Skip that step and you can’t detect bad output later, in a meeting, in an interview, or at work, when it actually matters.
His second piece of advice is about specificity over general AI literacy: figure out which models are actually used in your target function, and be ready to explain why. “If you just vaguely say ‘I use AI’ — AI means Gemini, ChatGPT, Claude, and each one has many different models, and they’re different.” Interviewers ask this question deliberately, to gauge whether a candidate’s tool fluency actually matches what the team uses day to day.
The takeaway: if you’re coming into AI from a non-engineering background, don’t assume that’s a disadvantage. The specific vocabulary from your prior field is a direct lever on prompt quality. Pair that with a habit of deliberately withholding full automation from your own tools — building in the checkpoint where a human still has to look — and you end up with both a better prompt and a better product.