PIE Framework

Jede Testidee bekommt für die drei Faktoren einen Zahlenwert, aus dem sich ein Gesamtscore ergibt. So entsteht eine vergleichbare Rangfolge, die Bauchgefühl und laute Meinungen im Team dämpfen soll. Chris Goward, Gründer der CRO-Agentur WiderFunnel, schlug PIE 2011 erstmals vor und beschrieb es 2012 in seinem Buch „You Should Test That!“.

Der Begriff „PIE“ steht gelegentlich auch für die akademische Schreibmethode Point, Illustration, Explanation oder für ein Open-Source-Framework für Assessment-Items. Beide haben mit dem CRO-Framework nichts zu tun und sind hier nicht gemeint.

Die drei Faktoren: Potential, Importance, Ease

Die drei Faktoren beantworten unterschiedliche Fragen und dürfen im Scoring nicht vermischt werden.

Vor allem Potential und Importance werden häufig verwechselt: Potential fragt, wie schlecht die Seite heute läuft (Wie viel Potential hat diese Seite noch?).

Importance fragt, wie wichtig die Seite fürs Geschäft ist. Eine Seite kann in einem Faktor hoch und im anderen niedrig punkten.

Potential: Wie viel Verbesserungsspielraum hat die Seite?

Potential misst, wie viel auf einer Seite verloren geht und damit gewonnen werden kann.

Der Wert stützt sich auf Analytics-Signale: hohe Absprungrate, kurze Verweildauer, niedrige Klickraten auf zentrale Elemente, Auffälligkeiten in Session-Recordings, dokumentierte Nutzerprobleme aus User-Research.

Eine Seite mit sichtbaren Reibungspunkten und schlechten Verhaltensdaten bekommt einen hohen Potential-Wert, eine bereits gut laufende Seite einen niedrigen.

Ohne diese Datenbasis wird Potential zur Vermutung. Wer ohne Analytics, Recordings oder Research scort, produziert subjektive Einschätzungen im Zahlengewand.

Importance: Wie geschäftskritisch ist die Seite?

Importance bewertet den strategischen Wert der Seite für das Geschäft, nicht die Erfolgsaussichten eines Tests.

Bewertet werden Trafficvolumen, Umsatznähe und Position im Funnel. Eine Checkout-Seite mit hohem Traffic und direktem Umsatzeinfluss punktet höher als ein Blogpost, auch wenn der Blogpost mehr Optimierungsspielraum bietet.

Genau diese Trennung ist der Grund, warum PIE nicht Confidence misst (wie ICE), sondern Importance. Ein Test kann eine hohe Erfolgswahrscheinlichkeit haben und trotzdem auf einer Seite laufen, die für den Umsatz kaum eine Rolle spielt.

Ease: Wie einfach ist der Test umsetzbar?

Ease umfasst den gesamten Aufwand bis zum laufenden Test: technische Machbarkeit (Codeänderung, Tracking-Anpassung), Designaufwand, Abhängigkeiten von anderen Teams und interne Freigaben. Eine Headline-Änderung über ein Testing-Tool ist einfach umzusetzen. Ein Redesign des Checkouts betrifft dagegen Entwicklung, Design, Legal und Payment und bekommt entsprechend niedrige Werte.

Wer nur die reine Entwicklungszeit bewertet und politische Hürden ignoriert, überschätzt Ease systematisch und bekommt später Reibung bei der Umsetzung.

So berechnest du den PIE-Score

Die Berechnung ist bewusst simpel gehalten. Genau darin liegt die Stärke (Vergleichbarkeit über viele Ideen) und die Schwäche (Scheinpräzision), wenn die Skala nicht sauber geankert ist.

Skala und Formel: Mittelwert oder Produkt

Üblich ist eine Skala von 1 bis 10 pro Faktor, mit dokumentierten Ankerpunkten bei 1, 5 und 10 für jede Dimension. Manche Teams arbeiten mit 1 bis 5, um Scheinpräzision zu vermeiden, denn der Unterschied zwischen einer 7 und einer 8 lässt sich in der Praxis selten begründen.

Die Standardformel bildet den Mittelwert: PIE-Score = (Potential + Importance + Ease) / 3. WiderFunnels ursprüngliche Darstellung nutzt diesen Durchschnitt. Andere Quellen definieren PIE als Produkt (Potential × Importance × Ease). Das spreizt Unterschiede zwischen Ideen stärker, reagiert aber empfindlicher auf einzelne niedrige Werte. Der Mittelwert ist stabiler und leichter zu interpretieren.

Wichtiger als die Wahl selbst ist Konsistenz: Wer heute mittelt und morgen multipliziert, macht historische Scores unvergleichbar. Eines wählen und dabei bleiben.

Wer scort und wie oft neu bewertet wird

Als Sweet Spot für das Scoring gelten drei bis fünf Personen: genug Perspektive, um Meinungsunterschiede sichtbar zu machen, wenige genug, um Meetings handhabbar zu halten. Ein einzelner CRO-Lead, der solo scort, untergräbt den Zweck des Frameworks, weil das Verhandeln über abweichende Bewertungen wegfällt.

Die Top 10 bis 15 Ideen werden alle zwei Wochen im Sprint-Planning neu bewertet, das komplette Backlog quartalsweise. Ein einmaliges Scoring, das dann sechs Monate stehen bleibt, verfehlt den Zweck: Traffic verschiebt sich, Umsatzprioritäten ändern sich, Ideen weiter unten im Backlog gewinnen oder verlieren an Relevanz.

PIE oder ICE oder RICE?

PIE, ICE und RICE sind eng verwandt und werden regelmäßig verwechselt. Der funktionale Unterschied liegt in einem einzigen Faktor, der die Frameworks für unterschiedliche Situationen brauchbar macht.

Der entscheidende Unterschied zu ICE: Importance vs. Confidence

ICE (Impact, Confidence, Ease) wurde von Sean Ellis geprägt. Der Kernunterschied zu PIE liegt im mittleren Faktor: PIEs Importance beschreibt den strategischen Wert der Seite, ICEs Confidence beschreibt das Vertrauen des Teams, dass genau diese Variante gewinnt.

Damit arbeiten die beiden Frameworks in unterschiedlichen Phasen. PIE greift früher und hilft zu entscheiden, welche Seite Aufmerksamkeit verdient. ICE greift später, sobald konkrete Varianten skizziert sind und das Team eine Meinung zur Erfolgswahrscheinlichkeit hat. Als Faustregel: PIE lohnt sich, wenn die Diskussion um „welche Seite fassen wir an?“ kreist, ICE, wenn die Seite feststeht und über konkrete Hypothesen entschieden wird.

Wann RICE (und PXL) besser passen

RICE (Reach, Impact, Confidence, Effort) stammt von Sean McBride bei Intercom und ergänzt Reach als vierten Faktor. Damit wird RICE relevant, sobald Ideen unterschiedlich große Zielgruppen betreffen, etwa im Produktmanagement, wo ein Feature 5 Prozent oder 80 Prozent der Nutzerbasis erreichen kann. Bei klassischen CRO-Tests auf demselben Funnel ist Reach oft ähnlich, dann bringt der zusätzliche Faktor wenig.

PXL, entwickelt von Peep Laja bei CXL, ersetzt die 1–10-Skala durch rund zehn binäre Ja/Nein-Fragen, die auf konkreten Evidenzquellen basieren (etwa „wird das Element above the fold verändert?“ oder „belegen Analytics ein Problem?“). Der Aufwand ist höher, dafür streuen die Bewertungen weniger subjektiv. Sinnvoll, wenn das Team beim PIE-Scoring regelmäßig stark auseinanderliegt und die Ergebnisse dadurch beliebig wirken.

PIE im Alltag anwenden

Ein PIE-Prozess funktioniert nur, wenn Backlog, Team und Rhythmus zusammenpassen. Als praktikable Größe gelten 10 bis 30 bewertete Ideen im Backlog: Unter 10 gibt es zu wenig zu priorisieren, über 30 wird die Pflege zäh, Ideen mit niedriger Priorität werden selten neu bewertet und veralten.

Vor dem Scoring braucht jede Idee eine Datengrundlage: Analytics-Auszug für Potential, Umsatz- oder Trafficzahlen für Importance, technische Einschätzung für Ease. Wer ohne diese Basis scort, sortiert Meinungen, keine Hebel.

Nach jedem Test werden die Learnings dokumentiert, auch bei negativem Ergebnis. Ein Test, dessen Resultat nicht festgehalten wird, bringt keinen Lernfortschritt und die nächsten Scores bleiben auf demselben Wissensstand hängen. Testing-Plattformen wie Optimizely und VWO unterstützen PIE nativ in ihren Programm-Management-Modulen, was die Backlog-Pflege erleichtert.

Wo PIE an seine Grenzen stößt

PIE ist ein Priorisierungswerkzeug, kein Wahrheitsapparat. Die 1–10-Bewertungen bleiben subjektiv: Was für eine Person eine 7 für Ease ist, ist für eine andere eine 4. Kalibrierung über dokumentierte Ankerpunkte und Scoring im Team fängt das teilweise ab, hebt es aber nicht auf.

Das Framework gewichtet alle drei Faktoren gleich. In der Praxis ist Importance für die Umsatzwirkung oft kritischer als Ease: Ein aufwendiger Checkout-Test auf einer Seite mit hoher Importance kann mehr bringen als ein einfacher Test in einem umsatzfernen Bereich mit hohem PIE-Gesamtscore. Wer das nicht mitdenkt, priorisiert schnelle statt wirksame Tests. Eine temporäre Umgewichtung ist möglich (etwa Ease höher, wenn Geschwindigkeit zählt, Potential und Importance höher bei sinkendem Umsatz), sollte aber dokumentiert werden und nicht ständig wechseln, sonst lädt das Framework zum Gaming ein.

PIE ist außerdem kein Ökonomie-Modell. Es berechnet weder LTV/CAC noch Marge oder Payback und ersetzt weder Experimentdesign noch Sample-Sizing oder statistische Signifikanzprüfung. Es taugt für das relative Ranking innerhalb eines Backlogs, nicht für die Prognose absoluter Umsatzwirkung. Für größere Initiativen mit relevanten Investitionen gehört eine Wirtschaftlichkeitsrechnung daneben, nicht statt PIE.

FAQ