Building in public on LinkedIn® before you have big wins

Building in public on LinkedIn® means sharing useful parts of your work while the outcome is still uncertain. Early founders can publish decisions, experiments, customer lessons, and setbacks without revenue milestones. Explain what happened, what you think it means, and what you will do next, while protecting private information.

Key takeaways

• A decision with a clear tradeoff can teach readers something before your company has impressive results.
• Separate observations, interpretations, and plans so readers can judge your evidence.
• Share customer lessons only when the details are yours to disclose.
• Label unfinished experiments honestly and return with updates when you have them.
• Keep a short decision log so posting follows useful work instead of creating extra work.

What can you share when you have no major wins?

Share the reasoning behind work your intended readers understand. A founder choosing how onboarding should work has a publishable decision even before the product has paying customers.

Building in public is the practice of sharing selected decisions, work, and learning while a project develops. The word “selected” matters.

You can explain your reasoning without publishing every conversation, financial detail, or disagreement.

Choose a reader before choosing a story. A potential customer might care about a workflow problem.

Another founder might care about your implementation tradeoff. A possible teammate might care about how you handle uncertainty.

The same event can serve these audiences differently, so give each post one primary reader.

For example, postponing a dashboard feature could produce a post about helping operations teams understand exceptions. A detailed account of your frontend framework choice would serve a different reader.

Neither angle needs a launch announcement or a revenue screenshot.

Our 30 post ideas for founders offer more subjects drawn from ordinary work. Here, the task is narrower: turn one unfinished piece of work into an honest, useful post.

Start by writing down a decision you made this week and the person who might benefit from understanding it.

How do you turn ordinary work into a useful post?

Use a decision log that preserves the difference between what happened and what you believe. Five short fields are enough to prepare a draft without exaggerating your evidence.

Field	What to capture	Illustrative entry
Situation	The specific task or problem	Designing the first setup screen
Observation	Something directly observed	The draft asks for information users may not have
Decision	What you chose	Let people explore a sample workspace first
Tradeoff	What the choice gives up	The sample may hide setup complexity
Next check	How you will revisit the choice	Watch a new participant try their own data

The entry above is hypothetical. Its usefulness comes from the reasoning, not a claim that the change improved conversion.

Before drafting, mark every sentence in your notes as an observation, interpretation, or plan. “The participant asked where to start” is an observation if it happened.

“The screen feels overwhelming” is your interpretation. “We will remove a required field” is a plan until you implement it.

GOV.UK’s note-taking guidance similarly distinguishes observations from personal interpretations. Keep that distinction when turning a conversation into a post.

One person's confusion can justify further investigation. It does not establish that your entire audience wants a different product.

Use this copyable structure:

We were trying to [specific task].

We noticed [bounded observation].

We chose [decision] because [reason].

That means accepting [tradeoff].

Next, we will check [specific uncertainty].

Replace every bracket with something true. If you cannot fill the observation field, write a clearly labeled hypothesis instead of inventing a customer reaction.

What do honest early founder posts look like?

The following four posts are fully written hypothetical examples. They describe an imaginary founder building software for service businesses.

They are writing models, not accounts of Reepl's work or evidence of business results. Adapt the structure to your actual work rather than presenting these events as your own.

Example one: explain a product decision

We are leaving the dashboard out of our first prototype.

The product helps a service team hand work from one person to another. Our first design put charts above the list of unfinished handoffs.

Looking at that screen, we realized we were answering “How is the team doing?” before answering “What needs my attention?”

We are changing the opening screen to show work waiting for an owner. The charts can wait.

There is a tradeoff: someone evaluating the product will see less of the reporting story. We are accepting that while we work out whether the daily workflow makes sense.

Next, we will ask a participant to identify the next action without a guided tour. That will give us something more useful than our preference for a cleaner screen.

This post gives the reader a decision, a reason, and an unresolved question. It does not call the change successful before anyone has used it.

Use this format when you can explain both sides of a choice. If the decision affects customers already using the product, communicate the change to them directly before making it a public story.

Example two: describe an experiment before the result

Our next onboarding experiment is about preparation.

The current prototype asks someone to bring a real project before they can explore the workflow. We think that request might be too early.

We are preparing a second version with a sample project. A participant will be able to assign work, change a status, and see a handoff without collecting their own information first.

The question is whether the sample helps someone understand the product or simply lets them click around without understanding setup.

We will watch for the point where they can explain how their own project would fit. Finishing the sample alone will not answer that question.

We do not have a result yet. This is the assumption we are trying to test.

The ending makes the evidence boundary explicit. Readers can discuss the experiment without mistaking your hypothesis for a finding.

GOV.UK’s research planning guidance recommends turning unfounded assumptions into research questions. Before posting a planned experiment, check that you intend to run it.

Public updates become confusing when every tentative idea is presented as a commitment.

Example three: share a customer lesson without exposing the customer

A recent discovery conversation changed how we describe the handoff problem.

We had been talking about visibility: everyone should be able to see the status of a project.

The conversation pointed toward a more specific issue. Seeing a status does not necessarily tell the next person whether they are responsible for acting.

We are separating those ideas in our notes: knowing what is happening, and knowing who should act next.

This is one conversation, so we are treating it as a question to investigate. In the next interviews, we will ask people to walk through an actual handoff and identify where responsibility becomes unclear.

We have omitted identifying details. The useful lesson for us is to ask about the next action before assuming that another status view solves the problem.

This hypothetical post paraphrases a lesson without creating a customer quotation. In real use, omitting a name may still leave someone identifiable through their role, industry, timing, or project details.

Check whether you have permission to disclose the substance of the conversation. Where that is uncertain, publish your own revised question without describing the source conversation.

Example four: discuss a setback with ownership

We are delaying the prototype walkthrough we planned for this week.

Our sample project works only when someone follows the sequence we expected. Moving a task backward leaves the next owner unclear.

That means the walkthrough would demonstrate our script more than the product's behavior.

We are fixing the ownership rules before inviting people to try it. The uncomfortable part is that we treated the happy path as enough for a useful first session.

The change to our process is small: before booking the next walkthrough, we will try a canceled task, a reassignment, and a reopened task ourselves.

We cannot promise the next session will be smooth. We can make sure it tests a more honest version of the workflow.

A useful setback post describes the consequence and response. It does not need a dramatic confession, a villain, or a lesson that claims the problem was secretly beneficial.

What should stay private when you build in public?

Keep information private when sharing it could break an obligation, expose someone else's situation, or create a misleading account. Your willingness to discuss your company does not give you permission to disclose another person's work.

Use a boundary check before turning notes into a post:

Usually easier to share	Requires a closer check	Keep out of a routine post
Your own design reasoning	Customer conversations and screenshots	Credentials and private personal information
A hypothesis you own	Financial details involving partners	Confidential contract terms
A deliberately fictional demo	Unreleased plans involving other teams	Active security vulnerabilities
A process change you control	Disagreements involving identifiable people	Private employee performance details

These categories are editorial guidance, not legal advice about a particular agreement. If you have a confidentiality obligation, use that obligation as the boundary.

GOV.UK’s guidance on publishing research findings calls for removing personal data and fully anonymising public examples. Redaction needs more than covering a company name.

A screenshot can reveal an email address, account identifier, customer project title, or browser tab. A distinctive story can identify someone even when the image is clean.

Prefer a recreated fictional example when the actual artifact is unnecessary to teach the lesson.

Delay a post when timing makes it sensitive. A hiring change, service incident, or customer dispute should reach the affected people through the appropriate direct channel first.

Public commentary can wait until facts are settled and disclosure is appropriate.

You can also decide that a subject will remain private permanently. Building in public does not require revenue disclosure, personal hardship, or a public record of every failed attempt.

Write down three topics you will share and three you will keep private before starting.

How can you keep the habit useful without manufacturing stories?

Capture notes during normal work, then choose one useful entry when you have time to write. Treat a weekly post as an optional output of learning, not a deadline to produce an event worth announcing.

A practical starting routine is 10 minutes at the end of the week to review decisions, followed by 20 minutes to draft one post. These are planning allowances, not measured productivity promises.

Give sensitive posts more review time, and skip publication if the source material is weak.

Keep a separate list of experiments you mentioned publicly. For each, record the original assumption, what happened next, and whether you owe readers a correction or update.

An experiment that remains inconclusive can still receive an honest follow-up: explain what you could not learn and why.

When a reader responds, distinguish encouragement from useful evidence. A compliment can be welcome without validating demand.

A detailed description of the same workflow problem may suggest a good discovery question. Follow up thoughtfully rather than counting every reply as proof that the product should exist.

If your posts start sounding like a different person, use the guide to teaching AI your writing style to compare drafts with language you actually use. Preserve ordinary words and specific uncertainty.

You do not need to sound like a keynote speaker to explain a product choice.

Avoid rewriting the original plan to make the outcome sound inevitable. If the evidence is inconclusive, say so.

An accurate update is more useful than forcing a neat success or failure story.

Choose one decision from your notes today. Write the observation, tradeoff, and next check before writing an opening line.

Publish only what you can explain honestly and disclose comfortably.