Peer feedback is one of the most valuable things a skill-based community can offer, and most feedback threads fail at both ends. The person asking posts their work with "thoughts?" and gets either silence or "looks great!" Or they get the opposite: six people rewriting it six different ways, half of them about things the person did not ask about and cannot change.
Neither is a problem with your members. Both are problems with the format. This is a guide to setting up peer feedback — critique, reviews, teardowns, whatever your community calls it — so that asking is easy, giving is useful, and people come back to do both. It is about members giving feedback on each other's work; members' feedback on the community itself is a different job, covered in what to do with member feedback.
Feedback threads fail at both ends
The silent thread and the pile-on look like opposites, but they have the same cause: nobody knows what kind of help is wanted.
Faced with a vague request, most members say nothing, because they do not know where to start and do not want to be the one who criticises. The few who do reply fill the gap with whatever they personally care about. The result is either no feedback or feedback on the wrong thing, and the person who asked learns that posting work here is either pointless or painful.
Fix the ask, and most of the reply problem fixes itself.
The ask decides the answer
Give every feedback request the same short shape. It takes a minute to write, and it tells the people reading exactly how to help.
| Line | Example |
|---|---|
| What it is | The sales page for my first course |
| What stage it is at | First draft — the structure, not the wording |
| The one question | Is it clear in the first screen who this is for? |
| What you do not need | Typos and colours; those come later |
The difference between "here is my page, thoughts?" and that request is the difference between silence and three useful replies by evening. The founder guide makes the same point about pitch decks: a pinned post on how to ask is the highest-leverage single post in a founder community.
Say what stage the work is at
Most hurt feelings in feedback threads come from a mismatch of stage. Someone posts a rough first draft to check the direction, and gets line edits on sentences they were about to delete. Someone posts something nearly finished, and gets told to start again.
A rough draft needs feedback on direction: is this the right idea, the right shape, the right audience? A working draft needs feedback on structure. Something nearly finished needs polish, and nothing else. When the asker says which, the people replying can pitch their help at the right level, and the asker can ignore, without guilt, anything aimed at a different stage.
Give before you ask
Every feedback space develops the same imbalance: a group of members who post work and never comment on anyone else's, and a smaller group who give feedback until they burn out. When the givers stop, the space stops.
So make reciprocity the norm from the start. A simple version: before posting your own request, reply properly to two others. It cannot be enforced, and it does not need to be. Say it in the pinned post, do it yourself, and thank people publicly when they do it. Members who have given feedback recently also ask better questions, because they have just seen what a useful request looks like from the other side.
A shape for the reply
Good feedback is short. Give replies a shape as well: one thing that works, one question, and one suggestion.
The first part is not politeness. Saying what works tells the person what to keep, which is half of what they need to know. The question shows you engaged with what they were trying to do rather than what you would have done. And one suggestion, the most important one, is far more useful than ten, because the person can act on it today.
Comment on the work, never the person. "This paragraph loses me" is feedback. "You always overwrite" is not. And unless someone asks for it, do not rewrite their work for them; a rewrite answers a question they did not ask, and takes their work away from them.
Protect beginners from experts
The most damaging feedback in any community is accurate, expert criticism of a beginner's first piece of work. Every point may be correct. The beginner still hears that they are not good enough to be here, and does not post again.
So separate the levels, at least by label. Let members mark a request as a first attempt, and ask experienced members to give one note on those, the single most important one, and to lead with what works. A beginner's first request is a version of a member's first post, and the first reply decides whether there is a second.
The asker gets the last word
Feedback is input, not instruction. The person who asked decides what to use and what to ignore, and they do not owe anyone an explanation. Make that explicit, because it lowers the stakes for everyone: givers can offer an honest opinion without needing it to be followed, and askers can hear it without having to defend themselves.
Then close the loop. Ask people to come back to the thread with the next version: what they changed and which comment made the difference. It is the most motivating thing a feedback giver can see, it shows newer members what good revision looks like, and it turns a one-off request into a record of someone getting better.
Keep it kind without making it useless
Some communities respond to harsh feedback by banning criticism altogether, and end up with a space full of encouragement and no help. The fix is not less honesty but better rules about how it is delivered.
Write the rules down where members will see them — about the work, not the person; one suggestion, not ten; no unrequested rewrites — and make them part of your code of conduct, so that enforcing them is applying a rule rather than taking a side. When someone breaks them, a private word usually does it. A comment that is cruel rather than critical gets removed.
What the software can and cannot do
There is no dedicated critique feature in Mateflow, but the parts fit well.
A Q&A space suits feedback requests: each request is its own post, replies can be upvoted, and the member who asked — or a moderator — can mark the reply they acted on as the accepted answer, which closes the loop in one click. Space topics let members label a request by stage: create topics such as "First attempt", "Rough draft" and "Nearly final", and members pick one when they post, so the people reading can filter to the requests they are best placed to help with. Posts can carry images, video, audio, or documents such as PDFs and slide decks, within a file size limit set by your plan. Pin the how-to-ask post so it sits at the top of the space, and name the space for what members do there: "Get Feedback" tells a member more than "Critique". For a live teardown, run it like office hours, one piece of work at a time, and set the group call's screen sharing to everyone, so members can show their own work.
The honest limits are about the norms. Nothing enforces give-before-you-ask, because there is no way to require a member to reply to others before posting. There is no post template either, so the four-line ask lives in a pinned post that members copy, not in the composer. Both are habits you model, not settings you switch on.
Three things not to do
Do not accept "thoughts?" as a request. Point people to the four-line ask, kindly, every time, until it becomes the way the space works.
Do not let experts open on a beginner's flaws. One note, the most important one, after what works.
Do not ban criticism to stop cruelty. Set rules for how feedback is given and enforce them; a space without honest feedback has nothing to offer.
The bottom line
Peer feedback fails when nobody knows what is being asked, when the same few people do all the giving, and when the first critique a beginner receives is also the last thing they post.
So structure both sides. A four-line ask that says what it is, what stage it is at, and the one question. Replies with one thing that works, one question and one suggestion. Give before you ask. Protect first attempts. And ask people to come back with the next version — because a feedback space where you can watch members get better is the strongest reason anyone has to join it.