Umfangreiche Erweiterung der Skill-Bibliothek: Neue Skills für Humanisierung (Englisch/PT-BR), Design-Validierung, AI-SEO und Coolify-Deployment inkl. Regelwerke, Presets, Pattern-Referenzen, Testfälle und Automatisierungsskripte. Zusätzliche Skills für Revenue-Centric Design, Pier Cloud, OKF, Lebenslauf- und LinkedIn-Optimierung sowie zahlreiche Referenzdateien, Checklisten und YAML/JSON/Markdown-Templates. Einführung einer vollständigen OpenWiki-Dokumentation mit Architektur-, Domain- und Workflow-Beschreibungen, zentralem Index und automatisierten Updates. Modularer Aufbau, restriktive Lizenzen und umfassende Qualitäts- und Evaluationsmechanismen für alle neuen Inhalte.
8.6 KiB
Product Strategy & Feature Discipline
Curated, distilled wisdom from @richardrx ("Richard — Design for startups"), translated from Portuguese. Each entry is a reusable principle linked to its source post.
Run every feature through a two-layer "Swiss Knife filter" before building
Principle. A feature you ship stays forever and charges rent forever, so the right question isn't "is this good?" but "does it deserve the permanent cost it imposes on the product?" Apply when. A roadmap item feels appealing but nobody applied a filter before committing to build. The move. Layer 1 — does it deserve to exist? Pass all four: (1) cognitive load (more surface = more to learn + Hick's law decision time); (2) ICP specificity (a CRM for facial-aesthetics clinics charges 5x a generic one); (3) operational cost (maintain/support/document, not build); (4) reinforces the core claim. Layer 2 — build now? Two axes: easily rejectable (clear "no"?) and easily implementable (cost to the validating version, not the dream version). Build the no-brainers first; fail any of the four, kill it guilt-free. To rank survivors, score (New Users + New Revenue + Impact Level) / Effort. Visual. Prioritization scoring table: (New Users + New Revenue + Impact Level) / Effort = Score Voice. "Every feature that gets in, stays. And it charges rent forever." Source. @richardrx · 2026-05-26
Feature adoption is a design problem, not a communication problem
Principle. Shipping a feature doesn't make it discovered; users move through their habitual path and never see what they aren't looking for. Apply when. Three weeks post-launch only ~9% of active users opened the feature and ~4% used it twice, despite changelog, email, and "new" badges. The move. Stop treating adoption as announcement. The killers are inattentional blindness (users don't see what they aren't seeking) plus status-quo bias (re-learning cost outweighs perceived benefit even when the new way is better). Instead: directional empty states that surface the feature where it'd be used; triggered onboarding fired by the behavior that signals need (CRM user hits the sales page → introduce the objection-busting AI); and a feature adoption rate metric measuring habit/appropriate frequency, not clicks. Anything below an adoption threshold goes back into review. Voice. "Launching a feature is easy; getting it used is a whole other thing." Source. @richardrx · 2026-05-20
Compute your Swiss Knife Index to expose feature creep
Principle. A product's worth is measured by features actually used, not features shipped; a bloated product is expensive to sustain and hard to sell, not rich. Apply when. The roadmap has become a user wishlist and every new feature feels like progress (especially with AI making building cheap). The move. Swiss Knife Index (SKI) = (features used by >40% of active users in a 30-day window) ÷ (total features). Below 0.3, you own a clumsy Swiss army knife. Fix it with: quarterly audits on real usage data (not team opinion); hide, don't delete (push rarely-used features into advanced settings — reachable for the 3%, gone for the 97%); and a gate on every new feature — "which existing feature do I kill to make cognitive room?" Litmus test: which feature would you show first with 30 seconds to sell? The rest stays invisible until needed. See the academic grounding (2034248739557159293) and the curve (2033880553607364684). Visual. SKI curve — perceived utility rises then declines past the optimal point as complexity keeps climbing Voice. "Which feature would I show first if I had 30 seconds to sell the product?" Source. @richardrx · 2026-05-20
Design the attention hierarchy to direct behavior, not just organize info
Principle. A product that organizes delivers access; a product that directs delivers activation — and the visual hierarchy decides which the user gets. Apply when. "My interface looks good, but people don't use the main features" — and the key feature is buried behind three clicks the user will never make. The move. Recognize that attention hierarchy is the structure deciding what users see first, find with effort, or never discover. Built without intent, the product sabotages itself: users use what's most salient, which is rarely what retains. Plan the hierarchy to influence behavior — make the value-driving, retention-driving feature the most prominent thing — instead of merely arranging information neatly. Visual. A typographic demo (huge headline "YOU WILL READ THIS FIRST") proving the eye follows visual weight, not reading order Voice. "A well-designed attention hierarchy makes the user use what retains; a bad one makes them use what's most salient." Source. @richardrx · 2026-04-01
Ground feature discipline in the academic feature-fatigue research
Principle. Past a cognitive-load threshold, the subjective evaluation of a product doesn't stay neutral — it declines into frustration, confusion, and task abandonment, directly hitting CAC and LTV. Apply when. You need the evidence behind cutting features, and want to separate pre-purchase appeal from post-purchase utility. The move. Apply the SKI as a decision criterion grounded in feature fatigue. More features help pre-purchase comparison via distinction bias but hurt the decision via analysis paralysis (more options = longer decisions and more no-decisions; no decision, no conversion). Each extra feature steepens the learning curve — measurable B2B productivity loss — and when value comes slowly, users silently churn before the trial ends, blaming themselves, not the product. This complements the index (2057124008445796659) and the curve (2033880553607364684). Evidence. Thompson, Hamilton & Rust (2005), "Feature Fatigue," JMR 42(4); distinction bias (Hsee & Zhang 2004); analysis paralysis (Iyengar & Lepper 2000). Voice. "A product that grows without criteria doesn't get rich — it gets expensive to sustain and hard to sell." Source. @richardrx · 2026-03-18
Past the optimal feature count, a technically bigger product becomes functionally worse
Principle. The relationship between feature count and perceived utility is non-linear: there's an optimal point, after which each added feature reduces perceived utility while raising sustaining cost and the learning curve. Apply when. You hear "my interface looks good, but people don't use the main features" — a sign you've passed the optimal point. The move. Read the SKI curve: utility climbs to a peak (~10 features in the example) then falls as complexity keeps rising. The fix isn't more visibility — it's reducing the product's cognitive load so the rest becomes visible again. Criterion: any feature used by under 10% of the active base must justify its existence or leave. There's no universal ideal count — only the ideal for your ICP, context, and device. Visual. SKI graph: green perceived-utility curve peaks at the optimal point (10.3 features, 97), red complexity curve rises monotonically and overtakes utility in the "decline zone" Voice. "A bloated product isn't a rich product — it's a product actively destroying the conversion and retention you paid dearly to win." Source. @richardrx · 2026-03-17
Focus on your core; trying to be "all-in-one" dilutes your value proposition
Principle. Chasing a bigger TAM by going generic destroys retention of your heavy users without converting new ones — the same roadmap mistake in cars and in software. Apply when. The product is tempted to "embrace the world" and become a do-everything tool, abandoning the specific ICP that made it loved. The move. Remember who your ICP actually is and build for them, even at the expense of broad appeal. In software, when UI/UX tries to cover everything, the value proposition dilutes: you wreck heavy-user retention and fail to convert newcomers because you've gone generic. Focus relentlessly on the core. Evidence. Porsche chased China's TAM with generic EVs, abandoning its ICP (visceral flat-six machines); ~€3.9B in losses to reverse the roadmap — operating profit fell from €4,000M (2022) to €40M (9M 2025), margin 18% → 0.2%. [Porsche figures from the quoted post; treat as illustrative.] Voice. "Focus on your damn core." Source. @richardrx · 2026-03-11