A simple weekly routine for getting value from a founder community

By Buildside · 2026-10-06

A simple weekly routine for getting value from a founder community is to share one concrete update, ask one focused question, and return to the conversation after people reply. Set aside a short session for it, but don’t force a post when you have nothing useful to ask. A decision you’re still working through gives other founders more to discuss than a polished announcement.

TLDR

Note what changed this week, what decision remains, and what input would help.
Give enough context for another founder to answer without telling your whole company story.
Ask one question tied to a next step, then acknowledge the replies and say what you’ll check.
Leave private customer, team, and business details out of public posts.
When you don’t need input, spend the session responding to someone else.

Why make room for a weekly conversation?

A regular session makes community participation easier to fit around product work. It gives you a moment to notice decisions that might benefit from another founder’s experience: changing an onboarding step, choosing which customer question to investigate, or deciding what to leave out of a first release. None requires a launch announcement.

Compare “Big week for the product—thoughts?” with a note that names a change and the choice still ahead. The first asks readers to guess what you want to discuss. The second gives them a way in. GrowthMentor’s guide to founder communities recommends choosing one or two relevant communities and showing up each week. That’s its advice on participation, not proof that a weekly post will produce a business result.

The point of the routine is to create an exchange. If you can’t write a useful update one week, reading another founder’s question and offering a considered reply is time well spent. You can keep the habit without making everyone else read a post you wrote only to stay on schedule.

A founder organizes a weekly community routine around sharing progress, asking a question, and following up.

Start with three notes from your work

Before opening the community, write down three things privately: what you worked on, what remains unresolved, and what input could affect your next step. Use ordinary descriptions. “We removed two fields from the signup form” tells a reader more than “We’re improving activation.” You can decide later which details belong in a public post.

The last note is the most useful filter. Are you looking for an example of how someone handled a similar choice? Do you want help spotting an assumption? Would a reaction to two options help? Pick one request. If what you really need is a customer interview, private financial advice, or a security review, a founder thread can’t take its place.

Imagine you run a small SaaS tool and have simplified its setup screen. Your private notes might say: “Removed two optional fields”; “Unsure whether to explain integrations before or after account creation”; “Want to hear what other founders considered when placing integrations in onboarding.” This is a hypothetical example, not a Buildside member story or a tested result.

Drafting privately also gives you a chance to strip out details you shouldn’t publish. You can describe a choice without naming a customer, exposing a confidential metric, posting a screenshot with personal information, or revealing a plan your team hasn’t agreed to share.

A notebook shows a concise progress update, a focused question, and space for a follow-up.

Write an update someone can respond to

A good progress update names the starting point, the change, and the uncertainty that remains. It needn’t cover everything that happened that week. If you don’t yet know whether a change helped, say so. Other founders can discuss a work-in-progress without being told it was a win.

For example: “We shortened our SaaS app’s setup form this week because two optional fields seemed better suited to later in onboarding. We haven’t measured whether the change helps new users. I’m deciding when to introduce integrations.” That gives readers the reason for the edit and the decision still open. It doesn’t turn an unmeasured change into a success story.

The Midwest Founders Community’s stated principles ask members to be constructive and to “keep it real,” while recognizing that each person brings something valuable. Those are its own principles, not a promise about how another community will respond. They’re a sound test for your post: describe the work plainly, leave room for other views, and respond to people as peers.

Read your draft as someone who has never seen your product. Add the one sentence of context they need to understand the decision. If you need several paragraphs of company history to make the question work, narrow the question instead. A useful post can be short without being cryptic.

Ask one question tied to your next step

“Any feedback?” makes readers guess what you want from them. A narrower question identifies a choice, a constraint, or an assumption. It also makes replies easier to use: you can judge whether an answer speaks to the decision at hand, even if you ultimately choose another route.

For the setup-flow example, you might ask: “If you’ve built onboarding for a SaaS tool with optional integrations, what made you introduce them before account creation rather than afterward?” You’re asking for relevant experience, not asking strangers to decide what your users want. Their replies may give you ideas to examine; you still need to check those ideas against your own product and customers.

A related example appears in First Round Review’s account of Joseph Quan’s community discovery. Quan interviewed Chief People Officers about networks they already used, what they liked, and how a new community could differ. He was researching how to build a community, not testing this weekly posting routine. The useful connection is the care he took to ask about specific, real experiences instead of inviting broad opinions.

If you can’t name a question yet, you have options. Share the progress without requesting advice, wait until you understand the decision better, or use the session to help another founder. A posting streak isn’t a reason to invent a dilemma.

Name the choice: “We’re deciding between A and B.”
Add the constraint: “We can build only one this month.”
Ask about comparable experience: “What did you consider when you made a similar choice?”

Return to the replies and close the loop

Publishing the update starts the conversation. Come back when you can read the replies properly. Thank people for taking the time, answer requests for missing context, and ask a follow-up when a suggestion depends on a situation unlike yours. You don’t have to follow the most popular recommendation.

Suppose one founder says they introduced integrations early because their users were technical, while another delayed them until users understood the core product. Both replies can be useful without settling your choice. You might say: “That audience difference helps. Our first users are less technical, so we’ll check whether the integration step is distracting them before moving it.” The reply explains your next step without treating either person’s experience as proof about your users.

If you later make a decision, a short follow-up helps others see where the discussion went: “We’re testing the later placement first. I’ll share what we learn when we have something reliable.” You needn’t promise results or a date you can’t meet. While you’re there, look for another founder’s post where a concrete observation or a careful question from you could help.

Some replies will require context you can’t share publicly. Say that you can’t provide those details and describe the decision at a higher level, or move on. For legal, financial, security, and other high-stakes matters, use qualified advice rather than treating a peer discussion as a substitute.

Keep the session small enough to repeat

Choose a time you can usually protect and give it a modest job: review your notes, write or answer one post, and leave room to return to the thread. You might spend a few minutes finding the week’s decision, a few drafting, and the rest reading and replying. That’s a suggested way to divide the time, not a measured ideal.

Keep the three notes in a document or notebook you already use. There’s no need for a special tool. Looking back over them may help you spot which questions needed more context and which decisions called for evidence from customers or specialists instead. If an issue remains open for weeks, you can update the same conversation rather than presenting it as a new problem each time.

Don’t judge a week only by reactions. A reply that exposes a missed assumption may help with your decision more than several quick congratulations. A quiet thread doesn’t prove the question was poor, either; the people with relevant experience may not have seen it. Look at what you can observe: whether readers understood the question, whether the replies addressed it, and whether you learned what to check next.

If participation starts to feel like another publishing obligation, reduce the commitment. Offer one genuine reply this week. Post your own update when there’s a piece of work or a question worth discussing.

Check your post before you publish

Use this quick check after drafting. It should help another founder understand and answer you, without making every update sound alike.

What changed? Name one piece of work, decision, or observation.
What remains uncertain? Choose one issue rather than listing every open task.
What input would help? Tie your question to something you can do next.
What context is essential? Add only what a reader needs to understand the choice.
What should stay private? Remove customer, team, or business details you’re not comfortable sharing.
Who else could use your input? Read another founder’s post and respond if you have something useful to add.
Will you return? Leave time to acknowledge replies and, when possible, say what you plan to check.

Next step

If you’d like to try this routine in a community for founders building in public, visit Buildside’s signup page. Bring one real update and one question, then see whether the conversations fit the way you work.

References

Prepared with AI assistance and linked source research.