Systeme denken,
Produkte formen,
Dinge die tragen.

Ob Küche, Studio oder Screen: Es war immer dasselbe. Ein Gericht braucht dieselbe Rezeptur wie ein Song: Harmonie, Proportion, den richtigen Moment. Auditiv, visuell, geschmacklich. Ich habe alle drei gelernt. Design war immer meine Sprache.

UX · Product Ownership · Heidelberg Projekte ansehen

REWE-Listung · End-to-End Projekte · UX & Operations · 15+ Jahre Systemdenken

Über mich

Ich habe mit Turbo Pascal angefangen. Nicht weil mich jemand hingesetzt hat, sondern weil mein 386er ohne eigene Boot-Tools gar nicht erst lief. Ich wollte spielen, also musste ich zuerst bauen.

Das Muster war damit gesetzt. Egal wo ich gelandet bin: Küche, Studio, Boden, Screen. Ich bin reingegangen, habe verstanden wie das System funktioniert, und angefangen die Stellen zu reparieren, an denen es unter Druck bricht. Nicht als Beobachter von außen. Immer mittendrin.

Ich habe in vielen Kulturen gelebt, nicht daneben. Nicht als Tourist, nicht als Gast. Ich gehörte dazu. Das trainiert etwas, das kein Studium ersetzt: ein Radar für Spannungen. Wo redet jemand an jemandem vorbei. Wo ist das beschriebene Problem nicht das eigentliche. Wo fehlt die Perspektive, die noch keiner eingenommen hat.

Die Küche hat mich gelehrt was kein Studium lehrt: Qualität entsteht unter Druck, nicht trotzdem. Seit 1999 produziere ich Musik. Ein Mix ist ein Feedback-System: zu viel von einem Element, und das Ganze kollabiert. Der Boden kam durch Farm-to-Table und eigene Züchtungen. Fermentation lässt sich nicht beschleunigen. Man kann nur die Bedingungen schaffen. Und warten.

Das alles war kein Umweg. Es war immer dasselbe: in Systeme reingehen, das Problem hinter dem Problem finden, zwischen Perspektiven übersetzen. Ich muss eine Perspektive nicht teilen, um sie vollständig zu begreifen. Das macht mich zu einem natürlichen Mediator in Teams, die an Kommunikation scheitern, nicht an Kompetenz.

Jetzt übersetze ich das in digitale Produkte.

Fokus
UX Design · Product Ownership
Tools
Figma Notion Jira Miro Ableton
Sprachen
DE · FR · EN
Ort
Heidelberg · Remote
Status
Offen für Projekte

Gearbeitet für & mit

Akai Professional Numark Matchachin Tausendkraut Europäischer Hof Heidelberg

Eine Linie. Viele Amplituden.

Identität ist kein Zustand, sie ist ein Verlauf.

Phase 01Code & MaschineTurbo Pascal, BASIC. Boot-Tools für den 386er, weil es sonst nicht lief.
Phase 02Küche & DruckInternationale Restaurants. Mise-en-place als Prozesslogik.
Phase 03 · 1999Sound & DesignCubase, Ableton, erste Releases. Graffiti, Photoshop, Flash.
Phase 04 · 2010Sounddesign & BodenKlang als Gestaltungsmittel. Farm-to-Table. Geduld als Methode.
GegenwartUX / POFigma. Prototypen. Epics. Research. Iteration.
RichtungSystemdesignNachhaltige digitale Produkte. Kreativität und Struktur als ein Gedanke.

Arbeiten, die etwas bedeuten.

Kein Showcase für den CV. Projekte, die zeigen wie ich denke.

Ein RTD-Getränk von der Hypothese bis zur Listung, komplett in Eigenregie. Die Ausgangsfrage war nicht "wie sieht es aus", sondern wer kauft es, warum, und in welchem Moment.

Persona-Arbeit, Rezepturentwicklung, Branding, Sounddesign für POS: alles als ein zusammenhängendes System.

Ergebnis: REWE-Listung im Energy-Segment.

Rolle
Founder · Product Owner · Brand Lead
Zeitraum
18 Monate · End-to-End
Kompetenzen
Produktstrategie Persona Research Brand System Sounddesign GTM
Matchachin im REWE Regal Matchachin REWE Listung Matchachin Website UX Matchachin Flasche

Im Regal. Auf dem Screen. Für real.

UX, Webshop, Lager, Produktion: alles ein System. Das kostet Geld, Zeit und Kundenerfahrung.

Ich habe den gesamten Stack von der Markenlogik bis zur Lagerverwaltung als eine zusammenhängende User Journey konzipiert.

Ergebnis: Klar strukturierte Prozesse zwischen Webshop, Lager und Produktion.

Rolle
Product Owner · UX Lead · Operations
Kompetenzen
End-to-End PO UX/UI Systemdesign Operations

Logodesign, Markenführung, Website. Die zentrale Entscheidung: Reduktion als Aussage, nicht als Mangel.

Jedes Element wurde daraufhin geprüft ob es das Markengefühl stärkt oder verwässert. Was nicht bestanden hat, wurde gestrichen.

Ergebnis: Reduziertes Brand-System mit klarer Markenidentität.

Rolle
Brand Lead · Designer · Web UX
Kompetenzen
Logodesign Brand System Web UX

Marketing-Assets für professionelle Audiotechnologie. Technische Tiefe zugänglich machen ohne sie zu vereinfachen.

Mein Vorteil war der Hintergrund im Sounddesign. Ich musste das Produkt nicht erst verstehen. Ich kannte es.

Ergebnis: Technische Inhalte verständlich und markenkonform strukturiert.

Rolle
UX · Content-Strategie · Sound
Kompetenzen
Informationsarchitektur UX/UI Sounddesign

Zwei Projekte. Vollständig durchdacht.

Vom Problem bis zum Ergebnis. Was ich entschieden habe, warum, und was ich daraus gelernt habe.

01

HNTZ App

Phenotype Hunting Tracker. Mobile-First Web App für datengetriebene Phänotyp-Selektion in der Pflanzenzucht. Von der ersten Idee zum skalierbaren Produktsystem.

Product Strategy UX/UI Design React · Supabase Design System Pivot Solo — PO + Design + Dev
HNTZ

Hunts · Tracks · Perfects.

Phenotype Discovery System. Von der ersten Skizze zum datengetriebenen Selektionswerkzeug. Diese Case Study dokumentiert die komplette Produktevolution eines Systems, das ich als Solo-Designer, Product Owner und Developer von Grund auf gebaut habe.

Product Owner UX/UI Design Frontend Dev Domain Expert
Closed Beta
01

Projektüberblick

Was HNTZ ist, welches Problem es löst und für wen es gebaut wird.

Professionelle Züchter haben ein Datenproblem, kein Tagebuch-Problem. Beim Phenotype Hunting werden 5 bis 20 genetisch verschiedene Pflanzen derselben Sorte parallel aufgezogen. Das Ziel: den einen überlegenen Phänotyp identifizieren, den sogenannten Keeper. Die Entscheidung basiert auf dutzenden Metriken über 7 Wachstumsphasen.

Die bestehenden Lösungen versagen an genau diesem Punkt. Journal-Apps sind Lifestyle-Tagebücher: ein Foto, ein Kommentar, fertig. Sie behandeln Pflanzen als Content, nicht als genetische Entitäten mit messbaren Attributen. Die Alternative ist Excel. Manche Züchter bauen sich eigene Spreadsheets. Das funktioniert, aber es skaliert nicht und die Dateneingabe am Smartphone zwischen Pflanzen ist eine Katastrophe.

HNTZ löst das durch ein System, das jede Pflanze als diskretes Datenobjekt über alle Phasen trackt und am Ende algorithmisch vergleichen kann, welche Phänotypen sich ähneln.

29
Components
7
Phasen
6
DB Tables
3
AI Features
6
Beta Tester
02

Problem Space & Wettbewerbsanalyse

Warum kein existierendes Tool das Problem löst.

KriteriumHNTZJournal-AppsExcel / Sheets
Per-Plant TrackingEinzelpflanze als EntityZyklus-Level, keine IsolationManuell, fehleranfällig
Phasen-Metriken7 Phasen, je eigene SkalenKeine phasenspezifischen FelderMöglich, enormer Setup
Pheno-VergleichAlgorithmisch (Bayesian Weighting)Nicht vorhandenManuell visuell
Mobile DateneingabeBottom-Sheet Sliders, One-ThumbAkzeptabelUnbrauchbar am Handy
Stammbaum / LineageVisuelles Lineage-MappingTextfeldManuell
AI IntegrationVoice, Photo, Import AIKeineKeine
ZielgruppePhänotyp-Tester, Pro-ZüchterHobby-Anwender, SocialData-affine Züchter
Zentrale Erkenntnis

HNTZ konkurriert nicht mit Journal-Apps. HNTZ konkurriert mit dem selbstgebauten Spreadsheet erfahrener Züchter, das zwar mächtig ist, aber kein Interface hat. Die echte Konkurrenz sind Happy Valley PhenoHunter (iOS, 2K Downloads), Grow with Jane (500K, aber kein Per-Plant Tracking) und PLNTRK (QR/NFC-basiert, aber kein Similarity-Scoring).

03

Erste Version — Cream UI Prototyp

Der Ausgangspunkt. Die Annahmen, die Designentscheidungen und die Interface-Konzepte der Version 1.

Die erste Version lief unter dem Namen Phenohunter auf phenohunta.netlify.app. Das Design basierte auf einer Cream/Apricot-Palette, die bewusst gegen den branchentypischen Dark-Look entwickelt wurde.

Die UX-Annahmen der ersten Version:

1. Ein Grow ist die zentrale Entity. Alles hängt am Grow.
2. Eine warme Cream-Palette funktioniert unter Pflanzenlampen besser als Dark UI.
3. Eine 3-Tab-Navigation (Home, Strains, Phenos) reicht für den Kern-Flow.
4. Slider-basierte Metriken (0–10) eliminieren das Tastatur-Problem.
5. Die Phasen-Timeline steuert, welche Metriken sichtbar sind.

Phenohunter v1 Home Screen mit Cream-Palette

HOME v1 Dashboard mit 4 KPI-Tiles, CTA und Grow-Cards. Cream-Palette mit Apricot-Akzenten. Emoji-basierte Phase-Badges.

Phenohunter v1 Grow-Übersicht mit Phasen-Timeline

GROW v1 Grow-Detail: Phasen-Timeline steuert den Kontext. Plant-Grid mit manueller Gruppierung. Status-Indikatoren (Gesund, Issues, Gruppiert, Elim.).

Phenohunter v1 Blütephase mit 10 kontextspezifischen Metriken

CONTEXT v1 Blüte-Phase expandiert: 10 phasenspezifische Metriken (Blütestart, Blütenstruktur, Harzproduktion, Trichom-Köpfe, Aroma, Aroma-Typ, Farbe, Kelch/Blatt-Ratio, Blüte-Vigor). Kontextuelle Reduktion als Kern-UX-Pattern.

Phenohunter v1 Curing Observation mit Slider-Metriken

INPUT v1 Plant-Detail als Bottom-Sheet: Curing-Observation mit Slider-Metriken (Trockengewicht, Cure-Aroma, Geschmack, Wirkung-Typ, Wirkung-Stärke). One-Thumb-Eingabe.

Phenohunter v1 Stammbaum-Visualisierung

LINEAGE v1 Stammbaum-View: Visuelles Lineage-Mapping mit Züchter-Attribution (Cookie Fam, Sherbinski, Seed Junky). Genetische Herkunft auf einen Blick.

04

Kritische Analyse — Was nicht funktionierte

Ein System-Audit nach den ersten Beta-Tests deckte fundamentale Architektur- und UX-Probleme auf.

Grow-zentrische Architektur
Das System war um Grows herum gebaut. Phenos waren untergeordnete Objekte. Problem: Ein Phänotyp existiert über Grows hinweg. Wenn ein Grow gelöscht wird, sterben die Pheno-Daten mit (CASCADE Delete). Das ist konzeptionell falsch.
GrowScreen-Monolith
535 Zeilen, 55% aller Datenbank-Schreiboperationen in einer Komponente. Nicht testbar, nicht wartbar, nicht erweiterbar. Feature-Overload in einem einzigen Screen.
Sicherheitslücke (RLS)
Die pheno_groups-Tabelle hatte SELECT using(true) als RLS-Policy. Jeder authentifizierte User konnte die Pheno-Daten aller anderen User sehen. Kritisch für einen Multi-User-Betrieb.
Fehlende Skalierbarkeit
Keine Import-Funktion für historische Daten. Keine Voice-Eingabe. Keine AI-Analyse. Der einzige Datenkanal war manuelle Slider-Eingabe — das skaliert nicht für 200+ Pflanzen.
Architektur-Erkenntnis

Die zentrale Erkenntnis aus dem Audit: Das System war Grow-zentrisch, obwohl es Pheno-zentrisch sein muss. Ein Phänotyp ist kein Ergebnis eines Grows. Er ist eine genetische Eigenschaft, die über beliebig viele Grows hinweg validiert wird. Die Architektur musste diese Realität abbilden.

05

Der Pivot — Design & Architektur Evolution

Rebrand, Design-System-Wechsel und Architektur-Fix. Drei parallele Transformationen.

Transformation 1: Von Phenohunter zu HNTZ. Der Name musste geändert werden — Happy Valley PhenoHunter hält die Marke. HNTZ (ausgesprochen: Hunts) ist kürzer, markenfähig und transportiert die Kernfunktion: das Jagen nach dem perfekten Phänotyp.

HNTZ Branding-Exploration: Logo-Geometrie, Golden Ratio, Farbsystem

BRAND Logo-Exploration: Geometrische Konstruktion mit Golden Ratio. Diamond-Mark referenziert die botanische Blattstruktur. Primary Color #DAB420 als Branding-Akzent.

Transformation 2: Von Cream zu Dark Forest.

Version 1 — Cream UI
  • Palette: Soft Apricot, Dry Sage, Cream (#f3ede3)
  • Logik: Wissenschaftliches Notizbuch, neutraler Lab-Look
  • Typografie: Plus Jakarta Sans (leicht, offen)
  • Navigation: 3 Tabs (Home, Strains, Phenos)
  • Emoticons: Emoji-basierte Phase-Icons
  • Limitierung: Unter Pflanzenlampen zu hell, wirkt generisch
VS
Version 2 — Dark Forest
  • Palette: Deep Forest #1c2f24, Gold #DAB420, Sage #93B48B
  • Logik: Professionelles Tool, eigenständige Markenidentität
  • Typografie: Plus Jakarta Sans (beibehalten, bewährt)
  • Navigation: 4 Tabs (Home, Strains, Phenos, Settings)
  • Status: Farbcodierte Badges statt Emojis
  • Vorteil: Augenfreundlich unter Pflanzenlampen, markenstark
HNTZ v2 Home Screen mit Dark Forest Theme

HOME v2 Neues Dashboard: Grow/Import CTAs, KPI-Tiles, Grow-Dropdown, Top Phenos mit Keeper/Watch-Verdikt und Confidence Score. Dark Forest Palette.

HNTZ v2 Settings Screen mit Beta-Status

SETTINGS v2 Neuer Settings-Screen: Account-Info, Beta-Status mit Limits (3 Grows, 5 Fotos/Pflanze, 5 MB), Feedback-Kanal, Version & Roadmap, Community-Chat (Coming Soon).

Transformation 3: Von Grow-zentrisch zu Pheno-zentrisch.

D1
CASCADE Delete entfernt
Phenos überleben jetzt das Löschen eines Grows. grow_id in pheno_groups wird nullable. Ein Phänotyp gehört nicht einem Grow — er wird durch Grows validiert.
D2
RLS-Policy gefixt
pheno_groups.SELECT von using(true) zu using(auth.uid() = user_id). Multi-User-Privatsphäre gesichert.
D3
FK Constraint hinzugefügt
plants.pheno_group_id bekommt einen echten Foreign Key mit ON DELETE SET NULL. Datenintegrität auf DB-Ebene statt im Frontend.
D4
Settings-Tab eingeführt
4-Tab-Navigation statt 3. Account, Beta-Status, Feedback und Roadmap in eigenem Screen. Entlastet den Home-Screen.
06

Neue Produktarchitektur

Das aktuelle System und wie die Subsysteme zusammenspielen.

UI LayerReact 18 · CDN · Babel29 Components · Mobile-First
SupabaseAuth · RLS · StorageEdge Functions (AI)
PostgreSQL6 Tables + 5 MigrationsJSONB Metrics · Indexes
Pheno EngineBayesian Weighting70% Terpen · 20% Morph · 10% Timing
Observation HubManual · Voice · Photo · Import4 Eingabekanäle
Pheno AtlasConfirmed Phenos · Keeper WallRadar Charts · Verdicts
HNTZ Radar-Chart: Pheno-Visualisierung mit 6 Achsen

RADAR Pheno-Visualisierung: 6-Achsen-Radar (Vigor, Verzweigung, Harz, Dichte, Aroma, Optik). Jeder bestätigte Phänotyp bekommt ein einzigartiges Profil. Visuelle Sofort-Differenzierung statt tabellarischer Vergleich.

Warum Radar-Charts: Ein Phänotyp ist ein multidimensionales Objekt. Tabellen zeigen Einzelwerte. Radar-Charts zeigen das Profil — die Form. Zwei Phänotypen mit identischem Durchschnitt können völlig unterschiedliche Profile haben. Das Radar macht diesen Unterschied sofort sichtbar.

07

UX Prozess — Informationsarchitektur & Flows

Wie die Datenstruktur die Interface-Logik bestimmt.

Die IA folgt der biologischen Realität: User → Grows → Plants → Observations → Pheno Groups. Jede Entität hat eine klare Eltern-Kind-Beziehung. Metriken sind als JSONB gespeichert, weil sich die Attribute je Phase ändern.

Die 7-Phasen-Timeline (Keimung → Sämling → Vegetativ → Stretch → Blüte → Ernte → Curing) steuert, welche Eingabefelder der User sieht. In der Blütephase trackt man Harzproduktion und Trichom-Köpfe. Beim Curing trackt man Aroma-Entwicklung und Geschmack. Irrelevante Felder werden ausgeblendet.

Cognitive Load Strategie — 3 Ebenen:

Ebene 1: Phasen-Gating. Metriken erscheinen nur in ihrer Phase. Trichom-Köpfe sind irrelevant in der Keimung. Das Interface zeigt sie nicht.

Ebene 2: Bottom-Sheet Pattern. Statt einer langen Scroll-Seite öffnet sich ein Modal-Sheet mit allen Metriken für eine Pflanze. Die Aufmerksamkeit bleibt fokussiert auf ein Objekt.

Ebene 3: Slider statt Textfeld. Terpen-Profile und Bewertungen sind 0–10 Skalen. Slider ermöglichen schnelle, konsistente Eingaben ohne Tastatur. Anwender stehen mit erdigen Händen zwischen Pflanzen, nicht am Schreibtisch.

UX-Erkenntnis

Theoretisch 1.400 Datenpunkte pro Grow (20 Pflanzen × 10 Metriken × 7 Phasen). Phasen-Gating reduziert die sichtbare Komplexität um 85%. Der User sieht nie mehr als 10 Metriken gleichzeitig.

08

Feature-Priorisierung

Feature-Priorisierung folgte einer klaren Logik: Pheno-Data-Integrity vor allem anderen. Ohne verlässliche Daten ist kein Vergleich möglich. Ohne Vergleich kein Phenotype Hunting.

Must Have
7-Phasen-TrackingPer-Plant Observation LoggingPheno-Grouping (Bayesian)Supabase Auth + RLSMobile-First Slider-InputPheno Engine Pipeline
Should Have
Stammbaum-VisualisierungVoice Observation InputGrow Report Import (AI)Radar-Chart VisualisierungKeeper/Watch Verdicts
Could Have
Photo-AI Trait ExtractionPDF/Excel ExportMulti-Strain GrowsOnboarding Wizard
Won't Have (Yet)
QR/NFC Plant LabelsCommunity Social FeedSensor IntegrationPublic Pheno Atlas
09

Produkt-Evolution — Neue Features

Vier Systeme, die HNTZ vom Tracking-Tool zum Phenotype Discovery System transformiert haben.

A — Die Pheno Engine

Das Herzstück des Systems. Eine mehrstufige Phenotype Discovery Pipeline mit Bayesian Weighting: 70% Terpene (genetisch am stabilsten), 20% Morphologie (Internodien, Stretch), 10% Timing (Blütebeginn, Trichom-Reife).

Observation Trait Vector Similarity Score Working Group Confirmed Pheno Keeper

Fuzzy Logic: Werte 6 und 7 auf der 1–10-Skala gelten als identisch, wenn das Terpen-Profil matcht. Abweichung > 3 = andere Gruppe. Das verhindert Daten-Fragmentierung durch natürliche Messungenauigkeit.

Phase Migration: Die Engine re-evaluiert Similarity in jeder Phase. Eine Pflanze kann die Gruppe wechseln, wenn die Abweichung über 2 Phasen > 30% beträgt. Das System dokumentiert: "Plant #66 moved from Pheno #2 to #5 (Reason: Terpen Development Phase 6)".

Limit: Maximal 50 Phenos pro Strain. 1.000 Pflanzen resultieren typischerweise in 4–6 bestätigten Phänotypen. Der Atlas bleibt Qualitätssignal, kein Rauschen.

B — Voice Observations

Spracheingabe als primärer Datenkanal. Der Grower spricht eine Beobachtung. Die KI parst den Freitext und befüllt automatisch die Slider-Felder mit strukturierten Metrik-Werten.

„Pflanze 27. Starker Stretch. Citrus-Terpen. Leicht luftige Buds."

→ stretch = 7 · terpene = citrus · bud_density = 4

Das eliminiert den Bruch zwischen Beobachten und Dokumentieren. Grower erfassen Daten, während sie sich durch die Reihen bewegen — nicht danach am Schreibtisch.

C — Grow Report Import

Historische Daten sind ein Asset. Viele Züchter haben jahrelang Daten in Excel-Sheets, CSVs, PDFs oder Textnotizen gesammelt. Das System erlaubt den Upload dieser Dokumente.

Dokument-Upload AI Document Parsing Grow-Struktur rekonstruiert Pheno Engine Matching

Die KI rekonstruiert aus unstrukturierten Dokumenten die Grow-Hierarchie. Enthält ein Dokument keine verwertbaren Phänotyp-Daten, wird der Import abgelehnt. Datenbank-Integrität vor Vollständigkeit.

D — Photo-AI Analyse

Visuelle Merkmale werden maschinenlesbar. Das System analysiert Pflanzenfotos und extrahiert strukturierte Trait-Daten: Bud-Dichte, Farbausprägung, Internodien-Abstand, Blattmorphologie. Diese Werte fließen direkt in die Similarity Engine ein.

Wichtige Einschränkung: Nur visuell erkennbare Merkmale werden extrahiert. Keine Terpen-Profile, keine Wirkung. Das System ist ehrlich über seine Grenzen.

10

System-Diagramm — Datenfluss

Grower Datenquelle GrowRun Zuchtzyklus Plants Einzelpflanzen Observations Strukturierte Metriken Pheno Engine Bayesian Weighting Working Groups Pheno Candidate Validierung Confirmed Pheno Bestätigter Phänotyp Pheno Atlas Radar · Referenz-Katalog Keeper Wall Selektions-Entscheidung Voice Input Spracheingabe Fotos AI Image Analysis Grow Report AI Document Parsing AI-EINGABEKANÄLE DATENFLUSS OUTPUT

HNTZ transformiert Grow-Beobachtungen in Phänotyp-Entdeckungen. Vier Eingabekanäle (manuell, Voice, Photo, Import) füttern den Observation Hub. Die Pheno Engine clustert, validiert und produziert bestätigte Phänotypen.

11

Strategisches Produktdenken

Warum das System so aufgebaut ist und wie es langfristig skaliert.

Zero-Build-Step Architecture. React 18 via CDN, Babel-Transpilation im Browser. Kein Webpack, kein Vite, kein package.json. Bewusste Entscheidung: Als Solo-Developer war Iteration Speed wichtiger als Engineering Best Practice. Eine HTML-Datei editieren und deployen in Sekunden. Das Risiko: keine Tree-Shaking, kein Code-Splitting. Akzeptabel für die Beta-Phase.

Closed Beta Strategie. 6 Tester (darunter ein prominenter Züchter der Szene), 3 Grows Limit, 5 Fotos pro Pflanze. Das Beta-Limit ist kein technisches, sondern ein strategisches Constraint. Es zwingt zur Priorisierung: Welche Grows sind wirklich Pheno-Hunts, welche sind nur Hobby-Grows? Das filtert die Zielgruppe automatisch.

Community Layer (geplant). Die Pheno-Datenbank wird das eigentliche Asset. Wenn Züchter ihre bestätigten Phänotypen teilen können, entsteht ein globaler Pheno-Atlas. Die architektonische Voraussetzung (pheno_groups als eigenständige, nicht-cascade Entity) ist bereits geschaffen.

Produkt-Positionierung

HNTZ ist kein Grow Diary. Es ist ein Phenotype Discovery System. Das Interface existiert, um strukturierte Daten zu erfassen, die algorithmisch verglichen werden können. Jeder Screen, jeder Slider, jeder Eingabekanal dient einem Zweck: die Entscheidung, welche Pflanze ein Keeper ist, von Bauchgefühl auf Daten zu verlagern.

12

Ergebnis & Learnings

Version 1 (Phenohunter)
  • Grow-zentrische Architektur
  • Cream UI, Emoji-Phase-Icons
  • 3-Tab-Navigation
  • Manueller Pheno-Vergleich
  • Ein Eingabekanal (Slider)
  • Keine Import-Funktion
  • Sicherheitslücke in RLS
Version 2 (HNTZ)
  • Pheno-zentrische Architektur
  • Dark Forest Theme, professionelle Marke
  • 4-Tab-Navigation + Settings
  • Bayesian Pheno Engine (algorithmisch)
  • 4 Eingabekanäle (Slider, Voice, Photo, Import)
  • AI-gestützter Grow Report Import
  • Korrekte RLS + FK Constraints
Domain Expertise
Ich habe 5 Jahre lang Phänotypen für spezialisierte Zuchtbetriebe getestet. Ich wusste nicht theoretisch, was ein Züchter braucht — ich wusste es, weil ich selbst der User war. Jede UX-Entscheidung basiert auf Erfahrung, die man nicht durch Interviews substituieren kann.
Architektur vor Features
Das System-Audit deckte auf, dass der Grow-zentrische Ansatz nicht skaliert. Die Entscheidung, zuerst die Architektur zu fixen (CASCADE, RLS, FK) bevor neue Features gebaut werden, war die wichtigste Product-Entscheidung des Projekts.
Feature-Kill ist Arbeit
QR-Labels, Community-Feed und Sensor-Integration waren attraktiv. Sie wurden bewusst gestrichen. HNTZ muss zuerst beweisen, dass die Kern-These stimmt: algorithmischer Pheno-Vergleich schlägt manuelles Bauchgefühl.
02

Matchachin

Natural Energy mit Guayusa. RTD-Getränk, entwickelt und bis zur REWE-Listung verantwortet.

REWE-Listung End-to-End PO RTD · Guayusa Packaging · GTM UX Research
01 Ausgangssituation

Guayusa ist eine Stechpalmenart aus dem ecuadorianischen Regenwald, botanisch verwandt mit Mate. Wirkstoffprofil: Koffein, L-Theanin, Theobromin. In Deutschland 2022 praktisch unbekannt, im Massenmarkt nicht präsent.

Der Energy-Drink-Markt war gesättigt und negativ konnotiert: synthetische Inhaltsstoffe, künstliche Süße, Taurin. Eine identifizierte Lücke: Konsumenten mit klarem Energie-Bedarf, die klassische Energy Drinks aktiv ablehnten, aber keine funktionale Alternative im Kühlregal fanden.

02 Problemdefinition

Nicht: Wie bauen wir ein Tee-Getränk. Sondern: Welcher Konsument hat ein Energie-Bedürfnis, das kein bestehendes Produkt sauber adressiert?

Zielgruppe: 25–40 Jahre, aktiver Lebensstil, informierter Konsum. Trinkt keinen Monster oder Red Bull mehr. Kauft Oatly, aber will nachmittags auch funktionieren.

Zutaten: Guayusa-Tee, Kalamansi, Zitronengras, Apfelsaft, Agavendicksaft. Kein Taurin, keine Farbstoffe, keine künstlichen Aromen.

03 Hypothesen
H1Die Kaufentscheidung fällt nicht am Regal. Sie fällt vorher, wenn jemand den Inhalt kennt und der Marke vertraut.Bestätigt
H2Der Hauptkonkurrent ist nicht anderer Tee. Es ist der Griff zur Dose Monster von jemandem, der eigentlich keinen will.Bestätigt
H3Guayusa als Zutat muss erklärt werden, bevor sie verkauft werden kann.Bestätigt
H4Das Packaging muss Energy-Regal-tauglich sein, ohne die Zielgruppe abzuschrecken, die Energy Drinks ablehnt.Mehrfach überarbeitet
H5REWE ist der richtige Erstzulassungskanal: Reichweite, Biobereich-Nähe, kaufbereite Zielgruppe.Bestätigt
04 Research-Fragen

Welche Konsumenten lehnen Energy Drinks aktiv ab und was trinken sie stattdessen in Situationen wo sie Energie brauchen?

Wie viel Erklärungsarbeit braucht eine unbekannte Botanik damit sie kaufauslösend und nicht kaufhemmend wirkt?

Was kommuniziert auf dem Energy-Shelf Natürlichkeit ohne dabei Wirkungslosigkeit zu signalisieren?

Wie verhält sich die Preisbereitschaft im Vergleich zu synthetischen Energy Drinks vs. Premium-RTD-Tees?

05 Entscheidungs-Konflikte
Natürlichkeit kommunizierenvsEnergie-Performance versprechen

Energie-Claim primär, Natürlichkeit als Begründung sekundär. Reihenfolge der Botschaft entscheidend.

GeschmackskomplexitätvsMassentaugliche Zugänglichkeit

Komplexität behalten, aber Kalamansi auf dem Label erklären. Packaging als Erklärungs-Interface genutzt.

Tee-Shelf: sichere ZielgruppevsEnergy-Shelf: größere Reichweite

Energy-Shelf. Wer Energie sucht, kann überzeugt werden, wenn das Produkt Vertrauen erzeugt bevor er es kennt.

Zwei SKUs zum LaunchvsEine SKU, fokussierte Listungsstory

Eine SKU. Listungsgespräche mit REWE funktionieren mit einer klaren Einheit.

06 Artefakte
Positioning-Matrix
Natural vs. Functional vs. Energy auf zwei Achsen.
PO: Markt-Entscheidungslogik
Shelf Competition Map (REWE)
Kategorisierung der tatsächlichen Regalumgebung.
UX: Kontextanalyse am Point of Decision
Rezeptur-Iterationslog
Version, Testgruppe, Hauptkritik, Konsequenz.
PO: Hypothesen-getriebene Iteration
Packaging-Iterationen (3 Versionen)
Drei Designzyklen mit Testfeedback. Version 1 wurde als "Drogerie-Produkt" beschrieben.
UX: Wahrnehmungstest am Regal-Kontext
Go-to-Market Board
Kanal-Reihenfolge, Begründung, was bewusst zurückgestellt wurde.
PO: Priorisierung unter Unsicherheit
Nutzer-Kontext-Map
Situativ: wann, wo, welche Energie-Alternative wurde bisher gewählt.
UX: Jobs-to-be-done Analyse
07 Iterationen
01

Rezeptur, Durchlauf 1: Zu herb, zu nah an klassischem Tee. Rückmeldung: "Schmeckt gesund aber nicht nach Energie." Konsequenz: Referenzpunkt neu definiert. Nicht Tee-Trinker, sondern Iced-Coffee-Trinker als primäre Testgruppe.

02

Packaging, Version 1: Klares, minimales Design. Testfeedback: "Sieht aus wie Drogerie-Produkt." Energie-Signalsprache, Farbsystem und Claim-Hierarchie komplett überarbeitet.

03

Positionierungs-Pivot: Ursprüngliche Idee war Tee-Shelf. Nach Shelf-Mapping entschieden: Energy-Shelf mit Natürlichkeit als Differenzierer.

04

GTM-Anpassung: POS-Sounddesign im Retailer-Briefing nicht umsetzbar. Ressourcen auf Packaging-Finalisierung und digitale Vor-Kaufstrecke umgeschichtet.

08 Ergebnis

Listung bei REWE im Energy-Segment. Erstkäufer mit Iced-Coffee-Hintergrund konvertierten stärker als Tee-affine Käufer. Bestätigung von H2.

Was nicht funktioniert hat: Guayusa als Zutat war zu unbekannt für spontane Impulskäufe ohne Vorwissen. Die digitale Bekanntheitsstrecke war unterinvestiert.

09 Learnings

Positionierungs-Entscheidungen müssen vor der Rezeptur stehen. Erst den Kaufkontext definieren, dann das Produkt daran ausrichten.

Packaging ist kein Designproblem. Es ist ein Informationsarchitektur-Problem auf 25 Quadratzentimetern.

Eine unbekannte Zutat ist kein Nachteil wenn man sie als Qualitätssignal rahmt. Aber das Framing braucht Fläche und Konsequenz.

Früher. Flash, Photoshop, Straße.

Erst Bleistift. Dann Tabletts. Jetzt Prompts. Das Ergebnis war immer das Gleiche: zu viele Ideen.

Ich betrachte keinen Würfel von einer Seite.
Ich analysiere das gesamte System: User, Stakeholder, Umfeld, Nutzungskontext, Nebenwirkungen.

Personas sind für mich keine isolierten Profile. Sie sind Teil eines lebenden Ökosystems.

Design ist Verantwortung.

KI nutzen kann jeder.
Wissen was man baut, nicht.

Klar gedacht.
Direkt gemacht.

Kein Anschreiben nötig. Eine klare Idee reicht.
Offen für UX- und Product-Rollen sowie projektbasierte Zusammenarbeit.