"I Just Asked" — Two Weeks, One Directive, and the Power of Keeping It Simple
Leadership gave us two weeks to deliver a product — not a plan, not a theory, a product. What followed was a masterclass in why the simplest question in the room is usually the most valuable.
May 24, 2026
Applied AI Design, AI Strategy, Operational Integration, Agentic AI, Leadership
The Directive
There was no ambiguity in the message. Our director didn't schedule a brainstorming session. He didn't ask for a roadmap or a status update. He delivered an instruction: you have two weeks to deliver a product. Output. Not activity. Not more testing, not more protocol development, not more theoretical exploration. A tangible, demonstrable product that does something real. Two weeks.
The Starting Position
We weren't starting from zero — but we weren't starting from a clean position either. A very motivated Sales Director had gotten ahead of the curve and built functional concepts using an LLM model and platform that didn't integrate with our enterprise environment. His work was solid — he'd proven the concept, generated meaningful outputs, and demonstrated clear value. The problem was that none of it connected to our systems. His platform couldn't talk to ours. His outputs couldn't be consumed by the teams that needed them. The concepts lived in isolation.
Our job was to take everything he'd built, replicate it within our own platform, improve on it where possible, and deliver a production-ready capability — in two weeks.
The Scope
When I say "everything he'd built," I mean everything. The full inventory included 7 distinct data inputs, 9 separate Python scripts handling various transformation and analysis tasks, 4 exportable output products, and a small collection of bundled AI skills including a structured .md skill file, a comprehensive playbook, and supporting documentation. This wasn't a simple chatbot configuration — it was a multi-stage analytical pipeline that ingested raw data, processed it through multiple AI-assisted transformation layers, and produced formatted deliverables.
All of it needed to be reverse-engineered, translated to our platform, and made operational. Fast.
Phase 1: Replication
I started by gathering every artifact the Sales Director had produced — raw inputs, Python scripts, skill files, playbooks, output samples, everything. Rather than manually deconstructing each component and rebuilding it piece by piece, I took a different approach: I fed the entire collection into our connected model and tasked it with analyzing, understanding, and transforming the other platform's outputs to make them native to ours.
The model ingested the skill architecture, parsed the Python logic, mapped the input-output relationships, and generated equivalent functionality within our environment. Seven inputs. Nine scripts. Four output formats. A handful of bundled skills.
It took less than three hours to replicate the entire process.
Three hours to reproduce what had taken another team weeks to build on a different platform. Not because their work was simple — it wasn't. But because the approach of using AI to understand and translate AI-built artifacts compressed what would have been days of manual reverse-engineering into a single working session.
Phase 2: Automating the Inputs
My boss looked at the replicated capability and said what any good leader says next: "Great start. Now we need to automate the inputs and figure out how and where to deliver the outputs."
He was right. The initial process was manual and clunky — you had to feed raw data in by hand, trigger the processing steps sequentially, and the end result was a zip folder of files in various formats sitting on a local drive. Functional, but not scalable. Not something you hand to a Sales team and say "use this every day."
The input automation challenge led us to our Snowflake cloud team. The raw data feeding the process existed in Snowflake's semantic layer — the question was how to connect our AI pipeline directly to that data source instead of requiring manual report pulls and file uploads.
One of the Snowflake developers immediately started working through my Python scripts line by line, manually mapping each field reference back to its corresponding column in the semantic layer. It was methodical, technical, and exactly how a trained developer approaches the problem.
I watched for a few minutes and then asked: "Why don't you just make the model do it? Let it figure out the mapping."
He paused. The suggestion was so straightforward that it clearly hadn't occurred to him — not because he lacked capability, but because his training and instinct pointed him toward the manual, systematic approach first. But he tried it.
Moments later: "We're 97% mapped. There's just a few fields we'll need to chase down."
Hours of manual field mapping compressed into seconds. Not because the developer wasn't skilled — he absolutely was. But because the tool was purpose-built for exactly this kind of pattern recognition and structural translation, and nobody had thought to ask it.
Phase 3: Solving the Output Problem
The next day brought the output challenge. We had AI-generated analytical products — Excel files, PDFs, formatted documents — but no clean mechanism to deliver them into Salesforce where the Sales team actually lives and works. The outputs needed to land in a format that was immediately useful, not dumped into a file share that nobody checks.
My cohort and I started discussing the options: custom objects, custom fields, Apex triggers, Salesforce Flows. All viable. All requiring meaningful development cycles that we didn't have time for within the two-week window.
On a whim, I asked a different question: "Can we ingest JSON files and do something with that?"
I could see the lightbulb go off. "We can," he said. "We can feed JSON into a Lightning Web Component and it will automatically display exactly as it's formatted from the LLM model."
Clean tables. Formatted charts. Structured data views. All rendered natively inside Salesforce, driven directly by the AI output — no custom object architecture, no Apex development, no multi-sprint build cycle.
One problem remained: the AI outputs were in Excel, PDF, and document formats. Not JSON.
I asked the model to figure it out. Take the generated outputs — the spreadsheets, the documents, the formatted reports — and convert them to JSON.
Moments later, I had my JSON files. Minutes after that, we had a clean, sleek, professionally formatted dashboard of tables and charts displayed directly in Salesforce. Built in an afternoon.
Phase 4: The Security Call
The next day, I got invited to a call. Security review — the final gate before production deployment.
My cohort opened the call: "Hi Trey, I need you to explain to this panel how you were able to convert your outputs to JSON."
I was momentarily confused by the question. It felt like being asked to explain how I opened a door.
"I just asked for it."
The room — a panel of senior developers and security approvers — laughed. Not dismissively. Genuinely. Because they informed me that their teams had been trying to solve that exact conversion problem for some time and had not been able to produce a reliable solution.
They asked if I had validated the data and output accuracy. I confirmed that I had.
Approval was granted on the spot.
Speed of Delivery
Two weeks was the directive. The core replication took three hours. The input automation was solved in a single working session with the Snowflake team. The output delivery pipeline was built in an afternoon. Security approval was granted on the first review.
The total elapsed time from directive to approved, production-ready product was measured in days, not weeks. Not because we cut corners — every output was validated, every integration was tested, every security concern was addressed — but because the approach prioritized letting the tools do what they're designed to do rather than defaulting to manual processes out of habit.
Cross-Functional Collaboration
What made this work wasn't any single person's technical ability. It was the willingness of a cross-functional group — AI strategy, Snowflake engineering, Salesforce development, security — to move fast, stay in the same room (literally and virtually), and challenge assumptions in real time. Every breakthrough in this project came from someone asking a question that reframed the problem: why not let the model map it? Can we ingest JSON? What if we just asked for the conversion?
None of those questions required deep technical expertise. They required a willingness to try something simple before defaulting to something complex.
The "I Just Asked For It" Moment
The security call will stay with me for a while. A team of experienced, formally trained developers had been working on a file conversion problem — and the solution turned out to be a natural language request to an AI model. No script. No custom code. No architectural workaround.
That's not a story about developers being bad at their jobs. They're excellent at their jobs. It's a story about how deep technical training can sometimes create blind spots around simple approaches. When your instinct is to write code, you reach for code. When your instinct is to ask the tool a question, you sometimes get the answer faster than anyone expected — including yourself.
The Fragility of Speed
Moving this fast creates its own risks. When you compress a multi-week development cycle into days, you gain speed but you lose some of the deliberation that a longer timeline forces. Design decisions that would normally go through multiple review cycles get made in real time. Architecture choices that would benefit from a week of consideration get locked in during a single working session.
The product works. The outputs are validated. But the documentation, the long-term maintenance plan, the onboarding materials for the next person who needs to understand the pipeline — all of that still needs to be built. Speed got us to delivery. Sustainability requires the follow-up work that isn't as exciting but is equally necessary.
Platform Dependency
The replication approach — feeding one platform's artifacts into another model for translation — worked cleanly in this case. But it revealed a dependency worth acknowledging: the quality of the replication was directly tied to the quality and completeness of the original artifacts. If the Sales Director's scripts had been poorly documented, if his skill files had been incomplete, if his playbook had gaps — the translation would have inherited those gaps.
We were fortunate that his work was thorough. But the approach assumes a level of documentation discipline from the source that isn't always present. In future iterations, validating source artifact quality before attempting AI-assisted translation should be a formal step — not something we discover mid-process.
The "Just Ask" Limitation
"I just asked for it" makes for a great moment in a security review. But it's worth being honest about its limits. The JSON conversion worked cleanly because the output formats were structured and the conversion was relatively straightforward. For more complex transformations — nested data relationships, cross-referenced tables, multi-format documents with embedded logic — "just asking" may produce outputs that look right but contain subtle structural errors that only surface downstream.
The lesson isn't "always just ask." The lesson is "try asking first, then validate rigorously." The simplicity of the approach doesn't exempt it from the discipline of verification. In this case, the validation confirmed accuracy. In the next case, it might not — and the humility to check is what separates a useful shortcut from a dangerous one.
Reflection
There's probably a handful of takeaways from this story. The two-week deadline was met. The product was delivered. Security approved it on the first pass. By most measures, it's a straightforward success story.
But what sticks with me isn't the speed or the outcome. It's the pattern that repeated itself at every phase of the project: the simplest approach was consistently the most effective one, and the people most likely to overlook it were the ones with the deepest technical backgrounds.
That's not a criticism. It's an observation about how expertise shapes problem-solving instincts. When you've spent years learning to write code, your first instinct is to write code. When you've spent years learning to manually map data structures, your first instinct is to manually map data structures. The tool that can do it for you in seconds doesn't enter the conversation — not because you don't know it exists, but because your training didn't wire you to reach for it first.
The Principle
Occam's Razor applies to AI strategy the same way it applies to everything else: the simplest solution that works is usually the right one. Ask the obvious question before building the complex solution. Let the tool do what the tool was designed to do. And when someone looks at you like your suggestion is too simple to possibly work — insist they try it anyway.
Work smarter, not harder. Keep it simple. And never underestimate what happens when you just ask.
This project is a case study in Applied AI Design, Operational Integration & SOP Development, and Cross-Industry AI Advisory — and a reminder that the most valuable person in the room isn't always the one with the most technical depth. Sometimes it's the one willing to ask the simplest question.