What agency managers and directors taught me that no coding course ever could
I started learning to code in a few months, then sat in real meetings with agency managers and directors in Singapore. The biggest lesson wasn't about software. It was about listening to the people who actually run the business.
Not case studies. Not hypotheticals. Actual people running actual teams.
The first thing I noticed was that the problems were not what I expected. I kept waiting for someone to say, “We need a better dashboard” or “We need a faster app.” Sometimes that was part of it. But the deeper issue was different.
The problems were structural, not technical
Again and again, I heard the same patterns. Manual activity tracking that nobody trusted. A recruiting pitch built on promises instead of proof. A feast‑and‑famine revenue cycle that wore people down.
These were not just missing features. They were structural problems in how agencies run day to day.
When a manager or director told me the team wasn't sure whose pipeline was real, I didn't hear a complaint about a missing tool. I heard a visibility problem. When someone described how hard it was to recruit because the pitch sounded too good to be true, I heard a trust problem. When they talked about busy months and empty months, I heard a business rhythm problem.
That changed how I thought about software. A tool can make something easier, but if the underlying process is unclear, the tool just makes the mess more visible.
Why sales changed my view of building
I came into Producer Framework thinking my main job was to get better at coding. I was still learning. I was still figuring out what I wanted to do next. But I also learned that sales is not just about convincing someone to buy. It is about understanding what someone actually needs before you try to solve it.
I used to think sales was the part after the product. Now I see it as the part where you learn what the product should be. Nothing moves without a sale, but a good sale starts long before the pitch. It starts with listening. It starts with understanding the pressure a manager or director feels when they are managing people, revenue, and client expectations at the same time.
That was the part no coding course taught me. A course can show me how to build a piece of an app, deploy it, or use AI to write code faster. It cannot sit me in a room with someone who has been running an agency for years and make me understand why a simple request is actually a complicated business problem.
What Producer Framework is trying to do
The gap I saw in those meetings is the gap Producer Framework is built to close: a system for running the agency, not another generic sales tool bolted onto workflows it wasn’t designed for.
That sentence sounds product‑y, but it came from something much more human. I was listening to people describe their days, their teams, their frustrations, and the moments where they felt the business was slipping away. The software had to fit that reality, not the other way around.
That is also why the product has to be specific. Insurance and financial advisory agencies are not just “businesses” with a login screen. They have people, pipelines, and daily habits. The software has to respect all of that.
You cannot build good software for an industry you don’t understand from the inside.
The takeaway I keep coming back to
The biggest takeaway for me personally is that every hour in those meetings taught me more about what “the client actually needs” means than any spec document could.
I’m still a student. I’m still learning how to code, how to sell, and how to think like a builder. But those meetings gave me something I didn’t expect: a sense of what real problems feel like. Not abstract problems. Not demo problems. Real ones, with real people and real consequences.
That is why I value this part of my Producer Framework experience the most. It taught me that the best technical work starts with humility. You have to be willing to listen before you build.