Draft Your Database Relationships Without Being a Programmer

The intention was to release a new feature fast.
Instead, we were stuck in meeting rooms for days.
At first, I thought the engineers were overthinking it.
The reality was I failed to provide a clear technical picture.

How does that happen?

Imagine hiring a builder.
You give a brief instruction.
Build a bedroom, a bathroom, and a garage.
Then you walk away.

The builder is confused.
Where does the bedroom connect?
Where exactly does the garage go?
On paper, the idea looks neat.
In execution, it becomes a mess.

Building digital products works exactly the same way.
If a Product Manager hands over a business concept without an architectural vision, engineers have to guess.
And guesses frequently miss the mark.

This is an old disease for product managers with no coding background.
I include myself in that group.
Over my 20 years building products, technical architecture has always been a friction point if not prepared early.

It used to require serious effort to solve.
I had to ask senior engineers to whiteboard with me.
Even then, it took days.
But the rules have shifted entirely.

I now use AI to draft database relationships.
Not to pretend I am a programmer.
But to provide a logical starting point.
This ensures discussions with the technical team never stall.

Old Habits, New Tools

On my profile page, one fact always makes people curious.
I helped cut company costs by over USD 4 million per year.
Many assume this was an instant result of AI.

Let me correct that.
That $4M+ in savings is a yearly figure, and it happened well before generative AI exploded.

The sources were various efficiency initiatives I drove with my teams.
At Flip, money transfer costs dropped by about 32% in six months.
That saved roughly USD 2.12 million per year.
At Tokopedia, optimizing the authentication system saved around USD 2 million every year.

Making companies lean is an old habit of mine.
I did this long before AI became a massive trend.
Automation is just one of the ways, not the only source.
We also fixed processes, routed traffic better, and made services efficient.

Leverage like that used to require a strong position, massive engineering teams, and very expensive systems.
A regular employee could never push changes of that size alone.

Now, AI is the sharpest tool for that exact same habit.
And you can train everyone on your team to use it.

The proof is real.
A few months ago, I built an eight channel content distribution system.
It automatically cuts one long video into short clips.
Then it posts them to YouTube, Shorts, Reels, Threads, and LinkedIn.
I built and run that system completely by myself.

The principle of solving the problem is identical.
But the tools I hold today are far more capable.

This applies perfectly to preparing product feature documents.
Especially when you are stuck trying to map out a database relationship.
You do not have to take coding classes.
You only need AI as an early stage thinking partner.

Why PMs Must Care About Data Architecture

Many PMs feel tables are a technical matter left to engineers.
It is the easiest excuse.
But on the ground, that excuse makes execution incredibly slow.

When I was leading four product teams at once, decision speed was crucial.
A single blocked discussion could push a launch off schedule.

If you come to the engineers with only interface drawings, they will ask details.
You might not have thought about those details at all.
Can one user have multiple shipping addresses, or just one?
If an order fails, is the data deleted or kept for history?

If you have not thought down to the level of tables and relations, you will be confused.
Meetings will drag on endlessly.
Decisions get delayed.
Everyone ends up exhausted and losing momentum.

That is why providing an initial draft is critical.
This draft does not have to be perfect or production ready.
It only has one purpose.
To trigger a sharp discussion grounded in strong logic.

Engineers can look at your diagram and give immediate feedback.
They might point out the data is too clustered and should be split.
Reacting to something tangible is much easier.
It is significantly faster than staring at a blank piece of paper.

A Real Workflow to Draft Database Relationships

How do you do this in the real world?
I use a method anyone can easily follow.
You do not need a special subscription, just open the AI tool you normally use.

First step: Write down the main entities in plain language.
Suppose you are building a digital wallet.
Type a simple prompt to your AI.
"Please help me draft a database relationship for a digital wallet. The main entities are User, Balance, Transaction, and Topup History."

Second step: Ask the AI to establish the rules.
Give a follow up prompt.
"Explain the logical relationship between these entities. Which are one to many, and which are many to many? Please explain in simple English a non programmer can understand."

The AI will give a clean, logical explanation.
It will tell you one User can have dozens of Transactions.
Every Transaction must be tied to one Topup History.

Third step: Ask for a visualization.
Humans process images faster than text.
You can ask the AI to format the output as a table.
Or ask it to write Mermaid format code.
Just copy the code, open a diagram generator website, and paste it there.
You instantly get a visual schema everyone can read.

Fourth step: Bring that draft to the meeting.
This is the part that changes how you work entirely.
Open the draft during the discussion.
State your intention clearly.
"I tried to make a rough sketch of the data structure. Does this match the business logic we need?"

Your engineers will be surprised.
They will immediately understand the boundaries you want to achieve.

When I built the FINA system, an AI customer support automation tool, this early architecture draft helped the team move exceptionally fast.
We successfully built a system that cut costs to about $0.004 per QA round.
That FINA system even caught data security gaps between users before going to production.
Everything was finished in just two weeks because discussions were highly targeted.

Saving Time and Money

The true cost of an AI tool is not its subscription fee.
The real price is how much time you waste by not using it.
The same applies to using AI to draft technical foundations.

If you leave all the heavy lifting to engineers from scratch, you pay for expensive waiting time.
Drafting a database relationship is not about writing complex code.
It is about understanding and building the logic of your own business.

Which side are you on today?
Are you waiting for someone else to figure out your product architecture?
Or are you ready to draft it yourself and lead team discussions?

For those who need a community for concrete practice, I built a space for us to grow.
You can join AI Circle, where we break down real AI tactics alongside other PMs.

If you see execution bottlenecks happening across your internal corporate teams, and you need a structured approach to train their productivity, head over to my corporate services page.
We can discuss strategies to make your team move faster, without constantly hiring more people.

Do not let big ideas stall just because you feel you are not technical.
Start with a small draft you put together yourself.
Let the free time and actual releases prove the results.