LinkedIn strategy for B2B SaaS: people before the page
A LinkedIn strategy for B2B SaaS that runs through the founder's and team's profiles, built on lessons from product data instead of feature announcements.
The LinkedIn strategy that works for most B2B SaaS companies puts the founder and a few team members at the centre and the company page at the edge. Those people post lessons drawn from the product and its data, not a stream of feature announcements, on a steady weekly rhythm and under a small set of themes. The company page carries announcements, jobs and ads, and borrows from the people.
Why personal profiles carry more than the company page
It is widely observed that posts from people reach and engage more readers than posts from company pages, and most B2B marketers who have tried both will tell you the same. LinkedIn does not publish how its feed ranks posts, so treat the reasons as reasonable guesses. People follow people. A person's post reaches their connections, who know them. A comment on a person's post starts a conversation with someone, while a comment on a page's post is addressed to a logo.
For a B2B software company this matters because your buyers are people with jobs, and they trust peers. A head of finance is more likely to read a post from another operator about closing the books faster than an announcement from a software brand about a new export button.
Who on the team should post
- The founder or CEO. Decisions, strategy, the numbers behind the business, the market as seen from inside it.
- The product lead. Why something was built, what users did with it, what got cut and why.
- An engineer who likes writing. How a hard problem was solved, what broke, what the fix cost.
- Someone in sales or customer success. The questions customers ask, the problems they arrive with, what they wish they had known.
Two or three people posting regularly is plenty. Forcing the whole team to post produces thin posts, and readers notice when a company has handed out a content quota.
Product updates vs lessons
The default for SaaS teams is to post the changelog. A feature ships, a post goes up saying so. These posts matter to current customers and to nobody else, and current customers already get the release email.
Every product update has a lesson inside it. The feature exists because someone noticed a problem, made a decision and measured something. Post that instead, and mention the feature where it fits.
- Update: 'New: bulk export to CSV.' Lesson: 'Support tickets about exporting data were the second largest category last quarter. Most came from finance teams closing the month. Here is what they were trying to do.'
- Update: 'Onboarding redesign is live.' Lesson: 'Activation sat flat for six months. Three changes to the first screen moved it. One of them was deleting a step.'
- Update: 'Faster dashboards.' Lesson: 'The slowest query was one nobody had looked at in two years. What an afternoon of profiling turned up.'
Using your product data
A SaaS company sits on more publishable numbers than almost any other kind of business. Billing, product analytics, web analytics and the code history all record what happened, with dates. That is the raw material for receipt posts, the kind nobody else can write.
- Billing: new revenue, new customers and churn in the last 30 days, and how they moved after a pricing or packaging change.
- Product analytics: which feature got used after launch, where people drop out of onboarding.
- Web analytics: which pages bring visitors and from where, including the visits your own posts send.
- Code history: what shipped this month, counted from merged pull requests and releases.
- Internal notes: the decision documents and retros where the reasoning is already written down.
Decide once what you are willing to share, and write it down. Many companies share growth rates and customer counts but not revenue totals. Whatever the line is, keep the definitions the same from post to post, so a reader following along can trust the comparison.
Pick four themes
Themes decide what posts are allowed to be about, and they keep a team from repeating the same three ideas. Four is enough to cover a SaaS company without losing focus. An example for a small billing tool:
- How finance teams close the month, and where the time goes.
- Pricing and packaging decisions, with the numbers that followed.
- Building the product: what was built, what was cut, what broke.
- Running a small software company: hiring, tooling, trade-offs.
Each person can lean toward the themes closest to their job. The founder takes pricing and the business, the product lead takes building, and customer success takes the month-end problems customers bring.
Cadence across a team
One post a day from the company as a whole, spread across two or three people, is a strong rhythm for a small SaaS team. That works out to two or three posts a week each, which fits beside a full job if the drafts are written in a weekly batch. Measure the rhythm itself, posts published and weeks without a gap, before you look at anything else. Reach follows consistency far more reliably than it follows any single post.
How GoodSocials handles this
GoodSocials posts to personal profiles, one board per person, and it can read a company's own numbers read-only from Stripe, GitHub, PostHog, Plausible and Notion with a pasted key. Sources sync once a day and a reading that stops coming back is removed, so no draft cites last quarter's churn as current. Posts are written in the third person, naming the company and the source, so a line like 'Stripe shows 42 new customers in August' says whose number it is.
The Agency plan holds up to 12 profiles for $1,000 a month, so a founder, a product lead and a few colleagues can each have their own board, themes and principles. Each person connects their own LinkedIn account, and nobody shares a password.