Files
SlipItIn/.github/skills/revenue-centric-design/references/product-strategy-and-features.md
Tim Krampitz 01046b01e4 Neue Skills, Referenzen & OpenWiki-Doku integriert
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.
2026-07-26 14:00:58 +02:00

59 lines
8.6 KiB
Markdown

# 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](https://x.com/richardrx/status/2059236567533650119)
## 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](https://x.com/richardrx/status/2057162392048476345)
## 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](https://x.com/richardrx/status/2057124008445796659)
## 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](https://x.com/richardrx/status/2039399756452057159)
## 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](https://x.com/richardrx/status/2034248739557159293)
## 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](https://x.com/richardrx/status/2033880553607364684)
## 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](https://x.com/richardrx/status/2031722047080960265)