How to propose new software to your manager

The fastest way to get a software proposal shut down is to open with the tool. Managers react to tool pitches the way they react to unsolicited sales calls: politely, briefly, then no. The way to get a real conversation is to lead with a problem your manager already agrees is expensive, show you have thought through procurement and security, frame the ask as a low-risk pilot, and name the tool only after they are already asking what to try.

This playbook applies to any software category. If you are proposing a knowledge management tool specifically, pair this with the business case template for a knowledge management tool.

Step 1: Build the problem, not the tool

Before you mention a product, make sure your manager sees the problem the same way you do. Two questions:

1. Does my manager already agree this is a problem?
2. Do they agree it is costing real money, time, or morale?

If the answer to either is no, your job is not to pitch a tool; it is to make the problem visible. Send two short examples over two weeks: “Here is the third time this month we re-decided X.” “Here is a new hire asking a question we have answered four times.” Do not mention a solution. You are seeding the problem statement.

Most managers do not need convincing that knowledge is lost. They need proof it is happening on their team, this quarter, at a cost.

Step 2: Quantify the pain

Once the problem is visible, put a number on it. Your manager does not need a precise figure; they need a defensible range.

Pick one cost and one source:

• “Employees lose 5.3 hours a week looking for information or recreating it.” (Panopto, Workplace Knowledge and Productivity Report, 2018)
• Multiply by your team size, hours worked per year, and a conservative fully-loaded cost.

Put one sentence in bold: “At our current team size, this is roughly $X per year.” That is the sentence your manager will repeat to their own boss.

For a full calculation, see the ROI calculator for AI knowledge tools.

Step 3: Pre-empt the three objections

Every software proposal gets the same three pushbacks. Handle all three before they are raised.

”Procurement will not approve it”

Show your manager you have thought about procurement before they do. Two answers usually defuse this:

• “The vendor has a free tier or trial, so a pilot does not need procurement approval.”
• “If the pilot works, the annual cost is within your discretionary budget (or under our procurement threshold).”

If you are proposing a tool that requires SSO, a security review, or a data processing agreement, say so up front. Do not pretend the procurement work does not exist.

”Security will not approve it”

For anything that touches meeting transcripts, email, or customer data, your manager’s first instinct is security. Anticipate it:

• Name the vendor’s security posture (SOC 2, ISO 27001, encryption in transit and at rest, SSO).
• Identify whether the pilot will touch regulated data (PII, PHI, customer contracts).
• Offer to scope the pilot to non-sensitive data first.

You do not need a full security review on day one. You need enough to show the question is not new to you.

”We already have Notion / Confluence / a wiki”

This kills most knowledge tool pitches. The answer is not “Notion is bad.” The answer is to explain what the existing tool does not do.

• “Notion stores pages people write. It does not capture what was decided in a Zoom meeting nobody wrote up.”
• “Our wiki has not been updated since Q1. The question is not ‘should we have a wiki?’, it is ‘should a decision made in a meeting be automatically captured and findable?’”

Mocking Notion or Confluence will make your manager defensive. Describe the gap specifically.

Step 4: Frame the ask as a pilot, not a purchase

Managers approve pilots they can kill. They hesitate to approve purchases.

A good pilot has four elements:

• Small scope. One team.
• Short duration. Four to six weeks.
• Defined success metric. One or two measurable outcomes agreed up front.
• Clean exit. If it fails, the team stops using it. No lock-in.

Ending a pilot cleanly is a feature, not a failure. The sentence that usually closes the approval: “If after six weeks we cannot point to the two metrics we agreed on, we stop.”

Step 5: Name the tool (at the end)

By the time you name the tool, your manager should already be asking “okay, so what do you want to try?” Only then do you name it.

When you do, keep it short:

• Two sentences on what the tool does in plain language.
• One sentence on the specific capability that addresses the problem you built.
• The trial link.

Example, for an AI knowledge tool: “Internode turns meetings, calls, and chat into a searchable record of decisions, tasks, and context. The chat agent answers ‘what did we decide about X?’ and proposes task updates we approve before they take effect, with two-way sync to Linear or Jira. Here is the trial.”

Step 6: Acknowledge your own risk

Propose the tool knowing it might not work. The career risk is real, and avoiding it by never proposing anything is its own cost.

Two things limit the downside:

• A clean fail condition. If the pilot ends, you end it. You are not stuck defending a bad tool.
• The proposal itself, done well, is a piece of work your manager will remember. A thoughtful proposal with clear math, a pilot scope, and pre-empted objections is a promotion-level artifact even if the tool is rejected.

If you are unsure whether your team has the kind of problem that warrants this, start with how to tell if your team has a knowledge management problem.

Sources

• Panopto, “Workplace Knowledge and Productivity Report” (2018), source of the 5.3-hours-a-week figure used in Step 2: panopto.com/resource/valuing-workplace-knowledge/
• McKinsey Global Institute, “The social economy: Unlocking value and productivity through social technologies” (July 2012), for the complementary 1.8-hours-a-day estimate: mckinsey.com/industries/technology-media-and-telecommunications/our-insights/the-social-economy