After more than 30 years working as a software architect and developer, I was comfortable talking about technology. Cloud platforms, data architectures, automation, machine learning, APIs, and integration were familiar territory.
But during a six-month Stanford digital transformation program, I was reminded of something easy to forget:
Digital transformation should not begin with technology. It should begin with a real organizational need.
That lesson eventually shaped the instructions I wrote for a custom GPT that could help assemble a digital transformation capstone project. The GPT was not supposed to invent a transformation strategy or recommend fashionable technology from memory. I deliberately constrained it to a small set of source documents and told it to confirm the organization and its needs before doing anything else.
The most important part of the instructions was not the list of technologies. It was the order of thinking.
This article describes the design principles at a high level. It does not disclose the underlying course methodology, source documents, templates, calculations, or organization-specific information.
Why Technology Can Become a Distraction
Digital transformation conversations can quickly turn into shopping lists:
- Move systems to the cloud.
- Add machine learning.
- Automate a workflow.
- Build an Internet of Things platform.
- Introduce low-code or no-code tools.
- Create an augmented-reality experience.
Any of those technologies might be useful. They can also be expensive distractions.
The question is not, “How can this organization use AI?” The better question is, “What important problem or opportunity does this organization have, and what information would help it respond?”
That change sounds small, but it changes the entire project. It moves the discussion away from novelty and toward purpose.
The Source Boundary I Gave the GPT
I instructed the GPT to work only from an approved, bounded source set and to distinguish organizational evidence from general reference material.
This was a deliberate constraint.
Language models can produce a confident answer even when important context is missing. For a transformation roadmap, that is dangerous. A polished plan can still be the wrong plan if it assumes the wrong business, data, capabilities, budget, or culture.
By restricting the source material, I was applying a principle I had used for years in software architecture: define the system boundary before designing the solution.
The GPT’s job was to assemble and reason within the approved boundaries—not to replace them, expose them, or silently supplement them.
Why I Told It to Ask Questions
My instructions explicitly allowed the GPT to ask the user questions.
That might seem inefficient. Wouldn’t a good AI system simply complete the capstone?
No. Not when the missing information could change the strategy.
If the organization’s needs were unclear, the GPT had to confirm them. If a template field required data that was not present, it needed to ask rather than fabricate. If two technologies appeared possible, the choice needed to reflect the organization’s constraints and priorities.
This is one of the most useful roles for AI in serious work: not automatically providing an answer, but helping expose the questions that still need human answers.
A High-Level Order for a Responsible Transformation Roadmap
Without reproducing the underlying methodology, the public-facing pattern can be expressed as a set of connected decisions.
1. Business problems and opportunities
What is preventing the organization from performing better? Where is an opportunity being missed? What would success look like?
This is the anchor. Without it, every later decision floats.
2. Data
What information is already available? What could be collected? What might need to be purchased? What are the cost, quality, privacy, security, and bias risks?
Data is not simply fuel waiting to be poured into an AI system. Its origin, quality, permissions, and fitness for the business question matter.
3. Technology
Only after the need and data are understood should the organization consider cloud services, analytics, machine learning, automation, APIs, low-code tools, robotics, IoT, or immersive experiences.
The technology should fit the problem, not force the problem to fit the technology.
4. Return and risk
What tangible and intangible returns might the initiative create? What will it cost? What could fail? What new dependencies or exposures will the organization accept?
A transformation initiative can save money and still fail culturally. It can produce a valuable new capability while taking longer than expected to show a financial return. Both sides belong in the analysis.
5. Execution and organization
Who must participate? What skills are missing? What resistance should be expected? Should the organization run a pilot? How will progress and impact be measured?
Technology does not transform an organization by itself. People must understand, adopt, operate, govern, and improve it.
An Architecture Lesson Hidden Inside the Process
When I look back at the instructions now, I see the habits of a software architect inside them.
Architecture is not the act of choosing impressive components. It is the work of understanding forces, defining boundaries, identifying tradeoffs, and creating a structure that can survive change.
The same is true of digital transformation.
A future-proof roadmap is not a prediction that gets every technology right. It is a sequence of decisions that keeps the organization connected to its purpose while it learns.
That is why the process included business experiments, pilots, performance indicators, data governance, cultural readiness, and risk. These are not administrative details added after the “real” technology work. They are part of the architecture of change.
What the GPT Was—and Was Not
The GPT was a structured assistant for assembling a capstone from approved sources without exposing those sources.
It could:
- connect an organizational need to relevant course concepts
- keep the capstone sections consistent
- compare possible technologies and methods
- identify missing information
- help fit material into the required template
- and ask questions when the evidence was incomplete.
It could not know the organization better than the people inside it. It could not create trustworthy facts that were missing from the source documents. It could not decide what level of risk leadership should accept. It could not make employees participate in a transformation they did not understand.
The GPT supported the process. It did not own the strategy.
The Rule I Would Keep Today
AI systems have become more capable since I wrote those instructions. The rule I would preserve is the simplest one:
Do not let the model run ahead of the evidence.
Confirm the organization. Confirm the need. Identify the data. Understand the constraints. Compare technologies. Evaluate return and risk. Plan the human execution.
Then use AI to help reason, organize, question, and communicate.
That order does not make the work less innovative. It gives innovation somewhere useful to go.