CHAPTER 08 • FIELD GUIDE
Product Feedback Loop
How user feedback turns into product improvements and better loops.
1 Lesson Sections • ~4 min read • 828 words.
🎓WHY THIS MATTERSDeep mastery of this section gives you an immediate advantage in architectural decisions and technical interviews.
Overview
This section documents a genuinely useful case study in tight, public, founder-led product iteration - nearly every major feature of the app was described in-thread as originating directly from the field feedback, with visible before/after outcomes:
| Feedback raised by the field | Resulting product change / response |
|---|---|
| Onboarding questions felt too long/effortful for a "low-focus mode" moment (e.g., lying in bed) | Acknowledged directly as valuable, specific feedback |
| No way to skip questions / no "I don't know" button during onboarding | Flagged as a legitimate drop-off risk |
| Only 9 questions available on paid plan felt thin | Led to development of "flash questions" on common topics, more up-front content, and a stated commitment to daily new questions + full backlog access forever |
| No visible way to review past questions | Clarified it already existed (Stats tab -> history squares) but was too subtle/undiscoverable - led to a plan to surface it more prominently in the UI |
| Suggestion: GitHub-heatmap-style visual progress tracker | Confirmed this was already the exact internal design intent before the suggestion was made - a nice validation moment |
| Requests for actual correct-answer explanations on ordering/matching questions, mini-lessons, daily goals/streaks/leveling, and spaced repetition on missed questions | All shipped together in a single major update (mini-lessons with knowledge checks, endless-scroll question mode, daily goals/leveling, and automatic spaced review of missed questions at 3, 10, and 20 days - a concrete, reusable spaced-repetition interval scheme) |
| Multiple-choice questions were beatable by "always pick the longest answer" (a well-known MCQ-writing pitfall - correct answers tend to accumulate extra qualifiers) | Explicitly acknowledged as a known MCQ design flaw and fixed within about a week |
| Request for a "difficulty mode" for harder MCQs | Raised as a considered feature (not confirmed shipped in the archive) |
| Jargon (e.g., WAL - Write-Ahead Log) used without explanation for newcomers to system design | Acknowledged; committed to explaining terms more carefully in future question-writing |
| Requests for networking/OS-focused questions | Confirmed as planned, with a stated skew toward networking over OS topics |
| A "View Resources" button not working on iPad | Investigated; ultimately appeared to be a client-side/one-off issue rather than a systemic bug |
| Highlighting which reordered-question answers were right/wrong (a previously-existing behavior that regressed) | Explicit user request to restore prior behavior |
| Request for a home-screen widget (Duolingo-style streak widget) | Acknowledged as under consideration since launch, with an explicit note the team was new to iOS development and unsure of implementation difficulty |
| Repeating questions too often, and no skip button in "endless practice" mode | Explained as a consequence of the current naive random-shuffle deck algorithm; acknowledged as something to improve, with plans to add more content and revisit the algorithm |
| Interest in company-specific or pattern-specific targeted question sets | Confirmed as a stated future direction, alongside more introductory learning tracks linked to related questions |
Meta-observations about the product philosophy, stated directly by the founders:
- Explicit design goal: avoid over-complicating the app - the stated ideal is "a quick way to practice system design every day and get exposed to the most common patterns," resisting scope creep even when many good feature ideas are suggested.
- On content strategy: an industry expert stated he hasn't found LLMs useful for generating video ideas or question content directly, framing this half-jokingly as actually a good thing competitively (keeps his content differentiated). His actual process for both video topics and question curation is grounded in real situations he's personally experienced or seen other engineers face, aided by talking to a large number of working engineers regularly, which gives him a high "surface area" of real material to draw from.
- On video delivery style (asked directly by an experienced professional wanting to learn to communicate technical material as cleanly): an industry expert doesn't script videos - he finds it hurts natural delivery and is painful to execute verbatim. Instead he builds a loose outline (which becomes the on-screen slides) using a recursive "keep asking the natural next question" method: pick an important topic, ask the most basic question about it (e.g., "SQL vs. NoSQL?"), then keep asking the natural follow-up question the way the trade-offs would keep raising a next question in a real system-design discussion, recursing until the topic feels sufficiently covered. In editing, he aggressively removes dead space between clips to keep viewer attention pulled forward.
- On dealing with feature requests thoughtfully rather than reactively: several requests were explicitly evaluated and partially pushed back on rather than blindly implemented - e.g., a suggestion for widgets showing "the question" or "stats" was met with a counter-preference from another experienced professionals for something simpler and more emotionally engaging (a pure streak-preservation widget, à la Duolingo), which was treated as valid, better-scoped input rather than dismissed.
KEY CHAPTER TAKEAWAYS
Explicit design goal: avoid over-complicating the app - the stated ideal is "a quick way to practice system design every day and get exposed to the most common patterns," resisting scope creep even when many good feature ideas are suggested.
On content strategy: an industry expert stated he hasn't found LLMs useful for generating video ideas or question content directly, framing this half-jokingly as actually a good thing competitively (keeps his content differentiated). His actual process for both video topics and question curation is grounded in real situations he's personally experienced or seen other engineers face, aided by talking to a large number of working engineers regularly, which gives him a high "surface area" of real material to draw from.
On video delivery style (asked directly by an experienced professional wanting to learn to communicate technical material as cleanly): an industry expert doesn't script videos - he finds it hurts natural delivery and is painful to execute verbatim. Instead he builds a loose outline (which becomes the on-screen slides) using a recursive "keep asking the natural next question" method: pick an important topic, ask the most basic question about it (e.g., "SQL vs. NoSQL?"), then keep asking the natural follow-up question the way the trade-offs would keep raising a next question in a real system-design discussion, recursing until the topic feels sufficiently covered. In editing, he aggressively removes dead space between clips to keep viewer attention pulled forward.
KNOWLEDGE CHECK