The most useful thing a COO can know about software is not which brand to buy. It is which categories of tool a well-run operation needs, what each one is actually for, and how to buy them without ending up with forty overlapping subscriptions nobody uses.

Vendors change. A product that leads its category this year can be acquired, repriced, or overtaken next. So this guide talks in categories, not brand names. Learn the category and you can evaluate any product inside it, switch when the fit breaks, and avoid being sold a logo instead of a solution — and keep the stack from sprawling into dozens of disconnected logins.

Think in categories, not brand names

A common mistake is to treat a tech stack as a shopping list of famous products. That framing puts the COO in the weakest position: reacting to sales demos, buying the tool with the best marketing, and finding out later that three departments bought three tools that do the same thing.

The stronger frame is a small set of jobs the operation needs software to do, and one deliberate choice per job. Strong is a leader who can say "we run on a system of record, a work-management layer, an analytics layer, an automation layer, a collaboration layer, and a security layer — here is the one tool doing each, and here is what would make us switch." Weak is a spreadsheet of 34 SaaS logins with no owner and no map of what connects to what. You do not need to pick the exact product yourself; you need to own the categories, the budget, and the standard each tool must meet. For the sequencing view — which layer to buy first as you scale — pair this with the tech stack blueprint for growing operations: this article is the map of the territory, that one is the build order.

The system of record: ERP and core operational data

This is the category everything else leans on. The system of record — usually an ERP, sometimes a lighter finance-plus-inventory tool for smaller firms — holds the single agreed version of your money, orders, inventory, and often HR — the source you return to when two reports disagree. Strong is when finance, operations, and the warehouse all pull the same numbers and nobody keeps a shadow spreadsheet. Weak is when the "real" inventory count lives in someone's Excel file because entering data into the ERP is painful.

Choose one from your transaction volume and reporting obligations, not the feature list — a firm doing a few thousand orders a month has very different needs from a two-plant manufacturer. Insist on a real data-migration plan before you sign, because most ERP failures are migration failures, not software failures, and budget the project in months, not weeks.

Work management: project and process tools

This category is where actual work gets tracked — projects, tasks, tickets, and the handoffs between teams. It describes what people are doing, not what the business owns. The trap: a work-management tool is not a substitute for a documented process; if your handoffs are undefined, a shiny board just makes the chaos colourful. Strong is every recurring workflow having a template, a clear owner per stage, and a bottleneck you can point at. Weak is tasks with no owner, three tools competing (one team on boards, one in email, one in chat), and a status only its creator understands.

The move that works: standardise one tool per team for one job, write down the actual steps and owners first, then wire the tool to that process. The tool makes an already-clear process faster; it cannot invent the process for you.

Business intelligence and the analytics layer

BI turns the raw data in your systems of record into dashboards and answers. For a COO it is the visibility layer: managing by evidence instead of anecdote. Strong is a small number of trusted dashboards a leadership team actually opens in a meeting, built on agreed definitions (everyone means the same thing by "active customer" or "on-time delivery"). Weak is a graveyard of dashboards nobody trusts, because two disagree and no one knows which is right. The failure is almost never the BI tool — it is undefined metrics and messy source data.

So fix the definitions before you buy the visualisation: agree what each metric means, where it comes from, and who owns it, then wire up the charts. This is the heart of running operations on data rather than opinion — a cheap BI tool on clean data beats an expensive one on a swamp.

Automation: RPA, iPaaS, and workflow glue

Three jobs live under "automation": robotic process automation (RPA) mimics a human clicking through screens for repetitive tasks; integration platforms (iPaaS) move data between systems through proper connections; lightweight workflow tools chain triggers and actions across apps. Strong is automating a stable, high-volume process — the same task, the same way, hundreds of times a week — after you have already simplified it. Weak is automating a broken process (which just produces errors faster) or a fragile web of automations no one documented, that breaks silently when a source system updates.

The rule that saves you: never automate a process you have not first cleaned up. Map it, cut the unnecessary steps, then automate what remains — the improve-then-automate sequencing at the core of any serious process automation guide. Treat automations like software: give each one an owner, a name, and a note of what breaks it, or you accumulate invisible dependencies.

Communication and collaboration

This is the most-adopted and least-thought-about category: chat, video, shared documents, and e-signature. Everyone has it, so leaders rarely treat it as a decision — a mistake, because these tools quietly set the rhythm of how the organisation works. Strong is clear norms (what belongs in chat versus a document versus a meeting) and a deliberate choice about how much of the day is synchronous. Weak is permanent notification overload, decisions buried in chat history, and five copies of the same document with no canonical version. The tool is rarely the problem; the missing agreement about how to use it is.

Pick one primary tool per job — one for chat, one for video, one for documents — and write down the norms for each. This matters double for distributed teams, where a chat app that is fine in an office becomes round-the-clock noise unless the tool and the working agreement are designed together.

Security, identity, and compliance tooling

The category most likely to be underfunded until something goes wrong. It covers identity and access (who can log into what), data protection, and the audit trails your industry's regulations require. Strong is single sign-on across your major tools, access granted by role and removed the day someone leaves, and a clear record of who touched what. Weak is shared passwords, ex-employees with live logins for months, and no idea which tools hold sensitive data. As the stack grows, so does the security surface — every new tool is another door.

Make identity the backbone: route your major applications through single sign-on so access is managed in one place, then apply least-privilege so people get exactly the access their role needs. The full discipline sits in a proper cybersecurity and data-protection handbook; the COO's job is to fund it before an incident forces the issue, not after.

A category map

Use this as the one-page view: the job each category does, the question to ask before you buy, and the signal that you have outgrown what you have.

How to evaluate a tool without getting sold

Once you know the category, buying inside it becomes a repeatable drill. Run the same four checks every time. First, define the job in one sentence before you take a single demo, so the vendor answers your question rather than reframing it around their strengths. Second, insist on integration reality — ask exactly how it connects to your system of record and identity provider, because a tool that cannot connect becomes another island. Third, run a real pilot with real data and a small team, and judge adoption, not features: a tool people quietly refuse to use is a failed purchase. Fourth, agree the exit before you enter — how you get your data out — so you are never trapped by a tool you have outgrown.

None of this needs deep technical expertise — just the discipline to buy the fit, not the logo. Negotiation and renewal are their own skill, covered in a dedicated vendor management guide, and where a COO recovers real money.

Avoiding tool sprawl

Sprawl is the default state of a growing company's stack, because buying a new tool is easy and retiring an old one is nobody's job. Left alone, you pay for overlapping tools, none fully adopted, all of them a security surface. The fix is a standing habit: keep a single inventory of every tool, its owner, its cost, and the job it does — if two claim the same job, one has to go. Review licences against actual usage on a schedule, because you are almost always paying for seats no one uses. And set a one-in-one-out rule so a new tool in an occupied category replaces the incumbent rather than joining it. This is where software cost quietly balloons, which is why the stack belongs in your regular cost-optimisation review, not treated as fixed overhead.

Key takeaways

• Own the categories, not the brand names — vendors change, but the jobs software has to do stay stable, and a category lets you evaluate any product inside it.
• The system of record is the foundation; most ERP failures are migration failures, so demand a migration plan before you sign.
• A work-management or automation tool cannot fix an undefined process — clean up the process first, then buy the tool to make it faster.
• Trusted BI depends on agreed metric definitions and clean source data far more than on the visualisation tool you pick.
• Security and identity are the most under-funded category; make single sign-on and least-privilege access the backbone before an incident forces it.
• Fight sprawl with a living inventory, scheduled licence reviews, and a one-in-one-out rule for occupied categories.

Frequently asked questions

Does a COO need to be technical to own the tech stack? No. The job is to own the categories, the budget, and the standard each tool must meet — not to configure the software. You should be able to name the categories your operation depends on, say which tool does each job, and explain what would make you switch. Leave implementation to technical owners and keep the strategic map for yourself. How is this different from a tech stack blueprint? This article is the map of the territory — the categories operations rely on and how to judge any tool inside each. A blueprint is the build order: which layer to buy first as you scale and how the pieces connect. Use this to understand the landscape, then the blueprint to sequence your buying decisions. Should we buy one all-in-one suite or best-of-breed tools? It depends on your size and how unusual your operations are. An integrated suite reduces the connections you maintain and is often right for a smaller, standard operation. Best-of-breed gives you the strongest tool in each category but leaves you to wire them together. Decide on your integration capacity and how specialised each job really is — not on which sounds more advanced. Where should a COO start if the current stack is a mess? Map what you already have against the six categories; you will usually find gaps in some and duplication in others. Fix the system of record and the metric definitions first, because everything else reads from them. Only then tackle the rest. Cleaning up almost always beats buying anything new.