Building in public on LinkedIn® before big wins means sharing the decisions, experiments, customer lessons and setbacks from work still in progress. Write what happened, what you think it means and what you will check next, label unfinished work as unfinished, and keep other people's details private.
Key takeaways
- A decision with a clear tradeoff makes a useful post before you have revenue, customers or a launch.
- Mark every note as an observation, an interpretation or a plan, and keep the three apart in the post.
- Share a customer lesson only when its substance is yours to disclose, and check role, industry and timing details for identifiability as well as names.
- Label experiments as unfinished, then return with the result, including an inconclusive one.
- Put the work state (exploring, prototype, scheduled or available) in the first sentence whenever it affects the claim.
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 about your implementation tradeoff, and a possible teammate about how you handle uncertainty. The same event serves these readers differently, so give each post one primary reader.
For example, an illustrative founder building a booking tool for independent physiotherapy clinics might postpone a reporting dashboard. That decision could become a post for clinic owners about seeing what needs attention today. A detailed account of the founder's frontend framework choice would serve developers instead. 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 now with one line: “This week we decided [decision], and [reader] would benefit from knowing why.” You will use that line in the decision log below.
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 clinic 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, and its value is the reasoning it records. 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.
Treat one person's confusion as a reason to investigate further, and keep claims about your wider audience out of the post until more conversations back them up.
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 from the illustrative physiotherapy booking founder. They are writing models: adapt the structure to your own work, and never present these events as yours.
Example one: explain a product decision
We are leaving the dashboard out of our first prototype.
The product helps a clinic front desk fill cancelled appointments. Our first design put charts of weekly bookings above the list of today's open slots.
Looking at that screen, we realized we were answering “How is the clinic doing?” before answering “Which slot do I need to fill now?”
We are changing the opening screen to show today's open slots. The charts can wait.
There is a tradeoff: a clinic owner 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 receptionist to find the next open slot without a guided tour. That will tell us more 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.
Example two: describe an experiment before the result
Our next onboarding experiment is about preparation.
The current prototype asks a clinic to import its real appointment calendar before exploring the workflow. We think that request might come too early.
We are preparing a second version with a sample clinic. A participant will be able to cancel an appointment, offer the slot to a waiting patient and see the calendar update without importing anything 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 clinic would fit. Finishing the sample alone will not answer that question.
We have no 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 get confusing when every tentative idea reads as a commitment, so name the stage in the post itself.
Example three: share a customer lesson without exposing the customer
A recent discovery conversation changed how we describe the cancellation problem.
We had been talking about visibility: everyone at the front desk should be able to see which slots are open.
The conversation pointed to a more specific issue. Seeing an open slot does not tell a receptionist whether a colleague is already calling a patient about it.
We are separating those ideas in our notes: knowing a slot is open, and knowing who is filling it.
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 a real cancellation and point to where responsibility becomes unclear.
We have omitted identifying details. The useful lesson for us is to ask who acts next before assuming 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 clinic works only when someone follows the sequence we expected. Moving an appointment to a different therapist leaves the slot's status unclear.
That means the walkthrough would demonstrate our script more than the product's behavior.
We are fixing the rules for moved appointments 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 cancelled appointment, a reassigned therapist and a rebooked patient 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 |
If you have a confidentiality obligation, that obligation sets the boundary; the table is editorial guidance, not legal advice about a particular agreement.
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. When the real artifact is unnecessary to teach the lesson, recreate a fictional one. Run this check before you post:
- Is every detail in the post yours to share?
- Could someone identify a customer or colleague from role, industry, timing or project details?
- Does any screenshot show an email, account ID, project title or open tab?
- Has everyone affected heard the news directly first?
- Would you be comfortable if the person described read it?
Delay a post when timing makes it sensitive, such as a hiring change, service incident or customer dispute, and wait until the facts are settled and disclosure is appropriate.
Some subjects can stay private for good. Building in public asks for none of these: revenue disclosure, personal hardship or a public record of every failed attempt. Before you start, write down three topics you will share and three you will keep private.
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. Treat both as suggested starting allowances. 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 inconclusive experiment can still get an honest follow-up that explains what you could not learn and why.
When a reader responds, sort the reply. A compliment is welcome. A detailed description of the same workflow problem may suggest a good discovery question, so follow up on that one thoughtfully.
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. Keep ordinary words and specific uncertainty; plain language is enough to explain a product choice.
Leave the original plan as it was, so the outcome never sounds inevitable in hindsight. If the evidence is inconclusive, say so; an accurate update helps readers more than 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, and publish only what you can explain honestly and disclose comfortably.
How do you close the loop on an unfinished experiment?
Return to the original question when you have useful evidence, even if the result is disappointing or inconclusive. Building in public becomes harder to trust when every hypothesis is announced and only flattering outcomes receive an update. A follow-up does not need a dramatic result; it needs an honest account of what changed.
Keep a follow-up field in your decision log: the question, the next observation, the condition that would change your mind and a review date. The review date is a reminder to examine the work; the answer may take longer. If recruitment stalled or the prototype changed, report that limitation plainly. A follow-up post can use this shape:
We said we would test [assumption].
What happened: [observation, including what went wrong with the test].
What it means for now: [bounded interpretation, or “we cannot tell yet”].
What we will do next: [next check, and when we expect to report back].
For the illustrative sample-clinic experiment, a useful follow-up might say: “We wanted to learn whether a sample clinic helped a new participant find the first action. The session showed where that person clicked, but our instructions gave away part of the answer. We are rewriting the task before treating the session as evidence about the screen.” The hypothetical update reports an invalid test honestly.
GOV.UK's guidance on sharing research findings emphasizes findings that teams can use for decisions and future work. Apply that principle publicly by explaining what your next decision depends on. A record of uncertainty can be useful when it names the missing evidence clearly.
Keep the original hypothesis as you wrote it, even when the outcome differs. If the early post claimed too much, correct that wording and make the change visible where practical, so readers can tell a revised interpretation from a prediction that supposedly came true all along.
Which public updates create obligations you may not intend?
A post can sound like a promise even when you intended it as a thought process. Be precise about whether you are exploring a change, testing a prototype, committing to a release or describing something available today. Those states create different expectations for customers and teammates.
| Work state | Accurate wording | Unhelpful implication |
|---|---|---|
| Exploration | We are comparing these two approaches. | The feature is definitely coming. |
| Prototype | This version is for evaluating the workflow. | Customers can rely on it today. |
| Scheduled release | We plan to release after these checks. | The date cannot change. |
| Available change | This behavior is available for the stated users. | Every account has identical access. |
In October 2026, the LinkedIn® Professional Community Policies prohibit false or misleading content. Carry the work state into the first sentence when it affects the claim, because a qualification buried later may not repair an opening that announces an unshipped feature as a finished success.
Tell affected employees or customers directly before any public post about a change that affects them. A story about changing clinic support hours might interest other founders, but current customers need the actual operational notice first, with the dates and options they require. The public explanation can follow once the people affected understand the change.
How do you keep building in public from replacing the building?
Give public updates a limited role in your operating week. A short decision log should make the writing easier; if every product choice requires a performance-ready narrative, the habit is beginning to shape the work in the wrong direction.
Separate product evidence from audience response. A thoughtful comment may reveal a missing use case worth investigating. Treat a popular post about a feature as a research input too, and test need, willingness to pay and usability through your normal product process.
Use a small review table with the original decision, the feedback received, the follow-up action and what remains unknown. If no useful feedback arrives, the post may still have explained your judgment to readers. Record that modest outcome instead of inventing pipeline impact or calling silence validation.
W3C's writing guidance recommends clear sentences and short paragraphs. Those editing practices suit an unfinished-work update: name the task, describe what you observed and keep the next step concrete. Lengthy defenses of your ambition rarely help a reader understand the decision.
A useful stopping rule is to skip the update when the only publishable detail is that you were busy. You can also postpone a story whose details would expose a customer or interrupt a sensitive discussion. The guide to human-sounding AI drafts can help when wording is the bottleneck, but an assistant cannot supply the work or permission behind the story.
Choose one open decision worth documenting this week. Save the evidence privately, publish the part that helps your intended reader and set a reminder to return to the question. That cycle gives early work a useful public record without requiring revenue screenshots, fabricated certainty or a new milestone every day.
Turn your ideas into useful posts
Draft from your own knowledge, check the facts and keep control of what you publish.
