The idea and why it works
On 9 November, Medium launched TK, a web writing app where you type "@TK" to ask an AI assistant for help inside your draft. TechCrunch reports that the app "incorporates human feedback in a social layer, the company says": writers can share early drafts with other people to get feedback. It is free for anyone with a Medium account, and users can set access permissions on their work. TechCrunch quotes Medium's announcement of TK calling it "a start of what we believe is required to publish in the AI era". The report does not say how sharing works in detail, for example whether a reviewer needs an account, and gives no usage numbers.
The feature points to a growth mechanism any small product can build, which we'll call the draft-review loop. A writer (or designer, or anyone making something) asks a person for feedback. That reviewer opens the draft inside your product, leaves comments, and sees their comments change the work. Later the reviewer has a draft of their own. Because they already know how easy it was to give feedback in your product, they ask for feedback the same way, and invite their own reviewers. Each request for feedback brings a new person in, and some of those people start creating.
It works because asking for feedback is something people already do, with a real reason to send the link. People share a draft because they want it to be better, so the invitation never reads as promotion. The reviewer arrives with a task, gets value straight away, and leaves with first-hand experience of the product.
Who it's for
This suits builders of any tool where people make something that others should check before it ships: writing apps, newsletter editors, proposal and contract builders, slide tools, landing-page builders, video editors, design tools and AI tools whose output needs a human sign-off. It also suits solo consultants and agencies who send client work for approval through a product they built themselves. It is a weak fit for tools where the output is private or where nobody else ever looks at it.
What you need
Tools: a share link with a "can comment" permission, inline comments anchored to a passage, an email notification to the writer, and a sign-up path that keeps a guest's comments. Most no-code and app stacks can do this with your existing auth provider.
Time: about one to two weeks (our estimate) for a small team to ship the basic version, plus a day to instrument the metrics below.
Cost: mainly build time. Email notifications run on your existing transactional email service.
Step-by-step
Add a "Get feedback" button beside Share. Make the request for feedback a first-class action, with comment-only access as the default. Google has offered exactly this permission for years: its comment-only sharing, introduced in 2011, lets people "view and add comments to your documents without giving them edit access."
Let reviewers comment before they sign up. The reviewer owes you nothing, so every extra field costs you comments. Ask only for a name the first time they comment, and save that name in their browser. Products differ here. Loom's help pages say that leaving a comment on a video's Share page requires signing in, while comments on embedded videos can be left without signing in unless the owner switches that off. Decide which side you are on and test it from the reviewer's chair.
Offer suggestions as well as comments. A reviewer who can propose a specific change feels more useful than one who can only remark on it. In Google Docs, people with comment permission can suggest edits, and the owner gets an email and accepts or rejects each one.
Close the loop for the reviewer. When the writer accepts a suggestion or resolves a comment, tell the reviewer. Seeing that their feedback landed is the moment of value that makes the product memorable.
Give guests a reason to keep their history. After their second or third comment, offer to save their comments and every draft they have reviewed in one place: "Create a free account to keep these and get notified when this draft changes." Keep what they have already done; never make them start again.
Prompt the reviewer to become a writer, once. After the draft is final, show one line: "Working on something yourself? Get feedback the same way." Link it to a blank draft with the "Get feedback" button already visible.
Pre-fill the reviewer's first request. When a former reviewer creates their first draft, suggest the writer who invited them as their first reviewer. The relationship already exists, and returning the favour is natural.
Template / copy / example
Reviewer invite (sent by the writer, editable):
Subject: Could you look over my draft?
Hi Sam, I'm working on my pricing page and would value your eye on it. You can comment straight on the text with no account needed: [Open the draft]. Even two or three notes would help. Thanks, John
First-comment prompt (shown to the guest):
Add your name so Sam knows who left this. That's all we need.
Feedback-landed notification (to the reviewer):
John accepted 3 of your suggestions on "Pricing page". See the updated draft.
Post-review prompt (after the draft is marked final):
Thanks for helping John. Get feedback on your projects from your friends. Sign up here!
The illustrative model
Illustrative maths, not a case study. These numbers are invented to show how the loop compounds; measure your own.
At a very low baseline, suppose each active writer asks for feedback on 2 drafts a month, with 3 reviewers each: 6 invitations. If 70% of reviewers open the draft and comment, that is 4.2 engaged reviewers. If 10% of those start their own draft within 30 days, each writer brings in 0.42 new writers a month. That figure is the k-factor, the number of new users each user generates.
At 0.42 the loop does not grow on its own, because each generation is smaller than the last. It still multiplies everything else: every 100 writers you win through other channels eventually become about 172 (100 divided by 1 minus 0.42). Lift reviewer-to-writer conversion to 15% and k becomes 0.63, so those 100 writers become about 270.
Metrics to watch
Feedback requests per active writer per month. Tells you whether the button is being used.
Reviewer engagement rate: share of invited reviewers who leave at least one comment.
Guest-to-account rate: share of commenting reviewers who save their history.
Reviewer-to-writer rate: share of reviewers who create a draft within 30 days. This is the number that drives the loop.
Second-generation invites: feedback requests sent by writers who arrived as reviewers.
Pitfalls
Signup walls before the first comment. You lose the comment and the reviewer. Ask for the account later, when it gives them something.
Spammy invites. Never send automatic invitations on the writer's behalf or upload their contacts. The writer chooses every reviewer.
Privacy surprises. TechCrunch notes that TK's writing is not encrypted because the app is built for collaboration. Tell writers plainly who can see a shared draft, and let them revoke links.
Pushing the writer prompt too hard. One prompt after the review is helpful. A banner on every visit trains reviewers to ignore you.
Comments that vanish. If a reviewer's comments disappear when they sign up, they will not trust you with their own work.
Variations
Approval flow: for client work, add "Approve" and "Request changes" buttons so the reviewer's decision is recorded.
Async video feedback: let reviewers record a short voice or screen note on a passage.
AI first pass: run an AI review before human reviewers see the draft, so their time goes on judgement and taste.
Review swaps: in a community, pair writers who agree to review each other's drafts.
Related reading: if you want reviewers to get value before any account, see Anonymous first task. For a loop that runs on published output, see the "Made with" badge. When reviewers start working as a team, read the personal-to-team move.
