Selling Your Ideas
Every job is sales.
Whatever your title, whatever the company, every role that succeeds is good at it. Not because everyone is closing deals with a customer. Because every job runs on convincing people. You have a new idea, and you have to sell your team on the fact that it's worth building. Interviewing is sales. Getting your kids out the door and to school on time is sales. To sell well is to convince someone to part with a resource: their time, their money, their attention. Not to take it from them, but to leave them better off than you found them.
This is the page The Product Leader's Job pointed at. Not selling a product to a customer. Selling an idea, a method, a direction, to the people whose buy-in you need and can't order. Here's how you do it.
How often you're really selling
Daniel Pink put a number on it. In his book To Sell Is Human, he surveyed more than 9,000 working adults and found we spend about 40% of our time at work on what he calls "non-sales selling." Persuading, convincing, moving people who don't report to us. That's the average across every job. For someone with no title to fall back on, it runs higher.
And here's the test most people fail: getting buy-in is not displaying a plan and walking through it. Showing the work is not selling it. Buy-in is the work.
The objection usually comes from strong engineers and analysts moving into product: selling is fluff, the building is the real job. Half right. Being great at the craft gets you in the room. It does not move the room. A perfect framework nobody uses is worth nothing. A decent one the whole org rallies behind changes everything.
Belief is the engine
You can't sell something you don't believe in.
Grant Cardone built a book called Sell or Be Sold around exactly this. If you don't fully believe what you're selling is possible, other people see it, and they aren't going to believe it either. I'm not a fan of his flashy attitude, and there's plenty I disagree with him on. But that one point is dead on. People read hesitation instantly. The moment they sense you're not sure, they decide they don't need to be.
There's a reason this matters more than any argument you'll make. People throw around a number here, that 95% of buying decisions are emotional. The real research says something narrower and more careful. What Harvard's Gerald Zaltman estimates, and he's clear it's an estimate, not a measured fact, is that about 95% of our decision-making happens in the subconscious. Subconscious, not "emotional." But the point holds either way. Getting someone to believe an idea is a purchase, and purchases don't run on logic alone. They run on what the person feels. So you don't win with a tighter slide deck. You win with conviction, trust, and a reason to care.
Which means the conviction has to be real, not performed. It's belief grounded in evidence: you believe in something because you've watched it work, and when it stops working, you're willing to change it. You're just telling the truth with energy.
Run Design Thinking on a person
Selling an idea is the same process as building a good product. Design thinking is usually taught for product development, but at its core it's a method for solving problems, and selling a person is a problem.
Design Thinking runs in five phases: empathize, define, ideate, prototype, test. We'll go into it much deeper later, but the process can be used on any problem. I've used these steps on everything from a salary negotiation to a micromanaging boss.
Empathize. Before you pitch anything, understand the person, because what convinces one person does not convince the next. What lands with an engineer is likely not what lands with a salesperson, nor an executive. The engineer wants to know the thing is sound and that you won't waste their time. The salesperson wants to know it moves their number. The executive wants the outcome and the risk. Same idea, three different pitches. So you ask what they actually need, what they're afraid of, what a win looks like for them, and you listen more than you talk.
Define. Now name the real problem you're solving for them, not the one you assumed walking in. It's almost always different. The clearer you are on what actually moves them, the less you have to push.
Ideate. Figure out how to frame it. Connect your idea to their why, the reason it makes their world, their team, or the company better. This is where Simon Sinek's point lands. People don't buy what you do, they buy why you do it. They don't rally around features or quarterly targets. They rally around a reason. So give them one.
Prototype. Don't unveil the finished pitch to a full room cold. Float it small first: a hallway conversation, a one-pager, a quick "what if we tried this" with one person. Cheap, low-stakes, easy to adjust.
Test. Put it in front of people and watch what happens. Read the reaction, fold it back in, run it again. Which is where the dissenter comes in.
Find the dissenter
When you're trying to win over a resistant team, don't try to convert it from the outside. Find the dissenter: the person already inside it who's frustrated with how their own team works and wants something better. To be a dissenter, you have to belong to the group you're dissenting from, so they carry trust on the inside that you, the outsider, never will. That's your way in.
I watched this work on a real project. My team was brought in to build a service for another department, and the team we were asked to support resisted the whole way. But one person on it kept reaching out, asking about our ways of working.
He'd been there two years and watched the team fail to deliver a single project the entire time. He was frustrated and looking for something better. So we used empathy to understand that frustration, then trained him to ask open-ended questions inside his own team, carrying the approach into rooms we couldn't reach. The project ended up fully agile, and it hit its numbers.
Backing that person does two things. You gain an advocate with real trust inside the team you're trying to move, someone who can carry the new way into rooms you'll never sit in. And you get an honest read of what's actually broken in there and why people resist, the kind of inside truth you'd never get from the outside. So you end up solving the real problem, not your guess at it.
It spreads by followership
None of this takes hold because it's mandated. You can decree a new operating model on Monday and watch nothing change by Friday. What shifts an organization is followership: people choosing the new way because they've seen it work and want in. A leader, after all, is just someone who has followers. So you're not installing a system. You're building a movement, one convinced person at a time, starting with a small group who prove it works and pull the rest along.
I learned this building a design system at a company that had no head of design. I had no authority to mandate it, and I didn't go around anyone to force it. I acted as a snowplow instead: I cleared the obstacles and educated people, which freed the designers to build what they knew was best and then work with engineering on how to get it incorporated. It was a grassroots effort, built from the inside and completely transparent. We all wanted the same outcome. We just didn't have the authority to order it, so we learned to work within the system to get there.
Selling in three directions
That movement gets built in three directions at once. Picture an org chart: a CEO on top, chiefs below, then VPs and directors. You're selling up it, down it, and across it.
Leading down is what most people picture: coaching, developing, and inspiring the people you manage or who are below you in the corporate ladder (not directly on your team).
Leading sideways is influencing your peers, the other functions whose cooperation you need but whose people don't report to you. In a matrixed org this is most of the job, and it's usually the hardest, because every team shows up with its own priorities and agenda. You can't order any of it, so you align it: get everyone pointed at a shared goal, give each function a real voice, and make the wins visible so every team sees how its work moved the thing forward. When priorities collide, you mediate instead of letting it fester, and you adjust until each side feels heard. The design system above was leading sideways. No authority, all influence, bridges built one team at a time.
Leading up is the one people neglect, and it quietly determines your effectiveness. If you can't influence the leaders above you, you stay stuck, never quite getting the resources, the air cover, or the decisions you need. The move isn't to push harder. It's to bring evidence instead of opinion, and frame it in their language: cost, risk, and the outcome they're already chasing. Start with your own boss, win an ally one level up, and let that backing carry you higher. It all runs on trust you bank long before you need it. I once doubled my office space (doubling the cost of my rent) in a five-minute pitch to my boss. I had more than 5 minutes to the pitch, but he cut me off early in. I'd built enough trust with him in the last 6 months that he didn't need it all. He knew I did the due diligence and our growth ambitions warranted it.
A product leader who can only lead down is a team lead. One who can move in all three directions can move an organization.
Selling never stops
Selling an idea isn't a one-time event. You don't present the new way of working once and watch the organization adopt it. Wins come through iteration. You sell it again next week, and the week after, to new people and to the same people who've drifted. Adoption is built on repetition and proof. The leaders who change organizations never stop telling the story.
And it comes back to where we started. Done right, selling leaves the person, the team, and the company better off than you found them. That's the difference between selling and pushing.
Believe it. Tailor it to the person in front of you. Win the ones who push back. Keep telling the story long after you think you're done. That's the job.