# How to Get Executive Buy-In for an IoT Project

> Why technology pitches for IoT stall at the executive level, and how to rebuild the pitch around one metric, a three-year cost, a pilot, and a phone demo.

![How to Get Executive Buy-In for an IoT Project](https://tago.io/og/blog/how-to-get-executive-buy-in-for-an-iot-project.png)

If you are trying to get an IoT project funded inside your company, you probably know the technology well. You have picked the sensors, tested the LoRaWAN coverage, maybe built a dashboard on a free account over a weekend. The pitch reflects that work: architecture slide, device list, connectivity options, a screenshot of live data. Everyone nods.

Then nothing happens. The feedback is some version of "interesting, come back next quarter," and next quarter the same slides get the same nods. The project is never rejected and never approved, which is worse, because a rejection tells you what to fix.

The problem is rarely the executive. Executives approve budgets against a business problem they already recognize, a number they can put in a plan, and a risk they can bound. A technology pitch gives them none of those. It asks them to translate sensors into savings on their own, in a meeting, with people watching. Most will not, so they defer.

The fix is to build the pitch backwards from what they need before they can say yes.

![Two ways to pitch the same IoT project: the technology pitch stacks sensors, network, platform, and a dashboard screenshot and ends in come back next quarter, while the executive pitch stacks one metric they already track, cost over three years, a pilot with a kill criterion, and a decision date, and ends approved](https://tago.io/images/blog/how-to-get-executive-buy-in-for-an-iot-project/technology-pitch-vs-executive-pitch.svg)

## Start from one metric the executive already tracks

Every executive has a short list of numbers they look at weekly: unplanned downtime hours, energy cost per site, spoilage rate, truck rolls per month, overtime hours. Your pitch should attach to exactly one of them.

The temptation is to list every benefit the sensors could deliver, because it feels like a stronger case. It is a weaker one: six benefits means six numbers the executive has to believe, and the weakest drags down the rest. One metric, with a current value they already agree on and a target you can defend, is something they can repeat to their own boss in a sentence.

Pick the metric by asking, not guessing. Twenty minutes with the operations lead about what gets them called at night usually surfaces it. If the sensors do not move any number the executive tracks, better to learn that before spending the political capital.

## Show three years of cost, not the first invoice

The second thing an executive needs is a number that will not embarrass them later. IoT projects are notorious for a small year-one budget followed by surprises: connectivity fees per device, replacement hardware, the engineer's time nobody costed, integration work when the ERP team gets involved. The [true cost of a mid-market IoT deployment](https://tago.io/blog/true-cost-of-a-mid-market-iot-deployment) is well documented, and most executives have been burned by the same pattern in some other project.

Put a three-year total on one slide: hardware and installation, connectivity, platform, and the internal time to run it. Say which lines are estimates and how wide the range is. "Roughly $140k over three years, with the platform line varying by device count" beats a precise $38k year-one figure everyone in the room suspects is incomplete. The [three-year pricing comparison](https://tago.io/blog/comparing-iot-platform-pricing-over-three-years) shows how platform costs behave as device counts grow.

Then put the metric next to that number. If downtime costs $9k per hour and the target is eight fewer hours per year, the executive can do the arithmetic without your help. The moment they do the math themselves is usually when the tone of the meeting changes.

## Propose a pilot with a kill criterion and a date

Executives are less afraid of spending money than of spending it on something that cannot be stopped. An open-ended "phase one" reads as a permanent commitment, and permanent commitments get deferred.

A pilot with a kill criterion reads differently: a fixed number of devices at one site, a fixed duration (ninety days is common), one measurement tied to the metric, and a written statement of what result ends the project. "If we cannot detect at least 80% of the compressor faults the maintenance log records during the pilot, we stop and write off the pilot cost" gives the executive an exit. A clear exit makes them far more willing to enter.

Attach a decision date. Not "we will review the results" but "on December 12 we meet and decide to expand, adjust, or stop." The [planning guide for non-technical project managers](https://tago.io/blog/planning-an-iot-project-non-technical-pm) covers scoping the pilot so the measurement is clean.

Size the pilot so its cost is inside the approving executive's own authority. A $15k pilot that one director can sign moves in a week. A $60k pilot that needs a committee waits for the committee.

## Demo on their phone, not on your slides

A screenshot of a dashboard proves you can make a dashboard. A live view on the executive's own phone proves the system exists and that they could use it without you.

With a few real devices already sending data, set up a small TagoRUN portal, create a user for the executive, and have them install the [TagoRUN mobile app](https://docs.tago.io/docs/tagoio/tagorun/getting-started/tagorun-mobile-app) and sign in before the meeting. When you say "the east cold room is at 3.8 degrees right now," they can check. Set up one Action so an alert reaches their phone during the meeting, and the conversation stops being about whether it works.

Keep the demo to the metric: one dashboard, two or three widgets, one alert. Fifteen charts invite fifteen questions about the charts and none about the budget.

## Answer the "why not build it on AWS ourselves" question honestly

Someone in the room will ask it, often the CTO. Do not dodge it, and do not pretend the alternative is unworkable. Companies build on AWS IoT Core, ThingsBoard, and in-house stacks all the time, and some should.

The honest answer is about time and staffing, not capability. Building ingestion, storage, user management, dashboards, alerting, and mobile access yourself puts an engineering team between the pilot and the decision date. The [AWS IoT Core versus managed platform](https://tago.io/blog/aws-iot-core-vs-managed-iot-platform) post lays out where each path makes sense. For the pitch, the point is that the pilot timeline you just proposed assumes configuring, not building. If leadership prefers to build, the timeline and the three-year cost both change, and you should say by how much.

Executives respect this answer because it does not sound like a vendor. It sounds like someone thinking about where the company's engineers should spend their time.

## What to leave out

Most of what makes a technology pitch feel thorough is what stalls it. Leave out:

- The architecture diagram. Keep it in the appendix for whoever asks.
- Protocol choices. LoRaWAN versus cellular is your decision to have made already, not theirs to weigh.
- Future use cases. Expansion is a conversation for the decision date, once the pilot has a result.
- Industry statistics about IoT adoption. They signal you could not find a number inside your own company.
- The platform's feature list. The executive is approving a pilot against a metric, not choosing software.

The pitch that gets approved fits on one page. The champions who get IoT funded are rarely the ones with the best technical case. They did the executive's translation work for them, so the only thing left to do in the meeting was say yes.

## Resources

- [The true cost of a mid-market IoT deployment](https://tago.io/blog/true-cost-of-a-mid-market-iot-deployment)
- [Comparing IoT platform pricing over three years](https://tago.io/blog/comparing-iot-platform-pricing-over-three-years)
- [AWS IoT Core vs a managed IoT platform](https://tago.io/blog/aws-iot-core-vs-managed-iot-platform)
- [TagoRUN mobile app](https://docs.tago.io/docs/tagoio/tagorun/getting-started/tagorun-mobile-app)

[llms.txt](https://tago.io/llms.txt)