TL;DR

Why nobody cares (and why it’s normal)

Usually, people are not ignoring you because your idea is bad. They’re ignoring you because they’re busy and risk-averse and measured on outcomes that do not always align with how exciting you think your idea is. In their head, your idea lives as “the thing inside one self-contained story” while in their head it’s “an unqualified change request to compete with 100 other issues.”

Selling someone an idea is mostly translating and de-risking – translating your concept into a result of their benefit, and reducing the perceived cost of being wrong.

If your idea touches anything that is regulated (health, finance, employment, safety, privacy), then read this article for informational purposes only. In those cases, solicit expert help from qualified professionals (legal, compliance, security) very early in your pitch so that it doesn’t die of “unknown risk”

Step 1 – Convert “my idea” to “there win”

People buy improvement to their current reality – not your intelligence. Take your idea and rewrite it using the language of outcomes. The best outcome statements are measurable or at least observable.

Use the 4-outcome filter

  1. Write your idea in one plain sentence (no jargon, no buzzwords).
  2. Add the “so that…” outcome: “I want to build X so that Y happens.”
  3. Quantify Y with a range if you can (even a conservative estimate).
  4. List the top 3 assumptions required for Y to be true.
  5. Decide how you could test each assumption in under 2 weeks.

Step 2: Find the real buyer (not the nicest listener)

Ideas die more often because they’re pitched to the wrong person than for any other reason. A buyer is someone who (a) has the problem, (b) can mobilize resources, and (c) faces consequences if the problem stays unsolved. Nice listeners are not buyers.

Map stakeholders in 10 minutes

Stakeholder Mapping Table
Role What they care about How they measure it What they fear Message that lands
Economic buyer (budget owner) ROI, priorities, timing Margin, growth targets, budget cycle Wasted spend, reputational hit “Low-cost pilot with clear ROI gates.”
Champion (daily pain owner) Relief, speed, fewer fires Time-to-complete, backlog, escalations Extra work, tool fatigue “We’ll remove X steps and keep your workflow.”
Blocker (risk/compliance/security) Safety, policies, liability Audit readiness, incident rate Unknowns, shadow IT “Controls, logs, and an approval path built-in.”
User (hands-on) Ease, reliability Clicks, errors, time saved Change, learning curve “Looks familiar; training is 30 minutes.”

If you don’t yet know the identity of the economic buyer, seek a champion with both strong organizational credibility and urgent pain. Your first “sale” will often be just convincing someone else to co-own the pitch and get you a budget.

Step 3: De-risk your idea with fast validation (before you ask for big commitments)

The quickest path to getting people to care is to show them evidence of your idea working, or being desired—without asking them to bet on a whole build, big budget, or leap of faith.

Step 4: Choose one validation path (choose the cheapest one that mitigates your biggest risk)

For your first proof, focus on one path. The more narrow your path, the cheaper your test will be.

Your options:

  1. Pick just one primary risk: desirability (do they want it?), feasibility (can we build it?), or viability (will it pay off?).
  2. Design a test that produces a number or a clear “go/no-go signal” (a quote like “7 of 10 said they’d switch this quarter”, or “20% clicked ‘Request access’”).
  3. Time-box it: 7 to 14 days max. More than 2 weeks, and you’re doing “a project,” not a proof, and your fire loses much of its heat.
  4. Agree on success thresholds before you run the test (so you aren’t tempted to rationalize weak results).
  5. Capture proof artifacts: screenshots, quotes, baseline metrics, & a one-pager summary.
Common trap: building a big demo to “prove it.” A big demo proves you can build a demo, not that anyone wants the outcome, or wants to put down their real stakeholder money to get it.

Proof that people want it: “10 people asked me to add this feature”, “3 teams asked me to add this feature to help with their pilots / trials”.

Proof that it actually accomplishes the intended outcome: “In this concierge run, we helped reduce onboarding time from 45 minutes to 20 minutes.”

“Authority” proof that decrees this is OK to build: have a real internal champion for this thing. Preferably a leader who sponsors this directly. Or, bring a FLOSS guru in with a clear reputation and track record.

Proof that this is feasible to build: spike into a small technical POC of the thing, a basic integration plan to see if it holds up, or even outline exactly how security reviews would be run.

Proof that this can be undone if necessary: Look at landscape and be willing to define a black-box that limits this change, at least until you know for sure you won’t roll it back. If needed, peg some other condition to define reversal criteria.

Make a one page “decision memo”

Write a one page decision memo. You appear smart and strategic when you do this. For a high-impact or expensive decision, especially, you might pick up some major credibility and stands a good chance of getting buy-in, since it rides the thinking pre-sell coattails from your memo. It basically has the same components as a business case, but in a smaller space.

Make the pitch easy for others to rewrite accurately

If I cannot repeat the contents of that pitch in the hallway then it will not survive either of us through the future.
Think of a pitch format that is short, specific, and that I can count on and trust from you to repeat accurately, even if you are not present at the time! Ride the (P-I-P-P-A) technique.

(P-I-P-P-A) (Problem –> Impact –> Proof –> Plan –> Ask)

A pitch is not a tour of your idea.

Step 6: Run the sales conversation (even if you hate “sales”)

Asking questions and listening is selling your idea. You’re not here to win a debate; you’re here to discover a fit, and come to mutual agreement on the next step.

Discovery questions that uncover “yes” conditions

A simple meeting flow you can reuse

  1. Set frame (60 seconds): “I’d like to understand your priorities a little more and see if a small pilot is worth it.”
  2. Ask 3-5 discovery questions (10 min).
  3. Reflect back what you heard (2 minutes): “It sounds like X is causing Y, and the biggest constraint is Z…”
  4. Share the P-I-P-P-A pitch (3-5min).
  5. Talk about risks and constraints 5-10 min.
  6. “Close with a next step and owner (2 minutes): schedule the decision meeting, confirm pilot criteria, or agree on a smaller validation test.

Step 7: Handle objections without getting defensive

Objections are often unspoken requirements. Treat them as missing information. Your job is to clarify what would make the risk acceptable—or to discover that this isn’t the right time or buyer.

Objection handling: response patterns that keep trust

Objection Handling Patterns
Objection What it usually means A strong response
We don’t have time. Not a priority, or unclear ROI “What would need to be true for this to become worth time? If we could save X hours/week, would that change it?”
We tried something like that before. Skepticism from past failure “What specifically failed—adoption, results, or implementation? Let’s design a pilot that avoids that failure mode.”
This feels risky. Unknowns and accountability fear “Totally fair. Let’s scope a reversible test: limited users, clear stop conditions, and a rollback plan.”
We already have a tool for that. Status quo inertia “What’s the gap between what the tool promises and what you experience? If the current tool was working, would this pain exist?”
Budget is tight. Competing priorities “Can we start with a no/low-cost pilot or shift cost to savings? What budget cycle would this fit?”

The 3-step objection method: Acknowledge → Clarify → De-risk

  1. Acknowledge: “That makes sense.” (Don’t argue first.)
  2. Clarify: “When you say risky, do you mean security, adoption, or opportunity cost?”
  3. De-risk: “Here’s how we can test that risk cheaply and reverse it if needed.”

Step 8: Close with a specific ask (and make the decision easy)

Most ideas fail because they end with a vague ending: “Thoughts?” “Feedback?” “What do you think?” You need a close that produces movement—even if the answer is “not now.”

Pick one close (use the smallest commitment that still creates progress)

A strong close includes: scope, timeline, success criteria, and who owns what. The easier you make it to say yes without career risk, the more likely you’ll get traction.

Step 9: Follow up like a pro (and avoid “ghosting”)

People don’t ghost because they hate your idea. They ghost because the next step is fuzzy, your meeting notes are fuzzy, or some other fire came up. Your follow-up should make it easier and clearer to keep going.

Follow-up email template (copy/paste)

Subject: Next step on [Outcome]
Thanks again for your time today. Here’s what I heard:

  • Current situation: [1-2 bullets]
  • Impact: [metric/time/risk]
  • Constraints: [security, timeline, dependencies]

Proposal:

  • Pilot scope: [who/what]
  • Timeline: [start-end]
  • Success metrics: [metric 1], [metric 2]
  • Stop/go decision: [date]

Ask: Can you confirm (1) whether these success metrics are right, and (2) who else should join a 30-minute decision meeting? I’m available [2-3 options].
Best, [Name]

Common mistakes that make good ideas unsellable

Ethics note: Don’t trick numbers, mystify risks, or arm-twist stakeholders. Long-term trust is your biggest sales leverage—especially when selling ideas inside the company.

Quick checklist: Sell your idea in 7 days (practical sprint)

  1. Day 1: Write the outcome statement (one sentence) + find 3 key assumptions.
  2. Day 2: Stakeholder map (buyer, champion, blocker, users) and choose your target.
  3. Day 3: 3–5 problem interviews; write down the exact phrases people use.
  4. Day 4: Write up your lightweight test (fake door, prototype, concierge) +define thresholds for success.
  5. Day 5: Run the test and find at least 1 measure (clicks, signups, time saved, errors reduced).
  6. Day 6: Write a one-pager (decision memo) and then draft your P-I-P-P-A pitch.
  7. Day 7: Run a meeting and close on an outcome (a pilot decision meeting, or smaller validation).

FAQ

My idea is too early for proof – how do I sell that?

Sell a smaller decision first. Instead of “fund the build,” pitch: “approve a 2-week test.” Your first sale is buying permission to learn with a time-boxed experiment and clear thresholds for success.

I’m not senior – how do I sell an idea at work?

Identify a credible champion, and propose a low-risk pilot. Bring a one-page memo with outcomes, proof, from interviews, and a reversible plan. Make your manager’s life easier: show how it furthers team goals and how you’ll measure success.

I don’t know the prices or ROI – how do I sell that?

Use ranges and transparently write down your assumptions. Start with time saved (hours/week x fully loaded cost) or error reduction (incidents/month x estimated impact). Clearly mark what you do know vs. what you’re estimating. Suggest a light pilot to measure the real numbers.

They say they like it but nothing happens — how do I sell it?

Stop measuring compliments and start measuring commitments. Ask for a next step: pilot participants, access to data, calendar invite with the budget owner, or paid pilot/LOI. If they won’t commit to anything small, the pain may not be urgent.

I don’t want to be pushy – how do I sell it?

Politely ask what you’re asking for, and make it safe to say no. “If this isn’t a priority this quarter, that’s okay—what timing would be right and what would need to change for it to matter?” Clarity feels professional, not pushy.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *