What I’ve seen in practice
I’ve seen many product managers fall into the same trap.
“Well… here is my product.
It solves a real pain point.
So people will just use it.”
Sometimes adoption is mandated.
But often it isn’t.
Many internal products start as:
→ pilots
→ optional tools
→ platforms teams can choose to adopt or ignore
In some companies, internal teams even have to:
→ justify ongoing investment
→ convince other teams to pay for usage
→ define pricing or cost-allocation models
And this is where things usually break.
Weeks go by.
Months go by.
Usage stays low.
And one day, in a random meeting, someone casually says:
“Wouldn’t it be nice if we had something that solved this problem?”
And the PM is sitting there thinking:
“But… that is my product.”
That moment hurts.
And it’s usually not a product problem.
It’s a go-to-market problem.
On the other hand, I’ve seen product managers grow fast because they figured this part out.
They understood:
→ how to position the product internally
→ how to explain the value in business terms
→ who the product is for and who it is not
→ how to make adoption attractive, not forced
→ how to justify funding or chargeback models
Of course, context matters a lot.
If you’re in a 10-person company, one Teams message might be enough.
If you’re in a 1,000+ person organization across countries and functions… that’s a very different conversation.
But regardless of size, having an internal GTM plan is always better than hoping for organic adoption.
What is a GTM? And what does it include?
At its core, a go-to-market strategy answers one simple question:
How does this product actually reach the people it’s meant to help… and why should they care?
In the external product world, GTM often comes with:
marketing campaigns, sales motions, pricing, revenue targets.
But if you zoom out, most GTM frameworks boil down to the same core questions:
→ Who is this for?
→ What exactly are we offering?
→ Why should someone choose this?
→ Where do people encounter it?
→ How do we enable adoption?
→ When do we roll it out?
Below is a typical GTM model used for external products.
This is the version most people think of when they hear “go-to-market”.
And this is usually where internal product managers pause and think:
Okay… but this doesn’t really apply to me, right?
GTM for internal products
Here’s the interesting part.
The questions don’t change.
The answers do.
Internal products don’t always have mandatory adoption.
They don’t always have guaranteed funding.
They don’t always have a single “customer”.
In many cases, they actually compete:
→ with existing tools
→ with manual processes
→ with spreadsheets
→ with other internal or external vendors
Sometimes teams can opt in or opt out.
Sometimes they have to pay for usage.
Sometimes leadership is watching adoption closely to decide whether the product survives.
This makes GTM for internal products even more important, not less.
So internal GTM is less about selling in the classic sense…
and more about clarity, relevance, and trust.
If you take the same GTM structure and adapt it for internal products, it looks more like this:
Now those same questions mean something very different:
→ Who are the specific roles, teams, or functions this is for?
→ What capability, tool, or workflow does this product enable?
→ Why should someone switch from their current solution?
→ Where do users discover, access, and learn about it?
→ How do you enable adoption through onboarding and support?
→ When do you pilot, scale, or stop investing?
This is where many internal products fail.
Not because the solution is bad.
But because no one ever made these decisions explicit.
Example: a GTM strategy for an internal product I owned
Here’s a simplified GTM summary I used for one of my internal products.
Target users
Manufacturing process engineers and plant IT teams.
Problem
Manual data access and unclear ownership slowed down troubleshooting and decision-making.
Positioning
A single, reliable way to access production data without custom requests or manual exports.
Key message
If you need production data for analysis, troubleshooting, or reporting… start here.
Onboarding
→ Self-service access request
→ Starter documentation
→ Sample dashboards and queries
Enablement and support
→ Monthly office hours
→ Templates for common use cases
→ Dedicated Teams channel
Stakeholders and funding
→ IT leadership focused on stability and security
→ Business leadership focused on efficiency and cost transparency
Rollout
→ Pilot with two plants
→ Expand based on adoption and feedback
→ Internal demos and roadshows
Nothing fancy.
But intentional.
And it made a massive difference in adoption and trust.
Want a starting point?
I created a Notion template for an internal go-to-market strategy that you can adapt to your own context.
Whether your product is:
→ mandatory
→ optional
→ piloted
→ or internally “sold” via chargeback
This template helps you think it through.
→ [Link to the GTM Notion template]
