The Push Playbook: How internal products actually get adopted

Let me tell you about the worst product I ever pushed into production.

It was an ML model with 41% accuracy. Not 91%. Not 71%. Forty-one!

By any reasonable quality bar, it had no business being in anyone’s workflow. If it were a consumer product, it would have been uninstalled within the hour and roasted in the reviews.

But we pushed it anyway. Management backed it, teams were asked to use it, and feedback loops were set up from day one.

Within months, the same users who grumbled about its early misses had helped push it past 80% accuracy. Today, all everyone remembers is the product that works and that they are more efficient using it than they were before.

It took me years to accept but I now have enough clarity: that model didn’t survive because it was good. It survived because we pushed hard enough for it to have the time to become good.

Just like Google’s famous, public graveyard of consumer products, there’s a quiet graveyard inside every large company. It’s full of internal tools, platforms, and models that died young.

They died not because of quality, but because of neglect. Management sponsored the build, showed up at the launch demo, and then moved on. Adoption was left to organic discovery, which inside a company is a polite way of saying nobody’s job / build it and they will come.

Every product eventually improves if it stays alive. Improvement is almost mechanical: usage generates feedback, feedback generates fixes, fixes generate trust. The only real question is whether the product survives long enough for that flywheel to spin.

Quality determines how far a product can go. Push determines whether it gets to go at all.

If you’ve only ever built customer-facing products, this sounds backwards. Isn’t the whole point that good products win?

In consumer land, mostly yes. Users have choice, switching is cheap, and quality gets discovered fast. But internal and platform products live in a completely different universe, and the differences are worth spelling out:

Look at that Selling row again. It’s the whole article in one line.

A traveler comparing flight prices doesn’t need convincing to use the cheaper option. But an internal team? They have a working process already. It might be ugly, manual, and held together with spreadsheets, but it works, they know it, and their goals for the quarter don’t include “migrate to the new thing.”

Your internal product is competing against inertia, and inertia is undefeated unless leadership actively fights it.

A general advice I like to give:

If you are building internal products, spend more than half your time on adoption and pause building if adoption needs even more time.

Notice the last row of that table too. For a Product PM, the classic risk is building the wrong feature. For a Platform PM, the deadlier risk is building the right thing that nobody uses.

That second failure mode is more painful because it’s invisible. There’s no angry customer, no dip in conversion, no incident report. Just a dashboard showing three weekly active users, all of whom are on your own team : )

And here’s where the premature death happens: Six months in, someone in a budget review asks why the platform team exists. Usage is low, so the value looks low, so the investment gets cut. The product dies with everyone agreeing it “just didn’t land.”

Nobody writes in the post-mortem that it was never actually pushed.

Pushing is not sending a launch email and hoping. It’s a set of deliberate moves, and in my experience the successful ones share four ingredients. Think of it as the Push Playbook:

1. A mandate, not a suggestion. Somebody senior has to say “we are using this” and mean it. Not “feel free to try it.” Optional adoption of internal tools rounds to zero. With our 41% model, the decision to route real workflows through it wasn’t made by the users. It was made above them, with a clear message: this is the direction, help us make it work.

2. A protected runway. Early versions will embarrass you. Leadership’s job is to absorb that embarrassment instead of letting it kill the product. When users complained about the model’s misses, the answer was never “fine, go back to the old way.” It was “log it, we’ll fix it, keep going.” That protection is what bought me the flywheel time to spin.

3. Users turned into co-owners. The fastest way to convert a skeptic is to visibly ship their feedback. Our users didn’t improve the model out of goodwill. They improved it because every complaint they raised showed up as a fix within weeks, and eventually they started bragging about “their” model. Adoption stops being a fight the moment users feel authorship. I used to invite users to the ‘Sprint Demo’ at the end pf every sprint (2 weeks) where they could see what we had shipped and their feedback being incorporated.

4. A burning bridge. As long as the old way exists, people will drift back to it. At some point you have to retire the parallel path. Not on day one, but on a date everyone knows is coming. Nothing accelerates feedback like knowing the fallback is going away.

I kept pushing for phased adoptions (on Region / Customer Segment / Product Feature) to eventually introduce a date that sounded natural to the users.

None of this is a license to force garbage on your colleagues.

Pushing hard only works when three things are true:

1. the problem is real,

2. the product improves visibly with feedback, and

3. users can see their fingerprints on the improvements.

Push a product that fails those tests and you get resentment, and you burn credibility you’ll need for the next launch.

The 41% model earned its push because the long-term alternative was worse than 41%, and because we could demonstrably improve week over week. Push is an accelerant, not a substitute for a product worth accelerating.

If you’re building internal products or platforms, stop asking only “is it good enough to be adopted?”

Start asking the question that actually decides your fate: “who is pushing this, how hard, and for how long?”

Because in my experience, the products that die inside companies aren’t the worst ones. They’re the ones where everyone loved the idea and nobody owned the push hard enough for the product to have time.

Your product will improve. That part is almost guaranteed. Whether it lives long enough to improve is a leadership decision, and it gets made every week, in every prioritization call, whether anyone says it out loud or not. The narrative is on you.

Have you seen a good internal product die young, or a mediocre one thrive because someone refused to let it fail? I’d love to hear the story.