Building Your AI Toolbox: A Practical Guide to Using Claude, ChatGPT, and Copilot Together

Earlier this month I made the case that comparing AI platforms head-to-head misses the point. The question I keep seeing — "which AI is better?" — isn't really the question that matters. What matters is which tool fits the job in front of you.

That post seemed to resonate with people, so I want to go one step further. Because knowing that you should have an AI toolbox doesn't help much if you don't actually know how to use one. Owning a toolbox and knowing your workflow are two different things.

So here's what my workflow actually looks like, tool by tool, and the thinking behind it.

The problem with picking a "favorite"

Most of the AI discourse I see online is framed as a competition. Someone posts a benchmark, someone else posts a counter-example, and the comments turn into a debate about which platform "wins." I understand the impulse — we like rankings, they're easy to argue about, and picking a favorite feels like it saves you the work of thinking further.

But the ranking impulse breaks down the moment you actually try to use these tools for real work. A tool that's excellent at one stage of a task can be mediocre at another stage of the same task. If you judge it only on the stage where it's weak, you conclude "this AI isn't very good," when really you just used a screwdriver to turn a bolt.

The fix isn't finding the one tool that's good at everything. It's noticing that your work itself has stages, and matching the tool to the stage.

The three stages of a piece of work

When I look back at how I actually get things done, three distinct modes show up over and over:

1. Shaping the problem. This is the messy, early part — before you know exactly what you're building, sometimes before you're even sure the idea is a good one. You need something to push back on you, ask the annoying follow-up question, and help you find the holes in your own thinking.

2. Doing the real work. Once the idea is solid enough to act on, the job changes completely. Now you need depth and continuity — something that can hold the whole shape of a project, a codebase, or a document, not just one clever exchange.

3. Executing in the flow. This is the moment-to-moment part — writing the actual code, making the actual edit — where you don't want a conversation at all. You want something quietly keeping pace with you.

Three different jobs. Three different tools, for me.

How I actually use each one

ChatGPT, for shaping the problem. Before I write a line of code or open a document, I want to know I'm solving the right problem in the first place. I'll bring ChatGPT a half-formed idea — a technical approach, a leadership challenge, a strategy question — and use the back-and-forth to stress-test it. It's less "give me the answer" and more "help me find out where I'm wrong." That adversarial, sparring-partner quality is what makes it useful here. I'm not looking for agreement; I'm looking for friction.

Claude, for the real work. Once an idea turns into actual work — a project, a codebase, a document that needs real structure — that's when Claude takes over for me. It holds context across a whole piece of work rather than a single exchange, and that matters enormously once you've moved past brainstorming and into building something that has to hang together. Give it a technical problem or a messy codebase and it can work through it methodically rather than needing to be re-oriented every few minutes.

GitHub Copilot, for the flow. Copilot doesn't get a dedicated "session" the way the other two do. It's just there, inline, while I'm actually writing code — finishing a line, suggesting the next one, staying out of the way otherwise. It's less a tool I deliberately reach for and more a tool that's already in my hand when I need it.

The skill isn't prompting — it's routing

Here's the pattern underneath all of this: the tool changes as the work changes. Early-stage thinking, deep project work, and in-the-moment execution are three different modes, and trying to force one AI to do all three is where people get frustrated and conclude "AI isn't that useful for X."

It's not that the AI failed. It's that it was doing a job it wasn't built for.

I think this is where a lot of the "prompt engineering" conversation misses the bigger picture. Getting better at prompting one tool only gets you so far if you're using the wrong tool for the stage of work you're in. The more valuable skill — the one that's actually going to compound over time — is routing: recognizing what stage of work you're in and knowing which tool matches it, before you even open the app.

A rough framework, if you want one

If it helps to have something concrete, here's roughly how I decide:

• Am I not sure what I'm building yet? → Start with a sparring partner. Push on the idea until it either survives or falls apart.
• Do I know what I'm building, and does it require holding a lot of context across a real project? → Move to a tool built for depth and continuity.
• Am I already doing the work, and just need help keeping pace? → Use whatever lives inline, in the flow, with the least friction.

It's not a rigid rule, and there's plenty of overlap — any of these tools can do a decent job outside its "home" stage. But defaulting to this kind of routing has made my own work noticeably less frustrating, because I'm no longer expecting one tool to be everything at once.

The real competitive advantage

The future of AI probably isn't about picking one AI platform and becoming an expert in it. It's about building a toolbox and learning, almost instinctively, which tool to reach for depending on the job in front of you.

The real competitive advantage may not be having access to AI — at this point, most people do. It may be knowing which AI to use, when to use it, and how to move between them without losing momentum.

That's the part I'm still refining. But it's already changed how I work.

#ArtificialIntelligence #ChatGPT #ClaudeAI #GitHubCopilot #Leadership #SoftwareDevelopment #Technology

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

 

Building Your AI Toolbox: Why I Use Claude, ChatGPT, and GitHub Copilot Differently

There seems to be a constant debate happening around artificial intelligence: Which AI platform is the best?

Is it ChatGPT? Claude? GitHub Copilot? Something else?

I think we may be asking the wrong question.

I have spent most of my career working with technology, and one thing technology teaches you very quickly is that there is rarely one tool that is best at everything.

Think about the toolbox you have at home. You probably have screwdrivers, wrenches, sockets, pliers, hammers, drills, and dozens of other tools. Nobody opens that toolbox and asks, "Which one of these is the best tool?"

The answer would be obvious: It depends on what you're trying to accomplish.

I believe we should start thinking about AI the same way.

AI Is Becoming a Toolbox

Over time, I have found myself using Claude, ChatGPT, and GitHub Copilot differently.

There is certainly overlap between them. All three continue to evolve, and each can perform tasks that might traditionally be associated with another platform. But that doesn't mean they feel the same when you're actually working with them.

Each has developed strengths that make me reach for it in different situations.

Claude: When I Want to Build

Claude has become particularly interesting to me when it comes to software development.

When I have a coding project, existing codebase, technical problem, or something that needs to be built and iterated upon, Claude can be an extremely capable development partner.

What I find valuable isn't simply its ability to generate code. Writing code is only one part of software development.

Understanding an existing application, following dependencies, recognizing patterns, making changes without unnecessarily disturbing other parts of the system, troubleshooting problems, and iterating on a solution are often much more important.

That makes Claude interesting as more than a code generator. It can become part of the development environment itself.

For someone who understands technology but may not necessarily spend every day writing code, tools like this can also dramatically reduce the distance between having an idea and actually building something.

GitHub Copilot: AI Where Developers Already Work

GitHub Copilot approaches the problem from another direction. Instead of asking developers to leave their normal workflow and go somewhere else to interact with AI, Copilot brings AI directly into the development process.

That is an important distinction.

Developers already spend their days inside editors, repositories, pull requests, and development tools. Having AI available inside that environment makes it a natural companion.

It can assist with writing code, understanding unfamiliar code, generating tests, explaining functions, suggesting improvements, and handling some of the repetitive work developers deal with every day.

The value isn't necessarily replacing the developer. It's reducing friction.

A good power tool doesn't replace the carpenter. It allows the carpenter to accomplish more with the skills and experience they already have.

I see Copilot in much the same way.

ChatGPT: My Sparring Partner

My relationship with ChatGPT is somewhat different.

I certainly use ChatGPT for technical questions and coding. It is more than capable of helping in those areas. But where I personally find it particularly valuable is as a sparring partner for ideas.

Sometimes I don't need someone to give me an answer. I need something that helps me think.

I may start with a business problem, a technical strategy, a leadership challenge, an architecture decision, a product idea, or simply a half-formed thought. Then I start asking questions:

What am I missing? What assumptions am I making? What happens if we approach this differently? What are the risks? How would I explain this to an executive? How would I explain the same thing to an engineer? What would someone who disagrees with me say?

Those conversations can be incredibly valuable.

For me, ChatGPT becomes less of an answer engine and more of a thinking environment.

The AI doesn't have to make the decision. I still make the decision. But having something available that can challenge an idea, organize my thoughts, explore alternatives, and help turn a rough concept into something actionable can dramatically accelerate the thinking process.

The Tools Are Starting to Overlap

There is an important caveat to all of this: These categories are not permanent.

Claude can absolutely help with strategy and writing. ChatGPT can absolutely build and troubleshoot software. GitHub Copilot continues expanding beyond simple code completion.

The boundaries between these platforms will continue to move. Six months from now, I may use them differently than I do today.

And that's actually part of the point.

We shouldn't become so attached to a particular AI platform that we stop evaluating the tools available to us.

Technology changes. Our toolbox should change with it.

The Bigger Skill Is Knowing Which Tool to Use

For years, organizations have focused on teaching people individual technologies: learn this programming language, learn this database, learn this project management platform, learn this cloud environment.

Those skills still matter. But AI introduces another skill that I think will become increasingly important:

Tool selection.

The most effective AI users may not be the people who know the most prompts or subscribe to the most AI platforms. They may simply be the people who understand their problem well enough to choose the right tool for it.

Sometimes that might mean Claude. Sometimes GitHub Copilot. Sometimes ChatGPT.

And sometimes the best answer might be using all three during different stages of the same project.

Imagine starting with ChatGPT to challenge an idea and develop the requirements. Then moving into Claude to explore the implementation and work through the codebase. Then using GitHub Copilot alongside the development team as the solution is written, tested, reviewed, and maintained.

That isn't three competing AI platforms. That's a toolchain.

AI Doesn't Replace Experience. It Amplifies It.

There is another part of this conversation that I think sometimes gets lost.

AI can generate an impressive amount of information very quickly. But speed isn't the same thing as judgment.

Someone still has to recognize when an answer doesn't make sense. Someone still has to understand the business. Someone still has to recognize technical risk. Someone still has to understand customers, employees, budgets, deadlines, security, and all the other constraints that exist in the real world.

Experience provides that context.

AI can dramatically accelerate what an experienced person is capable of doing, but the person still needs to know where they're going.

A power tool in experienced hands can accomplish remarkable things. The same tool in inexperienced hands can create a remarkable mess.

AI isn't much different.

Stop Looking for the Winner

I don't believe there needs to be a winner between Claude, ChatGPT, GitHub Copilot, or whatever platform comes next.

Competition between these companies will continue, and that's a good thing. It will make the tools better. But as users, we don't have to participate in the rivalry.

We can simply use the best tool available for the job in front of us.

The screwdriver doesn't need to defeat the hammer. The socket wrench doesn't need to replace the drill. They simply need to be there when we need them.

That is how I increasingly think about artificial intelligence.

Build your AI toolbox. Learn what each tool does well. Understand where each one struggles. Experiment with how they work together.

And most importantly, don't become so focused on finding the "best AI" that you miss the larger opportunity.

The advantage isn't necessarily having access to artificial intelligence anymore. More and more people already have that.

The advantage will be knowing which tool to reach for, when to reach for it, and having the experience and judgment to know what to do with the result.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Claude's Computer Control Capabilities: Innovation, Risk, and Lessons from the Past

Anthropic recently introduced capabilities that allow Claude to interact directly with a computer, including opening applications, navigating websites, clicking buttons, entering information, and performing tasks on behalf of a user.

Having worked in technology leadership for more than 25 years, I have learned that every major innovation introduces new opportunities and new risks.

Before anyone accuses me of being opposed to artificial intelligence, let me be clear: I believe AI is transforming the way we work. These tools can improve productivity, reduce repetitive work, assist with troubleshooting, and help people accomplish tasks that once required considerable time and technical expertise.

However, history has also taught us that convenience often comes with a price. Organizations would be wise to understand the security risks before allowing an AI system to interact with their computers, applications, files, and administrative tools.

Haven't We Seen This Before?

For years, IT professionals have relied on Remote Desktop Protocol, better known as RDP, to access and manage computers remotely.

RDP was fast, convenient, and incredibly useful. It allowed employees to work from home, administrators to support servers from another location, and businesses to operate without requiring everyone to be physically present.

Then attackers learned how to exploit it.

Internet-exposed RDP services became a common entry point for ransomware attacks, unauthorized access, credential theft, and data breaches. Organizations spent years learning painful lessons about weak passwords, missing multi-factor authentication, excessive privileges, exposed network ports, and inadequate monitoring.

Today, most experienced IT professionals become immediately concerned when they discover that an RDP service has been directly exposed to the internet.

AI-powered computer control is not exactly the same as traditional RDP. It does not necessarily expose a Windows desktop or network port in the same manner.

However, it raises a similar and important question:

What happens when software can not only access a computer, but also interpret information, make decisions, and perform actions on behalf of the user?

That is where the conversation becomes more complicated.

The New Risk: Prompt Injection

Traditional software generally follows instructions written by its developers.

AI agents operate differently. They are designed to interpret natural language, review information, make decisions, and determine which actions should be taken next.

That flexibility is what makes them useful.

It is also what creates a new category of security risk.

Security researchers call one of these risks prompt injection.

Imagine an AI agent is asked to review a website, read an email, open a document, or analyze a PDF. Somewhere within that content, an attacker has inserted instructions intended specifically for the AI system.

Those instructions might tell the agent to ignore the user's original request, reveal sensitive information, open another website, download a file, modify a document, or perform some other unauthorized action.

The instructions may be visible, or they may be disguised within content that appears harmless to the person using the computer.

This creates a difficult problem. The AI must determine which information is legitimate content and which information is an attempt to manipulate its behavior.

Humans already struggle with phishing emails and social engineering attacks. AI agents may now face their own version of the same problem.

The concern is not simply that Claude, or any particular AI platform, is inherently insecure.

The greater concern is that AI agents introduce a new attack surface that businesses and security professionals are still learning how to manage.

Why Computer Control Changes the Risk

A chatbot that only answers questions has limited ability to cause direct harm.

An AI agent that can control a computer is different.

Depending on the permissions it has been given, an agent may be able to:

• Open applications
• Read documents and email
• Access cloud storage accounts
• Navigate internal business systems
• Enter or modify information
• Download and upload files
• Run scripts or terminal commands
• Interact with administrative tools
• Access remote management software
• Make changes using the user's credentials

The more access the agent receives, the greater the potential impact of a mistake, compromised account, malicious instruction, or successful prompt injection attack.

An AI system operating under an administrator's account could potentially have the same access as the administrator.

That is an enormous amount of trust to place in any tool.

The Lessons We Should Already Know

The technology industry has faced this problem before.

Remote monitoring and management platforms, remote access tools, service accounts, domain administrator credentials, and automation systems all provide tremendous value.

They also become extremely attractive targets because they have access to many systems at once.

History has repeatedly shown us that attackers often target the tools trusted to manage everything else.

We have seen serious security incidents involving remote access services, software management platforms, privileged accounts, and administrative utilities. In many cases, the problem was not that the tool had no legitimate purpose.

The problem was that it had broad access, insufficient restrictions, weak authentication, or inadequate monitoring.

The lesson is simple:

The more access a tool has, the more valuable it becomes to an attacker.

An AI agent with access to email, files, browsers, cloud platforms, source code repositories, or administrative systems should therefore be treated as a privileged technology platform, not merely as a convenient assistant.

Account Compromise Is Another Concern

Prompt injection is not the only risk.

Organizations must also consider what could happen if the user's AI account is compromised.

If an attacker obtains access to an account connected to a computer control session, the attacker may be able to misuse the permissions previously granted to the AI platform.

This is especially concerning when users reuse passwords, fail to enable multi-factor authentication, remain signed in on shared devices, or grant broad access without reviewing it later.

The risk becomes even greater when an AI account is connected to other services, including:

• Microsoft 365
• Google Workspace
• GitHub
• Cloud infrastructure
• Customer management systems
• Financial platforms
• Internal applications
• Corporate file shares
• Remote support tools

A compromised account may no longer provide access to just one service. It could become a gateway to several connected systems.

Human Approval Helps, but It Is Not Perfect

AI companies are introducing safeguards intended to reduce these risks.

Depending on the product and configuration, the system may require the user to approve sensitive actions, such as submitting a form, downloading a file, running a command, or accessing certain information.

These approval steps are important.

However, approval prompts only work when users understand what they are approving.

People are already accustomed to clicking "Allow," "Accept," "Continue," and "OK" without carefully reviewing the request. Over time, frequent approval prompts can become background noise.

An AI agent may ask permission to perform an action, but the user may not fully understand why the action is being requested or what the consequences could be.

Human approval should therefore be viewed as one layer of protection, not a complete security solution.

Does This Mean We Should Avoid AI Agents?

No.

AI agents have tremendous potential.

They may eventually help organizations perform routine troubleshooting, generate documentation, monitor systems, prepare reports, test software, manage repetitive processes, and reduce the burden placed on technical teams.

They may also make advanced technology more accessible to people who do not have traditional technical training.

The answer is not to reject innovation.

The answer is to introduce it carefully.

Businesses should avoid treating AI computer control as an ordinary consumer feature. It should be evaluated using the same security discipline applied to remote access tools, privileged accounts, automation platforms, and administrative software.

Practical Security Recommendations

Organizations considering AI-powered computer control should begin with several basic safeguards.

Require multi-factor authentication. Every account capable of controlling a computer or accessing connected business systems should require strong multi-factor authentication. A password alone should not be considered sufficient.

Follow the principle of least privilege. The AI agent should only receive the access necessary to complete the assigned task. It should not operate under a domain administrator, global administrator, root, or similarly privileged account unless there is a compelling and carefully controlled reason.

Separate everyday and administrative accounts. Users should not perform routine browsing, email, and document work while signed in with administrative credentials. The same separation should apply when using AI agents.

Require approval for sensitive actions. Actions involving software installation, command execution, credential access, financial transactions, security changes, file deletion, or external communication should require explicit human approval.

Restrict access to critical systems. AI agents should not automatically receive access to every server, client environment, cloud tenant, file share, or administrative console available to the user. Access should be limited by role and business need.

Maintain logs and review activity. Organizations should be able to determine what the agent accessed, what actions it attempted, what the user approved, and what changes were made. Logging is essential for accountability and incident investigation.

Review connected applications regularly. Permissions granted to AI platforms should be reviewed periodically. Connections that are no longer necessary should be removed.

Use isolated environments when possible. High risk or experimental tasks should be performed in a sandbox, virtual machine, test environment, or otherwise isolated system rather than on a primary workstation containing sensitive business information.

Train users to recognize AI-specific threats. Employees should understand that malicious instructions can appear inside websites, emails, documents, support tickets, source code, and other content reviewed by an AI agent. Users should be taught to question unexpected actions and unusual approval requests.

A Balanced Path Forward

Claude's computer control capabilities are impressive and may represent an important step forward in workplace productivity.

They may also change the way people interact with computers. Instead of manually opening applications, finding information, and completing each step, users may increasingly describe the desired outcome and allow an AI agent to perform the work.

That is a major shift.

It deserves serious consideration, not panic and not blind enthusiasm.

The security industry has repeatedly learned that powerful administrative capabilities must be introduced with strong authentication, limited permissions, effective monitoring, and clear accountability.

AI agents should be held to the same standard.

Organizations should begin cautiously, limit early use cases, monitor activity closely, and expand access only after they understand how the technology behaves within their environment.

Final Thoughts

Innovation has always required a degree of trust.

However, trust should never mean giving a new technology unrestricted access and simply hoping for the best.

The real question is not whether AI agents will become part of the modern workplace. They almost certainly will.

The more important question is whether organizations will apply the lessons learned from decades of remote access, privileged administration, automation, and cybersecurity, or whether those lessons will have to be learned again.

AI-powered computer control offers remarkable possibilities.

It also places more responsibility on technology leaders, security professionals, vendors, and users to understand what access is being granted and how that access could be misused.

Innovation is exciting. Security is what allows us to keep using it.

Thanks,

Michael Cronin

Website: https://www.michaelcronin.info
LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

The Story of Labor Day: A Holiday Built by Workers, Carried by Tradition

On a warm September morning in 1882, the streets of New York City were alive with an unusual energy. Workers, many in their union sashes and Sunday best, gathered with families and friends near City Hall. Bands struck up tunes, children waved flags, and crowds lined Broadway to watch what would become the first Labor Day parade.

 

That day, thousands marched shoulder to shoulder, not for protest or riot, but for recognition. They wanted the city, and the nation, to see the dignity in their labor and the strength of their unity. Some say the idea came from Matthew Maguire, a machinist and union secretary. Others insist it was Peter McGuire, a carpenter inspired by labor parades he had seen in Canada. To this day, no one is entirely sure who thought of it first. Let’s just call it the original “credit-stealing coworker” story.

 

From that spark, celebrations spread. States across the country began setting aside their own labor days. By the early 1890s, the holiday had taken root in the American calendar. In 1894, amid the turmoil of the Pullman Strike, President Grover Cleveland signed it into law: the first Monday in September would be a national holiday. Not just a day off, but a day to honor the men and women whose sweat and determination built the roads, the railways, the factories, and the very backbone of America. And yes, you can thank them for the reason you don’t have to explain to your boss why you are “working from home” on the first Monday of September.

 

Over the decades that followed, Labor Day grew into more than parades and speeches. It became family picnics, neighborhood festivals, and backyard barbecues. It became the last sweet taste of summer before the school year began. And yet, beneath all of that, the meaning has remained steady. This holiday is a reminder that the 40-hour workweek, fair wages, safe conditions, and the right to rest were all won through the persistence of workers who believed their contributions deserved dignity. So next time you clock out at 5 p.m. sharp, you can raise a toast to those folks.

 

Today, work looks very different. Some of us build with our hands, others with our minds. Some work on factory floors, others in digital spaces where the “reply all” button is the most dangerous tool of all. But the spirit of Labor Day calls us to the same truth: every effort matters, every role builds something greater than itself. Just as the laborers of the 19th century fought for balance and fairness, so too must we shape the future of work, whether it is ensuring flexibility, protecting well-being, or embracing new tools like technology and AI in ways that lift people rather than replace them.

 

So this Labor Day, as we gather with family and friends, let us carry forward the story begun on that September morning in 1882. It is a story of unity, dignity, and progress, and it is still being written one paycheck, one coffee break, and one backyard burger at a time.

 

Experience, Perspective, and Energy: What Sets Me Apart

Experience, Perspective, and Energy: What Sets Me Apart

When companies look to hire technology leaders, they often search for two things: experience and energy. Finding both in the same person is rare.

 

Over the past 26 years, I’ve built a career that spans system administration, product ownership, and IT leadership. Each role gave me a different lens on technology, business, and people. Together, they formed a perspective that is hard to duplicate.

 

What makes this unique is not just the depth of experience, but the way those roles connect. I know what it feels like to keep servers alive at 2 a.m. I know how to translate business needs into features that developers can deliver. I’ve balanced long-term technical decisions against short-term business pressures. And I’ve led teams where success depended not on my individual output, but on how well others thrived.

 

And while I am not young, my energy often outpaces those who are. That drive doesn’t come from energy drinks or bottomless coffee pots. It comes from passion. I love what I do, and that enthusiasm fuels every conversation, every project, and every challenge I take on.

 

For organizations, that combination matters. It means hiring someone who brings the wisdom of experience, the perspective of multiple roles, and the energy of someone who is still excited to build, lead, and deliver. In a market where depth and passion are both rare, I bring both to the table.

 

Let’s Connect

If you’d like to learn more, you can reach me at www.michaelcronin.info or call me directly at 210-347-1397.

 

From System Administrator to IT Director: Four Roles, Four Perspectives

From System Administrator to IT Director: A Career Told Through Four Roles

I didn’t set out to become a technology leader. In fact, my first role was simply about keeping the lights on. Over the past 26 years, my career has taken me from server rooms to board rooms, from chasing down cables to aligning entire organizations. Along the way, four roles shaped how I think about technology and leadership: system administrator, development product owner, technical product owner, and director of IT.

 

System Administrator: Where It All Began

I can still remember the long nights spent in server rooms, listening to the hum of machines while I tried to figure out why something wasn’t working. As a system administrator, every day was about solving problems as quickly as possible. Servers had to stay up. Networks had to stay secure. Users needed help, often at the worst possible times.

That role taught me one of the most important lessons of my career: reliability is everything. If technology doesn’t work, nothing else matters. Those years gave me discipline, attention to detail, and a respect for the often invisible work that keeps businesses running.

 

Development Product Owner: Learning to Listen

Eventually, I moved out of the server room and into meeting rooms. As a development product owner, my job was no longer fixing systems but listening to people. I had to understand what the business needed and translate that into stories and features for developers.

This was a shift in perspective. I couldn’t solve every problem by myself anymore. My role was to ensure we were solving the right problems. It meant balancing priorities, budgets, and timelines while earning trust on both sides of the table. More than anything, I learned the value of listening.

 

Technical Product Owner: Speaking Two Languages

Taking on the technical product owner role felt like standing with one foot in each world. On one side were the business leaders, focused on strategy and outcomes. On the other side were the engineers, focused on architecture, APIs, and code. My job was to translate between the two without losing meaning.

It wasn’t always easy. Every decision carried long-term consequences. Every innovation had to be weighed against stability. I learned that owning a product meant more than writing a roadmap. It meant owning the responsibility for its health and direction long after the initial launch.

 

Director of IT: Leading with Purpose

When I became a director of IT, the scope widened again. Suddenly, I wasn’t just responsible for systems or products. I was responsible for people. Teams looked to me for guidance, vendors looked to me for decisions, and executives looked to me for strategy.

This role taught me that leadership is not about being the smartest person in the room. It’s about creating an environment where other people can succeed. My success started to be measured not in how many problems I solved personally but in how well the team could operate without me.

 

Looking Back

Each of these roles gave me something I carry with me today. From the system administrator, I learned the importance of reliability. From the development product owner, the value of listening. From the technical product owner, the need to balance vision with reality. And from the director of IT, the responsibility of leadership.

Together, they shaped more than a career. They shaped a perspective: technology only succeeds when people, process, and purpose are working together.

 

Seeing the Forest Through the Trees: Product Leadership in a Small Business

In small businesses, product leadership isn’t just about having the roadmap. It’s about seeing the whole landscape, the forest, while also knowing when to zoom in and pull weeds.

 

Most days, I’m the person in the room asking, “Are we solving the right problem?” while also mapping out how we’ll get the fix deployed without blowing up the sprint. I’ve worn the title of VP of IT, Product Manager, Business Analyst, and sometimes just the guy who gets it done. The titles may change, but the core responsibility stays the same: drive clarity, keep the product aligned to the business, and don’t lose sight of the big picture.

 

Here’s how I navigate that balance in the kind of small teams where everyone wears a few hats and the stakes are real.

 

1. Translate vision into action
   Product leadership in a small business starts by understanding what the business is really trying to achieve. That doesn’t always come through cleanly in requirements or Jira tickets. It often shows up in hallway conversations, customer feedback, or an offhand comment from the CEO.
   
   My job is to distill that into a plan, not just a feature list, but a sequence of moves that make sense technically, tactically, and financially. I help teams turn “we need automation” into “let’s streamline claim assignment logic based on operating hours and carrier needs.”

 

2. Connect the dots others don’t see
   When you're close to both the business and the tech, you spot patterns early. A confusing customer workflow might actually be the result of a decade-old product assumption. A slow dev cycle might trace back to outdated deployment practices.   This is where product leadership really shines, pulling together different inputs and recognizing the upstream or downstream impact. It's about pattern recognition, not just backlog grooming.

 

3. Protect the path forward
   In a small shop, it's easy to get buried in daily fires. Bug here, blocker there, someone needs help resetting a password. But I carve out time to ask “where are we going?” and “are we still on track?” Even if it’s just an hour a week, I revisit the roadmap, double-check priorities, and make sure we haven’t let the urgent crowd out the important. This discipline keeps the team moving with purpose instead of just surviving the day.

 

4. Talk to people, not just roles
   You can’t lead products effectively without talking to the humans behind the job titles. That means spending time with customer support, sales, QA, and developers, not just in meetings, but in real conversations. What’s hard right now? What’s changing? These chats are gold. They often reveal friction points, new opportunities, or small wins worth scaling. It’s also how you build trust, which makes everything else easier.

 

5. Make the complex feel simple
   Good product leaders make hard things easier to understand. Whether I’m presenting to execs, coaching a developer through business logic, or helping a customer understand how a feature works, my job is to cut through the noise and communicate clearly. If the room is confused, progress stalls. But when everyone understands the what and the why, the how tends to follow.

 

Final Thoughts

In large organizations, product leadership can mean steering massive roadmaps or aligning siloed teams. In small businesses, it’s more intimate and more personal. You’re close to the work, the people, and the impact. You don’t have layers of abstraction, but you also don’t have as much room for error.

 

Seeing the forest through the trees is a constant exercise. But when you get it right, you’re not just building features. You’re building focus, momentum, and a product that truly supports the business.

 

About the Author

Michael Cronin brings over 30 years of IT experience and 16 years of product and software leadership to his role as VP of IT and Software Development at Claimatic. A hands-on, forward-thinking strategist, he specializes in helping small businesses translate complex needs into clear roadmaps and reliable products. Michael works with companies to realign their IT and product strategies for long-term success.