User testing in production: how to run a public beta
summary
Explains when to run a public beta (MVP that actually solves new user problems), why it must be opt-in and reversible, and how a year‑long IDE beta at Anvil used a docs toggle to show two realities. Covers concrete feedback channels—forums, email, in‑product prompts, scheduled user interviews—and a workflow that sorts issues into five feedback categories (broken, UX surprise, opinion, feature requests, demand) so teams can track, act, and announce fixes.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 0:48Background
- 9:15When should you use one
- 13:51When should you start one
- 15:59Documentation
- 21:06User feedback
- 25:11What to do with feedback
- 32:33Communication
- 34:57Things can go wrong
- 39:34When do you know
- 43:26Feedback
related talks
47mUser testing in production: how to run a public beta
44mUser testing in production: how to run a public beta
32mZero to Test, How to Run Your First Beta Testing Program
23mAPI users' feedback: why and how you get it
25mTIMING OF USABILITY TESTS
46mBeta testing. Change course in flight
15mPut On Your Product Hat When Championing an Internal Tool
56mKEYNOTE: If the Users Can’t Use It, It Doesn’t Work