MASTER THESIS
zur Erlangung des akademischen Grades
„Master of Science in Engineering“
im Studiengang Innovations- und Technologiemanagement
Agile Produktentwicklung mit Running Lean
am Beispiel eines cloud-basierten Foto-Editors
Ausgeführt von: DI (FH) Franz Buchinger
Personenkennzeichen: 1210301007
1. Begutachter: Dipl.-Ing. Harald Swoboda, MBA
2. Begutachter: Dipl.-Ing. Andreas Hocevar
Wien, Jänner 2014
Eidesstattliche Erklärung
„Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbstständig angefertigt
habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als
solche kenntlich gemacht. Die Arbeit wurde bisher weder in gleicher noch in ähnlicher
Form einer anderen Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht. Ich
versichere, dass die abgegebene Version jener im Uploadtool entspricht.“
Ort, Datum Unterschrift
3
Kurzfassung
Die Entwicklung innovativer Produkte bedeutet häufig die Umsetzung vage formulierter
Bedürfnisse der Kundinnen und Kunden mit noch nicht ausgereiften Technologien.
Während traditionelle, seriell ablaufende Produktentwicklungsprozesse vor dieser ex-
tremen Umgewissheit kapitulieren müssen, versprechen agile Produktentwick-
lungsmethoden wie Lean Startup oder Running Lean Abhilfe: durch iterative Entwicklung
des Produkts und kontinuierliche Einbindung potentieller Kundinnen und Kunden in diesen
Prozess wird das Innovationsrisiko minimiert. Obwohl zahlreiche Referenzen aus Startups
und Innovationsabteilungen das Erfolgspotential agiler Produktentwicklungsmethoden
bezeugen, ist noch wenig über ihre Anwendbarkeit neben dem “Tagesgeschäft” bekannt.
In Bezug auf den in der Softwareindustrie verbreiteten Innovationsprozess stellt dies eine
echte Wissenslücke dar, zumal hier die Entwicklung eines neuen Produktes häufig in Form
von kurzzeitig anberaumten oder neben den Tagesaufgaben durchgeführten Teilzeitpro-
jekten durchgeführt wird. Diese oft als Hackathon, Codefest, 20% Projekt oder pet project
bezeichneten Explorationsprojekte konzentrieren sich auf die Umsetzung als innovativ
empfundener Funktionalitäten beziehungsweise die Erstellung neuer Prototypen. Die mit
echter Produktentwicklung verbundene Marktforschung und Entwicklung von Geschäfts-
modellen fehlt diesen Innovationsbestrebungen, was sich negativ auf die Umsetzbarkeit
ihrer Ergebnisse auswirken kann.
Diese Masterarbeit untersucht die Einsetzbarkeit einer agilen Produktentwicklungsmethode
in einem nebenberuflichen Innovationsprojekt mit dem Ziel der markttauglichen Qualifizier-
ung der Produktidee. Den Hauptteil der Arbeit bildet eine Fallstudie, in welcher der Autor
seine Produktidee eines cloudbasierten Foto-Editors auf Basis der agilen Produktentwick-
lungsmethode Running Lean über einen Zeitraum von sechs Monaten perfektionieren
möchte.
Die Fallstudie zeigt, dass Running Lean eine sehr effektive Methode zur Validierung und
Perfektionierung von Produktideen darstellt und sich besonders für eine nebenberufliche
Anwendung eignet. Klare, gut spezifizierte Prozesse erleichtern auch Produktentwicklungs-
Neulingen die Anwendung und führen rasch zu Ergebnissen. Für die erfolgreiche
Anwendung von Running Lean sind jedoch einige Rahmenbedingungen wie rasch
verfügbare, kostengünstige Prototypen zu berücksichtigen, was die Anwendbarkeit der
Methode beispielsweise bei Hardware-Projekten erschweren kann.
Schlagwörter: Agile Produktentwicklung, Software, Lean Startup, Running Lean, 20%
project, Customer Development, Entrepreneurship
4
Abstract
Developing innovative products often means implementing yet-unknown customer
requirements with still-evolving technologies. While traditional, sequential product
development processes struggle with this high degree of uncertainty, agile product
development methods such as Lean Startup or Running Lean can mitigate the risks of
innovations by iterative product development and continuous customer involvement.
Although a lot of success stories by full-time entrepreneurs and product development
managers indicate the effectiveness of agile methods, little information on the part-time
application of these methods is available.
This imposes a veritable information gap, because many innovation efforts especially in the
IT industry start as part-time or short-term exploration projects. These activities are often
called Hackathon, Codefest, 20% project or pet project and focus on the technical
implementation of new features or prototypes. Thus they lack the customer and market
research activities required for true product development.
This thesis examines whether holistic product development can occur in extra-occupational
innovation projects in order to improve their outcome. In a case study, the agile product
development method Running Lean is applied to such a scenario: While being fulltime-
employed as a software developer in a non-related field, the author tries to bring his
business idea of a cloud-based online photo editor to perfection by following the
Running Lean product development process for about six months.
The case study shows that Running Lean is a very effective method for the perfection of
business and product ideas, especially in an extra-occupational or part-time scenario.
Running Lean is well-suited even for novice entrepreneurs or product development
managers. Its processes are easy to follow, lightweight and quickly yield results. However,
the successful application of Running Lean imposes a few conditions (e.g. continuous
application period, fast prototype iteration times, low-cost production of prototypes) that
might prevent its employment for the development of certain products.
Keywords: Lean Startup, Running Lean, 20% project, Customer Development,
Lean Canvas, Case Study
5
Danksagung
Diese Masterarbeit hätte ohne die großartige Unterstützung zahlreicher Personen und
Organisationen nicht entstehen können. Der Autor möchte sich namentlich bedanken bei
der Internet Privatstiftung Austria (IPA), welche diese Arbeit im Rahmen des
Internet-Innovationswettbewerbs netidee 2013 mit einem Stipendium förderte.
Dipl.-Ing. Harald Swoboda, MBA für die kompetente und unkomplizierte Betreuung
dieser Masterarbeit
Dipl.-Ing. Andreas Hocevar vom OpenLayers-Projekt für wertvolle technische
Hilfestellungen und die Zweitbegutachtung der Arbeit
Lukas Fittl für die Organisation des Lean Startup Circle Vienna, aus dessen
Veranstaltungen sich wichtige Anregungen für diese Masterarbeit ergaben.
Mag. Bettina Riedlecker für die Durchsicht und Korrektur des Manuskriptes
den interviewten Fotoschaffenden, die mir in längeren Gesprächen Rede und
Antwort gestanden sind und so einen entscheidenden Beitrag zur Perfektionierung
meiner Produktidee geliefert haben.
Besonderer Dank gilt meiner Familie und meiner Lebensgefährtin Gabriela Lucano, die
nun eineinhalb Jahre auf meine zeitintensive berufsbegleitende Weiterbildung Rücksicht
nehmen mussten und dies mit sehr viel Verständnis taten.
6
Vorbemerkungen
Diese Masterarbeit berücksichtigt die Richtlinien für gendergerechtes Wording des
Corporate Wording Manuals der FH Technikum Wien in der aktuell geltenden Version 3
vom Februar 2013. Da diese Richtlinien nicht alle Formulierungsaspekte dieser Arbeit
abdecken, hat der Autor folgende Ergänzungen vorgenommen:
Bei den in der Arbeit enthaltenen Interview-Protokollen und Zitaten wurde von einer
nachträglichen Ergänzung beider Geschlechtsformen abgesehen, um die
Authenzität der getroffenen Aussagen zu bewahren.
Nicht gegendert wurden weiters in der Literatur etablierte Fachbegriffe
(„Kundentakt”), um einschlägig vorgebildeten LeserInnen das Verständnis zu
erleichtern.
Ebenso nicht gegendert wurden Bezeichnungen, die sich eindeutig auf
nicht-natürliche Personen beziehen (beispielsweise „Erzeuger von
Digitalkameras”).
„Lean Canvas” ist eine eingetragene Handelsmarke von Spark59 Inc.
„Running Lean” ist eine eingetragene Handelsmarke von O’Reilly Media Inc.
Die in dieser Masterarbeit wiedergegebenen Gebrauchsnamen, Handelsnamen und
Warenzeichen können auch ohne besondere Kennzeichnung Marken sein und als solche
den gesetzlichen Bestimmungen unterliegen.
7
Inhaltsverzeichnis
1 Einleitung ...........................................................................................................10
2 Die Entwicklung von Running Lean ...................................................................13
2.1 Toyota Production System .................................................................................13
2.1.1 Entstehung ........................................................................................................13
2.1.2 Aufbau ...............................................................................................................14
2.2 Lean Startup ......................................................................................................16
2.2.1 Startups und EntrepreneurInnen ........................................................................17
2.2.2 Prinzipien ...........................................................................................................18
2.2.3 Praktische Umsetzung .......................................................................................19
2.3 Business Model Canvas ....................................................................................20
2.3.1 Definition des Begriffes „Geschäftsmodell“ ........................................................21
2.3.2 Bausteine eines Geschäftsmodells ....................................................................21
2.4 Running Lean ....................................................................................................23
2.4.1 Bestandteile .......................................................................................................24
2.4.2 Durchführung .....................................................................................................24
3 Running-Lean-Fallstudie „Entwicklung eines cloud-basierten Foto-Editors“ .......26
3.1 Einleitung und Rahmenbedingungen .................................................................26
3.2 Ausgangssituation .............................................................................................27
3.2.1 Der Einsatz von DSLRs im Workflow des Autors ...............................................27
3.2.2 Camera RAW-Formate ......................................................................................29
3.2.3 Photosharing-Platformen zum Teilen der Bilder .................................................35
3.3 Problemstellung und Lösungsansatz .................................................................37
3.3.1 Ein erster Lösungsansatz ..................................................................................39
3.4 Überführung der Lösung in ein Produkt .............................................................44
3.4.1 Problem und Kundensegmente ..........................................................................45
3.4.2 Unique Value Proposition ..................................................................................46
3.4.3 Solution .............................................................................................................47
3.4.4 Channels ...........................................................................................................47
3.4.5 Einnahmequellen und Kostenstruktur ................................................................49
3.4.6 Wichtige Kennzahlen (key metrics) ....................................................................49
8
3.4.7 Unfairer Vorteil (unfair advantage) .....................................................................51
3.5 Der „Plan A“ als Lean Canvas............................................................................52
4 Test des „Plan A“ ...............................................................................................53
4.1 Testen der Produktidee durch Problem Interviews .............................................53
4.1.1 Vorüberlegungen ...............................................................................................53
4.1.2 Aufbau und Ablauf der Problem Interviews ........................................................57
4.1.3 Ergebnisse der Problem Interviews ...................................................................58
4.2 Abgleich der Kundenerwartungen mit den technischen Rahmenbedingungen ...60
4.2.1 Upload-Geschwindigkeit als potentieller Flaschenhals .......................................60
4.2.2 Beschleunigter Upload der RAW-Photos durch vorherige Kompression ............61
4.2.3 Echtzeit-Processing der RAW-Bilder am Server ................................................63
4.3 Analyse und Diskussion der Problem Interviews ................................................68
5 Umsetzung des „Plan B“ ....................................................................................69
5.1 Der Pivot als Ideen-Kurskorrektur ......................................................................69
5.2 Durchführung des Pivot .....................................................................................71
5.2.1 Analyse der Produktrisikos ................................................................................72
5.2.2 Analyse des Akquisitionsrisikos .........................................................................73
5.2.3 Analyse des Marktrisikos ...................................................................................73
5.2.4 Aktualisierung der Produktidee ..........................................................................74
5.3 Solution Interviews .............................................................................................75
5.3.1 Einsatz von Prototypen ......................................................................................76
5.3.2 Umsetzung des Trelew-Prototyps ......................................................................78
5.3.3 Definition des Preismodells für Trelew ...............................................................83
5.3.4 Durchführung der Solution Interviews ................................................................90
5.3.5 Ergebnisse der Solution Interviews ....................................................................92
5.3.6 Verifizierung der Exit-Kriterien ...........................................................................94
5.3.7 Überleitung in ein MVP – Minimum Viable Product ............................................95
6 Diskussion .........................................................................................................96
6.1 Persönliche Reflexion ........................................................................................96
6.1.1 Positive Aspekte ................................................................................................97
6.1.2 Herausforderungen ............................................................................................98
6.2 Bewertung der Methode „Running Lean“ ......................................................... 101
6.3 Bewertung der Produktidee ............................................................................. 102
9
6.4 Empfehlungen ................................................................................................. 103
6.4.1 Praktischer Einsatz von Running Lean ............................................................ 103
6.4.2 Einsatzkriterien ................................................................................................ 106
6.5 Externe Evaluierung der Ergebnisse ................................................................ 108
7 Ausblick ........................................................................................................... 110
Anhang ........................................................................................................................ 112
Abschrift der Problem Interviews ................................................................................... 112
Interview mit Bernhard Anders, Konzertfotograf .......................................................... 112
Interview mit Daniel Ortner, Fotografie-Dozent ............................................................ 114
Interview mit Paul Meier, Event-Fotograf ..................................................................... 115
Interview mit David Anger, Fotograf und Dozent .......................................................... 118
Interview mit Tobias Krammer, Mediengestalter und Fotograf ..................................... 120
Interview mit Thorsten Brenner, Panoramafotograf und Dozent für Mediengestaltung . 122
Abschrift der Solution Interviews ................................................................................... 125
Interview mit Paul Meier, Event-Fotograf ..................................................................... 125
Interview mit Tobias Krammer, Mediengestalter und Fotograf ..................................... 127
Interview mit Daniel Ortner, Fotografie-Dozent ............................................................ 129
Interview mit Thorsten Brenner, Panoramafotograf und Dozent für Mediengestaltung . 130
Interview mit Oskar Magenschab, Fotografie-Dozent .................................................. 131
Literaturverzeichnis ......................................................................................................... 133
Abbildungsverzeichnis .................................................................................................... 136
Tabellenverzeichnis ........................................................................................................ 137
10
1 Einleitung
„Agil“ – laut Duden bedeutet dieses in letzter Zeit gehäuft auftretende Modewort soviel wie
„von großer Beweglichkeit zeugend, regsam, wendig“. Um uns der praktischen Bedeutung
des Begriffs zu nähern, brauchen wir uns nicht lange mit agiler Softwareentwicklung oder
agilen Innovationsprozessen beschäftigen – es reicht eine kurze Rückbesinnung auf die
Fußballspiele unserer Kindheit.
Sich beim Dribbeln den Ball möglichst weit vorzulegen, mag anfangs als gute Idee er-
scheinen – schließlich kann man ohne Ball schneller laufen und macht so wertvolle Meter
in Richtung Tor. Für die gegnerischen Verteidiger waren solche „Tempo-Dribblings“ aber
ein gefundenes Fressen: der zu weit vorgelegte Ball konnte vom angreifenden Team nicht
mehr kontrolliert und damit leicht abgefangen werden.
Ballführende, die das Spielgerät stets körpernahe bewegten, waren hingegen wesentlich
schwerer auszurechnen: sie konnten Haken schlagen, ihre Laufrichtung ändern oder über-
raschende Pässe spielen. Der Vorteil dieser wendigen, agilen Spielweise lag einerseits
darin, dass der/die SpielerIn den Ball ständig unter Kontrolle hatte und so jederzeit belie-
bige Aktionen starten konnte. Andererseits erlaubte die körpernahe Ballführung eine Kon-
zentration auf die Geschehnisse am Spielfield, wodurch Gelegenheiten wie Stellungsfehler
der gegnerischen Mannschaft besser genutzt werden konnten. Der/die Tempo-DribblerIn
hingegen musste die ganze Aufmerksamkeit auf das Erreichen des vorgelegten Balls
legen - in der Umgebung lauernde Chancen und Gefahren konnte er oder sie gar nicht
wahrnehmen. Oft machte daher nicht die gegnerische Verteidigung, sondern die Outlinie
das mühevolle Tempo-Dribbling zunichte.
Agilität spielt aber nicht nur im Sport, sondern auch bei der Entwicklung neuer Produkte
eine große Rolle. 2001 übersiedelt der junge Softwareentwickler Eric Ries ins kalifornische
Silicon Valley, um für das Internet-Unternehmen There Inc. eine browserbasierte 3D-Welt
zu entwickeln. Er und bis zu 200 weitere Entwickler arbeiten an dem Projekt, das aus
Angst vor Nachahmern unter strengster Geheimhaltung und ohne Kundeneinbindung
durchgeführt wird. Als das Produkt schließlich 2003 unter dem Namen there.com ge-
launcht wird, hat There Inc. bereits über 40 Millionen Dollar in seine Entwicklung investiert.
Ein Jahr später muss das Unternehmen dichtmachen und die meisten seiner Mitarbeiter
entlassen, weil sich there.com als kapitaler Flop erweist.
Ries verarbeitet diese und weitere Erfahrungen als Internet-Unternehmer im 2011 veröf-
fentlichten Buch „The Lean Startup“ (Ries, 2012), das zum Bestseller wird. Er sieht groß
aufgezogene Produkt- und Technologieentwicklungsprojekte als eine der Hauptursachen
für teure Innovationsflops: sie würden häufig unter hohem Aufwand, aber zur Sicherstel-
11
lung von Veröffentlichungstermin und Geheimhaltung mit starrem Zeitplan und ohne Kun-
deneinbindung durchgeführt.
Die Folge seien Produkte und Technologien, die an den Bedürfnissen der Kunden vorbei-
gingen, aber dennoch auf den Markt geworfen werden, in der Hoffnung, die hohen Ent-
wicklungskosten werden doch noch eingespielt. Oft seien sich die Beteiligten schon vorab
des Flops bewusst, machen aber gute Miene zum bösen Spiel, da das Innovationsprojekt
vom Management als „too big too fail“ eingestuft worden war.
Die von Ries kritisierten „Monster-Innovationsprojekte“ ähneln damit den eingangs er-
wähnten Tempodribblern: während diese alle Kraft aufwenden müssen, um den vorgeleg-
ten Ball noch vor den Gegenspielern zu erreichen, wird in den Projekten einem starren, oft
zu ambitionierten Zeitplan hinterhergehechelt. Entwicklungen am „Spielfeld“, die sie in
ihren Bestrebungen unterstützen oder behindern könnten, bekommen beide nicht mit.
Ries‘ Thesen fanden nicht nur in den USA, sondern weltweit regen Widerhall: nach eige-
nen Angaben verfügt die von ihm ins Leben gerufene Bewegung „Lean Startup Circle“ über
80000 Mitglieder, die via Internet oder über die 130 lokalen Anwendergruppen miteinander
in Kontakt stehen. Die „Lean Startup Circle“-Anwendergruppe in Wien konnte in den zwei
Jahren ihres Bestehens 400 Mitglieder gewinnen und damit die meisten wesentlich länger
etablierten Anwendergruppen aus der IT-Szene überflügeln1.
Obwohl Eric Ries‘ Werk sich als bahnbrechend für die internationale Startup-Szene her-
ausstellte, hatten vor allem Startup-Neulinge Schwierigkeiten, seine in der „Lean Startup“-
Methodik zusammengefassten Empfehlungen für schlanke Innovationsprojekte praktisch
umzusetzen. Ries erläutert in seinem Buch vor allem die Vision hinter „Lean Startup“ und
stellt dann die Werkzeuge der Methode in loser, anekdotenreicher Aufzählung vor. Startup-
Neulingen fällt es mitunter schwer, aus diesen manchmal etwas detailarmen Schilderun-
gen eine konkrete Schritt-für-Schritt-Anleitung für ihr eigenes Vorhaben abzuleiten.
Der texanische Entrepreneur Ash Maurya erkannte dieses Problem und entwickelte mit
„Running Lean“ (Maurya, 2012) eine vielverlangte Konkretisierung von Eric‘ Ries Methode.
Wie in einem Tutorial wird der/die Neo-EntrepreneurIn durch den mehrphasigen Produkt-
entwicklungsprozess von „Running Lean“ geführt, der Ries‘ Methoden zudem um den
Lean Canvas erweitert. Dieser grafische Raster unterstützt den/die EntrepreneurIn bei der
ganzheitlichen Erfassung und Weiterentwicklung seiner/ihrer Produktidee.
Der Autor dieser Masterarbeit ist als Software-Entwickler tätig und kam vor vier Jahren
zum ersten Mal mit der agilen Softwareentwicklungsmethode „Scrum“ in Berührung, deren
1
Anzahl der „Entrepreneurs“ auf http://www.meetup.com/Lean-Startup-Vienna/, abgerufen am 23.12.2013
12
Fokus auf Effizienz und Zielerreichung er im Laufe der Jahre zu schätzen lernte. Nebenbe-
ruflich versuchte er sich immer wieder in der Umsetzung innovativer Software-Ideen,
konnte aber aufgrund beschränkter Ressourcen und mangelnder Kundeneinbindung nur
bescheidene Erfolge verbuchen. Nach intensiver Auseinandersetzung mit den Methoden
„Lean Startup“ und „Running Lean“ reifte in ihm der Entschluss, eine der beiden Methoden
im Rahmen der Masterarbeit zur Perfektionierung einer eigenen Produktidee zu verwen-
den. Das Rennen machte „Running Lean“, da es als besonders auf die Bedürfnisse von
Neo-EntrepreneurInnen zugeschnittene Herangehensweise für sein Vorhaben besser
geeignet erschien als der allgemeinere Ansatz von „Lean Startup“.
Die Forschungsfrage dieser Arbeit lautet daher: Eignet sich „Running Lean“ zur berufsbe-
gleitenden Perfektionierung von Produktideen in Österreich? Der Terminus „berufsbeglei-
tend“ bezieht sich dabei einerseits auf aktuell unselbstständig Beschäftigte, die eine vor-
handene Produktidee nebenberuflich perfektionieren und so ihre spätere Selbstständigkeit
vorbereiten möchten. Andererseits wird auf den innerbetrieblichen Einsatz von
„Running Lean“ abgezielt: wenn beispielsweise Mitarbeiter abseits ihrer täglichen Routine-
aufgaben neue Produkte oder Dienstleistungen für ihr Unternehmen entwickeln möchten.
Nach diesen einleitenden Worten folgt nun ein kurzes Theoriekapitel, das den Leser mit
der geschichtlichen Entwicklung und den wichtigsten Begriffen rund um die behandelten
Methoden „Running Lean“ und „Lean Startup“ vertraut macht. Danach folgt die angespro-
chene Fallstudie, welche sich über mehrere Kapitel erstreckt und die Entwicklung der Idee
vom ersten Innovationsimpuls bis hin zur Umsetzung des ersten minimal-funktionalen
Produktes beschreibt. In der abschließenden Diskussion werden die gewonnenen Erkennt-
nisse ausführlich analysiert und konkrete Handlungsempfehlungen abgeleitet.
Wien, im Dezember 2013
Franz Buchinger
13
2 Die Entwicklung von Running Lean
2.1 Toyota Production System
2.1.1 Entstehung2
Japan, 1950: die noch junge Automobilfirma Toyota hatte gerade eine ihrer schwersten
Prüfungen überstanden. Ihr Heimatland zählte zu den Verlierermächten des zweiten Welt-
kriegs, der mühsame Wiederaufbau und die grassierende Inflation hatten die Nachfrage
nach Produkten von Toyota beinahe zum Erliegen gebracht. Das Unternehmen konnte
sich zwar mühsam mit Gehaltsverzichten und Zwangspensionierungen aus der Krise
retten, doch am Horizont drohnte schon das nächste Ungemach: die US-amerikanische
Autoindustrie war der japanischen in Sachen Produktivität und Produktvielfalt weit überle-
gen und würde diese wohl früher oder später vernichten.
Just in diesem Jahr beauftragte der CEO von Toyota, Eiji Toyoda, seinen Produktionsleiter
Taiichi Ono mit einem ehrgeizigen Ziel: er möge die Produktivität von Toyota an jene des
damals führenden Automobilkonzerns Ford angleichen, um Toyota konkurrenzfähig zu
machen. Dies sollte freilich ohne Erhöhung der Produktionsmenge vonstatten gehen. Ono
besuchte in der Folge mehrfach die Ford-Automobilwerke in den USA und traf dort auf die
von Firmengründer Henry Ford geprägte Fließbandproduktion, bei der ein Auto am laufen-
den Band aus zahlreichen Einzelteilen zusammengebaut wurde. Durch standardisierte,
möglichst einfache Arbeitsschritte konnten diese Tätigkeiten auch von ungelernten Ar-
beitskräften ausgeführt werden. Es bestand zudem eine klare Trennung zwischen den pla-
nenden IngenieurInnen und den ausführenden ArbeiterInnen.
Doch Ono nahm auch bedenkliche Fehlentwicklungen in Fords Produktionssystem der
50er wahr: während Henry Ford noch den kontinuierlichen Materialfluss als überlegenes
Fertigungskonzept propagierte, hatten seine Nachfolger weite Teile der Produktion auf die
scheinbar ökonomischere Losfertigung umgestellt: Einzelkomponenten wie Autotüren wur-
den an spezialisierten Produktionsstätten in möglichst großen Stückzahlen produziert und
dann lange Zeit auf Lager gelegt, bis sie schließlich beim Zusammenbau des Autos zum
Einsatz kamen.
Ono erkannte die Schwäche dieses Ansatzes: die Massenlosfertigung mochte zwar die
Kosten pro Komponente drücken, bewirkte aber große Lagerbestände, die auch die finan-
ziellen Ressourcen des Unternehmens banden. Außerdem wurde dadurch die bedarfsge-
rechte Produktion erschwert: das Unternehmen konnte nicht auf kurzfristige Markttrends
reagieren (beispielsweise die vermehrte Nachfrage nach Allrad-Modellen infolge eines
2
Der Inhalt dieses Kapitels folgt der in (Liker, 2003), Teil 1, Kapitel 2 dargelegten Geschichte des Toyota
Produktionssystems
14
besonders strengen Winters), sondern war gezwungen, die lange vorab geplanten Stan-
dardausführungen der Fahrzeuge auf den Markt bringen. Etwas weniger offensichtlich,
aber umso drastischer waren die negativen Auswirkungen der Ford’schen Losfertigung auf
die Produktqualität: Komponenten, die nach ihrer Produktion auf Halde gelegt werden,
tragen ein latent höheres Defektrisiko, als solche, die unmittelbar danach weiterverarbeitet
werden. In letzterem Fall kann der/die WeiterverarbeiterIn den/die ProduzentIn der Kom-
ponente unmittelbar auf den Qualitätsmangel ansprechen (z.B. unsauber geschliffene
Kanten der Autotür), während diese/r nach mehrwöchiger Lagerung auf Halde vielleicht gar
nicht mehr eruierbar ist. Und selbst wenn die Eruierung erfolgreich war, so sind im verstri-
chenen Zeitraum möglicherweise hunderte fehlerhafte Komponenten produziert worden.
Ono erkannte also in der scheinbar ökonomischen Massenlosfertigung der westlichen Au-
tomobilhersteller eine gigantische Verschwendung von Material, Arbeitszeit und finanziel-
len Ressourcen. Im Laufe der folgenden Jahre entwickelte er das Toyota-
Produktionssystem, das eben diese erkannte Verschwendung vermeiden sollte. Durch
konsequente Anwendung dieses Produktionssystems schaffte Toyota nicht nur binnen
weniger Jahre den Sprung auf ein westliches Produktivitätsniveau, sondern übertraf die
westlichen Hersteller derartig in puncto Preis/Leistungsverhältnis, sodass die amerikani-
sche Automobilindustrie in den 80er Jahren in eine schwere Krise stürzte.
2.1.2 Aufbau3
Das von Ono erdachte Produktionssystem umfasste folgende Prinzipien, die schematisch
in Abbildung 1 dargestellt sind:
Produktion im Kundentakt: der/die HerstellerIn sollte danach trachten, die
Produktion mit dem Kundenbedarf zu synchronisieren, also nur das zu produzieren,
was interne oder externe AbnehmerInnen momentan benötigten (just-in-time
Produktion). Diese sollten ihm/ihr idealerweise das gerade fertiggestellte Produkt
„direkt vom Fließband“ abnehmen (pull system). Erst wenn diese absolute Taktsyn-
chronisation aufgrund von Bestellschwankungen oder technischen Produktionsbe-
dingungen nicht möglich ist, tritt das Kanban-System in Kraft: der/die ProduzentIn
befüllt ein kleines Pufferlager mit den Produkten, aus dem der/die KonsumentIn
den vorhandenen Bedarf stillt. Unterschreitet der Füllstand des Pufferlagers einen
Mindeststand, wird die Produktion verständigt und beginnt mit der Nachfüllung. Ono
ließ bei der Entwicklung von Kanban durch US-amerikanische Supermarktregale
inspirieren, die vom Personal bei Bedarf mit neuen Produkten nachgefüllt wurden.
Vermeidung von Verschwendung: Ono erkannte sieben Arten von Verschwen-
dung in der Produktion: Materialbewegung (Transportation), zu große Lagerbe-
stände (inventory), unnötige Bewegungen/Handgriffe der Arbeiter (motion), Warte-
3 Zusammenfassung der in (Liker, 2003), Teil 1, Kapitel 3 und 4 erläuterten Merkmale des Toyota Produktionssystems
15
zeiten (waiting), überflüssige Bearbeitung der Werkstücke (over-Processing), Über-
produktion (overproduction) sowie Korrekturen und Fehler (defects). Eine achte
Verschwendungsart, das Nichtnutzen der Kreativität und des Potentials der Mitar-
beiterInnen, wurde später in der Literatur hinzugefügt.
Methoden zur Vermeidung von Verschwendung: Durch Synchronisierung der
Produktionsprozesse (wofür die bereits erwähnten Prinzipien Just-In-Time-
Produktion und Kanban zum Einsatz kommen) und deren Standardisierung sollen
vor allem unnötige Lagerbestände und Transporte vermieden werden. Standardi-
sierung bedeutet bei Toyota nicht bloß die Dokumentation von Handlungsempfeh-
lungen in Papierform: Ono legte großen Wert darauf, dass ihre Einhaltung auch
beim Besuch einer Produktionsstätte sofort ersichtlich ist. Beispielsweise zeigen
Umrisse an den Arbeitsplätzen, wo Werkzeuge und Material abgelegt werden
sollen, um eine möglichst ergonomische Arbeitsweise zu gewährleisten.
In der Just-In-Time-Produktion ist ein hohes Qualitätsbewusstsein wichtig, da de-
fekte Teile durch den knappen Materialfluss eine Produktionslinie schnell lahmle-
gen können. Toyota entwickelte daher das Total-Quality-Management, das eine
ständige Qualitätsprüfung und –verbesserung durch alle
ProduktionsmitarbeiterInnen zum Ziel hat. Um die MitarbeiterInnen nicht durch Ab-
arbeitung langer Qualitäts-Checklisten zu überfordern, unterstützt Toyota sie durch
technische Hilfsmittel: die eingesetzten Maschinen erkennen selbst, ob sie die er-
forderlichen Fertigungstoleranzen erbringen und halten bei Nichterfüllung an
(Jidoka-Prinzip). Poka-Yoke-Einrichtungen verhindern unbeabsichtigte Fehler, in-
dem sie diese verunmöglichen (Beispiel: durch ein asymmetrisches Profil kann ein
Stecker nur auf die „richtige“ Art eingesteckt werden).
Verbesserung der Produktionsanlagen: Bei der Verbesserung der
Produktionsanlagen zielt Toyota vor allem auf eine einfache und rasche Wartung
ab – Störungen sollten möglichst während des laufenden Betriebes durch die re-
gulären MitarbeiterInnen selbst und nicht durch herbeigeholtes Wartungspersonal
behoben werden. Ein weiteres wichtiges Ziel ist die Minimierung der Rüstzeiten: auf
ein und derselben Maschine sollten viele Varianten eines Produktes erzeugt wer-
den können, ohne dass diese dafür lange stillgelegt und umgerüstet werden muss.
Kurze Rüstzeiten erlauben eine große Produktvielfalt trotz Just-In-Time-Produktion.
Toyota entwickelte hierfür das SMED-Konzept: diese Abkürzung steht für „Single
Minute Exchange of Die“ und bezeichnet einen Werkzeugwechsel im Minutentakt.
Qualifizierung der MitarbeiterInnen: Während der Fordismus den Einsatz
unqualifizierter MitarbeiterInnen propagiert und sich dadurch eine kostengünstigere
Produktion erhofft, sieht Toyota in der Qualifikation seiner MitarbeiterInnen ein
wichtiges Kriterium zur Steigerung der Prozessqualität. Toyota-MitarbeiterInnen
werden in eigenen Trainingszentren geschult, bevor sie im Betrieb eingesetzt
werden. Sie sind auch für viele Prozessverbesserungen verantwortlich, die sie in
16
ihrem Arbeitsbereich erkennen und in Kaizen-Zirkeln einmelden. In diesen
regelmäßigen Treffen reflektieren die WerkerInnen die Produktionsprozesse mit
ihren Vorgesetzten und erarbeiten Verbesserungsvorschläge.
Verbesserung in kleinen Schritten: Toyota bevorzugt kontinuierliche Prozessver-
besserungen unter direkter Einbindung der Beteiligten gegenüber dem „großen
Wurf“, also radikalen, von externen PlanerInnen über Nacht eingeführten Verfah-
rensinnovationen.
Abbildung 1: Schematische Darstellung des Toyota-Produktionssystems nach (Liker, 2003)
2.2 Lean Startup
Als sich der US-amerikanische Software-Entwickler und Internet-Unternehmer Eric Ries
2011 entschloss, seine Erfahrungen als Berater, Gründer und Mitarbeiter von Internet-Un-
ternehmen in Form einer neuen Existenzgründungsmethode zu veröffentlichen, nannte er
diese nicht von ungefähr „Lean Startup“. Der englische Begriff „Lean“ (schlank) bezog sich
auf das schlanke Produktionssystem von Toyota, das Ries mit einigen Modifikationen für
die Entwicklung neuer Produkte beziehungsweise die Neugründung innovationslastiger
Unternehmen nutzen wollte.
In seiner bisherigen Tätigkeit als Internet-Unternehmer war Ries mit verschiedenen For-
men der Verschwendung konfrontiert, die er durch Anwendung des Toyota-Systems elimi-
nieren wollte: als Beispiel nennt Ries die vorzeitige Fokussierung vieler junger Internet-Un-
ternehmen auf Wachstumsfaktoren wie die Lukrierung von Wagniskapital, die Gewinnung
neuer MitarbeiterInnen oder die Entwicklung ausgefeilter Businesspläne, ohne vorher
17
festgestellt zu haben, ob die gewählte Geschäftsidee des Unternehmens am Markt über-
haupt „greift“.
Als Negativbeispiel führt Ries seinen früheren Arbeitgeber There Inc. an4. Dieses
Softwareunternehmen entwickelte zur Zeit des Dot-Com-Booms über vier Jahre ein 3D-
Programm für virtuelle Welten im Internet. Die Entwicklung erfolgte unter strenger Ge-
heimhaltung und ohne Einbindung von Kundinnen und Kunden, um die Imitationsgefahr
durch Mitbewerber zu minimieren. Über 200 EntwicklerInnen arbeiteten an dem Projekt, 40
Millionen US-Dollar wurden investiert. Das Produkt konnte nicht am Markt Fuß fassen und
There Inc musste beinahe das gesamte Personal entlassen. Schlussendlich stand das
Unternehmen kurz vor der Liquidation.
2.2.1 Startups und EntrepreneurInnen
Ries‘ Lehren aus diesem Debakel: radikale Innovationen dürfen nicht in die Hände von
aufgeblähten Entwicklungsabteilungen gelegt werden, sondern bedürfen der Umsetzung
durch kleine, interdisziplinäre Teams, die Ries als Startups bezeichnet.
„Ein Startup ist eine menschliche Institution, die ein neues Produkt oder eine neue
Dienstleistung in einem Umfeld extremer Ungewissheit entwickelt. [...] Unsere Definition
sagt nichts über das Unternehmen, die Branche oder den Wirtschaftssektor aus.“
(Ries, 2012, p. 32)
Demnach kann ein frisch gegründetes Zwei-Personen-Unternehmen genauso ein Startup
darstellen wie ein zur Entwicklung einer Produktidee zusammengestelltes Acht-Personen-
Team innerhalb eines Großkonzerns. Startups können in Unternehmen beliebiger Größe
und Branche gegründet werden. Neuere Entwicklungen zeigen, dass Startups auch in
nicht gewinnorientierten, gemeinnützigen Organisationen oder Behörden existieren kön-
nen. Auch solche Organisationen müssen ständig neue Dienstleistungen anbieten, um
ihrem Daseinszweck gerecht zu werden.
Die Entwicklung neuer Produkte in einem sich rasch ändernden Marktumfeld stellt beson-
dere Anforderungen an die MitarbeiterInnen eines Startups. Ries fordert nicht nur geeig-
nete fachliche Qualifikation, sondern auch unternehmerisches Denken von ihnen.
„Der Begriff des Entrepreneurs trifft auf jeden zu, der in einem Startup arbeitet.“
(Ries, 2012, p. 15)
4
vgl.: http://www.youtube.com/watch?feature=player_detailpage&v=EMysvIXmbl0#t=292
18
Er verwendet dafür den Begriff „Entrepreneur“, der vom österreichischen Ökonomen
Joseph Schumpeter für UnternehmerInnen geprägt wurde, die ihre wirtschaftliche Position
durch Hervorbringen von Innovationen verbessern wollen5. Schumpeter unterscheidet
diese von Kapitalisten, die ihre Profite durch kostenpflichtige Bereitstellung von Kapital
machen (siehe Abbildung 2).
Abbildung 2: Die Rolle von Entrepreneuren im Wirtschaftssystem nach Schumpeter
(Brown & Ulijn, 2004, p. 106)
2.2.2 Prinzipien
Ries definiert folgende fünf Grundprinzipien für die Lean-Startup-Methode:
1. EntrepreneurInnen sind überall: Wie im vorangegangenen Abschnitt erläutert,
beschränken sich Startups nicht auf bestimmte Wirtschaftszweige (z.B. Internet-
Unternehmen) oder Unternehmensarten. Jede Organisation oder jedes Individuum
kann zur Entwicklung neuer Produkte oder Dienstleistungen ein Startup ins Leben
rufen.
2. Entrepreneurship ist Management: Die Fähigkeiten der EntrepreneurInnen dür-
fen sich nicht auf die Produktentwicklung allein beschränken, sondern müssen Ma-
nagementkompetenzen wie die Führung der MitarbeiterInnen umfassen. Dabei ist
das äußerst dynamische und fragile Umfeld des Startups zu berücksichtigen.
3. Validierte Lernprozesse sind der Daseinszweck des Startups: Startups werden
gegründet, um tragfähige Geschäftsmodelle für neue Produkte, Dienstleistungen
oder Märkte zu entwickeln, über die noch kein oder wenig Wissen vorhanden ist.
Daher ist der primäre Zweck eines Startups, sich dieses Wissen über eigene Expe-
rimente anzueignen. In diesen werden einzelne Annahmen der Produktidee bzw.
unternehmerischen Vision auf ihre Gültigkeit geprüft.
5
vgl. (Schumpeter, 1926)
19
4. Bauen-Messen-Lernen: Jedes Startup-Experiment läuft nach der Bauen-Messen-
Lernen-Feedbackschleife (siehe Abbildung 3) ab, d.h. zuerst wird mit möglichst
minimalem Aufwand ein Versuchsobjekt gebaut (z.B. Prototyp zur Demonstration
einer Produktfunktion), dann die Reaktion der Kundinnen und Kunden darauf ge-
messen und schließlich die richtigen Lehren daraus gezogen (z.B. Weiterverfol-
gung oder Änderung der Ideenhypothese)
5. Innovationsbilanz: Der Lern- und Innovationsfortschritt eines Startups muss stän-
dig gemessen und hinterfragt werden. Durch Definition von Meilensteinen und Ein-
führung von Kennzahlen soll für jede/n Startup-MitarbeiterIn und auch die externen
InteressensvertreterInnen ersichtlich sein, wie es um die Zielerfüllung des Startups
steht. Das Erstellen der Innovationsbilanz ist aber nicht alleinige Aufgabe des
Managements, jede/r MitarbeiterIn soll durch Dokumentation von Experimenten etc.
seinen Beitrag dazu leisten.
(Ries, 2012, p. 15f)
Abbildung 3: Die Bauen-Messen-Lernen Feedbackschleife nach Ries (Ries, 2012, p. 73)
2.2.3 Praktische Umsetzung
Wesentliches Element der „Lean Startup“-Methodik ist die „schlanke“ Durchführung des
Innovationsprojektes, wofür Ries Anleihen beim vom japanischen Automobilhersteller
Toyota geprägten Lean Management nimmt.
20
Lean Startup minimiert Verschwendung und damit verbundenen finanziellen Aufwand
durch eine Fülle von Aktivitäten:
Potentielle Kunden und Kundinnen werden bereits am Beginn des
Innovationsprozesses identifiziert und in diesen eingebunden. Dadurch erübrigen
sich teure Marktforschungsaktivitäten, die Gefahr unvorhersehbarer Flops sinkt.
Die Geschäftsidee des Startups wird als Bündel von Hypothesen betrachtet, die in
Experimenten bestätigt werden müssen, bevor tatsächlich Geld in großem Stil in
sie investiert wird. Da gröbere Änderungen an der Geschäftsidee in dieser Phase
durchaus wahrscheinlich sind, definiert Lean Startup mit dem sogenannten Pivot
einen eigenen strukturierten Umdenkprozess für derartige Fälle.
Neben qualitativen, offenen Kundeninterviews stellt das minimal-funktionale
Produkt (minimum viable product) das wichtigste Experimentierobjekt dar: mit mög-
lichst geringem Aufwand wird frühzeitig ein minimales Produkt umgesetzt, das
den/die zentralen Aspekte der Produktidee demonstriert und von Interessierten
ausprobiert werden kann.
Das minimum viable product wird kontinuierlich, aber defensiv mit weiteren Funktio-
nen ergänzt. Entscheidend ist nicht die Anzahl oder Originalität der Funktionen,
sondern einzig und allein ihre Akzeptanz durch den Kunden/die Kundin.
Erst wenn sich eine klare Übereinstimmung des entstehenden Produktes mit den
Bedürfnissen der Kunden abzeichnet (product/market-fit), kann das Startup die
Wachstumsphase einläuten und sich mit Kapital und Personal ausstatten, um die-
ses Wachstum zu bewältigen.
2.3 Business Model Canvas
Während die Lean-Startup-Methode den Weg einer Produktidee über ihre Umsetzung bis
hin zur Marktakzeptanz begleitet, bleibt für viele EntrepreneurInnen die Frage offen, wel-
ches Geschäftsmodell sie für ihr Produkt wählen sollen, sobald dieses am Markt „greift“.
Heutzutage werden Produkte mit einer Vielzahl von Geschäftsmodellen angeboten, die
von werbefinanzierten Gratis-Angeboten (U-Bahn-Zeitung) über kostenlose Basisversionen
mit kostenpflichtigen Premium-Funktionen (dieses Freemium-Modell wird gerne von
Online-Diensten wie Google und Flickr verwendet) bis hin zu „echten“ Bezahlangeboten
reicht. Die Motivation hinter der Wahl eines Geschäftsmodells ist dabei für Neo-Entrepre-
neuerInnen nicht immer ersichtlich.
Der Internet-Unternehmer Alex Osterwalder hat mit dem Wirtschaftsprofessor Yves
Pigneur daher den Business Model Canvas entwickelt. Mit diesem einseitigen
Darstellungraster lassen sich Geschäftsmodelle anschaulich in ihre Komponenten
aufspalten und so analysieren, verbessern oder neu entwickeln.
21
Da der Business Model Canvas in abgewandelter Form auch in der Running-Lean-
Methode zum Einsatz kommt, soll nachfolgend kurz auf ihn eingegangen werden.
2.3.1 Definition des Begriffes „Geschäftsmodell“
Zunächst gilt es, die Bedeutung des Begriffes „Geschäftsmodell“ näher zu erklären. Er wird
von Osterwalder und Pigneur wie folgt definiert:
„Ein Geschäftsmodell beschreibt das Grundprinzip, nach dem eine Organisation Werte
schafft, vermittelt und erfasst.“
(Osterwalder & Pigneur, 2011, p. 18)
Die Autoren reduzieren also das Geschäftsmodell nicht auf die landläufig verbreitete Defi-
nition „womit das Unternehmen Geld verdient“, für sie umfasst es auch die Entwicklung je-
ner Wertangebote, welche die späteren Einnahmen generieren oder die Akquisition der
Kunden und Kundinnen, die diese Zahlungen leisten.
2.3.2 Bausteine eines Geschäftsmodells
Abbildung 4: Der Business Model Canvas nach Pigneur und Osterwalder
(Osterwalder & Pigneur, 2011, p. 48)
Aus der obigen Definition leiten Pigneur und Osterwalder neun Bausteine eines Ge-
schäftsmodells ab, die im Business Model Canvas grafisch dargestellt werden (siehe
22
Abbildung 4). Pigneur und Osterwalder präzisieren die Bausteine wie folgt (Osterwalder &
Pigneur, 2011, p. 25 ff):
Kundensegmente (customer segments): Eine Organisation bedient ein oder
mehrere Kundensegmente (der IT-Konzern Hewlett-Packard wendet sich mit sei-
nen Produkten beispielsweise an private Endkundinnen und -kunden, klein- und
mittelständische Unternehmen sowie große Konzerne, die Art und Aufmachung der
Produkte unterscheidet sich je Kundensegment).
Wertangebote (value proposition): mit ihren Wertangeboten versucht die
Organisation, Kundenprobleme zu lösen und Kundenbedürfnisse zu befriedigen.
Ein Wertangebot kann aus Produkten, Dienstleistungen oder einer Kombination
dieser beiden Faktoren bestehen.
Kanäle (channels): Wertangebote werden den Kundinnen und Kunden durch
Kommunikations-, Distributions-, und Verkaufskanäle unterbreitet. Eine Organisa-
tion kann direkte (eigene Website, Filialen) oder indirekte Kanäle (Vertriebspartner,
Händlernetz) zur Vermittlung der Wertangebote nutzen.
Kundenbeziehungen (customer relationships): zu jedem Kundensegment muss
die Organisation Beziehungen herstellen und pflegen. Je nach Geschäftsmodell
geschieht dies über die Verkaufsberater (z.B. Autohandel) oder über Selbstbedie-
nungs-Terminals (z.B. Fahrkartenautomaten)
Einnahmequellen (revenue streams): sind das Ergebnis der Konsumation von
Wertangeboten. Je nach Geschäftsmodell kann es sich bei den Einnahmequellen
um einmalige oder fortlaufende Zahlungen handeln.
Schlüsselressourcen (key ressources): sind Güter, die zum Anbieten der
Wertangebote oder für die Nutzung der Kundenkanäle erforderlich sind. Schlüssel-
ressourcen können physische (Rohstoffe, Fabrik, Computernetzwerk,...), immateri-
elle (Patente, Markenrechte), menschliche (Schlüsselarbeitskräfte,...) oder finanzi-
elle (Kredite, Bürgschaften,... ) Ausformungen haben.
Schlüsselaktivitäten (key activities): damit die Schlüsselressourcen ihren Nutzen
entfalten können, müssen sie in Aktivitäten zum Einsatz gebracht werden (bei-
spielsweise Produktion, Innovation, Vertrieb). Diese bezeichnen Osterwalder und
Pigneur als Schlüsselaktivitäten.
Schlüsselpartnerschaften (key partnerships): nicht alle erforderlichen Ressour-
cen und Aktivitäten können vom Unternehmen selbst bereitgestellt werden, es
muss Partnerschaften mit anderen Organisationen eingehen, um an sie zu kom-
men. Schlüsselpartnerschaften können aber auch zwischen konkurrierenden Un-
ternehmen eingegangen werden, um wichtige Technologien zu standardisieren und
zu vermarkten (z.B. Blu-Ray-DVDs) oder finanzielle Vorteile durch Einkaufsge-
meinschaften zu lukrieren.
Kostenstruktur (cost structure): Die Elemente des Geschäftsmodells verursa-
chen Kosten, welche in einer Kostenstruktur zusammengefasst werden.
23
Osterwalder und Pigneur unterscheiden hierbei zwischen kostenorientierten Unter-
nehmen, welche die Preisführerschaft in ihrem Marktsegment anstreben wollen und
wertorientierten Firmen, die aufwendige, qualitativ hochwertige Produkte ohne
übertriebenen Kostendruck anbieten möchten.
2.4 Running Lean
Der texanische Entrepreneur Ash Maurya hatte bereits eine zehnjährige Historie als
Internet-Unternehmer hinter sich, als er 2012 seine Startup-Methode „Running Lean“ ver-
öffentlichte. Wie der Titel bereits vermuten lässt, baut Maurya auf dem Werk von Eric Ries
auf. In der Tat entstand „Running Lean“, als Maurya versuchte, die von Ries in
„Lean Startup“ vorgeschlagenen Techniken zur Entwicklung seines neuen Produkts „Cloud
Fire“ anzuwenden:
„I was determined to test these techniques on my next product (CloudFire) but ran into
many early challenges when trying to take these concepts to practice. [...] while Eric Ries
was sharing his retrospective lessons learned from working at IMVU, IMVU was no longer
a startup. With a technical staff of 40 people and more than $40 million in revenue, what
you saw was a fully realized Lean Startup machine, which was at times daunting.“
(Maurya, 2012, p. 33)
Maurya hatte also Probleme, die von Ries innerhalb des mittelständischen, etablierten
Softwareunternehmens IMVU entwickelten Startup-Techniken auf sein Ein-Mann-Startup
zu übertragen und folgerte daraus, dass die von Ries für einen sehr weiten Anwenderkreis
gedachten Methoden für die Bedürfnisse von Klein- und Kleinstunternehmen konkretisiert
werden müssen.
Mit Running Lean schuf Maurya ein Startup-Tutorial, das den/die Neo-EntrepreneurIn
Schritt für Schritt durch die Verfolgung seiner Geschäftsidee begleitet und ihn dabei mit
klar vorgegebenen und ins Detail definierten Prozessen unterstützt. Besonderes Augen-
merk richtet Maurya auf die zahlreichen Richtungswechsel der Geschäftsidee, die ein
Startup im Laufe der Zeit vollführen muss, um am Leben zu bleiben:
„Most startups still fail. But the more interesting fact is that, of those startups that succeed,
two-thirds report having drastically changed their plans along the way6.“
(Maurya, 2012, p. 24)
6
Maurya bezieht sich bei dieser Aussage auf in (Mullins & Komisar, 2009, p. vii) veröffentlichte Daten.
24
Er folgert daraus, dass es einen systematischen Prozess benötigt, um die meist wirkungs-
lose Ursprungsgeschäftsidee in Richtung eines funktionierenden Geschäftsmodells zu trei-
ben:
„Running Lean is a systematic process for iterating from Plan A to a plan that works, before
running out of ressources.“
(Maurya, 2012, p. 25)
2.4.1 Bestandteile
Für Running Lean griff Ash Maurya nicht nur auf die Erkenntnisse von Eric Ries‘ The
Lean Startup zurück, er verwendete ergänzende Techniken, um die Methode abzurunden:
Die vom US-Wirtschaftsprofessor und Internet-Unternehmer Steve Blank geprägte
Methode Customer Development bezeichnet ein frühzeitiges Indentifizieren
potentieller Kundinnen und Kunden am Beginn des Produktentwicklungsprozesses
und deren kontinuierliche Involvierung in diesem Prozess über Feedback-Schleifen
[vgl. (Blank, 2013)]
Lean Startup: Aus der Lean-Startup-Methode übernahm Maurya die Prämisse ei-
nes Startups – das Maximieren des Wissens über Kundenbedürfnisse und Markt-
gegebenheiten in möglichst kurzer Zeit durch validiertes Lernen – sowie Elemente
wie die Bauen-Messen-Lernen-Feedbackschleife und den Pivot-Prozess.
Bootstrapping ist eine Technik zur Minimierung des externen Kapitalbedarfs für
Produktentwicklung und/oder Existenzgründung und stellt die Antithese zur wag-
niskapitalhungrigen Finanzierung US-amerikanischer Internet-Unternehmen dar.
Der Begriff leitet sich aus der englischen Redewendung "to pull oneself up by one's
bootstraps" ab (ungefähre deutsche Übersetzung: „sich am eigenen Schopf aus
dem Sumpf ziehen“). Ziel der Methode ist eine einfache, rasche Unternehmens-
gründung sowie die weitgehende Bewahrung der unternehmerischen Souveränität
durch Verzicht auf Fremdkapital. [vgl. (Gianforte & Gibson, 2007)]
Business Model Canvas: Zur permanenten Visualisierung der Geschäftsidee
kommt in Running Lean der Lean Canvas, eine abgewandelte Version des von
Osterwalder/Pigneur erdachten Business Model Canvas zum Einsatz.
2.4.2 Durchführung
Maurya gliedert Running Lean in drei Grundschritte, welche im Lauf der Anwendung von
Lean Canvas wiederholt durchlaufen werden. Nachfolgend werden diese Schritte über-
blicksmässig beschrieben, eine detaillierte Beschreibung erfolgt im Rahmen der nachfol-
genden Fallstudie [vgl. (Maurya, 2012, p. 43ff)].
25
1. Dokumentation des „Plan A“ auf dem Lean Canvas: Der/die EntrepreneurIn
dokumentiert die Ausgangsidee auf dem einseitigen Lean-Canvas-Raster, der von
Running Lean bereitgestellt wird. Neun vorgegebene Aspekte zwingen zu einer
ganzheitlichen, auf ein vollwertiges Geschäftsmodell abzielenden Dokumentation
der Geschäftsidee, der limitierte Platz sorgt für eine „schlanke“ Erfassung der zu-
grunde liegendenen Hypothesen. Running Lean gibt auch die Reihenfolge der Be-
füllung vor: erst nach der Dokumentation des Problems aus Zielgruppensicht darf
der (technische) Lösungsansatz ausgeführt werden. Ash Maurya drückt die An-
sprüche von Running Lean wie folgt aus: „Your job isn’t just building the best
solution, but owning the entire business model and making all the pieces fit. [..]
Lean Canvas helps deconstruct your business model into nine distinct subparts that
are then systematically tested, in order of highest to lowest risk.“ (Maurya, 2012, p.
43)
2. Identifikation der riskantesten Teile des Plans: Im zweiten Schritt gilt es die ris-
kantesten Teile des in Schritt 1 erstellten Plan A zu identifizieren. Running Lean
unterstützt den/die EntrepreneurIn dabei mit einem phasenabhängigen Risikobe-
urteiltungsmodell, das auf den aktuellen Produktentwicklungsfortschritt des Star-
tups abstellt:
o Am Beginn seiner Existenz muss das Startup danach streben, den
sogenannten Problem/Solution-Fit zu erreichen – das vom Startup ange-
gangene Problem muss von den potentiellen Kunden und Kundinnen als so
dringlich eingestuft werden, dass sie bereit wären, das Produkt oder die
Dienstleistung des Startups zu nutzen. Die Frage „Verfolge ich ein lösens-
wertes Problem?“ stellt also das Hauptrisiko in der Frühphase des Startups
dar. Running Lean verwendet qualitative Befragungstechniken wie
problem/solution interviews, um dieses Risiko aufzuklären.
o Als nächstes Ziel sollte der Product/Market-Fit angestrebt werden – dabei
stellt sich die Frage, ob die in ein meist kostenpflichtiges Produkt paketierte
„Problemlösung“ auch vom Markt akzeptiert wird. Zur Aufklärung dieses
Produktrisikos verwendet Maurya das aus Lean Startup bekannte minimum
viable product, welches in Beta-Tests frühen Anwendern zur Verfügung ge-
stellt wird.
o Wenn die Markttauglichkeit des Produktes durch die Frühanwendergruppe
bestätigt wurde und diese möglicherweise schon kleine Umsätze generiert,
stellt sich die Frage nach dem Wachstum des Startups: Mit welchen Mitteln
kann das Startup mehr Kundinnen und Kunden generieren? Hierfür werden
neue Marketingkanäle getestet (z.B. Online-Anzeigen) und in ihrer Wirkung
optimiert (beispielsweise durch verbesserte Textierung)
3. Durch Experimente werden die riskantesten Planelemente systematisch getestet
und verbessert.
26
3 Running-Lean-Fallstudie „Entwicklung eines
cloud-basierten Foto-Editors“
3.1 Einleitung und Rahmenbedingungen
Die Forschungsfrage dieser Arbeit lautet: Eignet sich „Running Lean“ zur berufsbegleiten-
den7 Perfektionierung von Produktideen in Österreich? Zur Beantwortung dieser Frage
testet der Autor im Rahmen einer Einzelfallstudie die berufsbegleitende Anwendung von
Running Lean: neben seiner Vollzeitbeschäftigung als Software-Entwickler wendet er die
Methode über einen Zeitraum von sechs Monaten an, um seine Idee eines cloud-gestütz-
ten Speicherdienstes für digitale Negative weiter zu perfektionieren – auf die technischen
Einzelheiten der Produktidee wird im Verlauf der Fallstudie noch detailliert eingegangen.
Der Anwendungszeitraum von sechs Monaten ergab sich aus dem studienbedingten frü-
hestmöglichen Starttermin der Arbeit (Juli 2013) und dem ebenfalls von der Studien-
gangsleitung definierten Abgabetermin per 30.1. 2014, von dem für diverse Finalisierungs-
arbeiten an der Masterarbeit ein Monat abgezogen wurde.
Weitere wichtige Rahmenbedingungen sind die Beschränkung auf die genannte Produk-
tidee aus dem Bereich digitale Medientechnologien, die gleichzeitige Evaluierung mehrerer
Ideen oder die Ausdehnung der Idee auf andere Fachbereiche stellen aufgrund des knap-
pen Zeitbudgets klare Nicht-Ziele dar.
Aus finanzieller Sicht erfolgt eine Beschränkung der möglichen Ausgaben auf maximal
1000 EUR pro Monat, die aus dem Privatvermögen des Autors bestritten würden. Der be-
absichtigten Gewinnung institutioneller Geldgeber zur Finanzierung der Produktidee wird
aufgrund der Empfehlungen von Running Lean8 ebenfalls nicht nachgegangen. Eine Aus-
nahme bildet das von der Internet-Förderaktion „netidee“ dankenswerterweise gewährte
Förderstipendium zur Fertigstellung dieser Masterarbeit.
Erhofftes Ergebnis der Anwendung von Running Lean ist zum einen die Konkretisierung
der Produktidee des Autors in technischer (welche Technologien sind zur Umsetzung des
Produktes nötig?) und funktioneller (welche Funktionen erwartet der Kunde oder die Kun-
din?) Hinsicht. Zum anderen sollten die Erfahrungen aus der Fallstudie natürlich der Be-
antwortung der Forschungsfrage dienen: ergibt sich weiters eine gute Eignung von
Running Lean für die betriebliche und „private“ Produktentwicklung, möchte der Autor
7
Wie in der Einleitung bereits erläutert, bezieht sich „berufsbegleitend“ entweder auf die innerbetriebliche Anwendung von
Running Lean (zusätzlich zu den eigentlichen Kernaufgaben der betroffenen Beschäftigten) oder auf den nebenberuflichen
Einsatz. 8
Externes Investitionskapital zählt nach Running-Lean-Ansicht zu den Wachstumsfaktoren eines Startups. Es sollte daher
erst nach Erzielung des product/market fit akquiriert werden [vgl (Maurya, 2012, p. 46)].
27
mithilfe von Anwendungsempfehlungen den Einsatz der Methode in diesen Bereichen
erleichtern.
Aufgrund des offenen Ausgangs der Fallstudie stellt die Kommerzialisierung der Produk-
tidee durch ein vom Autor gegründetes Unternehmen kein definitives Ziel der Arbeit dar.
Diese Aktivitäten würden zudem auch den zeitlichen Rahmen der Masterarbeit sprengen,
sollen aber bei erfolgreicher Umsetzung der Idee nach Erstellung der Masterarbeit durch-
geführt werden.
3.2 Ausgangssituation
Der Autor dieser Masterarbeit ist ein leidenschaftlicher Hobby-Fotograf, der seine auf Rei-
sen oder Veranstaltungen geschossenen Fotos gerne mit seinem Familien- und Freundes-
kreis teilt. Dafür verwendet er das kostenlose Desktop-Programm Google Picasa, mit dem
die Fotos gesichtet und bearbeitet werden. Die integrierte Upload-Funktion von Google
Picasa publiziert anschließend eine Auswahl gelungener Bilder auf dem sozialen Netzwerk
Google+. Die jeweilige Zielgruppe der Fotos erfährt durch die Benachrichtigungsfunktion
von Google+ vom neuen Bilderangebot und kann dieses unter einem veröffentlichten
Hyperlink abrufen.
3.2.1 Der Einsatz von DSLRs im Workflow des Autors
Abbildung 5: Modell "EOS 5D Mark II" von Canon9
Die Fotos selbst werden mit einer digitalen Spiegelreflex-Kamera (digital single lens reflex
camera, DSLR) geschossen. Abbildung 5 zeigt eines der aktuell populärsten Modelle die-
9 Quelle: unmodifiziertes Originalbild von Charles Lanteigne, das unter der creative-commons-Lizenz CC BY-SA 3.0
veröffentlicht wurde (Bild und Lizenzbestimmungen: http://commons.wikimedia.org/wiki/File:Canon_EOS_5D.jpg)
28
ser Produktgattung10, die „EOS 5D Mark II“ der Firma Canon. Digitale Spiegelreflexkame-
ras bieten gegenüber Kompakt- oder Smartphone-Kameras folgende Vorteile:
durch einen größeren Bildsensor kommt es zu weniger Rauschen und einer höhe-
ren Bilddynamik (Bockaert, 2009).
Ein klappbarer Spiegel leitet das im Objektiv eintreffende Licht durch den Sucher
oder während des Auslösevorgangs auf den Bildsensor (Abbildung 6).
Kompaktkameras hingegen verfügen über keinen Klappspiegel, sondern zwei ge-
trennte Linsensysteme für Sucher und Aufnahme. Bei ihnen ist der Tausch des
Objektives nicht möglich, während bei Spiegelreflexkameras wechselbare Objektive
eine flexible Bildgestaltung ermöglichen (Abbildung 7)
ein herstellerspezifisches Rohdatenformat (RAW-Format) bietet durch verlustfreie
Speicherung der Bildsensordaten eine deutlich höhere Bildqualität als das in Kom-
pakt- und Smartphonekameras verbreitete, verlustbehaftete JPEG-Format (Fraser,
2004).
Abbildung 6: Lichtwege bei DSLRs (Gockel, 2011, p. 28)
10
Quelle: Flickr.com Kamerastatistik, September 2013
29
Abbildung 7: DSLR-Modell Sony A230 mit Wechselobjektiven und weiterem Zubehör11
3.2.2 Camera RAW-Formate
Aufbau und Bedeutung
Der Terminus „Camera RAW-Format“ bezeichnet eine Familie von unterschiedlich aufge-
bauten Dateiformaten, die von den Herstellern digitaler Spiegelreflexkameras entwickelt
wurden. Es gibt dutzende verschiedene RAW-Formate, die aber einen gemeinsamen
Zweck verfolgen: die beim Fotografiervorgang vom Bildsensor ermittelten Helligkeitswerte
möglichst unverfälscht zu speichern. [vgl. (Fraser, 2004)]
Damit liefert die RAW-Datei ähnlich einem analogen Negativ die Ausgangsdaten eines
Fotos, aus denen aber erst durch mehrere Entwicklungsschritte ein fertiger Fotoabzug
wird.
11
Quelle: unmodifiziertes Originalbild von Brian Eager, das unter der creative-commons-Lizenz CC BY 2.0 veröffentlicht
wurde (Bild und Lizenztext: http://commons.wikimedia.org/wiki/File:Sony_A230_DSLR_kit_(6)_(5789834752).jpg)
30
Abbildung 8: Interpolation von Farbwerten im Raw-Konverter (Fraser, 2004)
Diese Entwicklungsschritte übernimmt der Raw Converter, eine Softwarekomponente, die
in viele moderne Bildbearbeitungsprogramme integriert ist. Der Entwicklungsprozess ist
allerdings interaktiv, der Benutzer kann durch Einstellungsänderungen eingreifen.
Abbildung 9: Der in die Bildverwaltungssoftware Adobe Lightroom integrierte Camera RAW Konverter
31
Der Raw Converter durchläuft beim Entwicklungsprozess eines Raw-Bildes folgende Ar-
beitsschritte (Fraser, 2004):
1. Demosaicing: Die meisten Digitalkameras verfügen über einen Color Filter
Array (CFA)-Bildsensor, der 1975 vom Kodak-Ingenieur Bryce Bayer patentiert
wurde (Bayer, 1975). Bei diesem Sensortyp wird der „farbenblinde“, d.h. nur auf
Helligkeitsunterschiede reagierende Bildsensor durch Aufbringen von Filterfo-
lien für die RGB-Grundfarben Rot, Grün und Blau empfindlich gemacht. Jeder
Sensorpixel liefert dabei entweder einen Rot-, Grün- oder Blauwert. Da für die
Farbdarstellung eines Bildes alle drei Farbwerte je Pixel vorliegen müssen, ist
ein Interpolationsvorgang zwischen den Farbwerten erforderlich, der als Demo-
saicing bezeichnet wird (siehe Abbildung 8). Es existieren verschiedene
Demosaicing-Algorithmen, die Vor- und Nachteile haben.
2. Korrektur von Abbildungsfehlern: Die bei der Aufnahme eingesetzten Objek-
tive sind nicht frei von Abbildungsfehlern, wie beispielsweise Abschattungen an
den Objektivrändern (Vignettierung). Durch Einsatz entsprechender Filter kann
der RAW-Konverter diese Fehler beseitigen oder abmildern.
3. Weißabgleich: Beim Weißabgleich werden die „neutralen“ Bildpixel bestimmt,
die keine Farbinformation enthalten, also weiß, grau oder schwarz sind. Durch
dieses „Neutralsetzen“ einzelner Pixel ändert sich die Farbcharakteristik des
Bildes.
4. Gammakorrektur: bei der Gammakorrektur wird eine physikalisch proportional
wachsende Größe mit einer Potenzfunktion „korrigiert“, weil sie dem menschli-
chen Empfinden nach nicht proportional wächst. Bei der digitalen Fotografie
betrifft dies die vom Sensor gemessenen Tonwerte – die Kontrastunterschiede
der Werte wären bei linearer Umrechnung für das menschliche Auge zu niedrig.
Die Gammakorrektur sorgt für die nötige Anpassung der Werte.
5. Rauschunterdrückung, Antialiasing und Schärfen: Diese Korrekturfilter die-
nen der Minderung des unvermeidbaren Sensorrauschens bzw. der Vermei-
dung von Moiré-Effekten bei der Abbildung klein strukturierter Muster. Der
Schärfe-Filter wirkt dem durch das Demosaicing bewirkten Schärfeverlust ent-
gegen.
Durch Beeinflussung dieser RAW-Entwicklungsparameter kann der/die FotografIn Bilder
unterschiedlichster Charakteristik „entwickeln“. Diese Flexibilität hat jedoch ihren Preis: für
ein RAW-Foto sind je nach Kamera-Modell, Bildauflösung und Dateiformat zwischen 10
und 45 Megabyte Speicherplatz zu veranschlagen12, die Umrechnung des Graustufen-
Negativs in ein Farbbild ist zudem ein sehr leistungsintensiver Rechenvorgang (vgl. die
Performance-Tests für Camera-RAW-Decoding in Kapitel 4.2.3).
12
Bandbreite des Speicherbedarfs der RAW-Testbilder in (Busch, 2013)
32
Unterschiede zum JPEG-Format
Das von digitalen Kompakt- und Smartphone-Kameras produzierte JPEG-Format ent-
spricht einem analogen Farbabzug: binnen Sekundenbruchteilen wird die vom Bildsensor
wahrgenommene Helligkeitsinformation an einen Bildprozessor umgeleitet, der daraus
unter Anwendung der im vorigen Abschnitt genannten Entwicklungsschritte ein Farbbild
erstellt. Da dieser Prozess in Sekundenbruchteilen in der Kamera stattfinden muss, hat
der/die FotografIn nur wenige Eingriffsmöglichkeiten. Um Speicherplatz zu sparen, wird
dieses sogleich in ein JPEG-Bild konvertiert. Bei diesem verlustbehafteten, in (ITU
Consultative Comitee, 1993) standardisierten Kompressionsverfahren wird das Foto in 8x8
Pixel große Quadrate unterteilt, innerhalb dieser werden durch Irrelevanzreduktion für den
Menschen schlecht wahrnehmbare Kontrastunterschiede entfernt. JPEG ermöglicht Kom-
pressionsraten von 1:10 – 1:15 für „visuell verlustfreie“ Bilder (d.h. auch geübten Betrach-
terInnen wird kein Qualitätsunterschied auffallen).
Abbildung 10 zeigt die Auswirkungen der JPEG-Kompression – das linke Beispielbild
wurde mit JPEG-Qualitätseinstellung 90 gespeichert – rechts kam die Einstellung 12 zum
Einsatz13. Dabei werden die durch die Kompression verursachten Blockartefakte und der
Verlust an Schärfe sichtbar. Bei der nachträglichen Bearbeitung treten diese Artefakte
auch bei guten Qualitätsstufen schnell zutage („Treppchen“-Effekt).
Abbildung 10: Visuelle Artefakte bei der verlustbehafteten JPEG-Kompression14
13
Das Vergleichsbild wurde mit dem JPEG-Enkoder des Bildbearbeitungsprogramms Paint.NET Version 3.5.10 erstellt, die
möglichen Qualitätswerte reichen von 1 (schlechteste Qualität, geringste Dateigröße) bis 100 (maximale Qualität und
Dateigröße). 14
Quelle: modifiziertes Foto von Richard Bartz, das unter der creative-commons-Lizenz CC BY-SA 2.5 veröffentlicht wurde
(Originalbild und Lizenztext: http://commons.wikimedia.org/wiki/File:Schnepfenfliege_Rhagio_scolopaceus2.jpg)
33
Probleme und neue Entwicklungen
Die Verwendung von Camera-RAW-Formaten bringt allerdings auch Probleme mit sich:
wie bereits im vorigen Abschnitt angesprochen wurde, handelt es sich bei den
RAW-Formaten um proprietäre Bildformate, die von Kameraherstellern für eine
bestimmte Modellpalette entwickelt wurden. Zur Darstellung und Bearbeitung einer
RAW-Datei ist der/die AnwenderIn primär auf Originalsoftware des Kameraherstel-
lers angewiesen. Dieser hat aber nur ein beschränktes Budget für Softwareent-
wicklung zur Verfügung und wird vermutlich die Unterstützung seiner „Altformate“
einstellen, wenn er genügend neue Modellgenerationen auf den Markt gebracht
hat. Aus dem Blickpunkt der Archivierungssicherheit ist dieser Umstand natürlich
höchst bedenklich.
Kommerzielle Bildbearbeitungsprogramme wie Adobe Photoshop oder Adobe
Lightroom können zwar eine Vielzahl von RAW-Formaten lesen, bei jenen neuer
Kameramodelle kommt es aber immer wieder zu Fehlanzeigen, wie zum Bei-
spiel bei Fujifilm-Kameras mit EXR-Sensoren15. Auch hier sind unvollständig doku-
mentierte, proprietäre RAW-Dateiformate als Fehlerursache anzunehmen.
Wie in Kapitel 4.2 erläutert wird, benötigen RAW-Bilder viel Speicherplatz, ihre
Bearbeitung ist zudem sehr rechenintensiv. Obwohl RAW-Dateien aufgrund ih-
rer Informationsmenge niemals an die Dateigrößen des verlustbehafteten JPEG-
Formats herankommen werden, besteht bei Speicher- und CPU-Bedarf durchaus
Optimierungsbedarf. Schließlich muss die DSLR nach Betätigung des Auslösers
die RAW-Datei so schnell als möglich in ihren Speicher schreiben, um bereit für
das nächste Foto zu sein. Für aufwendige Kompressionsvorgänge fehlt schlicht die
Zeit16. Durch die nachträgliche Änderung der Dateistruktur lässt sich zudem der Re-
chenaufwand für die Darstellung der RAW-Datei senken.
Mit dem 2004 veröffentlichten DNG-Format (DNG = digital negative) wollte der Soft-
warehersteller Adobe die Probleme der zueinander inkompatiblen RAW-Formate lösen:
DNG ist ein offen spezifiziertes Dateiformat, das von Adobe für EntwicklerIn-
nen und AnwenderInnen kostenfrei zur Verfügung gestellt wird17. Es stellt eine
einheitliche, standardisierte Datenstruktur für RAW-Daten bereit. Somit können
Bildbearbeitungsprogramme die RAW-Daten beliebiger Kameramodelle lesen,
ohne dafür adaptiert werden zu müssen.
DNG erlaubt den Einsatz des verlustfreien Kompressionsalgorithmus „JPEG
Lossless Compression“ zur Reduktion der Dateigröße. Damit lassen sich je
15
vgl.: http://blogs.adobe.com/lightroomjournal/2013/04/lightroom-4-4-now-available.html 16
Einige Hersteller haben Kompressionsalgorithmen von unterschiedlicher Effizienz in ihren RAW-Formaten implementiert:
http://encode.ru/threads/1775-lossless-recompression-of-camera-raw?p=34255&viewfull=1#post34255 17
Gegenüber Software-Entwicklern verzichtet Adobe auf jegliche Einnahmen aus Patenten, die dem Unternehmen durch die
Implementierung des DNG-Formats zustehen würden. AnwenderInnen wird ein kostenfreies Konverter-Programm ins
DNG-Format zur Verfügung gestellt.
34
nach RAW-Format zwischen 20 und 60% der Dateigröße einsparen. Die Beschrän-
kung auf einen Kompressionsstandard erleichtert Software-EntwicklerInnen die
Einbindung des Dateiformats.
Mit der 2008 veröffentlichten Version DNG 1.2 (Adobe Systems Incorporated,
2008) verbesserte Adobe das rechenaufwendige Lesen und Schreiben von
DNG-Dateien. Das mehrere Megapixel große RAW-Bild wird vor der Speicherung
in 512x512 Pixel große Kacheln (SubTiles) unterteilt, die unabhängig voneinander
komprimiert werden. Dies bringt sowohl beim Öffnen als auch beim Speichern der
RAW-Datei große Geschwindigkeitsvorteile, da moderne Prozessoren die Arbeits-
last auf mehrere Rechenkerne verteilen können18.
Die 2012 veröffentlichte DNG-Version 1.4 (Adobe Systems Incorporated, 2012)
brachte mit „Lossy DNG“ ein verlustbehaftetes Kompressionsverfahren für
RAW-Dateien. Adobe sieht den Haupteinsatzbereich von Lossy DNG in der platz-
sparenden Archivierung von „Zweite-Wahl-Fotos“. Lossy DNG und JPEG-Dateien
nutzen denselben Kompressionsalgorithmus, daher sind auch ihre Dateigrößen
vergleichbar. Lossy DNG bietet allerdings wesentlich mehr Bearbeitungsspielraum
als JPEG, da vor der verlustbehafteten Komprimierung nur das Demosaicing
durchgeführt wird, während JPEG auch Weißabgleich, Gamma-Korrektur und
Schärfefilter auf das Bild anwendet. (vgl. obigen Abschnitt „Aufgaben eines RAW
Konverters“). Durch das bereits durchgeführte Demosaicing kann bei Lossy DNG
zudem die Auflösung des RAW-Bilds beliebig angepasst werden, was sich sehr
vorteilhaft auf die Dateigröße auswirkt (siehe Tabelle 1).
Dateiformat Komprimierung Auflösung Megapixel Dateigröße [MB]
.CR2 (Canon
RAW)
Verlustfrei 5184 x 3456 17,92 22,37
DNG Verlustfrei 5184 x 3456 17,92 18,2
DNG Verlustbehaftet / Bildpixel
beibehalten
5184 x 3456 17,92 6,65
DNG Verlustbehaftet / auf 10
Megapixel verkleinert
3872 x 2581 10 3,18
DNG Verlustbehaftet / auf 6
Megapixel verkleinert
3000 x 2000 6 1,97
Tabelle 1: Vergleich verschiedener DNG-Varianten, die aus einer Canon RAW-Datei erstellt wurden19
.
18
In (Shankland, 2012), Abschnitt „New DNG features“ wird von einer Verdreifachung der Lese/Schreibgeschwindigkeit
berichtet. 19
Erstellt mit Adobe DNG Konverter 7.3
35
Knapp 10 Jahre nach der Einführung hat Adobe sein Ziel, DNG als neues RAW-Stan-
dardformat für Digitalkameras zu etablieren, deutlich verfehlt: nur wenige, nach heutigem
Stand veraltete Modelle unterstützen DNG20.
Durch seine Innovationen in Bezug auf Speicherbedarf und Rendering-Performance hat
DNG aber eine hohe Bedeutung als Austausch- und Archivierungsformat für RAW-Daten.
Bereits 2010 gab es über 290 Software-Applikationen aus den Bereichen Bildbearbei-
tung, -verwaltung und -konvertierung, die das DNG-Format unterstützten21. Auch der in
Kapitel 3.3.1 beschriebene Lösungsansatz wird sich die Vorzüge des DNG-Formats
zunutze machen.
3.2.3 Photosharing-Platformen zum Teilen der Bilder
Photosharing-Plattformen dienen Fotoschaffenden zur Veröffentlichung ihres Bildmaterials
im Internet und dem Austausch mit Gleichgesinnten. Der seit 2004 betriebene Online-
Dienst flickr.com ist Urahn und zugleich einer der populärsten Vertreter dieser Produkt-
gattung. Der Name „flickr“ leitet sich vom englischen „to flick through“ ab, was soviel wie
„durchblättern“ bedeutet. Flickr wurde ursprünglich als Zusatzmodul eines Onlinespiels
entwickelt, zählt aber mittlerweile zu den 50 populärsten Websites weltweit. 2009 wurde
das viermilliardste Foto hochgeladen. [vgl. (Gockel, 2011, p. 183 ff)]
Abbildung 11: Eine auf flickr.com veröffentliche Fotogalerie
20
(Pearson, 2011) listet etwa 30 Modelle 21
„These pages identify over 290 non-Adobe products that support DNG in some way, from well over 250 sources.“
(Pearson, 2011)
36
Das Geschäftsmodell von flickr wurde mittlerweile von vielen anderen Photosharing-Sites
wie Google Picasa oder Photobucket.com kopiert und eignet sich deshalb gut zur Charak-
terisierung dieses Produktgenres:
Photosharing-Plattformen bieten Fotografen und Fotografinnen eine leistungsstarke
Online-Software zum Erstellen und Präsentieren ihrer Bilder und Fotoalben im In-
ternet. Der Online-Dienstanbieter kümmert sich um den laufenden Betrieb, die
Wartung und etwaige Updates der involvierten Hard- und Software. Damit stellt
eine Photosharing-Platform ein SaaS (Software-as-a-Service)-Angebot im Sinne
des Cloud-Computings dar [vgl. (Vogel, et al., 2010, pp. 119-121)].
Die Kernfunktionen von Photosharing-Diensten sind die Bereitstellung von
Online-Fotogalerien, die sich sowohl von mobilen Endgeräten als auch von
Desktop-Browsern nutzen lassen (siehe Abbildung 11). Der/die ErstellerIn kann
detailliert festlegen, wer seine/ihre Galerien betrachten darf und diesen Personen-
kreis über eine Nachrichtenfunktion verständigen. Durch Beschlagwortung kann
er/sie die Auffindbarkeit seiner Bilder erhöhen, die dabei vergebenen Schlagworte
(Tags) werden häufig aggregiert in einer Tag Cloud dargestellt (siehe Abbildung
12). Der Upload der Bilder wird meist durch eine eigens programmierte Desktop-
Software erleichtert, welche die Fotos in ein geeignetes Übertragungsformat (meist
JPEG) konvertiert und so die Upload-Zeit verkürzt. Auch die BetrachterInnen kön-
nen sich die hochgeladenen Bilder in verschiedenen Auflösungen anzeigen lassen.
Aufgrund des verbrauchten Online-Speicherplatzes und der langen Upload-Dauer
werden die Fotos vor dem Upload allerdings oft verkleinert, wodurch dem/der Be-
trachterIn nur ein Bruchteil der möglichen Bildauflösung zur Verfügung steht – ein
„fauler“ Kompromiss, wie die Erläuterung der Problemstellung in Kapitel 3.3 zeigen
wird.
Einnahmen generieren die meisten Photosharing-Dienste über ein „Freemium“-
Modell. „Freemium“ ist eine Wortkombination aus „free“ und „premium“ und be-
zeichnet ein Geschäftsmodell, bei dem der Kunde/die Kundin anfangs ein kostenlo-
ses Basisprodukt nutzen kann, später aber auf dessen kostenpflichtige Premium-
Variante wechseln wird. Dieser Wechsel wird durch den bewusst reduzierten Funk-
tionsumfang des Basisprodukts provoziert, der ab einer gewissen Nutzungsdauer
hinderlich wird. Flickr.com limitierte über viele Jahre das monatliche Upload-Volu-
men seiner Gratis-Accounts, um die NutzerInnen zum Umstieg auf die kosten-
pflichtige Pro-Variante zu bewegen. Andere Anbieter wie Picasa beschränken den
zur Verfügung stehenden Online-Speicherplatz. [vgl. (Osterwalder & Pigneur, 2011,
p. 100)]
Als „retention tools“, die User am Abwandern zu alternativen Diensten hindern sol-
len, dienen häufig Diskussionsforen und andere Community-Werkzeuge. In den
zahlreichen Flickr-Diskussionsgruppen können sich Fotografinnen und Fotografen
37
zu unterschiedlichen Fachbereichen wie Tier- oder Naturfotografie austauschen
und auch Feedback zu eigenen Werken erhalten.
Abbildung 12: Tag Clouds visualisieren die Popularität von Schlagworten über deren Schriftgröße.
Obwohl soziale Netzwerke wie Facebook den klassischen Photosharing-Diensten beim
Veröffentlichen von Bildmaterial immer mehr Konkurrenz machen, sind letztere noch im-
mer das Mittel der Wahl zur Publikation größerer Bildkataloge. Ein auf visuelle Inhalte ab-
gestimmtes Layout und die Möglichkeit zur Veröffentlichung größerer Bildauflösungen sind
nur zwei Beispiele für wichtige Differenzierungsfeatures. Allerdings werden weitere Inno-
vationen nötig sein, um die „Kernkompetenz“ Photosharing gegenüber sozialen Netzwer-
ken zu behaupten. Der in Kapitel 3.3.1 vorgeschlagene RAW-Entwicklungsmodus könnte
eine solche Innovation darstellen.
3.3 Problemstellung und Lösungsansatz
In den vergangenen sieben Jahren hat der Autor über 120 Fotoalben mit seiner DSLR er-
stellt und über verschiedene Photosharing-Dienste im Freundes- und Bekanntenkreis ge-
teilt. Dabei ist er auf folgende drei Hauptprobleme gestoßen, deren Ursachen bereits im
vorangegangenen Kapitel angeschnitten wurden:
1. Kein Cloud-Backup von RAW-Bildern: In der „Cloud“ (d.h. auf den umfassend
durch Backups, Zutrittsbeschränkungen, etc. gesicherten Servern des Photosha-
ring-Anbieters) werden nur verkleinerte und qualitätsgeminderte JPEG-Versionen
der Fotos gespeichert. Grund dafür sind die hohen Dateigrößen der RAW-Dateien,
38
die lange Upload-Zeiten und großes Datenvolumen verursachen. Dieses Datenvo-
lumen verursacht Kosten in Form von erhöhtem Internet-Traffic und Server-Spei-
cherplatz. Die wertvollen „digitalen Negative“ liegen relativ ungeschützt auf lokalen
Festplatten in den Wohnräumen des Autors.
2. Kein mobiler Zugriff auf hochauflösende Bildversionen: es ist nicht möglich,
von unterwegs auf die hochaufgelösten Originalbilder zuzugreifen, um beispiels-
weise Bekannten spontan druckfähige Versionen der im Internet geteilten Fotos
zukommen zu lassen. Die Kundschaft professioneller Fotografinnen und Fotografen
muss anhand niedrig aufgelöster Vorschaubilder in Web-Galerien entscheiden,
welche Fotos sie gerne (kostenpflichtig) bestellen würde.
3. Für Ausarbeitungen/Bearbeitungen müssen Bilder mehrfach hochgeladen
werden: erfolgt die Bestellung von Fotoprodukten wie Postern, Fotobüchern oder
Plakaten bei verschiedenen Dienstleistern, müssen die Bilder vom lokalen PC
mehrfach hochgeladen werden. Da es mittlerweile eine Vielzahl von Fotoprodukten
und Anbietern gibt, die sich jeweils auf verschiedene Teilsegmente spezialisiert
haben, ist es durchaus wahrscheinlich, dass ein/e AnwenderIn bei mehreren An-
bietern Aufträge platziert. Für RAW-Bilder können selbst einfache Bearbeitungen
nicht online ausgeführt werden. Selbst wenn das unter Punkt 1 geschilderte Cloud-
Backup angeboten wird, wären also mehrere Up- und Downloads erforderlich, um
das RAW-Foto für verschiedene Anwendungszwecke anzupassen.
Um die angenommene Problemstellung einem Realitätstest zu unterziehen, wurde der
Leistungsumfang der wichtigsten Photosharing-Anbieter in Bezug auf die genannten
Probleme untersucht. Die Untersuchung erfolgte anhand folgender Kriterien:
Erlaubt der Anbieter einen Upload von RAW-Bildern oder müssen diese vorher in
andere Bildformate (z.B. JPEG oder TIFF) konvertiert werden? Ist ein Download
der vom Anbieter gehosteten RAW-Bilder möglich?
Bietet die Photosharing-Site eine Browser-Darstellung der RAW-Bilder, bei der
diese in voller Auflösung betrachtet werden können?
Gibt es Online-Bearbeitungsfunktionen für RAW-Bilder (Helligkeits- und
Farbkorrekturen etc)?
Request-Workflow: Können Kundinnen und Kunden von Fotoschaffenden gezielt
hochauflösende Versionen von einem niedrig aufgelösten Bild anfordern (bei-
spielsweise zur Erstellung eines Fotobuchs). Wie hoch ist der Automatisierungs-
grad dieses Prozesses?
39
Anbieter Upload Download Darstellung
im Browser
Bearbeitung Request-
Workflow
Instagram.com nein22 nein nein nein nein
Photobucket.com nein23 nein nein nein nein
Flickr.com nein24 nein nein nein nein
Picasa.com / Google+
Photos
ja ja ja (Zoom
beschränkt)
ja (JPEG-
Version)
nein
Dropbox.com ja ja nein25 nein nein
SmugMug.com ja26 ja nein nein nein
Tabelle 2: Camera-RAW-Unterstützung der wichtigsten Photosharing-Sites (Stand: August 2013)
Die Ergebnisse in Tabelle 2 zeigen, dass kein Anbieter alle genannten Kriterien unterstützt.
Die Hälfte der Anbieter erlaubt überhaupt keinen RAW-Upload, der Request-Workflow wird
von keinem der Anbieter unterstützt. Picasa/Google+ zeigt zwar gute Ansätze, die
Browserdarstellung ist bei diesem Dienst aber nur auf wenige Zoomstufen beschränkt. Bei
den Bearbeitungsfunktionen wird nur eine JPEG-Version des RAW-Bildes verwendet.
Daher sollte im Rahmen dieser Masterarbeit an einer besseren Lösung des Problems
gearbeitet werden.
3.3.1 Ein erster Lösungsansatz
Ein erster, vom Autor spontan entworfener Lösungsansatz sieht einen cloud-basierten
Online-Dienst für RAW-Fotos vor, der Fotoschaffenden das interaktive Bearbeiten und
Teilen ihrer Fotos im Browser erlaubt.
Abbildung 13 zeigt den grundlegenden Aufbau des Dienstes in 5 Schritten:
1. Der Fotograf konvertiert die RAW-Fotos in das komprimierte DNG-Format, wodurch
zwischen 10 und mehr als 75% des Speicherplatzes gespart werden27. Durch die
Wahl der „richtigen“ Kompressionsmethode lässt sich ein guter Kompromiss zwi-
22
vgl.: http://instagram.com/developer/iphone-hooks/ 23
vgl.: http://support.photobucket.com/entries/21812019-Troubleshooting-Upload-Problems 24
vgl.: https://www.flickr.com/help/photos/#150488231 25
https://www.dropbox.com/help/6/en 26
Unterstützung über kostenpflichtiges Zusatzprodukt SmugMugVault –siehe
http://help.smugmug.com/customer/portal/articles/93324 27
Der Einsparungsgrad hängt vom Ausgangsformat des RAW-Fotos und von der Wahl der DNG-Komprimierung
(verlustfrei/verlustbehaftet) ab. Die Dateigrösse neuerer RAW-Formate verringert sich bei verlustfreier DNG-
Komprimierung nur mehr um 10-20%, da das Ausgangsformat bereits ähnliche Kompressionstechniken einsetzt. Mit Lossy
DNG, der verlustbehafteten Version, ist eine Einsparung um mindestens 75% möglich, die allerdings zulasten der späteren
Bearbeitungsmöglichkeiten geht. Durch die Anpassbarkeit der Bildauflösung lässt sich bei Lossy DNG die Dateigröße
dramatisch reduzieren (siehe Tabelle 1)
40
schen Datenmenge/Upload-Dauer und der erforderlichen Bildqualität des Fotos er-
zielen.
2. Upload der konvertierten Fotos über das HTTP-Protokoll auf den Server des
Online-Dienstes, wofür entweder der Web-Browser oder ein kommandozeilenba-
sierter HTTP-Client wie curl28 verwendet werden kann.
3. Der Online-Dienst prozessiert die einlangenden Bilder am Server in eine Bildpyra-
mide und speichert sie in einem kachelbasierten Bildformat, das eine effiziente
Übertragung einzelner Bildansichten ermöglicht (siehe Abschnitt „Bildkachelung zur
schnelleren Anzeige“)
4. AnwenderInnen können das gekachelte Bild nun über ein Anzeigeprogramm (tile
viewer) im Webbrowser betrachten. Da viele tile viewer mittlerweile in der im Brow-
ser integrierten Skriptsprache Javascript verfügbar sind, müssen zur Betrachtung
der Bilder keine Zusatzprogramme installiert werden. Die meisten tile viewer funkti-
onieren auch auf mobilen Endgeräten wie Smartphones.
5. Durch das Anhängen von URL-Parametern an die Bildkacheln kann eine serversei-
tige Bearbeitung mit Filtern oder Transformationswerkzeugen ausgelöst werden
(siehe Abschnitt „Bearbeitungsfunktionen“).
Abbildung 13: Struktur des RAW2Cloud-Dienstes29
28
curl ist ein Kommandozeilen-Tool zur URL-basierten Datenübertragung in Computernetzwerken und kostenlos unter
http://curl.haxx.se/ verfügbar 29
Quelle: vom Autor erstellte Übersichtsgrafik unter Verwendung von Einzelgrafiken, die auf OpenClipart.org unter der
Public-Domain-Lizenz veröffentlicht wurden (siehe: http://openclipart.org/share)
41
Bildkachelung zur schnelleren Anzeige
Am Server wird das hochgeladene RAW-Bild in eine gekachelte Bildpyramide prozessiert
(siehe Abbildung 14, Schritt 3) und in ein Kachelformat konvertiert. Eine Bildpyramide ist
eine hierarchische Struktur, die ein pixelbasiertes Bild in verschiedenen Auflösungen re-
präsentiert. Die unterste Stufe entspricht dem Bild in Originalauflösung. Für alle weiteren
Stufen wird das Bild der vorherigen Stufe auf 25% seiner Größe verkleinert (d.h. seine
Länge und Breite halbieren sich), bis ein vordefinierter Grenzwert erreicht wird. Meist wird
die Verkleinerung abgebrochen, wenn das Bild in einer Kachel (siehe folgender Absatz)
Platz findet.
Anschließend werden die errechneten Zwischenauflösungen gekachelt, also in quadrati-
sche Einzelbilder mit vorgegebener Größe unterteilt. Verbreitete Kachelauflösungen sind
256 x 256 oder 512 x 512 Pixel.
Abbildung 14: Aufbau einer Bildpyramide30
Nun erfolgt die Konvertierung in das Kachelformat, bei der die generierten Kacheln in ein
internettaugliches Übertragungsformat konvertiert und nach einer bestimmten Dateina-
menskonvention abgespeichert werden. Verbreitete Kachelformate sind das von Microsoft
entwickelte DeepZoom-Format31 und das vom gleichnamigen Unternehmen veröffentlichte
Zoomify-Format32. Während das einfachere Zoomify-Format die Bildpyramide eines
hochauflösenden Fotos abspeichern kann, unterstützt das komplexere DeepZoom-Format
ineinander übergehende Bildpyramiden (sparse images) und Kollektionen mehrerer Bilder.
30
vgl.: IIPImage Project Documentation (http://iipimage.sourceforge.net/documentation/images/) 31
vgl.: http://blogs.msdn.com/b/jaimer/archive/2008/03/31/a-deepzoom-primer-explained-and-coded.aspx 32
vgl.: http://zoomify.com/
42
Beide Formate bestehen aus einem Metadatendokument und einer standardisierten Datei-
pfadstruktur. Das im XML-Format vorliegende Metadatendokument beschreibt die Auflö-
sung des Originalbildes, die Anzahl seiner Bildpyramidenstufen und die verwendete Ti-
legröße. Die standardisierte Dateipfadstruktur erlaubt es dem Anzeigeprogramm, den
Dateinamen einer anzufordernden Kachel aus den bereits vorhandenen Metadaten zu er-
rechnen. Beim Zoomify-Format lautet die Struktur TileGroup{TileGroupIndex}/{z}-
{x}-{y}.jpg, wobei sich die Platzhalter wie folgt errechnen:
TileGroup: ergibt sich aus der aktuellen Zoomstufe sowie dem Rechts- und Hoch-
wert der Kachel.
z: entspricht der Zoomstufe, also der aktuellen Ebene der Bildpyramide (0=Spitze
der Pyramide, entspricht kleinster Zoomstufe)
x: entspricht dem Rechtswert der Kachel auf der aktuellen Ebene der Bildpyramide
y: entspricht dem Hochwert der Kachel auf der akutellen Ebene der Bildpyramide.
Mithilfe des Metadatendokuments und der standardisierten Ordnerstruktur kann das An-
zeigeprogramm später gezielt jene Kacheln anfordern, die für die aktuelle Ansicht des Bil-
des erforderlich sind, unnötige Datenübertragungen unterbleiben (siehe Abbildung 14,
Schritt 4). Damit eignen sich Kachelformate auch für die Darstellung hochauflösender Bil-
der auf mobilen Endgeräten.
Ein Beispiel verdeutlicht dies: betrachtet man ein gekacheltes RAW-Bild in einem 1024 x
1792 Pixel großen Viewer-Fenster, sind dafür 7 x 4 = 28 Kacheln à 256 x 256 Pixel Auflö-
sung erforderlich. Bei etwa 5 Kilobyte Dateigröße je Kachel sind dies 140 KB Daten. Das in
diesem Beispiel verwendete RAW-Bild hat eine Dateigröße von 22,5 Megabytes, was in
etwa der 160-fachen Datenmenge entspricht. Selbst bei einer vorherigen Konvertierung in
das verlustbehaftete JPEG-Format hat das Bild noch 1,48 MB, was der etwa zehnfachen
Datenmenge entspricht.
Bearbeitungsfunktionen
Will der/die UserIn nun das RAW-Bild im Browser bearbeiten, sollen die verwendeten
Filtereinstellungen (z.B. Tonwertkorrektur, Weißabgleich) über URL-Parameter an den
Server übertragen werden. Dieser öffnet die RAW-Datei, wendet die Einstellungen an und
generiert eine gekachelte Version des Bildes, die auf den Client übertragen wird. Die Be-
arbeitungen am Server nimmt ein kommandozeilenbasierter Bildprozessor vor, wie bei-
spielsweise das weitverbreitete OpenSource-Tool ImageMagick33. Der Bearbeitung
nachgelagert ist der oben bereits erwähnte Kachelungsprozess. Anschließend werden die
Bildkacheln an den Browser zurückgeschickt.
33
ImageMagick ist ein für Windows, Linux und MacOS verfügbares Kommandozeilentool, das Bilder in verschiedensten
Formaten bearbeiten kann. Das Programm ist unter http://www.imagemagick.org/ kostenlos beziehbar.
43
Eine Technologierecherche ergab, dass es bereits einige cloud-basierte Bildbearbeitungs-
dienste gibt, wie beispielsweise cloudinary (http://www.cloudinary.com). Dieser Dienst bie-
tet unter anderem Bearbeitungsfunktionen für bereits in der Cloud befindliche Bilder an,
wobei die anzuwendenden Bearbeitungsschritte über URL-Parameter übergeben werden.
Kachelungen größerer Bilder unterstützte aber keiner dieser Dienste.
Abbildung 15: Ausgangsbild für den Test des Cloud-Bildbearbeitungsdiensters cloudinary34
Abbildung 16: Durch den URL-Parameter e_contrast:80 wurde der Kontrast des Fotos erhöht35
.
34
Quelle: Cloudinary.com, abrufbar unter http://a5.res.cloudinary.com/demo/image/upload/horses.jpg 35
Quelle: Cloudinary.com, abrufbar unter http://a5.res.cloudinary.com/demo/image/upload/e_contrast:80/horses.jpg
44
3.4 Überführung der Lösung in ein Produkt
Die bisherigen Abschnitte dieses Kapitels widmeten sich einer ausführlichen Erläuterung
des Problems und der Formulierung eines Lösungsansatzes. Der „logische“ nächste
Schritt wäre die Umsetzung des Lösungsansatzes in einen realitätsnahen Prototypen. Die-
ses Vorhaben würde sich über mehrere Monate hinziehen und neben einem beträchtlichen
Einsatz an Arbeitszeit auch zahlreiche weitere Investitionen in Server-Hardware, Software-
Lizenzen, Fachliteratur etc. erfordern. Potentielle Kunden bekämen den Prototypen also
erst zu Gesicht, nachdem der/die EntrepreneurIn eine beträchtliche Menge der zur Verfü-
gung stehenden Ressourcen investiert hat.
In dieser Herangehensweise ortet Lean-Canvas-Autor Ash Maury zwei Hauptprobleme:
1. „The bigger risk for most startups is building something nobody wants“ (Maurya,
2012, p. 43) - das größte Risiko eines Startups ist die Entwicklung eines Produk-
tes, das niemand brauchen kann. Mit der oben geschilderten Prototyp-Entwicklung
„im stillen Kämmerlein“ findet der nötige Abgleich zwischen der Idee des Entrepre-
neurs oder der Entrepreneurin und der Realität viel zu spät statt. Innovierende
sollten daher die Praxistauglichkeit ihrer Ideen durch Befragung der angedachten
Zielgruppe prüfen, bevor sie nennenswerte Ressourcen in die Umsetzung investie-
ren.
2. Die gesamte Aufmerksamkeit wird auf den (technischen) Lösungsaspekt der Idee
gelenkt. Dieser macht aber nur einen verschwindend kleinen Anteil des späteren
Produktes aus. Wichtige Produktaspekte wie Zielgruppe, Absatzkanäle, Ge-
schäftsmodell bleiben unberücksichtigt. „Your job isn’t just building the best
solution, but owning the entire business model and making all the pieces fit.“
(Maurya, 2012, p. 42)
Mit bereits in Kapitel 2.4.1 vorgestellten Lean Canvas versucht Maurya, die meist auf
technische Aspekte beschränkte Perspektive von Innovierenden zu erweitern und ihre
Aufmerksamkeit auf eine ganzheitliche Produktentwicklung zu lenken. Der Lean Canvas
„dekonstruiert“ das Produkt dabei in neun verschiedene Bereiche, die im Rahmen einer
kurzen Kreativitätssitzung befüllt werden.
Alle nun folgenden Aktivitäten haben das Ziel, die gemachten Angaben zu prüfen und ge-
gebenenfalls zu korrigieren, wobei mit den riskantesten Angaben begonnen wird. Der in
Abbildung 17 dargestellte Lean Canvas ist entsprechend durchnummeriert.
45
Abbildung 17: Leerer Lean Canvas mit Ausfüllhilfen (Maurya, 2012, p. 66)
3.4.1 Problem und Kundensegmente
Maurya empfiehlt, mit dem Befüllen der Segmente „Problem“ und „Kunden“ zu beginnen.
Der/die EntrepreneurIn sollte bereits ein klares Bild von der Zielgruppe des späteren Pro-
duktes haben und sich in ihre Lage versetzen. Welche ihrer dringenden Probleme kann
das Produkt lösen? Gibt es existierende Konkurrenzprodukte, die das Problem (ansatz-
weise) lösen? Die Konkurrenzanalyse sollte nicht aus der Perspektive der Innovierenden,
sondern aus dem Blickwinkel der potentiellen Kunden erfolgen. Dies kann mitunter zu
überraschenden „Konkurrenten“ führen: eine neuartige Buchhaltungssoftware für Heiman-
wender wird sich nicht nur mit existierenden Lösungen aus diesem Marktsegement ver-
gleichen müssen, sondern auch mit einer Tabellenkalkulation, da viele EinsteigerInnen
Tabellenkalkulationen für Buchhaltungszwecke verwenden. Für die spätere Entwicklung
des Geschäftsmodells ist es außerdem wichtig, zwischen nutzenden und zahlenden Kun-
den und Kundinnen eines Produkts zu unterscheiden. Bei einem Internet-Preisvergleich-
sportal wird die überwiegende Anzahl der NutzerInnen aus Kaufinteressierten bestehen,
die kostenlose Preisvergleiche durchführen wollen. Die eigentlichen Kunden des Portals
sind aber die dort gelisteten Unternehmen, denn sie bezahlen für diese Leistung [vgl.
(Maurya, 2012, p. 66f)].
46
Die potentielle Zielgruppe seines Online-Dienstes für RAW-Fotos sieht der Autor in folgen-
den Anwendergruppen:
(Hobby)-Fotografen und Fotografinnen mit DSLR-Kamera und regelmäßiger
Bildausbeute
An hochauflösenden RAW-Fotos interessierte Kunden und Kundinnen von Foto-
schaffenden (bessere Beurteilung von Schärfe,..)
Fotografinnen und Fotografen, die ihre RAW-Bilder online zum Kauf anbieten
möchten.
Die wichtigsten, noch ungelösten Probleme dieser Zielgruppe sind nach Sichtweise des
Autors folgende:
Photosharing-Dienste unterstützen keine hochauflösenden (RAW)-Bilder mit mehr
als 5 Megapixel Auflösung
Photosharing-Dienste ermögliche kein Backup der originalen RAW-Bilder in der
Cloud.
Es gibt keine Möglichkeit, unterwegs oder von Drittrechnern aus auf hochauflö-
sende Bilder zuzugreifen. Dies ist aber zur Beurteilung von Schärfe und Bilddetails
erforderlich.
Für Ausarbeitungen müssen hochauflösende Bilder mehrfach hochgeladen werden,
wenn der Kunde oder die Kundin verschiedene Fotodienstleister nutzen will.
3.4.2 Unique Value Proposition
Unter „Unique Value Proposition“ versteht Maurya Alleinstellungsmerkmale des Produkts,
welche seinen Kauf oder zumindest das Interesse der Kunden und Kundinnen am Produkt
rechtfertigen. Der Begriff lässt sich in etwa mit „einzigartiges Wertangebot“36 ins Deutsche
übersetzen. Maurya sieht in der Definition dieses Wertangebots einen der schwierigsten
Lean Canvas-Bereiche, da sowohl die rationale als auch emotionale Seite der Kundschaft
angesprochen werden muss. Häufige Fehler bei der Wahl des Wertangebots sind Allein-
stellung um jeden Preis (auch wenn das Merkmal für die Zielgruppe gar nicht relevant ist)
oder die bloße Aufzählung von Produktfunktionen ohne den Endnutzen für die Kundschaft
hervorzuheben (z.B. „professionelle Gestaltung von Bewerbungsunterlagen“ vs. „Ihre
Eintrittskarte für den nächsten Traumjob“). [vgl. (Maurya, 2012, p. 70f)]
Mögliche Wertangebote für den Online-RAW-Dienst sind:
Online immer auf die native/beste Bildauflösung zugreifen
RAW-Bilder im Browser und auch auf mobilen Endgeräten bearbeiten
36
In der deutschen Ausgabe von (Osterwalder & Pigneur, 2011) wurde der englische Begriff „value proposition“ mit dem
deutschen „Wertangebot“ übersetzt. Da die von Maurya gewählte Bezeichnung auf diesem Begriff aufbaut, hat der Autor
die Übersetzung übernommen.
47
Ihre schönsten Momente in bester Qualität und an den sichersten Orten der Welt
gespeichert
RAW-Bilder online zu Geld machen
3.4.3 Solution
Im Bereich „Solution“ sieht Maurya den vielleicht gefährlichsten Lean-Canvas-Bereich. Hier
beschreiben die Innovierenden jene oft technischen Produkteigenschaften, mit denen die
in Punkt 1 genannten Probleme gelöst werden sollen. Da viele Innovierende einen techni-
schen Background besitzen, besteht die Gefahr, diesem Punkt zuviel Aufmerksamkeit und
Detailierung zu widmen oder aber an „liebgewonnenen“ Lösungsansätzen festzuhalten,
auch wenn diese den Bedürfnissen der Zielgruppe widersprechen. Aus diesem Grund hat
Maurya das Solution-Feld besonders klein ausgeführt und hält ausdrücklich fest, dass der
technische Lösungsansatz im Verlauf der Lean-Canvas-Iterationen häufig geändert wer-
den muss. [vgl. (Maurya, 2012, p. 75f)]
Für den Online-Dienst des Autors bieten sich folgende Lösungselemente an:
RAW-Upload in die Cloud im komprimierten DNG-Format (75% geringere Dateig-
röße)
browerbasierter Viewer auf Tile-Basis (auch für mobile Endgeräte)
API zur Anbindung an Fotodienstleister verhindert unnötige Up- und Downloads
3.4.4 Channels
Channels sind Kanäle zu potentiellen Kundinnen und Kunden. In der Frühphase von
Running Lean wird der/die EntrepreneurIn diese Interessenten aus dem Freundes- und
Bekanntenkreis bzw. dem professionellen Umfeld rekrutieren. Mit ihnen überprüft und
verfeinert er/sie die Geschäftsidee in den problem und solution interviews (siehe Kapitel
4.1 und 5.3), Für die später angestrebte Wachstumsphase des Startups ist es aber
unerlässlich, sich frühzeitig über Kanäle zu neuen Kundinnen und Kunden Gedanken zu
machen. Es gilt, aus der Fülle der möglichen Kanäle – von Blogs über Online-Anzeigen bis
hin zur Präsenz auf Fachmessen – die für das Produkt passenden auszuwählen.
Maurya charakterisiert dazu die Kanäle nach folgenden Gesichtspunkten [vgl. (Maurya,
2012, p. 76)]:
Inbound/Outbound: Bei Inbound-Kanälen initialisiert der/die InteressentIn den
Kontakt, indem er/sie beispielsweise einen Blog-Beitrag zur Produktidee mit einer
Nachfrage-Email beantwortet und mehr über das vorgestellte Produkt wissen will.
Auch im Internet veröffentlichte Tutorials, Online-Seminare oder E-Books können
Inbound-Kontakte generieren. Bei Outbound-Kanälen hingegen stellt der/die Entre-
preneurIn den Kontakt her, etwa durch gezielte Schaltung von Werbeanzeigen,
48
Verfassen von Newslettern oder das in Europa meist verbotene cold calling – dem
ungefragten Anrufen potentieller Interessenten.
Kostenlos/Kostenpflichtig: Ein Kanal kann kostenlos oder kostenpflichtig sein.
Ein Blog kann – zumindest in einer einfachen Basisversion – bei diversen Online-
Anbietern kostenlos betrieben werden. Für die Schaltung von Online-Anzeigen fal-
len hingegen sofort Gebühren an. Bei näherer Betrachtung zeigt sich allerdings,
dass kein Kanal wirklich kostenlos sein kann – schließlich muss der/die Entrepre-
neurIn für das Verfassen von Blog-Beiträgen Arbeitszeit investieren. Auch bei kos-
tenpflichtigen Kanälen kann der nötige Aufwand an Humankapital den „offiziellen“
Preis schnell übersteigen. Möchte der/die EntrepreneurIn beispielsweise 300 EUR
in die Schaltung von Online-Anzeigen investieren, ist es durchaus wahrscheinlich,
dass die Produktionskosten der erforderlichen Texte und Grafiken die reinen „Ka-
nalkosten“ (d.h. den Preis der Schaltungen) bei weitem übersteigen.
Direkt/Indirekt: Der/die EntrepreneurIn kann das Produkt entweder selbst bzw.
durch eigene Mitarbeiter verkaufen (direkter Kanal) oder sich dafür einer Vertriebs-
partnerschaft mit einem etablierten Unternehmen bedienen (indirekter Kanal).
Manuell/Automatisiert: Bei einem manuellen Kanal findet die Kundenkommunika-
tion immer zwischen zwei Menschen statt, bei der automatisierten Variante hinge-
gegen ersetzt meist ein Computerprogramm den Verkäufer. Ein Beispiel dafür sind
Empfehlungssysteme in Online-Shops, die den Kundinnen und Kunden automa-
tisch Alternativen zum aktuell betrachteten Produkt empfehlen und diese bei Bedarf
auch rabattieren.
Kundenkanäle werden vor allem in der Wachstumsphase des Startups relevant, die auf die
Entwicklungsphase des Produktes folgt. Maurya empfiehlt daher, den Kundenkanälen in
der Frühphase von Lean Canvas nicht zuviel Aufmerksamkeit zu schenken.
Dies betrifft etwa die Schaltung von Werbeanzeigen im Internet oder die Rekrutierung von
freiberuflichen Vertriebs- und Marketingmitarbeitern. Beide Aktivitäten helfen zwar den
Bekanntheitsgrad des Produktes bei der Zielgruppe zu steigern, kosten aber auch finanzi-
elle und zeitliche Mittel, die für die nötige Perfektionierung der Produktidee fehlen. Im
schlimmsten Fall erzeugt die frühzeitige Vermarktung der Idee einen erhöhten Nachfrage-
druck, der den/die EntrepreneurIn zwingt, das Vorhaben überhastet umzusetzen.
Inbound-Kanäle wie Blogs sind nach den Erfahrungen von Maurya mit geringeren Ge-
samtkosten behaftet als Outbound-Kanäle und können bereits in der Frühphase der Pro-
duktentwicklung mit Informationen bespielt werden, um die Aufmerksamkeit potentieller
Kunden zu erlangen. Vom exzessiven Einsatz von Outbound-Kanälen rät Maurya hinge-
gen ab. [vgl. (Maurya, 2012, p. 78f)]
49
Der Autor sieht in folgenden Kanälen gute Kontaktmöglichkeiten zu potentieller Kund-
schaft:
Fotogruppen an der FH Technikum Wien und FH St. Pölten (der Autor studierte an
beiden Hochschulen und hat Kontakt zu Lehrkräften)
Usergroups/Fotokurse im Raum Wien
Online-Werbung (Google Adwords)
Mundpropaganda
3.4.5 Einnahmequellen und Kostenstruktur
Die Sicherstellung von Einnahmen ist ein weiteres Problem bei der Umsetzung neuer Pro-
dukte: Welcher Kunde oder welche Kundin möchte schon für ein noch in Entwicklung
befindliches Produkt bezahlen? Nach Mauryas Ansicht wird er oder sie das gerne tun,
wenn das Produkt tatsächlich ein dringendes Problem löst. Zögert der/die EntrepreneurIn
hingegen die „Preisfrage“ hinaus, wird die endgültige Bestätigung der Produktidee ver-
fälscht, was die langfristige Existenz des Produktes gefährdet. Möglichen Zweifeln kann
mit einer großzügigen Geld-Zurück-Regelung und einer Abbuchung des Betrages am Ende
der Rechnungsperiode begegnet werden. Auf der Aufgabenseite sollte der/die
EntrepreneurIn unnötige Ausgaben vermeiden und die nötige Infrastruktur für die
Erzeugung und Bereitstellung des Produktes mieten [vgl. (Maurya, 2012, p. 81f)].
Die Einnahmen- und Ausgabenstruktur für den Online-Dienst des Autors sieht in einer
ersten Grobschätzung wie folgt aus:
Einnahmen werden über die monatlichen Nutzungsgebühren des Online-Dienstes
erwirtschaftet, die bei 10 EUR im Monat liegen sollen.
Die beiden Ausgabenblöcke bestehen aus Hosting- und Personalkosten:
o Hosting-Kosten für den Betrieb des Online-Dienstes auf einer Cloud-Platt-
form (Heroku/Amazon Cloud) - Grobschätzung 1000 EUR
o Monatliche Brutto-Personalkosten für eine Vollzeitstelle (Autor, 40h*60
EUR*4,5 Wochen) = 10800 EUR
Aus diesen Zahlen folgt, dass der Break-Even bei 1200 Usern und Userinnen liegen
müsste.
3.4.6 Wichtige Kennzahlen (key metrics)
Moderne Kennzahlensysteme wie Balanced Scorecard verlassen sich bei der Beurteilung
des Unternehmenserfolges nicht ausschließlich auf Finanzkennzahlen, da diese den Zu-
stand des Unternehmens verspätet und nur teilweise abbilden. Ein Unternehmen, dass
seine Innovationsaktivitäten eingestellt hat und sich auf den Vertrieb seiner erfolgreichen
50
Bestandsprodukte konzentriert, mag durch die Einsparung der Entwicklung zwar momen-
tan gute Gewinne erwirtschaften, in einigen Jahren wird es aufgrund veralteter Produkte
aber in Konkurs gehen.
Auch bei der Beurteilung neu eingeführter, innovativer Produkte darf man sich nicht aus-
schließlich auf die erzielten Umsätze verlassen. Setzt das Unternehmen beispielsweise
das in Kapitel 3.2.3 vorgestellte Freemium-Geschäftsmodell ein, werden die meisten
AnwenderInnen anfangs die kostenlose Basisversion des Produkts nutzen und erst später
Umsätze über die kostenpflichtige Premium-Version generieren.
Lean Canvas nutzt ein ganzheitliches Kennzahlensystem, um den Umsetzungserfolg einer
Idee zu beurteilen. Maurya empfiehlt das Pirate Metrics System von Dave McClure, um
das gesamte Interaktionsverhalten von Kunden und Kundinnen mit dem neuen Produkt in
Form von Kennzahlen abzubilden und so die Stärken und Schwächen in der Interaktions-
kette zu analysieren. Dieses System sieht folgende Interaktionsphasen vor:
Abbildung 18: Das Pirate-Metrics-Modell von Dave McClure [Quelle: (Maurya, 2012, p. 85)]
Acquisition: die Kundschaft wird auf das Produkt aufmerksam. Beispiele: eine
Kundin betritt ein Geschäft oder interagiert mit der Produktwebsite.
Activation: die Kundschaft hat die erste positive Erfahrung mit dem Produkt. Bei-
spiel: eine gelungene Warenpräsentation im Geschäft oder eine vielversprechende
Demonstration auf der Produktwebsite.
Retention: die Kundschaft nutzt oder probiert das Produkt wiederholt – dies kann
sowohl ein mehrfaches Ausprobieren vor dem Kauf im Geschäft bedeuten oder die
Nutzung einer Demoversion
51
Revenue: die Kundschaft bezahlt für das Produkt – der Kunde erwirbt das
physikalische Produkt im Geschäft oder nutzt die kostenpflichtige Premium-Version
eines Online-Dienstes
Referral: die Kundschaft empfiehlt das Produkt weiter und wirbt aktiv um andere
Anwender.
Die trichterförmige Darstellung der Phasen in Abbildung 18 kommt nicht von ungefähr: sie
symbolisiert den Selektionsprozess von einer größeren Anzahl von Interessierten in eine
kleinere Anzahl von Kunden und Kundinnen, wobei in jeder Phase eine Reduktion stattfin-
det. Nicht jede Person, der auf ein Produkt aufmerksam wird (Activation) möchte dieses
auch ausprobieren (Retention), von den Testern und Testerinnen eines Produkts wird sich
nur ein bestimmter Prozentsatz zum Kauf (Revenue) entschließen. Durch die Abbildung
des gesamten Kundeninteraktionsprozesses in Form von Pirate-Metrics-Kennzahlen kann
der/die EntrepreneurIn Schwächen im Angebot präzise aufspüren: signalisieren die Kenn-
zahlen gute Acquisition-Interaktionen, aber schlechte „Activation“, könnte den Interessier-
ten das Testen des Produkts zu kompliziert erscheinen (beispielsweise aufgrund einer
langwierigen Registrierung oder verpflichtender Software-Downloads). Bei Freemium-
Geschäftsmodellen gibt es häufig gute Retention-Werte, aber zu wenig Revenue (Umsatz)
– ein Hinweis darauf, dass die kostenlose Basisversion zu großzügig gestaltet wurde und
die AnwenderInnen keinen Grund sehen, auf die kostenpflichtige Premiumversion
upzudaten. [vgl. (Maurya, 2012, p. 89f)]
Für den Dienst des Autors könnte man folgende Pirate Metrics Kennzahlen definieren:
Acquisition: Anzahl Besuche Website
Activation: Anzahl der Anmeldungen für die kostenlose Basisversion
Retention: Anzahl der hochgeladenen Bilder
Revenue: Anzahl der NutzerInnen für die kostenpflichtige Premium-Version
Referral: Anzahl der Einladungen an Dritte zur Nutzung des Online-Dienstes
3.4.7 Unfairer Vorteil (unfair advantage)
Maurya definiert einen unfairen Vorteil als eine Eigenschaft, die nicht einfach kopiert oder
gekauft werden kann. Sollte sich die Produktidee des/der EntrepreneurIn als erfolgreich
erweisen, muss diese/r den unfairen Vorteil ausspielen, um sich gegen finanziell besser
gestellte Konkurrenzunternehmen zu wehren, welche die Idee kopieren wollen. Als Bei-
spiele für „unfaire Vorteile“ führt er Insider-Informationen, persönliches Charisma, eine
etablierte Kundencommunity oder gute Suchmaschinen-Platzierungen an. [vgl. (Maurya,
2012, p. 90)]
52
Der Autor könnte folgende „unfaire Vorteile“ mitbringen:
gute Kontakte in die lokale Fotografie-Community
für die Umsetzung nützliches KnowHow aus GIS-Branche (Web-Kartendienste)
3.5 Der „Plan A“ als Lean Canvas
Zusammengefasst sieht der Lean Canvas für den Online-Dienst des Autors wie folgt aus:
Abbildung 19: Der Plan "A" als Lean Canvas (Maurya, 2012, p. 66)
53
4 Test des „Plan A“
Der „Plan A“ des Autors wurde zwar nun umfassend in einem Lean Canvas dokumentiert,
dieser Plan enthält aber zahlreiche ungeprüfte Annahmen: sieht die Zielgruppe tatsächlich
einen zwingenden Nutzen in der Produktidee? Verspürt sie die Probleme tatsächlich in der
angenommenen Dringlichkeit?
4.1 Testen der Produktidee durch Problem Interviews
Zum Testen des „Plan A“, des Erstenwurfs der Produktidee, sieht die Lean-Canvas-Me-
thode die Befragung potentieller Kunden und Kundinnen im Rahmen von problem inter-
views vor. Diese etwa einstündigen, überwiegend aus offenen Fragen bestehenden Inter-
views dienen der qualitativen Validierung der Produktidee. Der/die EntrepreneurIn versucht
also nicht, eine möglichst große Anzahl an geeigneten Personen zu interviewen, sondern
konzentriert sich auf etwa sechs bis acht Kandidaten, die möglichst repräsentativ für die
angedachte Zielgruppe sind und Produktinnovationen zumindest wohlwollend gegenüber-
stehen – den klassischen „early adopter“. Im folgenden Abschnitt werden weitere wichtige
Überlegungen im Hinblick auf die Durchführung von problem interviews vorgestellt.
4.1.1 Vorüberlegungen
Die Bauen-Messen-Lernen-Feedbackschleife
Abbildung 20: Erfolgskriterien der Bauen-Messen-Lernen Feedbackschleife nach Ries (Maurya, 2012, p. 109)
Die von Eric Ries entwickelte und in Kapitel 2.2 vorgestellte Bauen-Messen-Lernen-Feed-
backschleife ist nach Maurya ein zentrales Element bei der Konzeption von problem inter-
views. Die ausformulierte oder schon teilweise umgesetzte Produktidee („Bauen“) wird
54
mittels der im Lean Canvas aufgestellten Hypothesen bewertet („Messen“) und aufgrund
des Feedbacks angepasst („Lernen“). Problem interviews sind also keine Verkaufsgesprä-
che, sondern dienen folgenden Zielen [vgl (Maurya, 2012, p. 107)]:
Effektives Lernen: Der/die EntrepreneurIn sollte die nötigen „Lektionen“ in Bezug
auf die Konzeption des Produktes und seine Vermarktung möglichst rasch und mit
wenig Aufwand lernen. Dabei getroffene Fehlannahmen (z.B. im Hinblick auf die
Zielgruppe oder die Funktionalität des Produkts) sollten möglichst schnell zutage
treten. Für effektives Lernen ist es unerläßlich, vom Erfahrungsschatz der Befrag-
ten zu profitieren. Im Vordergrund des Interviews steht daher nicht die neue Pro-
duktidee, sondern die bisherigen Erfahrungen und Herangehensweisen der be-
fragten Personen im Anwendungsbereich des künftigen Produkts.
Fokussierierung der Produktidee: Wie Abbildung 21 zeigt, sind Ideen in der
Frühphase der Produktentwicklung tendenziell zu weit gefasst: auf die einfache
Grundidee, Filme im Internet gegen Entgelt zu vertreiben, passen dutzende, grund-
verschiedene Ausführungen. Dies beweisen die in diesem Bereich tätigen Internet-
Unternehmen Netflix, Google, Bittorrent oder Vimeo, die sich in Bezug auf den ver-
triebenen Content (Hollywood-Produktionen versus von Nutzern produzierte Filme)
oder den Vertriebskanal (zentrale Cloud-Server versus dezentrale Peer-To-Peer
Netzwerke) unterscheiden. Der/die EntrepreneurIn sollte die problem interviews
daher nutzen, um sich auf mehrheitlich positiv beurteilte Aspekte der Produktidee
zu fokussieren und die weitere Entwicklung so zu konkretisieren.
Geschwindigkeit: Der/die EntrepreneurIn verfügt nur eine beschränkte Menge an
zeitlichen und finanziellen Mitteln zur Umsetzung der Idee. Lean Canvas verfolgt
das Ziel, die Bauen-Messen-Lernen Schleife innerhalb dieses Zeitraums möglichst
oft zu durchlaufen, um die Erfolgswahrscheinlichkeit der Ideenumsetzung zu erhö-
hen. Die problem interviews sollten daher möglichst rasch und über einen kurzen
Zeitraum hinweg durchgeführt werden. Daher sind eine gute Terminplanung und
die zeitnahe Verfügbarkeit der Befragten wichtige Erfolgskriterien für problem inter-
views.
55
Abbildung 21: Ideenlabyrinth - auf eine "Grobidee" passen dutzende, grundverschiedene Ausführungen
(Srinivasan & Pande, 2013)
Risikopriorisierung
Als Entwickler eines neuartigen Produkts ist der/die EntrepreneurIn mit vielen Risiken
konfrontiert. Die Produktidee kann an konzeptionellen Mängeln, fehlender Nachfrage oder
zu schwieriger Kundenakquise scheitern. Maurya empfiehlt daher, bereits in der Phase vor
den problem interviews mit einer einfachen Risikopriorisierung zu beginnen und die drän-
gendsten Gefahren in den Interviews gezielt anzusprechen. Das Feedback der Inter-
viewpartner erleichtert dann die Einschätzung der Risken oder kann sie bestenfalls aus
dem Weg räumen.
Unter dem Begriff Risiko wird gemeinhin ein möglicherweise eintretendes Ereignis mit un-
erwünschtem Ausgang verstanden. Die internationale Industrienorm ISO 30000 definiert
Risiko als das Produkt der Eintrittswahrscheinlichkeit eines Ereignisses und dessen negati-
ver Konsequenzen, die in verschiedenen Zielgrößen quantifiziert werden können. Da in der
Frühphase der Produktentwicklung oft die nötigen Erfahrungswerte für die Quantifizierung
der Risiken fehlen, verwendet Lean Canvas eine vereinfachte Risikopriorisierung anhand
dreier Risikoarten:
Produktrisiko: Löst das Produkt tatsächlich ein drängendes Problem potentieller
Kunden? Wenn ja, kann es unter den gegebenen finanziellen, personellen und
technischen Rahmenbedingungen so umgesetzt werden, dass es den Kundenan-
forderungen entspricht?
Akquisitionsrisiko: Wer genau ist die Zielgruppe des Produkts? Kann sie mit den
gegebenen Mitteln in ausreichender Zahl erreicht werden?
56
Marktrisiko: Lässt sich mit dem Produkt ein rentables Geschäftsmodell aufbauen?
Wie sieht die Konkurrenzsituation am Markt aus?
Bei der Identifizierung von Risiken ist es wichtig, zwischen diesen und gewöhnlichen Unsi-
cherheiten zu unterscheiden.
Abbildung 22 ordnet diese Risiken den Lean Canvas-Feldern zu. Nach Analyse seines
Lean Canvas kommt der Autor zum Schluss, dass bei seinem Online-Dienst das Produktri-
siko am größten ist. Angebot und Marktanteil der im weitesten Sinne konkurrierenden
Photosharing-Dienste ist bekannt, das Alleinstellungsmerkmal „RAW-Entwicklung“ wurde
bei der Konkurrenzrecherche in Kapitel 3.3 bestätigt. Durch gute Kontakte zu
Fotoschaffenden im deutschen Sprachraum erscheint auch das Akquisitionsrisiko verkraft-
bar.
Beim Produktrisiko bleiben allerdings sowohl bei der technischen Umsetzbarkeit als auch
beim Nutzen für die Kundinnen und Kunden einige Fragezeichen: kann die Lösung wie im
Erstentwurf der Idee (Kapitel 3.3.1) umgesetzt werden? Wenn nein, welche Adaptionen
sind mit welchem Aufwand erforderlich? Werden die Kunden funktionelle Einbußen (weni-
ger Bearbeitungsfunktionen im Vergleich zu Desktop-Programmen) zugunsten der gewon-
nenen Flexibilität und Datensicherheit (Bedienung im Webbrowser, Datenspeicherung in
der Cloud) in Kauf nehmen? Daher wird dem Produktrisiko im Aufbau der folgenden
problem interviews besondere Beachtung geschenkt.
Abbildung 22: Die Risikoarten und ihre Entsprechung im Lean Canvas [Quelle: (Maurya, 2012, p. 121)]
57
Qualitative versus Quantitative Validierung
Wie bereits in der Einleitung zu diesem Kapitel erwähnt, empfiehlt Maurya eine qualitative
Validierung der Produktidee in der Frühphase der Entwicklung. Erst nachdem sich ein
product/market-fit abzeichnet, also eine klare Übereinstimmung des Produktes mit den
Bedürfnissen des Marktes, kann die Idee mit einer quantitativen Validierung weiter verbes-
sert werden. Maurya stützt seine Herangehensweise auf eine Feststellung des US-Statis-
tikprofessors Douglas W. Hubbard:
„If you have a lot of uncertainty now, you don’t need much data to reduce uncertainty
significantly. When you have a lot of certainty already, then you need a lot of data to
reduce uncertainty significantly.“
(Hubbard, 2010, p. 110)
Demnach reichen in einem Szenario mit vielen Unsicherheiten wenige Messwerte aus, um
diese Unsicherheiten signifikant zu reduzieren, was für eine qualitative Validierung spricht.
Erst wenn in einem Szenario relativer Sicherheit diese signifikant gesteigert werden soll, ist
eine Vielzahl von Messwerten erforderlich.
Maurya nennt eine Mindestzahl von fünf problem interviews, um eine Produktidee sinnvoll
bewerten zu können. Er bezieht diese Anzahl aus einer Studie des User-Experience-Spe-
zialisten Jacob Nielsen, wonach fünf Testpersonen bis zu 85% der Konzeptionsfehler
einer grafischen Benutzeroberfläche erkennen können. Mehr Testpersonen können diesen
Wert nur mehr unwesentlich steigern, weshalb angesichts knapper Projektbudgets von
größeren Testteams abgesehen werden soll. (Nielsen, 2000).
Als Konsequenz dieser Aussagen wählte der Autor sechs professionelle Fotografen aus
seinem Bekanntenkreis als Interviewpartner aus. Diese haben einen Output von mehr als
500 Bildern im Monat, der Großteil von ihnen leitet Fotokurse im universitären Umfeld.
4.1.2 Aufbau und Ablauf der Problem Interviews
Die problem interviews folgten dem von Maurya in (Maurya, 2012, p. 138ff) empfohlenen
Aufbau und gliedern sich in einen kurzen, demografischen Teil und den Hauptteil, der die
angenommenen Probleme der Zielgruppe mit der Entwicklung von RAW-Fotos untersucht.
Die Interviews wurden von Juli bis September 2013 in Form von persönlichen Gesprächen
durchgeführt, Abschriften der Gespräche finden sich im Anhang dieser Arbeit.
58
Demografische Fragen
dienen der Erfassung einiger nützlicher statistischer Parameter (z.B. der Aktivitätsgrad des
Fotografen in Form der pro Monat erstellten Bilder) und geben überblicksmässig darüber
Auskunft, welche Produkte/Technologien von den Fotografen eingesetzt werden.
Besitzen Sie eine digitale Spiegelreflex-Kamera?
Wenn ja, um welches Modell handelt es sich?
Wieviele Fotos schießen Sie damit im Monat?
Fotografieren Sie im RAW oder JPEG-Format?
Welche der folgenden Tools verwenden Sie zum Bearbeiten Ihrer Fotos (Google
Picasa, Adobe Lightroom, div. andere Tools)
Welche der folgenden Online-Dienste verwenden Sie zum Teilen Ihrer Fotos?
(Flickr, Picasa, 500px, ...)
Feedback-Fragen
zu den angenommenen Problemen. Die Interview-Partner wurden gebeten, die Dringlich-
keit jedes Problems einzustufen („Wie wichtig ist eine Lösung des Problems für Sie?“) und
in freier Form zu dem Problem Stellung zu nehmen:
Cloud-Backup der Fotos (die sonst nur auf einem Heimrechner gesichert sind)
Bilder direkt aus der Cloud an Druckdienstleister weiterleiten, kein separater Up-
load
Hochauflösende Bilder auf mobilen Endgeräten betrachten
HighRes-Bilder online verkaufen oder für einen guten Zweck / creative commons
bereitstellen
4.1.3 Ergebnisse der Problem Interviews
Die Cloud-Backup-Funktion für RAW-Bilder wurde ausdrücklich von allen Befrag-
ten begrüsst. Allerdings haben die Interviewten angeregt, die Backup-Funktion
nicht nur auf RAW-Bilder zu beschränken: nach seiner „Entwicklung“ und Bearbei-
tung kann ein RAW-Bild nicht mehr als solches gespeichert, sondern muss in ein
RGB-Bild37 überführt werden. Da eine Nachbearbeitung vor der Veröffentlichung ei-
nes Bildes häufig erforderlich ist (insbesondere Retusche), wäre der Nutzwert des
Dienstes stark eingeschränkt, wenn er nur reine RAW-Bilder akzeptieren würde.
Folgende Rahmenbedingungen wurden für den Backup-Dienst genannt:
o Vertrauenswürdiger Anbieter (NSA-Problematik)
37
In einem RGB-Bild werden für jeden Pixel die Farbwerte Rot, Grün und Blau gespeichert, in einem RAW-Bild enthält ein
Pixel nur jeweils einen dieser Farbwerte. Die fehlenden Werte werden beim Entwicklungsvorgang durch Interpolation
berechnet.
59
o Performante Anbindung (keine signifikante Verzögerung im Vergleich zur
Bearbeitung in einem Desktop-Programm)
o Postalische Übermittlung größerer Datenmengen
o Hohe Ansprüche an Datensicherheit
o Zukunftssicherheit (RAW-Formate sind proprietär und werden vom Anbieter
manchmal eingestellt, ein Online-Dienst sollte sie automatisch in ein zu-
kunftssicheres Rohdatenformat wie DNG konvertieren)
Den mobilen Zugriff auf hochauflösende Bilder bzw. die Freigabe dieser Bilder
an ausgewählte User sehen die Befragten als zweitwichtigstes Feature. Für die
mobile Präsentation der Bilder verwenden einige der Befragten derzeit Dropbox
und andere Dateisynchronisationsdienste, die von Lightroom aus mit herunterge-
rechneten JPEG-Versionen der RAW-Dateien bestückt werden. Wichtig ist allen
Befragten, dass nie originale RAW-Dateien zum Download durch Dritte freigegeben
werden dürfen, sondern nur fertig bearbeitete Bildversionen. Andernfalls wäre dies
ein Eingriff in die künstlerische Freiheit.
Der Idee, RAW-Bilder im Internet zu verkaufen, stehen die Befragten eher
zurückhaltend gegenüber. Erstens kommen dafür nur sogenannte „Stock-Photos“
infrage – neutrale, auf Vorrat (stock) produzierte Fotos, die häufig nachgefragte
Motive zum Inhalt haben. Bei Auftragsfotos (z.B. Fotodokumentation eines Events)
entfällt diese Möglichkeit. Zweitens gibt es schon zahlreiche etablierte Plattformen
für Stock Photos. Drittens würde keiner der Befragten die originale RAW-Datei ver-
kaufen, sondern stets die bearbeitete RGB-Version des Bildes.
Denkbar wäre aber für viele Befragte ein Bestellportal für Auftragsfotos, das nach
einem Login die bestellten Fotos des Auftraggebers oder der Auftraggeberin in
voller Auflösung anzeigt und ihm die Möglichkeit der Nachbestellung gegen Entgelt
gibt. Die Darstellung in voller Auflösung erhöht das Vertrauen, durch die Kachelung
des Bildes wird verhindert, dass der/die BestellerIn das Bild ohne Bezahlung ab-
speichert.
Die Online-Bearbeitung von RAW-Fotos wird von den meisten Befragten skep-
tisch gesehen, sie glauben nicht, dass ein Online-Dienst die Funktionen in der
Qualität der führenden Programme Adobe Photoshop und Adobe Lightroom an-
bieten kann, da es viele technische Fragezeichen gibt (z.B. Farbmanagement im
Browser, identische Algorithmen,...). Bei mobilen Bearbeitungsgeräten wie Tablets
und Smartphones wird dieses Problem sogar noch verstärkt, da es keine Möglich-
keit gibt, eine Farbkalibrierung des Displays vorzunehmen. Aus Energiespargrün-
den wird die Helligkeit des Displays meist nach kurzer Inaktivität herunter geregelt,
was die Bildbeurteilung zusätzlich erschwert. Für etwa 25% der Befragten wäre
aber eine Art kollaborative Bildbearbeitung für Digitalfotos interessant, bei der
UserInnen bestimmte RAW-Bilder zur Bearbeitung freigeben („zeige mir, was du
60
aus meinem Foto machen kannst“) – die Bearbeitung selbst würde dann aber in
Desktop-Bildbearbeitungsprogrammen wie Adobe Lightroom stattfinden.
Das interessanteste Ergebnis des demografischen Frageteils: Alle Befragten ver-
wenden (nahezu) ausschließlich Adobe Lightroom zum Verwalten ihrer Fotos und
wünschen die Einbindung des Online-Dienstes über ein Plugin.
4.2 Abgleich der Kundenerwartungen mit den techni-
schen Rahmenbedingungen
Die im vorigen Abschnitt durchgeführten problem interviews haben gezeigt, dass Kunden
und Kundinnen zwar die Flexibilität einer browserbasierten RAW-Bildbearbeitung und die
sichere Archivierung ihrer Bilder in der Cloud schätzen, dafür aber keine Performance-
Nachteile in Bezug auf Desktop-Bildbearbeitungsprogramme in Kauf nehmen wollen. Dies
betrifft insbesondere das potentielle Nadelöhr des Datei-Uploads, mit dem die RAW-Bilder
vom Rechner des Users oder der Userin auf die Cloud-Server übertragen werden müssen.
Der enorme Funktionsumfang von Desktop-Produkten wie Adobe Photoshop oder Adobe-
Lightroom stellt ein zusätzliches Problem dar – die Befragten schätzen diesen sehr, aber
es ist fraglich, ob er sich mit für den Autor verfügbaren Grafikbibliotheken „nachprogram-
mieren“ lässt. In diesem Kapitel sollten daher die technischen Rahmenbedingungen, die
dem Autor zur Verfügung stehen, mit den geäußerten Kundenanforderungen abgeglichen
werden. Am Ende des Abgleichs steht die Entscheidung, ob die ursprüngliche Produktidee
in dieser Form weiterverfolgt werden kann oder abgeändert werden muss.
4.2.1 Upload-Geschwindigkeit als potentieller Flaschenhals
Für einen datenbasierten Online-Dienst wie Trelew ist die erzielbare Upload-Geschwindig-
keit vom Rechner des Anwenders oder der Anwenderin zu den Servern des Dienstes von
hoher Relevanz. Erst wenn die hochgeladene RAW-Datei dort einlangt, kann mit der Bear-
beitung des Bildes begonnen werden. In den problem interviews deuteten die Befragten
mehrfach an, diese Upload-Dauer mit der Ladedauer des Bildes in einem Desktop-Bildbe-
arbeitungsprogramm zu vergleichen. Ergeben sich hier signifikante Unterschiede, wird die
Attraktivität des Online-Dienstes leiden.
Erzielbare Upload-Geschwindigkeit in Österreich
Zur Messung der in Österreich erzielbaren Upload-Geschwindigkeit wurde der Ookla
Netindex (Ookla, 2013) herangezogen. Dieser browserbasierte Test bewertet weltweit die
Qualität der Internet-Anschlüsse diverser Internet Service Provider (ISPs). Er wird von den
Kundinnen und Kunden der ISPs durchgeführt, indem sie sich auf die Testportale speed-
test.net und pingtest.net begeben. Beim Test verbindet sich der Browser mit einem Server,
der geographisch möglichst nahe am Standort des Providers liegt. Auf diese Weise ist es
61
möglich, die Geschwindigkeit der „letzten Meile“ (die vom Provider betriebene Netzwerkinf-
rastruktur vom lokalen Rechner zum Internet) möglichst exakt zu messen. Der Test misst
dabei 3 Größen:
Verbindungsgeschwindigkeit zum Testserver (Ping-Wert)
Download-Geschwindigkeit (Daten werden vom Testserver heruntergeladen)
Upload-Geschwindigkeit (Daten werden auf den Testserver hochgeladen)
Im ebenfalls von Ookla betriebenen netindex werden die Werte eines Landes zusammen
geführt. Für Österreich ermittelt der netindex eine durchschnittliche Upload-Geschwindig-
keit von 3,94 Mbps (Megabit pro Sekunde). Dies entspricht etwa 0,5 Megabyte Daten-
transfer pro Sekunde.
Die durchschnittliche Uploaddauer einer RAW-Datei würde bei einer angenommenen
Dateigröße von 23MB38 also etwa 43 Sekunden betragen.
Vergleich mit der Ladeperformance von Desktop-Bildbearbeitungen
Ein von Usern und Userinnen im Adobe Camera RAW Forum durchgeführter Performance-
Test39 erlaubt einen Vergleich mit den Ladezeiten für ein RAW-Bild im Desktop-
Bildbearbeitungsprogramm Adobe Photoshop Version CS6 in Verbindung mit dem inte-
grierten RAW-Konverter Adobe Camera RAW 7. Je nach Hardware-Ausstattung benötigte
die Software 3,6 – 8 Sekunden, um ein lokal vorhandenes RAW-Foto zu öffnen und in
voller Auflösung darzustellen.
In den problem interviews haben die Interviewten angemerkt, dass der Online-Dienst
RAW-Bilder in ähnlicher Geschwindigkeit „öffnen“ sollte wie ein Desktop-Programm. Ein
erster Vergleich zeigt, dass aber mit der mindestens zehnfachen Ladezeit zu rechnen ist,
zumal die Zeit für die Prozessierung der RAW-Bilder am Server noch nicht einkalkuliert
wurde. Im folgenden Kapitel soll daher untersucht werden, ob die Upload-Dauer von RAW-
Bildern durch vorherige Kompression signifikant verringert werden kann.
4.2.2 Beschleunigter Upload der RAW-Photos durch vorherige
Kompression
Eine Möglichkeit, um die lange Uploaddauer für RAW-Dateien zu verkürzen, besteht in der
vorherigen Kompression der Daten. Hierbei ist zwischen verlustfreien und verlustbehafte-
ten Kompressionsverfahren zu unterscheiden. Erstere können die Ausgangsdaten bei der
Dekompression bytegenau wieder herstellen, erzielen aber schlechtere Kompressions-
38
entspricht der gemittelten Dateigröße der RAW-Dateien in (Busch, 2013) 39
siehe http://forums.adobe.com/message/5447242
62
grade. Zweitere verwerfen gezielt Informationen, die vom menschlichen Auge schlecht
oder gar nicht wahrgenommen werden können und liefern wesentlich bessere Kompressi-
onsverhältnisse, wobei aber ein Datenverlust in Kauf genommen werden muss. In Kapitel
3.2.2 wurden mit DNG und Lossy DNG bereits zwei Vertreter von RAW-
Kompressionsformaten vorgestellt. In diesem Kapitel sollen alternative Verfahren analy-
siert werden.
Verlustfreie Kompression
Im Camera RAW Compression Benchmark (Busch, 2013) untersuchte Stephan Busch 16
verschiedene Softwareprogramme zur verlustfreien Kompression von Camera RAW-Da-
teien. Einige der Kompressionsprogramme waren speziell auf RAW-Dateien ausgerichtet,
andere dienten der allgemeinen Datenkompression. Als Testdaten dienten 25
Camera RAW-Bilder der Kamerahersteller Canon, Fujifilm, Leica, Nikon, Olympus, Pa-
nasonic, Pentax, Samsung, Sigma und Sony. Diese wiesen eine durchschnittliche Da-
teigröße von 23 Megabyte auf, insgesamt lagen 577 MB an RAW-Daten vor. Das Kom-
pressionstool „RawSpeedCmp3“ konnte im Verbund mit den Tools „precomp“ und „qpaq“
den höchsten Kompressionsgrad erzielen und die Dateigröße um durchschnittlich 30%
reduzieren. Allerdings sind für den Kompressions- und Dekompressionsvorgang jeweils ca.
52 Sekunden pro Datei zu veranschlagen. Etwas besser schneidet die Variante
„RawSpeedComp3/Precomp/DCGA“ ab, die zwar nur 26,4% Kompression bietet, dafür
aber nur 8,2 Sekunden pro Datei benötigt.
Der erzielbare verlustfreie Kompressionsgrad bei einer RAW-Datei beträgt also
durchschnittlich 30%, bei einer gemittelten Dateigröße von 23 Megabyte pro RAW-
Datei würden also 17,6 Megabyte Uploadvolumen anfallen. Dies entspräche 36 Se-
kunden durchschnittlicher Upload-Zeit.
Verlustbehaftete Kompression
Um einen Vergleichswert für verlustbehaftete RAW-Kompression zu erhalten, wurden die
RAW-Daten aus dem Benchmark mit den in Kapitel 3.2.2 vorgestellten Lossy-DNG-Verfah-
ren komprimiert. Hierfür wurde der frei erhältliche Adobe DNG Konverter 7.3 verwendet,
wobei folgende Einstellungen zur Anwendung kamen:
Kompatibilität: Camera RAW 6.6 und neuer
Keine JPEG-Vorschau
Verlustreiche Komprimierung anwenden, Anzahl der Bildpixel beibehalten.
Die Eingangsdatenmenge von ca. 532 Megabyte konnte so auf 180 Megbyte komprimiert
werden, was einer Speicherersparnis von 67 % entspricht.
Der erzielbare verlustbehaftete Kompressionsgrad bei einer RAW-Datei beträgt
durchschnittlich 67%, bei einer gemittelten Dateigröße von 23 Megabyte pro RAW-
63
Datei fallen 7,59 Megabyte Upload-Volumen an. Dies entspricht 15,18 Sekunden
Upload-Zeit.
4.2.3 Echtzeit-Processing der RAW-Bilder am Server
Nach dem Hochladen der RAW-Dateien auf die Server des Online-Dienstes müssen diese
auch noch von einem RAW-Konverter prozessiert werden, um kameraspezifische Abbil-
dungsfehler zu korrigieren und ein RGB-Bild zu erhalten. Die dafür nötigen Bearbeitungs-
schritte wurden bereits in Kapitel 3.2.2 erläutert. Nun stellt sich die Frage nach dem dafür
nötigen Rechenaufwand. Die RAW-Konvertierung muss pro Bild zumindest einmal nach
dessen Upload durchlaufen werden. Ändert der Benutzer oder die Benutzerin aber grund-
liegende RAW-Parameter wie beispielsweise den Interpolationsalgorithmus oder das
Linsenprofil, könnte eine wiederholte Prozessierung erforderlich werden. Der Zeitaufwand
für diese Verarbeitung soll wiederum anhand vorhandener Benchmark-Daten abgeschätzt
werden.
Benchmark-Tests zum Processing von RAW-Bildern
dcraw ist ein kommandozeilenbasierter RAW-Konverter, der unter einer OpenSource-
Lizenz steht. Er bietet sich für die Verarbeitung der RAW-Bilder am Server an, da er keine
grafische Benutzeroberfläche erfordert und über Kommandozeilenparameter gut „fernsteu-
erbar“ ist. Ähnlich wie der Adobe RAW-Konverter wird das Programm laufend um neue
RAW-Formate erweitert.
Die Phoronix Open Benchmark Suite, eine Sammlung von Performancetests zur Beurtei-
lung der Leistungsfähigkeit verschiedener Linux-Systeme, enthält auch einen Test, der die
Dauer von RAW-Konvertierungen mit dcraw misst. Da bereits eine Vielzahl von Linux-Ser-
versystemen mit dieser Benchmark-Suite getestet wurden, kann der zeitliche Rechenauf-
wand für die serverseitige Raw-Konvertierung relativ genau abgeschätzt werden. Für die
acht zu konvertierenden RAW-Bilder benötigten die ausgewählten Server der Cloud-An-
bieter Amazon, Rackspace und Joyent je nach Hardware-Ausstattung zwischen 25 und 50
Sekunden, was einer Konvertierungsdauer pro Bild von 3 bis 6 Sekunden entspricht.
64
Abbildung 23: Dauer des dcraw-Konvertierungsvorgangs auf verschiedenen Cloud-Servern
Experten-Interview zur Problematik des Echtzeit-Processing
Die im vorigen Abschnitt ermittelte Konvertierungsdauer für RAW-Dateien nimmt sich
neben den relativ langen Upload-Zeiten zwar bescheiden aus, doch nach derzeitigem Wis-
sensstand des Autors ist unklar, wie oft diese Konvertierung beim Bearbeiten der RAW-
Bilder durchlaufen werden muss. Wenn jede unwesentliche Einstellungsänderung eine
neue, mehrsekündige RAW-Konvertierung erfordert, würde dies die Nutzbarkeit des On-
line-Dienstes stark einschränken.
Zur Klärung dieser Frage hat der Autor mit dem Softwareentwickler Klaus Post ein Exper-
ten-Interview geführt. Klaus Post ist Entwickler der OpenSource-Programme RawStudio
(Bearbeitungsprogramm für Camera RAW-Dateien) und RawSpeed (Programmbibliothek
zum beschleunigten Einlesen von Camera RAW-Dateien), das Interview wurde per E-Mail
zwischen 25.8. und 2.9. 2013 durchgeführt.
65
Frage: Welche Besonderheiten müssen bei der Verarbeitung von Camera RAW-Da-
teien im Vergleich zu anderen Bildformaten wie JPEG berücksichtigt werden?
Klaus Post: RAW-Bilder ähneln den analogen Filmnegativen: sie definieren kein eindeuti-
ges visuelles Abbild der in ihnen enthaltenen Information. Der Bildbearbeiter muss sie erst
„entwickeln“ und mehrere, teilweise interaktive Bearbeitungsschritte durchführen, um eine
RAW-Datei am Computerbildschirm darstellen zu können. Im Unterschied dazu kann eine
JPEG-Datei ohne Zutun des Anwenders sofort am Computerbildschirm dargestellt werden.
Frage: Welche Bearbeitungsschritte sind das?
Klaus Post: Zuerst erfolgt die Dekodierung der RAW-Datei, d.h. in ihrer Datenstruktur der
muss das Graustufenbild der Sensordaten lokalisiert und extrahiert werden. Oftmals liegen
die Sensordaten auch komprimiert vor, sodass sie vor ihrer Weiterverarbeitung dekompri-
miert werden müssen. Der nächste Schritt ist das sogenannte Demosaicing. Die meisten
Kameras können pro Sensorpixel nur einen Farbwert aufzeichnen, entweder Rot, Grün
oder Blau. Um für jeden Pixel die nötige RGB-Information zu erhalten, werden die fehlen-
den Farbwerte durch Interpolation berechnet, wofür es mehrere Algorithmen gibt. Das
Demosaicing ist häufig der Flaschenhals bei der RAW-Darstellung.
Frage: Warum ist das Demosaicing so performance-intensiv?
Klaus Post: Das liegt einerseits an der Vielzahl der Rechenoperationen, die für jeden
Sensorpixel ausgeführt werden müssen. Die meisten Demosaicing-Algorithmen analysie-
ren die Umgebung des Pixels, um möglichst gute Farbwerte zu interpolieren. Nur so ist
gewährleistet, dass kontrastreiche Übergänge an den Kanten von abgebildeten Objekten
erhalten bleiben. Ein Beispiel: Mein Testsystem kann 35 Megapixel des RAW-Formats
Olympus ORF pro Sekunde dekodieren – und das ist das mit Abstand langsamste Format.
Beim Demosaicing kam keines der RAW-Formate auf über 20 Megapixel pro Sekunde.
Frage: Gibt es Möglichkeiten, das Demosaicing zu beschleunigen?
Klaus Post: Eine Möglichkeit ist die Verwendung „genügsamerer“ Demosaicing-Algorith-
men, die weniger Rechenoperationen benötigen, was aber zulasten der Bildqualität geht.
Frage: Was sind nach Decoding und Demosaicing die nächsten Schritte im RAW-
Decoding-Workflow?
Klaus Post: Als nächstes folgt die Objektivkorrektur, also Abbildungsfehler, die durch nicht
vermeidbare optische Unzulänglichkeiten der verwendeten Objektive verursacht wurden.
Dazu zählen beispielsweise Verzerrungen (distortion), chromatische Aberationen (Farb-
säume an kontrastreichen Übergängen) oder Vignettierungen (Abdunkelungen an den
Rändern des Fotos durch verminderten Lichteinfall). Diese Abbildungsfehler werden für
66
jedes Objektivmodell durch verschiedene Testverfahren eruiert und in Objektivprofilen ge-
speichert. Da das verwendete Objektivmodell in den meisten Fällen auch in den Metadaten
der RAW-Datei gespeichert ist, kann die RAW-Entwicklersoftware mithilfe der Objektivpro-
file eine automatische Korrektur durchführen. Kommerzielle RAW-Entwicklungsprogramme
wie Adobe Lightroom bringen ihre eigenen Objektivprogramme mit, im OpenSource-Be-
reich stellt das Projekt LensFun40 sowohl Objektivprofile als auch eine Korrektursoftware
für gängige Abbildungsfehler bereit. Bei extremen Lichtsituationen oder der Verwendung
nicht-unterstützter Objektivmodelle ist allerdings eine manuelle Korrektur erforderlich.
Frage: Nach diesen überwiegend automatisch durchgeführten Operationen wird der
RAW-Workflow mit einer Reihe manueller Schritte abgeschlossen, in denen der User
die Bildcharakteristik aktiv beeinflussen kann. Welche sind das?
Klaus Post: Als nächstes folgt der Weißabgleich (white balance), bei dem die im Bild neut-
ral erscheinenden Farbtöne (weiß, grau oder schwarz) bestimmt werden. Damit lässt sich
die Farbtemperatur beeinflussen, ein wichtiges gestalterisches Mittel für jeden Fotografen.
Daher wird der Weißabgleich vorzugsweise manuell durchgeführt, auch wenn die Kamera
bzw. das RAW-Bearbeitungsprogramm ihn automatisch durchführen kann. Danach folgen
Farb- und Tonwertkorrekturfilter, mit denen die Präsenz einzelner Farben oder Kontraste
im Bild verstärkt oder abgeschwächt werden kann. Zum Abschluss können je nach Bedarf
noch Spezialfilter zum Einsatz kommen, die beispielsweise für Rauschunterdrückung sor-
gen.
Frage: Welche Herausforderungen gibt es aus Ihrer Sicht, wenn man eine webbrow-
serbasierte Camera RAW-Applikation entwickeln möchte?
Klaus Post: Das hängt von den Anforderungen an diese Applikation ab. Ihr Anwendungs-
fall zielt auf die zentrale Speicherung der RAW-Datei auf einem Webserver und auf die
Bearbeitung derselben im Webbrowser ab, wobei nur die für die aktuelle Bearbei-
tung/Ansicht unbedingt nötigen Daten übertragen werden sollen. In diesem Fall wäre die
größte Herausforderung die Aufteilung der bereits beschriebenen Arbeitsschritte zwischen
Client (Browser) und Web/Applikationsserver. Man müsste die ersten, eher statischen
Workflowschritte Dekodierung, Demosaicing und Objektivkorrektur am Server ausführen
und die prozessierten RAW-Daten in einem möglichst „schlanken“ Zwischenformat an den
Browser senden.
Die dynamischen, vom User stark beeinflussten Schritte Weißabgleich, Farbkorrektur und
(optional) Postprocessing-Filter müssten im Webbrowser stattfinden, um eine echtzeitnahe
Darstellung der Filtereinstellungen zu gewährleisten. Für die dafür nötige Performance
könnte die 3D-Programmierschnittstelle WebGL sorgen, welche in modernen Browsern zur
40
vgl.: http://lensfun.berlios.de/
67
Verfügung steht. Sie kann auch zur Programmierung leistungsfähiger Grafikfilter genutzt
werden.
Frage: Kennen Sie Unternehmen oder OpenSource-Projekte, die derartige Applikati-
onen bereits anbieten?
Klaus Post: Mir ist das Startup pics.io bekannt, das eine derartige Applikation anbieten
möchte. Derzeit durchläuft das Startup die private-beta-phase, nur ein Werbevideo ist
öffentlich zugänglich. Daher kann ich den technischen Fortschritt von pics.io nicht beurtei-
len. Ich selbst arbeite an einem web-basierten RAW-Editor, den ich in absehbarer Zeit auf
den Markt bringen möchte. Momentan kann ich über technische Details noch keine Aus-
kunft geben.
Frage: Welche Marktchancen sehen Sie für webbasierte Camera-RAW-Applikatio-
nen?
Klaus Post: Für sich alleine ist ein web-basierter Camera-RAW-Konverter keine „Killer
Applikation“, dafür sind die Upload-Zeiten zu hoch und die Bearbeitungsmöglichkeiten
noch zu gering. Betrachtet man ein solches Tool jedoch in einem ganzheitlichen Kontext,
beispielsweise als Teil eines digital asset management systems, ergeben sich jedoch inte-
ressante Möglichkeiten. Beispielsweise könnte das Fotomaterial einer Organisation über
einen zentralen Server zur Verfügung gestellt werden, wo es je nach Berechtigungsstufe
(z.B. anonymer Web-User, registrierter Journalist) in verschiedenen Auflösungen down-
loadbar ist. Der RAW-Konverter könnte die nötigen Umrechnungen in andere Formate „on
the fly“ durchführen. Wichtig ist jedoch eine gute Interoperabilität mit existierenden Tools,
Bildbearbeitung wird wohl noch eine geraume Zeit in Desktop-Programmen wie Adobe
Photoshop durchgeführt werden.
Die derzeit verbreiteten lokalen Bildkataloge von Fotomanagement-Applikationen wie
Adobe Lightroom führen zu redundanter Speicherung von Bildmaterial und für eine große
Organisation wird es schwierig, ihren Fotobestand im Überblick zu behalten.
Ein Online-Dienst, der Unternehmen genügend Speicherplatz und Rechenkapazität für das
Handling großer RAW-Archive zur Verfügung stellt, hätte meiner Meinung nach gute
Marktchancen.
68
4.3 Analyse und Diskussion der Problem Interviews
Nach ausführlicher Analyse der durchgeführten problem interviews sowie der technischen
Rahmenbedingungen hält der Autor ein Umdenken der ursprünglichen Produktidee für
erforderlich. Die dafür maßgeblichen Gründe ergaben sich aufgrund der in diesem Kapitel
erhobenen Fakten:
Die problem interviews ergaben, dass die Befragten die erhöhte Flexibilität eines
Online-Dienstes für RAW-Bilder zwar schätzen, aber gleichzeitig die Performance
und den Funktionsumfang ihrer bekannten Desktop-Bildbearbeitungsprogramme
erwarten. Abschnitt 4.2 zeigt, dass insbesondere das Importieren von RAW-Da-
teien in einen Online-Dienst viel länger dauern würde als in ein Desktop-Programm.
Im Experten-Interview zum Echtzeit-Processing von RAW-Bildern wurde klar, dass
die dafür nötige Basistechnologie noch nicht existiert. Der Experte Klaus Post
räumt zudem einer „Standalone-Lösung“ zur Online-Bearbeitung von RAW-Bildern
nur wenig Marktchancen ein.
Dies deckt sich mit den Angaben der Befragten aus den problem interviews, die
den Anteil an „reiner“ RAW-Bearbeitung in ihrem Bildbearbeitungsworkflow auf
etwa 10% schätzen. Die meiste Zeit wird für die Bearbeitung des bereits konver-
tierten RGB-Bildes in einer klassischen Bildbearbeitung wie Adobe Photoshop ver-
wendet. Diese Funktionalität müsste ein Online-Dienst demnach auch anbieten,
was den Projektumfang um viele Mannjahre vergrößern würde.
Im folgendenen Kapitel sollten daher die als positiv beurteilten Aspekte der Produktidee zu
einem „Plan B“ verarbeitet werden.
69
5 Umsetzung des „Plan B“
Im vorigen Kapitel versuchte der Autor, seine Idee eines Online-Editors für Camera RAW-
Dateien zu spezifizieren und im Rahmen von problem interviews sechs ausgewählten
Fotografen schmackhaft zu machen. Die zurückhaltende Resonanz der Zielgruppe und
einige technische Fragezeichen zwangen den Autor schließlich zum Umdenken seiner
Idee. Dieser Umdenkprozess beziehungsweise die Ergebnisse bilden den ersten Teil die-
ses Kapitels.
Der zweite Teil des Kapitels beschäftigt sich mit der Vorbereitung und Durchführung der
problem interviews: dabei wird die abgeänderte Produktidee mithilfe eines Prototypen
weiter konkretisiert. Nach einer Demonstration des Prototypen urteilen ausgewählte
Testuser erneut über die Idee, aus ihrem Feedback werden Rückschlüsse über den Funk-
tionsumfang und die Preisgestaltung des späteren minimum viable products (siehe Kapitel
5.3.7) gezogen.
5.1 Der Pivot als Ideen-Kurskorrektur
Zunächst stellt sich natürlich die berechtigte Frage, ob der Autor sein Projekt überhaupt
weiterverfolgen sollte. Einzelne Aspekte der Idee wurden von den befragten Fotografen
zwar sehr positiv beurteilt und scheinen auch technisch problemlos umsetzbar, aber in
seiner Gesamtheit ist der RAW-Online-Editor weder ein nachgefragtes noch ein gut um-
setzbares Produkt. Dennoch sprechen einige Fakten für eine Weiterführung des Projektes
mit einer geänderten Produktidee:
Eric Ries definiert ein Startup als „menschliche Institution, die ein neues Produkt
oder eine neue Dienstleistung in einem Umfeld extremer Ungewissheit entwickelt“
(Ries, 2012, p. 32). Diese Ungewissheit betrifft vor allem die „Gültigkeit“ der ange-
nommenen Problemstellung („Für Fotografen dauert die RAW-Entwicklung in
Desktop-Programmen zu lange“) und des Lösungsansatzes („Online-Editor für
RAW-Dateien mit Rechenleistung aus der Cloud“). Solange diese Gültigkeit noch
nicht von der Zielgruppe bestätigt wurde und der sogenannte Problem/Solution-Fit
noch nicht eingetreten ist, muss der Fokus des Startups auf validiertem Lernen lie-
gen: Einzelne Hypothesen der Produktidee werden solange abgewandelt, bis die
Zielgruppe diese bestätigt. Diese Ideen-Kurswechsel werden auch als Pivots be-
zeichnet (siehe Abbildung 24). Sie sind fester Bestandteil von Lean Canvas.
Der/die EntrepreneurIn ist sogar aufgerufen, in der Frühphase des Startups Pivots
einzubauen, um einen guten Problem/Solution-Fit zu gewährleisten.
Das im vorigen Kapitel vorgestellte Ideenlabyrinth (siehe Abbildung 21) zeigt, dass
Ideen in ihrer Frühphase tendenziell zu weit gefasst sind und ein und dieselbe
Grundidee durch erforderliche Konkretisierungen in der Konzeptionsphase zu völlig
verschiedenen Umsetzungen führen kann. Die vom Autor durchgeführten problem
70
interviews ergaben, dass sein angedachter RAW-Editor mit Funktionen für Bild-
kompression, Echtzeit-RAW-Darstellung, Farbkorrektur, Retusche, Bildexport und
Schnellansicht ein technologisch sehr weites Feld abdecken müsste, um den Kun-
denansprüchen gerecht zu werden. Im Rahmen der Interviews wurde aber auch
deutlich, hinter welchen Teilaspekten der Idee die Befragten den meisten Nutzen
sahen. Mit einer Konzentration auf den vielversprechendsten Teilaspekt seiner Idee
würde der Autor daher einerseits die Umsetzungswahrscheinlichkeit und anderer-
seits die Marktakzeptanz des späteren Produktes erhöhen.
Ash Maurya unterteilt die Entwicklung eines Startups in drei Phasen (Maurya, 2012, p. 43):
Problem/Solution Fit: in der Frühphase des Startups muss der/die EntrepreneurIn
herausfinden, ob die Produktidee tatsächlich ein für die jeweilige Zielgruppe rele-
vantes Problem löst.
Product/Market Fit: Wurde das Problem und der Lösungsansatz von der Ziel-
gruppe bestätigt, kann mit der Entwicklung eines Minimum Viable Products (MVP)
begonnen werden. Während der Umsetzung des MVP sorgen kontinuierliche Tests
mit Beta-Usern dafür, dass es in Bezug auf Funktionsumfang und Preisgestaltung
den Bedürfnissen der Zielgruppe entspricht.
Scale: Qualitative Interviews und Beta-Tests liefern zwar wertvolle, neue Erkennt-
nisse, tragen aber wenig zum wirtschaftlichen Erfolg des Startups bei. Nach der
Bestätigung des MVP gilt es daher, so rasch wie möglich zu wachsen, um die für
die Profitabilität erforderlichen Umsätze zu generieren.
Für Maurya steht dabei während der ersten beiden Phasen das validierte Lernen im Vor-
dergrund, bei denen Einzelaspekte der Idee bzw. Funktionen des Mininum Viable Products
auf ihre Akzeptanz getestet werden. Dies geschieht durch die im vorigen Absatz erwähn-
ten Pivots.
Erst in der letzten Startup-Phase steht das Wachstum im Vordergrund und damit auch die
Optimierung der damit verbundenen Prozesse.
Abbildung 24: Zielsetzungen eines Startups vor und nach dem Product/Market-Fit (Maurya, 2012, p. 45)
71
Für Maurya ist es wichtig, zwischen Pivots und Optimierungen zu unterscheiden. Pivots
sind grobe Kurskorrekturen der Produktidee, Optimierungen stellen geringfügige Verbesse-
rungen bereits bestätigter Ideenhypothesen dar:
„The best way to differentiate pivots from optimizations is that pivots are about finding a
plan that works, while optimizations are about accelerating that plan.“
(Maurya, 2012, p. 45)
Häufig gestellte Optimierungsfragen lauten: Wie können wir den Registrierungsprozess
verkürzen, sodass sich mehr Kundinnen und Kunden für die Demoversion anmelden?
Welche Zahlungsmöglichkeiten sollten wir anbieten, damit ihnen die Bezahlung leichter
fällt?
Wendet sich der/die EntrepreneurIn vorschnell Optimierungsfragen zu, besteht die Gefahr,
große und wichtige Lernschritte zugunsten nebensächlicher Verbesserungen zu versäu-
men:
„In order to maximize learning, you have to pick bold outcomes instead of chasing
incremental improvements. So, rather than changing the color of your call-to-action button,
change your entire landing page. Rather than tweaking your unique value proposition
(UVP) for a single customer segment, experiment with different UVPs for different
customer segments.“
(Maurya, 2012, p. 46)
5.2 Durchführung des Pivot
Um die Produktidee strukturiert und ohne „Schnellschüsse“ umdenken zu können, emp-
fiehlt Maurya, die Ergebnisse der problem interviews hinsichtlich ihrer Implikationen auf
das Produkt-, Akquisitions- und Marktrisiko zu strukturieren. Diese drei Risikoarten wurden
im Abschnitt „Risikopriorisierung“ des Kapitels 4.1.1 vorgestellt und bezeichnen die Wag-
nisse, ein tatsächlich nachgefragtes Produkt zu entwickeln, dafür ausreichend Kundschaft
akquirieren zu können und in einem profitablen Markt ohne „übermächtige“ Konkurrenz
tätig zu werden.
Für jede Risikoart wird eine zentrale Eingangshypothese definiert, die durch die problem
interviews entweder bestätigt oder verworfen wurde. Die Anregungen der Interviewten
wiederrum werden in neuen Hypothesen münden, die im Rahmen des Pivot in die Produk-
tidee aufgenommen werden müssen.
Am Ende des Pivot steht also ein aktualisierter Lean Canvas, auf dessen Basis die Proto-
typ-Entwicklung und die solution interviews durchgeführt werden können.
72
5.2.1 Analyse der Produktrisikos
Hypothese
Die problem interviews werden zeigen, dass die Speicherung und Bearbeitung von
Camera RAW-Bildern in der Cloud sowie der browserbasierte Zugriff darauf ein wichtiges
Feature für professionelle Fotoschaffende ist.
Erkenntnisse aus den problem interviews
Die interviewten Fotografen können dem Online-RAW-Editor nur wenig Nutzen abgewin-
nen, sehen aber großes Anwendungspotential für einen Teilaspekt der Idee: die zeitspa-
rende Darstellung hochaufgelöster Fotos im Web-Browser auf Basis von Kachelbildern.
Allerdings gelangt dadurch der Kunde oder die Kundin vorab in Besitz des hochaufgelös-
ten Fotomaterials, ohne entsprechende Zahlungen geleistet zu haben. Der Einbau von
Sicherheitsmechanismen wie Wasserzeichen wäre daher erforderlich.
Alle Interviewten haben Interesse an Produktfunktionen, welche die Veröffentlichung ihres
Bildmaterials beschleunigen könnten. Viele Aufnahmen entstehen auf Veranstaltungen
oder Reisen, daher wurde insbesonders Interesse an Features angemeldet, die die Uplo-
adzeit von Bildern auch über schlechte Internetverbindungen verkürzen.
Alle Befragten sehen sich häufig mit Anfragen von Kundinnen und Kunden konfrontiert, bei
denen einzelne Aufnahmen aus vergangenen Aufträgen nachbestellt werden. Diese Anfra-
gen sind zwar sehr profitabel, stellen aber meist einen manuellen, fehlerbehafteten Pro-
zess dar. Die Nachbestellungen werden oft über E-Mail abgewickelt, als häufigste Fehler-
quelle entpuppen sich fehlerhaft angegebene Identifikationsnummern für die Bilder bzw. zu
niedrige Empfangslimits für E-Mails auf Kundenseite.
Neue Hypothesen
Kunden und Kundinnen von Fotoschaffenden würden gerne hochaufgelöste Vor-
schaubilder betrachten, scheuen aber große Downloads. Die Fotoschaffenden
fürchten die illegale Verbreitung des Bildmaterials.
Fotoschaffende möchten ihren Kunden und Kundinnen Bilder möglichst schnell zur
Verfügung stellen, auch von Orten mit langsamer Internet-Verbindung.
Fotoschaffende wünschen sich eine Automatisierung des fehlerbehafteten Nachbe-
stellprozesses für Bilder.
73
5.2.2 Analyse des Akquisitionsrisikos
Hypothese
Die Zielgruppe des Online-Dienstes sind Fotografen, die regelmäßig Auftragsfotos einer
beschränkten Personengruppe online zugänglich machen wollen (Auftragsfotografie) oder
neutral produzierte Aufnahmen von Sehenswürdigkeiten, Alltagssituationen oder Gegen-
ständen an die Allgemeinheit verkaufen wollen („stock photography“).
Erkenntnisse aus den problem interviews
Nach einhelligem Feedback der Interviewten werden Fotoschaffende im „stock photo“-
Bereich nicht mehr als Zielgruppe betrachtet, da es für diese Fotografiegattung bereits
zahlreiche Plattformen gibt. Außerdem würden Fotoschaffende niemals ihre „digitalen
Negative“ verkaufen, sondern nur von ihnen bearbeitete Versionen.
Eine potentielle neue Zielgruppe sind Fotoschaffende, die häufig größere Personengrup-
pen fotografieren und deshalb viele Nachbestellungen bearbeiten müssen.
5.2.3 Analyse des Marktrisikos
Hypothese
Die problem interviews werden zeigen, dass Fotoschaffende zwar andere Online-Dienste
zur Veröffentlichung ihres Bildmaterials nutzen, diese aber aufgrund des geänderten Funk-
tionsumfangs keine Konkurrenz für Trelew darstellen.
Erkenntnisse aus den problem interviews
Fotoschaffende nutzen Online-Dienste nur zum Veröffentlichen ihrer Bilder und verwenden
die dort integrierten Bearbeitungsmöglichkeiten kaum. Die Bearbeitung der Bilder wird in
den etablierten Bildbearbeitungsprogrammen Adobe Lightroom und Adobe Photoshop
erledigt. Daher stehen sie auch einem Online-Bearbeitungstool für RAW-Dateien sehr
skeptisch gegenüber.
Die Befragten räumen einem Online-Dienst, der ihren Kunden das einfache und schnelle
Betrachten von hochauflösenden Bildern ermöglicht und gleichzeitig das Bestellwesen
drastisch vereinfacht, sehr gute Marktchancen ein.
74
5.2.4 Aktualisierung der Produktidee
Aufgrund der vorangegangenen Analyse ergeben sich folgende Änderungen in der Pro-
duktidee:
In Trelew können nunmehr nicht nur RAW- oder DNG-Dateien hochgeladen wer-
den, der Dienst steht für hochaufgelöste Bilder aller Formate offen. Als Untergrenze
wird eine Bildauflösung von 5 Megapixel festgelegt.
Um den Bildupload über langsamere Internet-Verbindungen zu beschleunigen, kön-
nen Fotoschaffende besonders speichereffiziente Formate wie JPEG XR verwen-
den, das im Vergleich zu JPEG um bis zu 50% weniger Speicherplatz bei gleicher
Bildqualität benötigt.
Kunden und Kundinnen von Fotoschaffenden können über eine Menüfunktion ge-
zielt das Original des gezeigten Vorschaubildes anfordern. Diese Menüfunktion
kommuniziert mit einem bei dem/der Fotoschaffenden installierten Softwaretool,
das automatisch den Upload des richtigen Bildes auf Trelew übernimmt und damit
die manuellen Abwicklung der Bestellung obsolet macht. Optional lässt sich eine
Bezahlschnittstelle in diesen Prozess integrieren, die den Bilddownload erst freigibt,
wenn die dafür vereinbarte Zahlung geleistet wurde.
von Trelew heruntergeladene Vorschaubilder bleiben mit den online gehosteten Bil-
dern verknüpft: wird ein heruntergeladenes Bild in den Browser gezogen, erkennt
es Trelew und öffnet automatisch die gehostete Version. Damit kann ein Kunde
oder eine Kundin jederzeit Bestellungen zu bereits downgeloadeten Vorschaubil-
dern aufgeben.
75
Abbildung 25: Aktualisierter Canvas nach durchgeführtem Pivot
5.3 Solution Interviews
Während die in Kapitel 4.1 durchgeführten problem interviews einen ersten Abgleich der
Produktidee des Innovators mit den Problemen der Zielgruppe zum Inhalt hatten, geht es
in den solution interviews um die Konkretisierung einer bereits bestätigten Produktidee.
Zudem rückt erstmals das Thema Preisfindung in den Vordergrund.
Für Maurya besteht die Ideenkonkretisierung der solution interviews vor allem in der Be-
antwortung folgender Fragen in Bezug auf die drei Startup-Risiken:
Akquistionsrisko: Wer genau sind die potentiellen early adopter des Produkts?
(Weitere Präzisierung der Zielgruppe aus den problem interviews, beispielsweise
eine Verfeinerung der Zielgruppe „Fotoschaffende mit DSLR“ auf „Fotoschaffende
mit mindestens 10 Aufträgen pro Quartal“)
Produktrisiko: Was ist der minimale Funktionsumfang, den ein sinnvoll nutzbares
Produkt aus Sicht der Kundinnen und Kunden haben sollte?
Marktrisiko: Wird die Zielgruppe für das Produkt bezahlen? Wenn ja, welcher
Preis ist erzielbar?
[vgl.: (Maurya, 2012, p. 157)]
76
5.3.1 Einsatz von Prototypen
Bei der Durchführung der problem interviews wurde bewusst auf die Erstellung von Proto-
typen und erklärender Screenshots verzichtet. Dies geschah einerseits, um die Schilde-
rung der Problemstellung aus Sicht des Interviewten in den Vordergrund zu rücken, ande-
rerseits, um eine unvoreingenommene Beurteilung der Idee zu ermöglichen.
Vor der Durchführung der problem interviews empfiehlt Maurya hingegen die Umsetzung
eines ersten Prototyps, um den Interviewten die gefundenen Lösungsansätze besser vor
Augen führen zu können.
„Most customers are great at articulating problems but not at visualizing solutions.“
(Maurya, 2012, p. 159)
Auf den ersten Blick sollte der Prototyp die Befragten also dabei unterstützen, den vom
Entrepreneur oder der Entrepreneurin vorgeschlagenen Lösungsansatz zu verstehen und
auf dessen Basis nötige Änderungen zu diskutieren. Für ein umfassendes „Verständnis“
wäre aber die Implementierung eines Großteils der vorgesehenen Produktfunktionen
erforderlich, was wiederrum den Zeitaufwand für die Erstellung des Prototyps massiv
erhöhen würde. Angesichts der Tatsache, dass die Interviewten zum ersten Mal mit dem
konkreten Lösungsansatz konfrontiert werden und daher wahrscheinlich umfangreichere
Änderungswünsche haben werden, rät Maurya explizit zu „schlanken“ Prototypen:
„I use the term ‚demo‘ (hier ist der Prototyp gemeint, Anm. d. Verf.) loosely to mean
anything that can reasonably stand in for the actual solution. The assumption here is that
building the ‚full solution‘ is time-consuming and could lead to waste if you build the wrong
solution or add unneeded features.“
(Maurya, 2012, p. 159)
Maurya konkretisiert seine Anforderungen an Prototypen wie folgt:
Technologiekongruenz: die für den Prototypen eingesetzten Technologien soll-
ten auch für die Umsetzung des späteren Produkts zur Verfügung stehen. Maurya
wendet sich insbesondere gegen den Einsatz von Animationseffekten, die in eini-
gen Rapid-Prototyping-Tools zur „Verhübschung“ der Ergebnisse eingesetzt wer-
den. Bei der tatsächlichen Implementierung des Programms stehen diese nicht
mehr zur Verfügung, was zu einem Vertrauensverlust der Befragten führen kann
(„in der Demo sah das anders aus“).
Realistisches Aussehen: Der Prototyp sollte dem Aussehen des Endprodukts
möglichst nahe kommen. Eine bloße Aneinanderreihung skizzenhafter Screenshots
(wireframes, siehe Abbildung 26) würde nach Maurya zwar die Umsetzungsdauer
des Prototyps massiv senken, den Befragten (und möglicherweise späteren Kun-
77
dinnen und Kunden) eine Menge Vertrauen abnötigen („Ist der Innovator überhaupt
in der Lage, dieses Produkt umzusetzen?“). In Bezug auf die Preisfindung, die
ebenfalls im Rahmen des Interviews stattfinden soll, ist dieser erzwungene Ver-
trauensvorschuss sicher nachteilig.
Rasch anpassbar: berechtigte Änderungsvorschläge der Interviewten sollten sich
noch vor dem nächsten Interviewtermin in den Prototyp einarbeiten lassen. Auf
diese Weise kann der Prototyp schnell schrittweise verfeinert werden. Maurya
warnt in diesem Zusammenhang vor einem Outsourcing der Prototyp-Umsetzung.
Zudem ist bei der Erstellung des Prototyps zu beachten, dass alle Daten in editier-
barer Form vorliegen (Bei in Bitmap-Formaten gespeicherten Screenshots lassen
sich Format und Position von Texten nur mehr sehr schwer ändern).
Minimaler Aufwand: Die größte Herausforderung ist die Erstellung des Prototyps
mit minimalem Aufwand. Je schneller der Prototyp umgesetzt und angepasst wer-
den kann, desto schneller können Erkenntnisse gesammelt werden. Vorschnell ge-
nommene „Abkürzungen“ können sich dabei später als Bremsklotz entpuppen: es
mag anfangs reichen, ein Screendesign im Bildbearbeitungsprogramm Adobe
Photoshop anstatt in HTML und CSS umzusetzen, will man später Interaktions-
funktionen demonstrieren, wird aber erst recht eine zeitaufwändige Neuumsetzung
in HTML/CSS erforderlich. Der/die EntrepreneurIn ist also aufgerufen, unter Einsatz
der vorhandenen Kenntnisse eine optimale „Marschroute“ zu finden.
Verwendung authentischer Daten: Prototypen sollten mit authentischen, echt wir-
kenden Daten bestückt werden, die den demonstrierten Anwendungsfall wirksam
illustrieren. Platzhaltertexte wie das bekannte „lorem ipsum“ irritieren den Betrach-
ter und lenken ihn ab.
Abbildung 26: Wireframe-Darstellung einer Dialogbox
78
5.3.2 Umsetzung des Trelew-Prototyps
Bei der Umsetzung des Prototyps für Trelew versuchte der Autor die von Maurya gestellten
Anforderungen so gut als möglich umzusetzen. Als erstes wurden aufgrund der Ergebnisse
des Pivot (siehe Kapitel 5.2) vier Funktionen ausgewählt, die im Rahmen des Prototyps
demonstriert werden sollten:
1. Schnellansicht hochauflösender Bilder im Web-Browser mittels Tiling-Technologie
2. Verkürzung der Upload-Dauer durch Unterstützung speichersparender Bildformate
3. Automatische Abwicklung von Fotobestellung durch Kundinnen und Kunden (Up-
load der entsprechenden Bilder bei Bedarf)
4. Dauerhafte Verknüpfung downgeloadeter Bilder mit dem Originalbild
Sie sollten entsprechend der von Maurya geforderten Prinzipien umgesetzt werden:
Um die Technologiekongruenz und ein realistisches Aussehen des Prototyps
zu gewährleisten, plant der Autor die direkte Umsetzung aller Features in den
Browsertechnologien HTML, CSS und Javascript, die auch im finalen Produkt zum
Einsatz kommen werden.
Zur Minimierung des Aufwandes für die Prototyp-Erstellung nutzt der Autor die
Javascript-Bibliothek jQuery sowie das Web-Frontent-Framework Bootstrap. Mit
diesen beiden Komponenten lassen sich Web-Oberflächen rasch umsetzen. Eine
Sonderstellung nimmt das OpenSource-Framework OpenLayers ein, das an sich
zur Darstellung von Kartenwerken im Webbrowser konzipiert wurde. Im Prototyp
des Autors ist es für die Tiling-Ansicht der hochauflösenden Bilder verantwortlich.
Während dem Autor alle genannten Frameworks aus seiner Tätigkeit als Frontend-
Entwickler bekannt sind, betritt er mit der Nutzung des Javascript-Frameworks
AngularJS Neuland. Dieses Framework verspricht zwar eine radikale Vereinfa-
chung der clientseitigen Datenhaltung, hat aber eine nicht unerhebliche Lernkurve.
Um die Eignung von AngularJS für die Umsetzung des späteren Produkts zu tes-
ten, soll es bereits bei der Implementierung des Prototyps zum Einsatz kommen.
Um den Umsetzungszeitraum des Prototyps nicht unnötig zu verlängern, wurde auf
die Implementierung eines serverseitigen Backends verzichtet. Die Generierung
der für Trelew nötigen Kachelbilder und downloadbaren Bildversionen übernahm
ein Python-Skript, das die Daten in einer standardisierten Ordnerstruktur ablegte.
Die so gewonnenen statischen Demodaten erfüllten aber die von Maurya postu-
lierte Forderung nach Authentizität der Daten.
79
Abbildung 27: Demoseite des CSS-Frameworks Twitter Bootstrap
Schnellansicht hochauflösender Bilder im Web-Browser
Als Ausgangsdaten für die Demonstration der Schnellansicht im Webbrowser nutzte der
Autor einige Camera RAW-Bilder in verschiedenen Formaten. Sie wurden durch ein in der
Skriptsprache Python implementiertes Konvertierungsskript in das Zoomify-Kachelformat
umgewandelt. Hierfür griff das Skript auf die OpenSource-Bibliotheken dcraw (RAW-
Konvertierung) und libvips (Umwandlung in das Zoomify-Format) zurück.
Die konvertierten Dateien wurden unterhalb eines gemeinsamen Verzeichnisses abgelegt,
das über einen Webserver freigegeben wurde. Auf diese Weise konnte der in Javascript
implementierte Client auf die Bilddaten zugreifen. Die Darstellung des Bildes erfolgte über
das OpenSource-Kartenframework OpenLayers, das auch die Anzeige von Zoomify-Bil-
dern unterstützt. Die den Bildbereich umgebende grafische Benutzeroberfläche erlaubt ein
Umschalten zwischen den einzelnen Bildern, sie entstand unter Verwendung der Frame-
works Bootstrap und AngularJS.
80
Abbildung 28: Der Prototyp der Schnellansicht im Webbrowser
Erläuterung der übrigen Features auf einer Marketingseite
Da die meisten Interviewten über einen E-Mail-Link auf den Prototyp zugreifen würden,
entschloß sich der Autor, ihm eine Marketingseite voranzustellen, welche die Idee hinter
dem Dienst grundsätzlich erklärt und die vier prominentesten Features hervorstreicht. Der
Aufbau dieser Seite folgt den in (Srinivasan & Pande, 2013) vermittelten Prinzipien zur
Gestaltung von Startup-Marketingseiten. Die Seite wurde in englischer Sprache verfasst
und enthält folgende Elemente (siehe Abbildung 29) :
1. Name des Dienstes („Trelew“) und Slogan („Download a few Kilobytes. Enjoy a lot
of megapixels“), gefolgt von einer kurzen Erklärung des Dienstes selbst
2. Klickbare Fotogalerie (grau hervorgehoben), welche dem User oder der Userin die
wesentlichen Features näher bringt.
3. Auflistung der vier prominentesten Features mit kurzen Erklärungstexten:
a. „Show full Resolution photos on any device“: Dieses Feature nimmt Bezug
auf die im vorigen Abschnitt vorgestellte Schnellansicht und verlinkt den dort
vorgestellten Foto-Viewer.
b. „Efficient Photo I/O“: Verkürzung der Upload-Dauer durch Unterstützung
speichereffizienter Bildformate
c. „Photo Requests“: Automatisierte Abwicklung von Fotobestellungen durch
Kunden und Kundinnen
d. „Find By File“: Von der Trelew-Seite downgeloadete Bilder öffnen das
Originalbild, wenn sie in den Browser gezogen werden, dieses Prinzip wird
durch eine Screenshot-Animation verdeutlicht.
81
Da die Fertigstellung des Foto-Viewer-Prototyps länger als geplant gedauert hat,
entschloß sich der Autor, die übrigen Features nur mit Screenshots zu dokumen-
tieren und von der prototypischen Implementierung dieser Funktionen abzusehen.
Neben dem zeitlichen Argument sprachen auch technische Gründe für diesen An-
satz: für eine tatsächliche Demonstration der Upload-Funktionen müsste der/die
AnwenderIn die vom Autor bereitgestellte Software auf dem eigenen System in-
stallieren, was bei unsachgemäßer Anwendung oder durch unkorrigierte Pro-
grammierfehler zu Datenverlust führen könnte. In jedem Fall würde der durch die
Bereitstellung der Softwarekomponenten gestiegene Test- und Supportaufwand
den Autor in der Weiterentwicklung der Lösung bremsen.
82
Abbildung 29: Vollumfänglicher Screenshot der Trelew-Marketingseite
83
Veröffentlichung des Prototyps auf Dropbox.com
Damit die per E-Mail befragten Anwender auf den Prototyp bzw. die Marketingseite zu-
greifen konnten, mussten diese Komponenten im Internet veröffentlicht werden. Auch
dabei galt es einige Bedingungen zu berücksichtigen:
Beim Testen des Prototyps wird eine nicht unerhebliche Menge an Daten übertra-
gen – ist der Webserver nicht mit ausreichender Bandbreite an das Internet ange-
bunden, könnte bei den Befragten der Eindruck einer schlechten Performance ent-
stehen.
Änderungen an den Quelldaten sollten möglichst schnell und einfach durchführbar
sein
Den Befragten sollte klar sein, dass sie einen frühen Prototyp verwenden und noch
kein fertiges Produkt – die Verwendung einer Top-Level-Domain wie trelew.at
könnte für diesen Eindruck kontraproduktiv sein.
Die Veröffentlichung des Prototyps sollte kostenfrei und ohne verpflichtende
Offenlegung des Quellcodes möglich sein. Der Webspace sollte die Bereitstellung
einer größeren Menge an Bilddaten unterstützen.
Aus den genannten Gründen entschied sich der Autor für eine Veröffentlichung des Proto-
typs über die Dateisynchronisationsplattform dropbox.com. Als eine der führenden Dienste
für Dateisynchronisation im Internet bietet Dropbox ein redundantes Hosting der Daten in
mehreren Rechenzentren mit guter Anbindung, die automatische Synchronisierung von
Änderungen erleichtert Anpassungen des Prototyps.
5.3.3 Definition des Preismodells für Trelew
Mit Interessierten über den Preis für ein noch nicht existierendes Produkt zu sprechen,
stellt besonders Entrepreneure und Entrepreneurinnen mit technischem Background vor
große Herausforderungen. Man kennt die technischen Unzulänglichkeiten und Beschrän-
kungen der eigenen, in Entwicklung befindlichen Lösung zu genau und tendiert dazu, die
bereits am Markt bestehenden Konkurrenzprodukte als übermächtige Konkurrenz wahrzu-
nehmen. Als Konsequenz wird das Thema Preisfindung und Kundenakquise in der An-
fangsphase des Startups gerne ignoriert. Erst wenn ökonomische Zwänge das Thema aufs
Tapet bringen, wird zaghaft die Lukrierung von Einnahmequellen versucht.
Die „Lowering Signup Friction“-Strategie
Eine gängige und bequeme Strategie besteht darin, es Interessierten möglichst angenehm
zu machen, zu zahlenden Kunden und Kundinnen zu werden: zunächst werden sie be-
fragt, wieviel ihnen die Nutzung des Produktes Wert sei. Auf den genannten Betrag wird
84
ein beträchtlicher Anfangsrabatt gewährt, in der Hoffnung, den Widerstand der Interes-
sierten gering zu halten.
Maurya nennt diese Strategie „lowering signup friction“ (Verringerung des Zahlungswider-
standes):
„The mindset most of us have during Solution interviews is one of ‚lowering signup
friction‘. We want to make it as easy as possible for customers to say yes and agree to
take a chance on our product, hoping the value we deliver over time will earn us the
privilege of their business.“
(Maurya, 2012, p. 162)
In weiterer Folge erläutert er, warum er diese Strategie für problematisch hält:
Nicht nur der/die EntrepreneurIn, sondern auch die „early adopter“, die ersten
Kundinnen und Kunden, müssen sich zum Produkt bekennen, es regelmäßig nut-
zen und Feedback liefern. Wenn vorrangig der Preis und nicht die Lösung der in
den problem interviews genannten „brennenden“ Probleme den Ausschlag für die
Nutzung des Produktes geben soll, stellt sich die Frage nach dessen Sinnhaftigkeit.
Anders gesagt: ein Produkt, das nur mit Preisdumping Nutzer gewinnen kann, ist
keine Innovation mehr, sondern nur mehr ein Nachzügler (late follower) in einem
bereits umkämpften Markt.
Überzogen kundenfreundliche Preisgestaltung schadet der Kundschaft selbst:
der/die EntrepreneurIn wird zu niedrig kalkulierte Preise auf Dauer nicht durchhal-
ten können und das Produkt einstellen müssen. Die Kunden sind dadurch gezwun-
gen, sich nach Alternativen umzusehen, ihnen entstehen zusätzliche Migrations-
kosten.
Kundinnen und Kunden bringen nicht nur Umsätze, sie brauchen auch Unterstüt-
zung bei der Anwendung des Produktes. Aufgrund der beschränkten Zeitressour-
cen des Entrepreneurs oder der Entrepreneurin macht es daher keinen Sinn, mög-
lichst viele Kunden um „jeden Preis“ gewinnen zu wollen und diese später durch ei-
nen schlechten Kundenservice zu verärgern.
85
Die „Raising Signup Friction“-Strategie
Maurya empfiehlt daher, den Zahlungswiderstand nicht zu senken, sondern zu erhöhen:
„Don’t Lower Signup Friction, Raise It“
(Maurya, 2012, p. 163)
Um das Produkt trotzdem begehrenswert für die Kundinnen und Kunden erscheinen zu
lassen, rät Maurya bei der Gestaltung des Preismodells zu folgenden psychologischen
Kniffen:
Verknappung: Ein Produkt, das jederzeit und unbeschränkt verfügbar ist, übt auf
VerbraucherInnen nur einen geringen Kaufanreiz aus. Bei zeitlich oder mengen-
mäßig limitierten Produkten ist das Gegenteil der Fall: die Gefahr, schon morgen
nicht mehr zum Zug zu kommen, drängt zum Abschluß des Kaufs. Der/die
EntrepreneurIn erklärt also von sich aus, dass er/sie momentan nur eine be-
schränkte Anzahl von Kunden akzeptiert – zu nicht verhandelbaren Konditionen.
Die Innovations-Trophäe: Der US-Investmentbanker Oren Klaff postuliert in sei-
nem Werk „Pitch Anything“ (Klaff, 2011) die provokante These, dass Geld die ulti-
mative Massenware sei – jeder Mensch der Welt besitzt zumindest ein wenig da-
von und es ist global verfügbar. Klaff sieht daher wenig Sinn darin, eine/n InvestorIn
um Geld anzubetteln und damit aus einer Position der Schwäche auf Wohlwollen
zu hoffen. Er rät Entrepreneuren und Entrepreneurinnen, ihre Person bzw. Erfin-
dung als eine Art Trophäe hochzustilisieren und so einen Jagdinstinkt beim Gegen-
über auszulösen. Neben der bereits oben erwähnten Verknappungsstrategie kann
dies durch investigative Fragen erfolgen („Wir würden gerne wissen, ob Sie als
Kunde zu uns passen. Können Sie uns verraten, wie oft oder in welchem Stil Sie
fotografieren?“).
Positionierung gegenüber der Konkurrenz: der Innovator sollte den Vergleich
mit Konkurrenzprodukten nicht den VerbraucherInnen überlassen, sondern sein
Produkt aktiv gegen schwächelnde Produkte am Markt positionieren, um es attrak-
tiv und überlegen erscheinen zu lassen. Steve Jobs positionierte das erste iPad-
Modell von Apple 2010 gegen die damals sehr populären Netbooks, die allerdings
unter unterdimensionierter Hardware-Ausstattung und schlechter Ergonomie litten.
Die Strategie ging auf: in einer 2010 von Morgan Stanley in den USA durchgeführ-
ten Umfrage gaben 44% der amerikanischen iPad-KäuferInnen an, dieses anstatt
eines ursprünglich vorgesehenen Netbooks gekauft zu haben. Die Wachstumsraten
des Netbook-Marktes brachen in weiterer Folge drastisch ein.41
41
Quelle: http://tech.fortune.cnn.com/2010/05/06/how-the-ipad-gobbles-up-netbook-sales/
86
Vertrauen: der Vertrauensvorschuss der Interessierten („endlich einmal jemand,
der meine Probleme versteht und sie lösen möchte“) sollte im Verkaufsgespräch
bewusst genutzt werden.
Anwendung auf Trelew
Um die von Maurya empfohlene Vorgehensweise auf Trelew anwenden zu können, führte
der Autor zunächst eine Erhebung der Preismodelle bei jenen Photosharing-Anbietern
durch, die von den Befragten der problem interviews verwendet wurden. Aus Tabelle 3 ist
ersichtlich, dass alle Anbieter bis auf Smugmug.com ein Freemium-Modell verwenden, das
im Falle von Google Drive und Flickr.com sehr großzügig ausgelegt ist – in beiden Fällen
erhält der/die UserIn Gigabytes an Online-Speicher, ohne dafür bezahlen zu müssen. Mit
diesen Angeboten kann schon aus wirtschaftlicher Sicht nicht konkurriert werden. Aller-
dings laufen beide Dienste damit auch Gefahr, zur „Foto-Müllhalde“ zu werden, auf der
auch minderwertige Aufnahmen gebunkert werden. Aus Sicht der NutzerInnen erscheint
problematisch, dass beide Dienste nur Abteilungen der beiden Internet-Konzerne Google
und Yahoo bilden und deshalb häufigen unternehmensweiten Strategieänderungen
unterworfen sind (zum Beispiel die „Zwangsintegration“ des früher eigenständigen Photo-
dienstes Picasa Web in das unternehmenseigene soziale Netzwerk Google+).
Anbieter Preismodell
Google Drive 15 GB Speicher gratis42,
100 GB zu 4,99 USD/Monat
200 GB zu 9,99 USD/Monat
Flickr.com 1000 GB werbefinanzierter Speicher gratis43
1000 GB Speicher werbefrei zu 4,16 USD/Monat44
Smugmug.com Preisstaffelung erfolgt nach Produktfunktionen, alle Pro-
duktpakete beinhalten unlimitierten Upload von Fotos45.
Produktpakete:
Basic: 5 USD/Monat
Power: Basic + vollständig anpassbares Seitende-
sign: 8 USD/Monat
Portfolio: Power + Direktanbindung von Druck-
dienstleistern zur Bestellung von Fotonegativen: 20
USD/Monat
Business: Portfolio + erweiterte Bestellfunktionen
(Geschenkpapier, eigenes Antwortschreiben,...),
Mehrbenutzerfähig: 35 USD/Monat
42
Die erworbenen Speicherkontingente lassen sich auch mit anderen Google-Anwendungen wie dem E-Mail-Dienst Gmail
nutzen. Fotos mit einer Auflösung kleiner als vier Megapixel (2048x2048 Pixel) verringern das Speicherkontingent nicht. 43
Auf den Fotoseiten werden Werbebanner eingeblendet 44
Entspricht der Jahresgebühr von 49,90 USD
87
Anbieter Preismodell
500px.com Free: kostenlose Basisversion (maximaler Upload:
20 Bilder/Woche)
Plus: 25 USD/Jahr für unbeschränkte Uploads
Awesome: 75 USD/Jahr für anpassbare Portfolio-
Website
Tabelle 3: Preismodelle der Konkurrenzanbieter, Stand: November 2013
Smugmug.com hingegen verzichtet auf ein Freemium-Modell, hier werden in der kleinsten
Variante 5 USD/Monat fällig. 500px.com hat ein stark eingeschränktes Freemium-Modell
(maximaler Upload: 20 Bilder pro Woche), in der nächsten Stufe („Plus“) hingegen sofort
ein unbeschränktes Upload-Modell.
Bei näherer Betrachtung werden einige weitere Schwächen der Preismodelle offensicht-
lich:
Flickr verlangt zwar nur 49 Dollar für gigantische 1 TB Speicher, gleichzeitig ist dies
aber die „kleinste“ kostenpflichtige Produktversion. Will man sich also von Werbe-
einschaltungen freikaufen, bezahlt man um 100% mehr als noch vor einem Jahr
(Flickr Pro Abo um 24,95 US-Dollar im Jahr). Dieser Trend der erhöhten „Werbe-
frei“-Pönale könnte sich noch fortsetzen.
Starre Funktionalitäten: Produktfeatures wie die Nachbestellfunktion einzelner Bil-
der oder eine E-Shop-Einbindung lassen sich nicht auf Basis einzelner Fotokollek-
tionen aktivieren und bezahlen, sondern müssen pauschal für den gesamten
Account bestellt und bezahlt werden. Dies widerstrebt dem immer populärer wer-
denden „pay per usage“-Modell des Cloud-Computing.
Die Kontingentierung der Dienste erfolgt in Gigabytes, nicht in Fotos, obwohl diese
die „Basiseinheit“ der Fotoschaffenden darstellen. Die Ermittlung der im Kontingent
speicherbaren Bildanzahl ist schwierig, da dafür zahlreiche Variablen wie Bildauflö-
sung, Art der (verlustbehafteten) Kompression und das Bildmotiv selbst berück-
sichtigt werden müssen. Daher erschweren Gigabyte-Angaben die Kapazitätspla-
nung.
Preismodell für Trelew
Die von Maurya befürwortete „Raising Signup Friction“ wird im Preismodell von Trelew wie
folgt umgesetzt:
Verknappungsaspekt:
Nach dem Launch des MVP ist eine private-Beta-Phase geplant, bei der nur eine
geringe Anzahl eingeladener BenutzerInnen den Dienst nutzen kann.
45
Maximale Upload-Größe pro Bild: 50 MB
88
Trelew wird kein Freemium-Modell bieten, der Dienst ist kostenpflichtig. Eine
Kleinstmenge an Fotos kann aber kostenfrei hochgeladen werden, um Produkt-
funktionen zu testen. Das Limit ist so gewählt, dass eine über Demozwecke hin-
ausgehende Gratisnutzung von Trelew nicht möglich ist.
Das Preismodell selbst dient der Verankerung/Etablierung gegenüber der Konkur-
renz:
Trelew verzichtet gänzlich auf Werbeeinschaltungen und Zwangsintegration in sozi-
ale Netzwerke. Der Kunde oder die Kundin muss sich also nicht durch einen Auf-
preis von diesen unerwünschten Funktionen freikaufen.
Abgerechnet wird pro hochgeladenem Bild und Monat (gestaffelt in 1000er Blöcken
ab EUR 3 pro Monat), was den Fotografen die Kapazitätsplanung und Kostener-
mittlung erleichtert. Außerdem wird so der Vergleich mit den Gigabyte-dimensio-
nierten Produkten der Konkurrenz erschwert.
Der Basistarif deckt die gekachelte Vorschau des Bildes im Zoomify-Format und
dessen Download in einer maximalen Auflösung von fünf Megapixel ab. Weitere
Funktionalitäten stehen als aufpreispflichtige, monatlich stornierbare Erweiterungen
zur Verfügung:
o Kachelung im DeepZoom-Format (mehr Zoomstufen als bei Zoomify)
o Download bis zur tatsächlichen Auflösung des Bildes, Kostenpflichtiger
Download (Shop-Funktion)
o Wasserzeichen in Kacheln und/oder downgeloadeten Bildern als „Diebstahl-
schutz“, wahlweise mit Standardtext oder eigenem Logo.
o Retriever-Funktion (der/die UserIn kann mit downgeloadeten Bildern nach
dem Original suchen)
Diese Pay-per-usage-Funktion differenziert das Angebot von Trelew gegenüber
den starren Angeboten der Konkurrenz.
Mithilfe von Photo Cabinets kann der/die FotografIn unterschiedliche Trelew-
Konfigurationen innerhalb eines Accounts verwenden: beispielsweise ein „Privat-
fotos“-Cabinet, das die Funktionen des preisgünstigen Basistarifs nützt und ein
„Business“-Cabinet, das Wasserzeichen, DeepZoom-Format und andere Premium-
Features verwendet.
Shelve-Funktion: mit einem Klick kann ein Bild „offline“ genommen werden, damit
keine Kosten anfallen. Die Bilddaten bleiben aber in der Cloud gespeichert, sodass
es jederzeit online geschalten werden kann.
Ein bereits upgeloadetes Bild kann mit einer höher aufgelösten Version
„nachgebessert“ werden, ohne dass dafür zusätzliche Kosten anfallen.
89
Nachfolgend die Preisstaffeln für die Produktfunktionen:
Speicherkapazität Preis pro Monat
Erste 99 Fotos 0
99 – 1000 Fotos € 3,00
1000 - 2000 Fotos € 2,50
2000 - 3000 Fotos € 2,00
3000 - 4000 Fotos € 1,50
weitere 1000 Fotos je € 1
Tabelle 4: Preisstaffel für das Grundprodukt
Speicherkapazität Tiled Viewing (Aufpreis/Monat)
„Schneider“
Tile-Darstellung im Zoomify-Format
inkl. Farbraum-Konvertierung
„Petzval“
Tile-Darstellung im Deepzoom-
Format (50% mehr Zoomstufen)
inkl. Farbraum-Konvertierung
Erste 99 Fotos inklusive inklusive
99 – 1000 Fotos inklusive € 0,3
1000 - 2000 Fotos Inklusive € 0,25
2000 - 3000 Fotos inklusive € 0,2
3000 - 4000 Fotos inklusive € 0,15
weitere 1000 Fotos je inklusive € 0,1
Tabelle 5: Preisstaffel für Tiled Viewing
Speicherkapazität Download (Aufpreis/Monat)
„Talbot“
Zuschaltbarer Bild-
download bis 5 Megapi-
xel Auflösung
„Niepce“
Bilddownload in voller
Auflösung,
Photorequests ohne
Bezahlfunktion
„Daguerre“
Bilddownload in
voller Auflösung,
Photorequests mit
Bezahlfunktion
Erste 99 Fotos inklusive inklusive -
99 – 1000 Fotos inklusive € 0,15 € 0,3
1000 - 2000 Fotos
Inklusive € 0,13 € 0,25
2000 - 3000 Fotos inklusive € 0,10 € 0,2
3000 - 4000 Fotos inklusive € 0,08 € 0,15
weitere 1000 Fotos je inklusive € 0,05 € 0,1
Tabelle 6: Preisstaffel für Download
90
Speicherkapazität Watermarking (Aufpreis/Monat)
„Marey“
Addon zum Einfügen von Text-
Wasserzeichen in Bilder
„Morgan“
Addon für Wasserzeichen mit
SVG-Grafik (z.B eigenes Logo)
Erste 99 Fotos Inklusive inklusive
99 – 1000 Fotos € 0, 15 € 0,3
1000 - 2000 Fotos
€ 0,13 € 0,25
2000 - 3000 Fotos € 0,10 € 0,2
3000 - 4000 Fotos € 0,08 € 0,15
weitere 1000 Fotos je € 0,05 € 0,1
Tabelle 7: Preisstaffel für Watermarking
Produkt kapazitive Einzelpreise Gesamtsumme
Speicherung für bis zu 3000
Bilder
3 + 2,5 + 2 = 7,50€
Addon „Niepce“ 0,15 + 0,13 + 0,1 = 0,38€
Addon „Petzval“ 0,3 + 0,25 + 0,2 = 0,75€
8,63 €
Tabelle 8: Preisbeispiel für die monatliche Nutzung von Trelew bei 3000 gespeicherten Bildern
5.3.4 Durchführung der Solution Interviews
Maurya definiert ein solution interview als ein circa 30-minütiges, strukturiertes Interview,
das die Resonanz der Zielgruppe auf die wichtigsten Produktfunktionen testen soll. Da
diese nicht vollständig, sondern nur prototypenhaft umgesetzt wurden, kann der/die Entre-
preneurIn schneller und mit weniger Aufwand zu wertvollen Rückmeldungen kommen, als
dies bei herkömmlichen Produktdemonstrationen der Fall ist. Das solution interview ist
aber mehr als eine bloße Produktvorführung: Maurya empfiehlt, auch die Frage der Preis-
gestaltung des späteren in den Interviews zu behandeln und sie zur Verfeinerung der
Zielgruppendefinition zu nutzen (siehe hierzu die am Anfang des Kapitels formulierten
zentralen Fragen des solution interviews).
Maurya empfiehlt, die GesprächspartnerInnen für die solution interviews mehrheitlich aus
den TeilnehmerInnen der problem interviews zu rekrutieren. Da diese im Rahmen der
problem interviews bereits Einfluss auf die Produktidee genommen haben, sollte auch
einige neue Interessenten befragt werden, um die unbefangene Beurteilung des Lösungs-
ansatzes sicher zu stellen. (Maurya, 2012, p. 169)
91
Ablauf
Im Verlauf des solution interviews (siehe Abbildung 30) werden zunächst einige demografi-
sche Daten des Interviewten erhoben, um eine bessere Zielgruppendefinition erstellen zu
können. Im Fallbeispiel des Autors könnte dies beispielsweise die „professionelle Aktivität“
der Fotoschaffenden (Aufträge pro Monat) sein, um stärker zwischen haupt- und nebenbe-
ruflichen Tätigkeiten differenzieren zu können.
Abbildung 30: Aufbau eines Solution Interviews nach Maurya [Quelle: (Maurya, 2012, p. 170)]
Anschließend erläutert der/die EntrepreneurIn kurz die Motivation hinter dem Produkt, um
die/den Interviewte/n auf die nun folgende Demonstration des Prototyps einzustimmen.
Diese nimmt etwa die Hälfte der Interviewzeit ein und besteht aus der schrittweisen
Vorführung der vorab definierten wichtigsten Produktfeatures (siehe Kapitel 5.3.2). Nach
der Demonstration jedes Features wird der/die Interviewte um ein kurzes Feedback
gebeten, am Ende des Demonstrationsblocks priorisiert er/sie die vorgestellten Features
nach den persönlichen Bedürfnissen.
Danach kommt die Preisgestaltung des späteren Produktes zur Sprache: der/die Entrepre-
neurIn muss herausfinden, welchen Preis die Interviewten für das vorgestellte Produkt
bezahlen würden und diese Daten bei der späteren Gestaltung des Geschäftsmodells
92
berücksichtigen. Hierfür sieht Maurya einige besondere Strategien vor, die im vorigen
Abschnitt vorgestellt wurden.
Das Interview endet mit der Frage nach weiteren potentiellen Interessenten und Interes-
sentinnen im Bekanntenkreis des/der Interviewten, die für ein solution interview angefragt
werden können. Nach der Verabschiedung des Interviewgastes erfolgt die sofortige Doku-
mentation des Gesprächsinhalts, um Erinnerungslücken vorzubeugen.
Der Autor folgte bei seinen solution interviews diesem Ablauf, allerdings fand die „Neube-
fragung“ der Interviewpartner aus den problem interviews per E-Mail statt (75% der Inter-
viewpartner), lediglich die Neuinteressenten (25%) wurden persönlich befragt. Diese Ver-
einfachung war dem straffen Zeitplan der Masterarbeit geschuldet – die ausschließlich
persönlich durchgeführten problem interviews erstreckten sich über einen Zeitraum von
zwei Monaten, eine weitere zweimonatige Interviewrunde hätte den Fertigstellungsrahmen
dieser Masterarbeit gesprengt.
Die Zusammenfassungen der solution interviews sind im Anhang dieser Arbeit abgedruckt.
5.3.5 Ergebnisse der Solution Interviews
Akquisitionsrisiko: Wer braucht das Produkt?
Hypothesen
Hauptzielgruppe sind Fotoschaffende, deren Bildmaterial von einer größeren Personen-
gruppe in hoher Qualität und/oder Auflösung nachgefragt wird und die deshalb häufig
Nachbestellungen von Bildern bearbeiten müssen.
Erkenntnisse
Die Hauptzielgruppe wurde durch die Befragungen bestätigt. 50% der befragten Fotogra-
fen gaben aber an, mit der Problematik von Nachbestellungen auch im privaten, nicht-
kommerziellen Umfeld konfrontiert zu sein. Ein gängiges Szenario hierbei sind Fotodoku-
mentationen von Familienfeiern wie Hochzeiten und Geburtstagen, die von den Fotografen
kostenlos oder gegen Unkostenersatz abgewickelt werden, aber angesichts des hohen
Erinnerungswerts und der großen Menge an Teilnehmern viele Nachbestellungen von Bil-
dern generieren. Besonders für diese Ereignisse wünschen sich Fotografen eine professi-
onelle Abwicklung der Nachbestellungen.
Zum essentiellen Kriterium wird damit weniger die Tatsache, ob ein Fotograf seine Tätig-
keit haupt- oder nebenberuflich ausübt, sondern der Prozentsatz seiner Aufträge mit Publi-
kumswirkung.
93
Produktrisiko: Welche konkreten Funktionen sind nötig, um das Problem der
Kunden zu lösen?
Hypothesen
Kunden und Kundinnen von Fotoschaffenden würden gerne hochaufgelöste Vor-
schaubilder betrachten, scheuen aber große Downloads. Fotografen fürchten ille-
gale Verbreitung des Bildmaterials. Eine Schnellansicht hochauflösender Bilder im
Web-Browser auf Basis von Kachelbildern löst das Problem der großen Down-
loads, in die Bildkacheln integrierte Wasserzeichen verhindern eine illegale Nut-
zung des Bildmaterials.
Fotoschaffende möchten ihren Kunden und Kundinnen Bilder möglichst schnell zur
Verfügung stellen, auch von Orten mit langsamer Internet-Verbindung. Speicher-
sparende Upload-Formate wie JPEG XR können dieses Problem lösen.
Fotoschaffende erhalten häufig Nachbestellungen für hochaufgelöste Originalbilder
per E-Mail und müssen den fehlerbehafteten Bestellprozess manuell abwickeln.
Trelew vermeidet diese Fehler, indem es menügestützte Fotobestellungen direkt im
Viewer ermöglicht. Von Trelew downgeloadete Vorschaubilder bleiben mit der
Downloadquelle verknüpft, sodass der Kunde oder die Kundin nur das entspre-
chende Bild in das Browserfenster ziehen muss, um zum in Trelew gehosteten Ori-
ginalbild zu gelangen.
Ergebnisse
Die Demonstration der Foto-Schnellansicht mittels Prototyp wurde sehr positiv aufgenom-
men, die Interviewten lobten die gute Performance der Anwendung und zeigten sich auch
von der Einsatzmöglichkeit auf mobilen Endgeräten sehr angetan. Auf besonderes Inte-
resse stießen aber der beschleunigte Foto-Upload und die menügestützte Nachbestel-
lungsfunktion. Hier hätten sich die meisten Befragten eine umfangreichere Demo ge-
wünscht, standen aber dem damit verbundenen Software-Download eher ablehnend ge-
genüber.
Weitere Anregungen betrafen die Unterstützung verschiedener Farbprofile, um eine opti-
male Farbdarstellung der Bilder sicherzustellen, sowie Verbesserungen bei den Texten der
Marketingseite. Einige der Feature-Überschriften wurden als zu unspezifisch bemängelt.
Beispielsweise drückt die Überschrift „Show full-resolution images on any device“ für die
meisten Befragten keinerlei Differenzierungsmerkmal zu den etablierten Photosharing-
Plattformen aus. Auch diese bieten eine Downloadfunktion für hochauflösende Bilder an.
Erst die Tatsache, dass durch die Kacheltechnologie eine um bis zu 90% schnellere An-
zeige als beim herkömmlichen Download des Bildes erfolgen kann, stellte für die Befragten
ein „killer feature“ dar.
94
Als „Learning“ wird der Autor die Marketingtexte konkretisieren, um den Wettbewerbsvor-
teil der einzelnen Features besser zur Geltung zu bringen. Ergänzend werden einfache,
auf HTML-Animationen beruhende Demofunktionen in die Marketingseite eingebaut. Die
Zeitersparnis durch den JPEG-XR-Upload im Vergleich zum JPEG-Upload lässt sich bei-
spielsweise über zwei animierte Ladebalken veranschaulichen. Durch den Download der
verwendeten Demofotos kann sich der/die BenutzerIn von der gleichwertigen Qualität der
JPEG-XR-Daten überzeugen.
Marktrisiko: Wie sieht das Preismodell aus?
Hypothese
Die Zielgruppe bevorzugt ein Preismodell mit flexibler, bildbasierter Abrechnung, um ihre
Kosten präziser planen zu können.
Ergebnisse
Die Befragten stehen einem nutzungsbasierten Preismodell positiv gegenüber, erwarten
sich aber eine verständliche und genaue Abrechnung.
5.3.6 Verifizierung der Exit-Kriterien
Maurya (Maurya, 2012, p. 178) definiert folgende Exit-Kriterien für die solution interviews:
1. Demographische Eigenschaften der Zielgruppe sind bekannt
2. „must-have problem“: Die Dringlichkeit und Lösungswürdigkeit des Problems wurde
von der Zielgruppe akzeptiert
3. Benötigte Mindestfunktionalität zur Lösung des Problems ist bekannt und wurde in
den solution interviews anhand von Prototypen demonstriert.
4. Preis(modell) wird vom Kunden/von der Kundin akzeptiert
5. Aus der Preisgestaltung lässt sich ein tragfähiges Geschäftsmodell ableiten.
Wie dieses Kapitel zeigte, konnten die vom Autor durchgeführten solution interviews die
genannten Exit-Kriterien erfüllen: als Kernzielgruppe haben sich Fotoschaffende mit häufi-
gen privaten und geschäftlichen Auftragen herauskristallisiert, die ihre Bilder einer größe-
ren Menge an Personen präsentieren müssen. Die vom Autor angenommenen Haupt-
probleme dieses Unterfangens – die Präsentation des hochauflösenden Bildmaterials im
Internet sowie die mühsame Abwicklung von Nachbestellungen – wurden von der Ziel-
gruppe bestätigt und der in Form eines Prototypen präsentierte Lösungsansatz begrüßt.
Das nutzungsbasierte, nicht-pauschalierte Abrechnungsmodell stieß ebenso auf positive
Resonanz, aus ihm lässt sich ein tragfähiges Geschäftsmodell ableiten.
95
5.3.7 Überleitung in ein MVP – Minimum Viable Product
An dieser Stelle war die schrittweise Überführung der Funktionalitäten des Prototypen in
ein minimum viable product geplant. Den Anfang sollte die browserbasierte Schnellansicht
für hochauflösende Bilder machen, für ihre Umsetzung hat der Autor einen Aufwand von
circa 50 Stunden geschätzt. Da sich diese Arbeiten nicht mehr vor dem Redaktionsschluss
der Masterarbeit per 29.12. 2013 realisieren ließen, kann hier kein Bezug mehr auf sie
genommen werden. Der Autor beabsichtigt aber, auf seinem Blog unter
http://leancanvasthesis.wordpress.com/ über den weiteren Fortschritt von Trelew zu
informieren.
96
6 Diskussion
Nachdem in den vorangegangenen vier Kapiteln die Durchführung eines Lean-Canvas-
Projektes ausführlich geschildert wurde, sollte dieser Abschnitt der Analyse und Bewertung
des durchgeführten Projektes dienen. Er wird mit einer persönlichen Reflexion des Autors
eingeleitet, welche die positiven und negativen Erfahrungen des Autors mit Running Lean
zum Inhalt hat. Anschließend erfolgt eine Analyse und Bewertung der durch Running Lean
verfeinerten Produktidee sowie der Methode Running Lean selbst. Daraus ergeben sich
die abschließenden Empfehlungen zum Einsatz von Running Lean für persönliche und
betriebliche Innovationsprojekte.
6.1 Persönliche Reflexion
Der Autor setzte Running Lean über einen Zeitraum von sechs Monaten (Juli – Dezember
2013) ein. Sein Ausgangsziel bestand darin, die ursprüngliche Produktidee „Online-Editor
für Camera RAW-Dateien“ möglichst rasch und unverändert umzusetzen. Durch den Ein-
satz von Running Lean sollte lediglich die bereits sehr detailliert konzipierte Idee mit Hilfe
der Interviews bestätigt und an ihr eventuell Detailverbesserungen vorgenommen werden.
Das Hauptmotiv für den Einsatz von Running Lean sah der Autor aber in der Akquise von
Kundinnen und Kunden. Diese war für die Umsetzung der Produktidee notwendig, aber
aufgrund mangelnder Verkaufserfahrung schwierig. Der Autor nahm Running Lean also
anfänglich als Verkaufs- und Vermarktungstechnik für seine bereits bestehende Produk-
tidee wahr.
Die von Running Lean propagierte frühe und umfassende Einbindung von Kunden in den
Ideenentwicklungsprozess bewirkte beim Autor aber ein Umdenken und ganzheitliches
„Einlassen“ auf den Lean-Canvas-Prozess, da im Zuge der Projektumsetzung zahlreiche
positive Effekte auftraten:
Beim erstmaligen Befüllen des Lean-Canvas-Rasters mit der Grundidee zeigten
sich einige konzeptionelle Lücken in der Produktidee, die aufgrund der Anweisun-
gen ad hoc geschlossen werden konnten. Beispielsweise war im Ursprungskonzept
eine Zielgruppendefinition vorhanden, an die Kommunikationskanäle zum Errei-
chen dieser Zielgruppe wurde aber nicht gedacht.
Die Aufteilung der Urspungsidee in mehrere, durch Experimente verifizierbare
Einzelhypothesen („Fotoschaffende wollen ihre digitalen Negative auf Tablets be-
arbeiten“) erleichterte nicht nur ihre Validierung, sondern auch die Kommunikation
der Idee Dritten gegenüber.
Im Zuge der problem interviews kam es sehr schnell zur gewünschten
Konkretisierung der Produktidee in Bezug auf Funktionsumfang, Zielgruppe und
97
Geschäftsmodell. Durch Zustimmung oder Ablehnung der vom Autor präsentierten
Hypothesen wurde die ursprüngliche, sehr umfangreiche Produktidee auf wenige,
erfolgversprechende Aspekte zurechtgestutzt. Dies erhöhte wiederrum die Umset-
zungswahrscheinlichkeit des Endproduktes. Die Ablehnung der vom Autor favori-
sierten RAW-Bearbeitungsfunktion durch die Kunden mag zwar im ersten Moment
schmerzhaft gewirkt haben, auf lange Sicht konnte sich der Autor dadurch aber
hohe und unnötige Aufwendungen ersparen.
Der in Running Lean sehr gut spezifizierte Pivot-Prozess erlaubte ein strukturiertes
und rasches Umdenken der Produktidee nach den problem interviews.
Während die Durchführung der problem interviews circa zwei Monate in Anspruch
nahm, konnte die Dauer der nachfolgenden solution-interview-Phase durch mehr-
heitliche Durchführung von E-Mail-Interviews auf nur ein Monat verkürzt werden –
und das trotz des Mehraufwands durch die Prototypen-Entwicklung.
Am Ende der solution-interview-Phase stand die Spezifikation eines minimal
nutzbaren Produktes (MVP), das mit einem geschätzten Arbeitsaufwand von circa
50 Stunden umsetzbar ist und danach bereits von Kunden getestet werden kann. In
ursprünglichen Schätzungen war der Autor von einem vielfach höheren Aufwand
ausgegangen.
Die Mehrheit der Interviewten hat Interesse an einem Beta-Test des Produktes in
der MVP-Phase bekundet, weshalb 7 der 10 vorgesehenen Beta-User-Plätze be-
reits vergeben sind.
6.1.1 Positive Aspekte
In der Gesamtbetrachtung des Projektablaufs haben sich folgende Versprechungen von
Running Lean erfüllt:
Für die Evaluierung der Produktidee waren kaum finanzielle Investitionen not-
wendig, die budgetierten 1000 EUR pro Monat wurden nicht einmal ansatzweise
verbraucht. Das Versprechen der risikolosen Evaluierung von Produktideen hat
sich also erfüllt (sofern keine Opportunitätskosten für die investierte eigene Arbeits-
zeit angesetzt werden).
Die in das Lean-Canvas-Projekt investierte Arbeitszeit betrug im Durchschnitt
acht Wochenstunden und wurde vom Autor zusätzlich zu den 38,5h gesetzli-
cher Wochenarbeitszeit als Vollzeit-Angestellter geleistet. In Anlehnung an den
vom Technologiekonzern Google geprägten Begriff des „20%-Projektes“ (der/die
ArbeitnehmerIn kann 20% der Arbeitszeit für eigene Innovationsprojekte verwen-
den) könnte man von einem „120%-Projekt“ sprechen, da die 8h oder 20% der Ar-
beitszeit zusätzlich zu den 100% Kernarbeitszeit geleistet wurden. Diese investierte
Arbeitsleistung reichte für die Fortführung des Projektes aus, wobei der Arbeitsauf-
wand für das Verfassen der projektbegleitenden Diplomarbeit nicht enthalten ist.
98
Der Autor sieht seine zentrale Hypothese einer berufsbegleitenden Durchführbar-
keit von Running Lean-Projekten dadurch bestätigt.
Als wichtig stellte sich aber eine möglichst kontinuierliche Arbeit an dem Pro-
jekt heraus. Längere, mehrwöchige Projektpausen wären im Hinblick auf die inten-
siv eingebundenen Interessenten kontraproduktiv gewesen, zumal dadurch ein
Eindruck entstehen könnte, das Projekt wäre eingeschlafen.
80% der in den problem interviews befragten Personen konnten auf Nach-
frage weitere potentielle Interessenten aus dem eigenen Bekanntenkreis für
das Projekt des Autors nennen. Obwohl es aus Zeitgründen nicht möglich war,
all diese Interessenten in das Projekt einzubinden, zeigt dieses Verhältnis die
„Mächtigkeit“ persönlicher Interviews in Bezug auf die Gewinnung neuer potentieller
Kundinnen und Kunden.
Im Laufe der Fallstudie hat sich gezeigt, dass Running Lean-Projekte nicht
unbedingt von mehreren Personen durchgeführt werden müssen. Obwohl
Trelew aus Zeitgründen als Einpersonenprojekt gestartet wurde – bei einer durch
die Terminierung der Masterarbeit vorgegebenen Projektlaufzeit von sechs Mona-
ten fehlte schlicht die Zeit für die Rekrutierung zusätzlicher Projektmitglieder – lag
die Arbeitslast nie allein auf den Schultern des Autors. Im Zuge der Projektinter-
views lernte er MitstreiterInnen kennen, die Einzelaufgaben wie Logodesign oder
Implementierung einzelner Prototypen übernahmen. Diesen UnterstützerInnen wa-
ren aber keine vollwertigen Projektmitglieder, sodass zeitaufwändige Abstim-
mungssitzungen entfallen konnten.
6.1.2 Herausforderungen
Im Laufe der sechsmonatigen Anwendung von Running Lean haben sich aber nicht nur
positive Aspekte der Methode gezeigt, es gab auch Verfahren und Situationen, die der
Autor als herausfordernd empfungen hat:
Das zentrale Mantra von Running Lean und anderer von Lean Management
inspirierter Methoden lautet „Vermeide Verschwendung und arbeite dadurch
effektiver!“. Bei der praktischen Berücksichtigung dieser Maxime stieß der Autor
auf einige Schwierigkeiten
– Verschwendung ist oft nicht vorweg erkennbar: erst nachdem ein
Prozess (z.B. Planung und Durchführung eines customer interviews)
mehrfach durchlaufen wurde, sind genug Erfahrungswerte vorhanden,
um zeitraubende Einzelaktivitäten dieses Prozesses zu identifizieren
und zu verbessern.
– Nicht nur ein „zuviel“, sondern auch ein „zuwenig“ ist Verschwen-
dung: Die Forderungen nach möglichst schlanken Prozessen ließ den
Autor einige voreilige Abkürzungen nehmen, die sich später rächten.
Beispielsweise wurden Screendesigns für die Prototypen ursprünglich in
99
Photoshop umgesetzt und nicht in HTML und CSS implementiert. Dies
sparte zwar anfänglich etwa die Hälfte der Arbeitszeit, die Inter-
viewpartner monierten aber die mangelnde Interaktivität der Screende-
signs. Dadurch wurde erst recht die Komplettumsetzung in HTML und
CSS erforderlich.
– Verschwendung ist oft eine Frage der Perspektive: Im Zuge des
Canvas-Projektes nahm der Autor zwei Perspektiven ein – jene des
Produktentwicklers/Innovators und jene des Software-Entwicklers. Wäh-
rend es aus Sicht des Produktentwicklers wichtig war, Prototypen mög-
lichst schnell zu entwickeln und die Code-Qualität im Hinblick auf die
ungewisse Lebensdauer des Prototypen eher vernachlässigbar er-
schien, strebte der Software-Entwickler nach der zumindest anfangs
zeitaufwändigeren Einhaltung der best practices des Software-Enginee-
ring. Beide Sichtweisen haben ihre Berechtigung – schnell implemen-
tierte Prototypen ermöglichen rascheres Feedback der Kunden, können
aber bei Weiterverfolgung der Idee durch mangelnde Code-Qualität zum
Problem werden. Nach allen Regeln der Programmierkunst fertigge-
stellte Prototypen hingegen überzeugen mit besserer Wart- und Erwei-
terbarkeit, brauchen aber anfangs mehr Zeitaufwand – der im Falle einer
Ablehnung durch den Kunden oder die Kundin umsonst gewesen sein
könnte. Die Vermeidung von Verschwendung erwies sich unter diesen
Gesichtspunkten als ein objektiv unlösbares Problem
Management von technical debt. Der amerikanische Programmierer Ward
Cunningham beschrieb das im vorigen Punkt geschilderte Spannungsverhältnis
als technical debt46 (technische Schuld), die durch Vernachlässigung der Code-
Qualität zugunsten von Fertigstellungstermin und Funktionsumfang auf das
Projekt geladen wird. Ist zuviel technical debt angehäuft, droht der technische
Bankrott des Projektes. Der Autor von Lean Startup, Eric Ries, ist hingegen der
Ansicht, dass sich Startups aufgrund hoher Entwicklungsgeschwindigkeit und
Ungewissheit auf technical debt einlassen müssen. Dem kontinuierlichen
Management von technical debt komme allerdings eine große Bedeutung zu.47
Dieser Umgang mit technischer Schuld erfordert allerdings viel Erfahrung, die
man von einem Lean-Canvas-Neuling nicht erwarten kann.
Die von Running Lean geforderte kontinuierliche Umsetzung einer neuarti-
gen Idee im Kontext hoher Ungewissheit stellt auch hohe Anforderungen
an den verwendeten Technologie-Stack: einerseits soll die Umsetzung neu-
artiger, innovativer Produkte ermöglicht werden – eine Forderung, die tendenzi-
ell eher von neuen, noch nicht ausgereiften Technologien erfüllt wird. Anderer-
46
vgl.: http://martinfowler.com/bliki/TechnicalDebt.html 47
vgl.: http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html
100
seits soll die Produktumsetzung mit planbaren, minimalem Aufwand vonstatten
gehen – was wiederrum für etablierte Technologien spricht, die ihre „Kinder-
krankheiten“ überwunden haben. Leider lässt Running Lean den/die Entrepre-
neurIn in der heiklen Frage der Technologieauswahl alleine, und das, obwohl es
im von Running Lean vielfach referenzierten Toyota Production System sogar
ein Selektionsprinzip für Technologien gibt („Principle 8: Use only reliable,
thoroughly tested technology that serves your people and processes“ (Liker,
2003, p. 39))
Da der Autor in seiner bisherigen Karriere nicht im Verkauf tätig war, fiel es ihm
trotz wohlwollendem Interesse seiner Interviewpartner schwer, ihnen ein finan-
zielles „Commitment“ (z.B. kostenpflichtige Monatsmitgliedschaft) zum Produkt
abzuringen. Als verkaufshemmend wirkte zudem die Tatsache, dass noch kein
fertiges, nutzbares Produkt zur Verfügung stand. Der Autor plant daher, nach
Umsetzung des MVP ein stärkeres Augenmerk auf Verkaufsaktivitäten zu rich-
ten.
Die als persönliche, mitunter mehrstündige Gespräche durchgeführten prob-
lem/solution interviews erwiesen sich als ein sehr wichtiges Element von
Running Lean, stellten aber gleichzeitig einen großen „Blocker“ im Projektfort-
schritt dar. Durchschnittlich vergingen drei Wochen zwischen Erstkontakt zum
Interviewpartner und der tatsächlichen Durchführung des Interviews. Durch die
mindestens 30-minütige Dauer können problem/solution interviews aber nur
schwer spontan durchgeführt werden (z.B. im Rahmen von Fotomessen). Für
einen effizienteren Befragungsprozess müsste also bei weiteren Interviews die
„Anbahnungsphase“ zwischen Erstkontakt und Interviewtermin drastisch ver-
kürzt werden.
Der Lean Canvas-Raster eignete sich hervorragend zur Darstellung des Ist-
Status der Idee, aber nicht, um bereits verworfene und geprüfte Hypothe-
sen zu archivieren. Dieser „Erfahrungsschatz der Vergangenheit“ kann aber
bei der zukünftigen Produktplanung eine wichtige Rolle spielen. Der Autor ver-
suchte, ein „Hypothesen-Archiv“ aufzubauen, indem er mehrere Versionen sei-
nes Lean Canvas-Dokuments abspeicherte. Allerdings war auch dieses Vorge-
hen unzureichend, da im Canvas aus Platzgründen nur eine Kurzfassung der
Hypothesen dargestellt werden konnte. Eine Verlinkung dieser Kurzeinträge mit
einer ausführlichen Beschreibung abseits des Lean-Canvas-Rasters erscheint
notwendig.
101
6.2 Bewertung der Methode „Running Lean“
Running Lean ist eine nötige und sehr hilfreiche Konkretisierung der Lean Startup-
Methode, die besonders auf angehende Entrepreneure und Intrapreneurinnen abzielt. Ihr
„Erfinder“, Ash Maurya, hat sie entwickelt, als er bei der Umsetzung der Rezepte aus
anderen Startup-Büchern für seine ersten Produkte auf Schwierigkeiten stieß. Der Autor
kann dieser Motivation beipflichten: die im Standardwerk „The Lean Startup“ präsentierten
Werkzeuge werden aus der Perspektive eines bereits etablierten Software-Unternehmens
vorgestellt, das sich an die Entwicklung neuartiger Produkte macht. Der Detaillierungsgrad
der vorgestellten Werkzeuge leidet mitunter an den zahlreichen eingeflochtenen Anekdo-
ten, in ihrer thematisch gruppierten Darstellungform fehlt ein Anwendungsrahmen, der
Schritt für Schritt die konkrete Umsetzung demonstriert.
Running Lean beseitigt diese Defizite. Ash Maurya hat aus den vielen Lean-Startup-Werk-
zeugen jene ausgewählt, die besonders in der Frühphase eines Startups relevant sind –
darunter fallen in erster Linie die Durchführung von problem/solution-Interviews, die
„schlanke“ Entwicklung von Prototypen sowie Kniffe zur raschen Umsetzung von minimum
viable products. Die umsetzungsfreundliche, mit einer Fallstudie konkretisierte Präsenta-
tion dieser Werkzeuge erleichtert auch Startup-Neulingen ihre Anwendung (vgl. beispiels-
weise die detaillierten Anweisungen zur Durchführung von customer interviews).
Der namensgebende Lean-Canvas-Raster eignet sich sehr gut für die ganzheitliche Dar-
stellung und Ausarbeitung von Produktideen.
In puncto Technologieauswahl lässt Running Lean den/die AnwenderIn leider etwas im
Stich: im Dickicht der immer zahlreicher werdenden Web-Technologien jene auszuwählen,
die für das erdachte Produkt geeignet scheinen, stellte den Autor vor unerwartete Schwie-
rigkeiten, Running Lean bot hier wenig methodische Unterstützung.
Die Empfehlung von Running Lean, am Produkt Interessierte schon im Rahmen der
solution interviews zu eine finanzielle Zusage abzuringen, wird nicht für alle Produkttypen
und Märkte funktionieren: in bereits umkämpften Märkten wie jener der Photosharing-
Plattformen wird der Kunde oder die Kundin zuerst das fertiggestellte Produkt testen wol-
len, bevor eine kostenpflichtige Mitgliedschaft abgeschlossen wird. Der Erfolg des Cloud-
Speicherdienstes Dropbox zeigt aber, dass man auch in scheinbar gesättigten Märkten
Erfolg haben kann, wenn man Kundenbedürfnisse mit Unterstützung neuer Technologien
konsequent umsetzt.
Insgesamt eignet sich Running Lean aber sehr gut für den Einstieg in die Welt der agilen
Produktentwicklung. Die in Ash Mauryas Buch „Running Lean“ angeführten Kochrezepte
102
lassen sich auch von Neulingen gut umsetzen, nach mehrmaliger Anwendung kann man
die Methode dann an eigene Bedürfnisse und best practices anpassen.
Bei der Umsetzung der Fallstudie stellte der Autor keinerlei Konflikte mit den rechtlichen
und gesellschaftlichen Rahmenbedingungen in Österreich fest, die sich ja stark von jenen
der USA, dem Entstehungsland von Running Lean, unterscheiden.
Running Lean kann sowohl in einem privaten als auch beruflichen Szenario eingesetzt
werden. Auf die nötigen Rahmenbedingungungen wird im nächsten Abschnitt eingegangen
werden.
6.3 Bewertung der Produktidee
Die ursprüngliche Produktidee eines Online-Editors für Camera RAW-Dateien wurde vom
Autor schon vor der Anwendung von Running Lean bearbeitet: etwa 50 Arbeitsstunden
flossen in Technologierecherche, Marktanalyse, Konzeption und Verschriftlichung der Idee.
Feedback von potenziellen Anwendern und Anwenderinnen wurde in dieser Vorideen-
phase allerdings nicht eingeholt, was sich als entscheidender Fehler herausstellte: bereits
in der problem interview-Phase wandten sich die befragten Anwender gegen die zentralste
Funktion der Idee, die cloudgestützte Bearbeitung und Speicherung von Camera-RAW-
Bildern.
In der vom Autor eher als nebenläufiges Feature beurteilten Kacheldarstellung hochauflö-
sender Bilder im Web-Browser erkannten sie hohes Potential, sodass sich der Fokus der
weiteren Produktentwicklung auf diese Funktion verschob.
Derartige Perspektivenwechsel, bei denen eine Nebenfunktion plötzlich zum zentralen
Aspekt der Produktidee wird, sind bei Startup-Ideen nicht ungewöhnlich: Eric Ries be-
zeichnet sie als Zoom-In-Korrektur, da der zu breit angelegte Funktionsumfang des Pro-
duktes durch intelligentes Einzoomen beschnitten wird (Ries, 2012, p. 158).
Im weiteren Anwendungsverlauf von Running Lean entwickelte sich die Idee aber
„wunschgemäß“ in Richtung eines Fotoportals für hochauflösende und hochqualitative
Aufnahmen weiter: durch diese Zoom-In-Korrektur, welche im Pivot-Prozess initiiert und
und in den folgenden Solution Interviews weiter präzisiert wurde, ergab sich ein in nur etwa
50 Arbeitsstunden umsetzbares minimum viable product.
Die ultimative Bestätigung der Produktidee durch zahlende Kunden und Kundinnen konnte
zwar noch nicht erreicht werden, dieser Umsetzungsaspekt musste aus Zeitgründen zu-
rück gestellt werden.
103
Der Autor als Ideengeber und Anwender von Running Lean ist aber mehr als zufrieden mit
den erreichten Ergebnissen und beabsichtigt die Weiterverfolgung der Produktidee über
den Abschluss dieser Masterarbeit hinaus.
6.4 Empfehlungen
Nach der Bewertung von Running Lean und der damit verfolgten Produktidee möchte der
Autor seine Erfahrungen in Form von Handlungsempfehlungen für den betrieblichen und
privaten Einsatz von Running Lean weitergeben. Dieses Kapitel versucht zunächst, geeig-
nete Einsatzzwecke für Running Lean in beiden Bereichen darzulegen und geht anschlie-
ßend auf die erforderlichen Rahmenbedingungen ein.
6.4.1 Praktischer Einsatz von Running Lean
Obwohl in der Fallstudie dieser Arbeit nur ein privates Lean-Canvas-Projekt verfolgt wurde,
das nicht in Verbindung zu einem existierenden Unternehmen steht, sieht sich der Autor
durchaus in der Lage, auch Empfehlungen für den betrieblichen Einsatz von Running Lean
auszusprechen: er führte sein Lean-Canvas-Projekt neben einer Vollzeit-Beschäftigung als
Angestellter durch und musste die in das Projekt investierte Arbeitszeit mit dieser Tätigkeit
abstimmen.
Betrieblicher Einsatz
In betrieblichen Innovationsprojekten findet sich häufig ein ähnliches Szenario: die Pro-
jektmitglieder können aus Kosten- und Qualifikationsgründen nicht einfach vom Tagesge-
schäft freigestellt werden und müssen daher sowohl die täglichen Routineangelegenheiten
als auch die angestrebten Projektziele erfüllen. Denkbar ist aber die Entlastung von einzel-
nen Aufgaben des Tagesgeschäfts, um mehr Handlungsspielraum im Innovationsprojekt
zu erhalten. Die Höhe dieses Handlungsspielraums (in Stunden) kann durchaus aus der
Fallstudie des Autors abgeleitet werden: es zeigte sich, dass ab einem wöchentlichen
„Investment“ von ca. 8 Stunden pro Projektmitglied sinnvoll an einem Running Lean-
Projekt gearbeitet werden kann.
Doch für welche betrieblichen Einsatzzwecke eignet sich Running Lean? Steve Blank defi-
niert ein Startup als „...organization formed to search for a repeatable and scalable
business model“48. Die von Blank erwähnten skalierbaren Geschäftsmodelle
(Einnahmequellen) sucht ein Unternehmen am ehesten bei der Entwicklung neuartiger
Produkte, mit denen es bisher noch wenig Erfahrung gesammelt hat. Daher kann die Qua-
lifizierung neuartiger Produktideen ein Einsatzgebiet von Running Lean darstellen.
48
vgl. http://steveblank.com/2010/01/25/whats-a-startup-first-principles/
104
Diese enge, ausschließlich auf monetäre Vorteile begründete Daseinsberechtigung für
Startups gilt aber heute als überholt: bei der Lean Startup Konferenz 2013 präsentierten
viele Behörden und nicht-profitorientierte Vereine ihre Einsatzzwecke für Lean-Startup-
Methoden: die US-Organisation Blackgirlscode49 entwickelte damit ein Trainingsprogramm
für farbige Mädchen, um diesen die am US-Arbeitsmarkt immer wichtiger werdenden Pro-
grammierkenntnisse altersgerecht zu vermitteln. Es handelt sich dabei um eine sehr wich-
tige Initiative, da diese Kenntnisse häufig nur in kostenpflichtigen, universitären Bildungs-
angeboten vermittelt werden, die für ärmere Familien nicht leistbar sind.
Im betrieblichen Umfeld kann also Running Lean nicht nur für die Entwicklung neuer Pro-
dukte zum Einsatz kommen, sondern auch für die Weiterentwicklung umfangreicherer
Verbesserungsideen zur Erreichung verschiedenster Unternehmensziele genutzt werden:
Erhöhung der Kundenzufriedenheit, Senkung der Beschäftigtenfluktuation, Qualifizie-
rungsoffensiven etc. Die Abgrenzung zum „einfachen“ Verbesserungsvorschlag, wie er im
Rahmen von Qualitätszirkeln geäußert wird, kann aufgrund budgetärer Grenzen gezogen
werden: Wenn der Vorschlag nur mit größerem finanziellem oder organisatorischen Auf-
wand umsetzbar ist, dann sollte er erst in einem „Running Lean“-Experiment geprüft wer-
den, bevor er tatsächlich umgesetzt wird.
Wichtig für den erfolgreichen Einsatz von Running Lean sind kleine, interdisziplinäre
Teams, die möglichst autonom arbeiten können. Sie sollten Konzeptions- und Umset-
zungskompetenz vereinen und nicht mehr als acht Personen umfassen. Nicht jede/r Be-
troffen/e der (Produkt-)Idee muss gleich Mitglied des Projektteams werden, auch die be-
fragten Personen können in den Interviews ihre Vorstellungen einbringen.
Den Abschluss eines betrieblichen Lean-Canvas-Projektes bildet wie in der Fallstudie die-
ser Arbeit ein minimum viable product: das neue, prototypisch in wenigen Einzellektionen
umgesetzte betriebliche Bildungsprogramm, das nach der Genehmigung durch die Ge-
schäftsführung in einer neuen Firmenakademie vermittelt wird, die in Zusammenarbeit mit
einer externen Maklerfirma gegründete Umzugsberatung, welche mehr Bewerber für den
Unternehmensstandort begeistern soll etc.
Der Vorteil für das Unternehmen: erst nach Evaluierung des de-facto investitionsfreien
Startup-Experiments muss eine endgültige Entscheidung über die Umsetzung der Idee
getroffen werden, auf diese Weise können teure Flops vermieden werden.
49
vgl. http://www.blackgirlscode.com/
105
Privater Einsatz
Viele der bereits im vorigen Abschnitt genannten Zwecke treffen auch für den privaten Ein-
satz von Running Lean zu: die Methode eignet sich vor allem für die Perfektionierung eige-
ner Geschäftsideen im Hinblick auf die zukünftige Selbstständigkeit.
Unterschiede gibt es in der Durchführung: einem/r privaten „EinzelkämpferIn“ fehlt die
Unterstützung der betrieblichen Infrastruktur – sowohl in personeller wie manchmal auch in
finanzieller Hinsicht.
Wie die Erfahrungen des Autors zeigen, sollte man sich dadurch aber nicht entmutigen
lassen, ein Startup mit Running Lean zu beginnen: ist die Idee einmal verständlich und
schlüßig zu Papier gebracht oder gar bereits in Prototypen umgesetzt, fällt es wesentlich
leichter, MitstreiterInnen für die eigene Sache zu gewinnen als mit bloßen Worten.
Die große Herausforderung für Einzel-Startups ist die Vereinigung vieler, teils einander
widersprechender Rollen in einer Person: ProduktentwicklerIn, VerkäuferIn und Program-
miererIn lassen sich nur schwer in einer Person vereinen. Umgekehrt droht bei Mehrper-
sonen-Startups ein höheres Konfliktpotential, da die in der Frühphase des Startups oft sehr
breit angelegte Produktidee sich in Richtung einer möglichen Umsetzung verengen muss –
in der sich mitunter nicht alle Teammitglieder wiederfinden.
Am Ende eines privaten Running-Lean-Projekts sollte neben einem minium viable product
auch die Entscheidung darüber stehen, ob man dieses nun hauptberuflich weiterverfolgen
möchte oder nicht. Diese Entscheidung fällt nicht immer leicht, zumal nur wenige Startup-
Projekte abheben und es auch bei erfolgreichen Startup-Projekten zu Seitwärtsbewegun-
gen ohne momentane Wachstumstendenz kommen kann.
Tabelle 9 stellt die beiden Einsatzbereiche einander gegenüber:
Betrieblicher Einsatz Persönlicher Einsatz
Einsatzzwecke Qualifizierung umfangreicherer
(Produkt-) Ideen, Ergänzung
zum betrieblichen Vorschlags-
wesen
Perfektionierung eigener
Geschäftsideen, Vorberei-
tung der eigenen Selbststän-
digkeit
Teamgröße 1 -8 Personen, ab 4 Personen
Trennung in Problem und
Solution-Teams
1-4 Personen50
50
diese Empfehlung geht davon aus, dass die Abstimmung zwischen den TeilnehmerInnen eines privaten Running-Lean-
Projektes schwieriger zu bewerkstelligen ist als bei einer innerbetrieblichen Anwendung (beispielsweise aufgrund
verschiedener ArbeitgeberInnen). Daher empfiehlt der Autor für diesen Fall kleinere Gruppengrößen.
106
Betrieblicher Einsatz Persönlicher Einsatz
Teamkomposition Interdisziplinär, mit Konzepti-
ons- und Umsetzungskompe-
tenz
Möglichst interdisziplinär,
Grundkompetenzen für Pla-
nung und Umsetzung sollten
gegeben sein, Outsourcing
erweiterter Kompetenzen
möglich.
Durchführungszeitraum 6 – 12 Monate
Zeitaufwand pro Woche
und Teammitglied
ab 8 Wochenstunden
Positionierung im Inno-
vationsprozess
Begleitung einer Idee bis hin
zur Frontend-Phase
Von der Idee zum finalen
Businessplan
Art der Einführung Schrittweise Einführung über
Mentoren-Modell, anfangs
nicht für zeitkritische Projekte
verwenden.
Kontinuierliche Anwendung
über einen längeren Zeit-
raum (ggf. mit verschiedenen
Projekten), um die nötige
Methodenkompetenz zu er-
werben.
Tabelle 9: Einsatzempfehlungen für Running Lean
6.4.2 Einsatzkriterien
Im Zuge der Fallstudie konnte der Autor folgende Erfolgsfaktoren für Lean-Canvas-Pro-
jekte ermitteln, die sich einerseits aus der verwendeten Literatur, andererseits aus den
gewonnenen praktischen Erfahrungen ergaben. Diese Erfolgsfaktoren definieren die Ein-
satzkriterien näher und können in Form einer Checkliste vor der Durchführung eines Lean-
Canvas-Projekts geprüft werden:
Das Projektteam bringt Grundkenntnisse im Projekt- und Prozessmanagement
sowie zumindest grundlegendes Fachwissen und Umsetzungskompetenz im
Themenbereich der Idee mit.
Ein Grundstock von mindestens fünf potentiellen Interessenten oder Interessen-
tinnen, welche auch für Interviews zur Verfügung stehen, sollte vorhanden
sein. Dies erleichtert das schnelle Einläuten der problem-interview-Phase.
Repräsentative Prototypen, die als Platzhalter für das spätere Produkt fungie-
ren, sind kostengünstig und zeitnah umsetzbar. Im Idealfall geschieht die Um-
setzung durch das Projektteam selbst, die für die Umsetzung nötigen externen Ab-
hängigkeiten sollten jedenfalls minimiert werden.
Die Teammitglieder können regelmäßig (wöchentlich) am Projekt arbeiten, pro
Person sind mind. 8h/Woche empfehlenswert. Kleinere Projektteams mit mehr
107
Arbeitszeit pro Mitglied sind größeren Teams vorzuziehen, um langwierige Abstim-
mungsphasen zu vermeiden.
Der Einsatz von Running Lean wird von den Entscheidungsträgern befürwortet
und von den Stakeholdern im Unternehmen zumindest toleriert. Die „heimli-
che“ Einführung von Running Lean sollte die ultima ratio darstellen.
Es gibt eine klare Abgrenzung zwischen dem Running Lean-„Labor“ und der
übrigen Unternehmensumwelt: für die an den Produktideen Interessierten muss
klar sein, dass es sich um „Produkt-Experimente“ handelt, die jederzeit wieder ein-
gestellt werden können, und nicht um seriennahe Produkte. Quellcode aus Lean-
Canvas-Prototypen darf nicht ungeprüft in „produktiven“ Code umgewandelt wer-
den, da er wesentlich geringeren Qualitätskriterien genügen muss.
Wie bei jeder Methode bestehen auch bei Lean-Canvas gewisse Anwendungsrisiken, die
in der folgenden Aufzählung konkretisiert werden:
Der mögliche Patentanspruch technischer Ideen und Erfindungen könnte durch die
vorzeitige Kommunikation nach außen verwirkt werden
Running Lean könnte im Widerspruch zu bestehenden betrieblichen Geheimhal-
tungsabkommen stehen
Hardware-Projekte stellen noch eine Herausforderung für agile
Produktentwicklungstechniken dar. Anders als bei Softwareprojekten kann der
Projektfortschritt nicht inkrementell an die Kundinnen und Kunden ausgeliefert
werden (der neue Greifarm eines in Entwicklung befindlichen Roboters kann nicht
über das Internet installiert werden, die neue Bilderkennungsfunktion eines Foto-
portals schon), die Erstellung von Prototypen verursacht hohen finanziellen und
personellen Aufwand (obwohl es durch den 3D-Druck Verbesserungsmöglichkei-
ten gibt)
Zuletzt ist auch der mit Running Lean verbundene Eingriff ins betriebliche
Kompetenzgefüge ein gewisses Risiko: wenn Produktentscheidungen nun durch
Experimente im Lean-Canvas-„Labor“ getroffen werden, wird das den bisher zu-
ständigen Verantwortlichen nicht unbedingt schmecken (selbst wenn sie im Lean-
Canvas-Projektteam sind, müssen sie damit Macht abgeben). Es empfiehlt sich
also eine behutsame Einführung unter Einbindung aller Betroffenen, das Lean-
Canvas-Labor sollte zudem eindeutig von der restlichen Unternehmensumwelt ab-
gegrenzt sein.
108
6.5 Externe Evaluierung der Ergebnisse
Um die Objektivität der gewonnenen Erkenntnisse sicherzustellen, wurde die vom Autor
durchgeführte Fallstudie sowie die sich daraus ergebenen Erkenntnisse einem externen
Evaluator zur Begutachtung vorgelegt. Als Evaluator konnte Herr Lukas Fittl gewonnen
werden, der als persönlicher Mitarbeiter von Running-Lean-Erfinder Ash Maurya an der
Entwicklung dieser Methode beteiligt war51. In seiner Funktion als Startup-Berater und
Koordinator der Anwendergruppe „Lean Startup Circle Vienna“ hat er einen umfassenden
Einblick in die Anwendung von Lean-Startup-Methoden im beruflichen und privaten Um-
feld.
Im Rahmen eines persönlichen Evaluierungsgesprächs stellte der Autor zunächst die Fall-
studie „Trelew“ in ihrer Gesamtheit vor und präsentierte danach die von ihm daraus gezo-
genen Schlüsse bezüglich der Stärken und Schwächen von „Running Lean“ sowie ihrer
Anwendbarkeit für betriebliche und private Innovationsprojekte.
Herr Fittl beurteilte sowohl den Umfang als auch die Durchführung der Fallstudie als sehr
gelungen und erbat sich folgende Anmerkungen zu den Schlussfolgerungen:
Zur Durchführung von Running-Lean-Projekten alleine oder im Team: Für
Herrn Fittl hat die Durchführung im Team den Vorteil, dass dadurch die Selbstdis-
ziplin und Fokussierung der TeilnehmerInnen steigt – schließlich gehen sie den an-
deren Projektmitgliedern gegenüber Verpflichtungen bezüglich der Erledigung ein-
zelner Aufgaben ein. Bei Einzelprojekten fehlt dieser positive Gruppendruck. Im
konkreten Fall wurde der Autor durch einen festen Zeitrahmen (vorgegebener Ab-
gabetermin der Masterarbeit) angehalten, kontinuierlich an seinem Running-Lean-
Projekt zu arbeiten. Herr Fittl empfiehlt diese als „Timeboxing“ benannte Technik
zur Aufrechterhaltung der Motivation bei Einzelprojekten.
Zu fehlenden Technologieauswahlprozessen in Running Lean: Herr Fittl sieht
rasche Feedback-Zyklen als das entscheidende Erfolgsmerkmal von Running-
Lean. Daher sollten Prototypen und Produkte mit jenen Technologien entwickelt
werden, die das Projektteam beherrscht und mit denen es möglichst produktiv ar-
beiten kann. Erst wenn die verwendeten Technologien in Einzelbereichen Defizite
aufweisen, sollten sie mit neuen Technologien ergänzt werden. Für Herrn Fittl be-
steht der Innovationsgehalt vieler Produkte zudem nicht in Technologie-, sondern in
Marktinnovationen: bekannte Produkte oder Teile ihrer Funktionen werden zum
ersten Mal auf einem neuen Markt verfügbar gemacht. Beispielsweise ähneln die
charakteristischen Fotoeffekte der höchst erfolgreichen Smartphone-Applikation
„Instagram“ jenen der wesentlich älteren PC-Bildbearbeitungsprogramme Google
Picasa oder Adobe Photoshop Elements. Das technologische Wagnis für solche
51
vgl http://fittl.com/about/
109
„Produkt-Portierungen“ sei wesentlich geringer als für echte Technologieinnovatio-
nen, da viele der technologischen Bestandteile im Zuge der Portierung unverändert
übernommen werden können. Insofern sei die vom Autor aufgestellte These, inno-
vative Produkte würden ein hohes technologisches Risiko verursachen, nicht immer
zutreffend. Er teilt aber die Kritik des Autors, dass Running Lean dem Aspekt der
Technologieauswahl zuwenig Bedeutung beimisst.
Zur von Autor kritisierten Running-Lean-Empfehlung, den Interessierten
schon während der solution interviews finanzielle Zusagen abzunötigen:
Herrn Fittl zufolge kann der „Bestätigungsaspekt“ einer finanzielle Zusage (z.B. ab-
geschlossenes Monatsabo) für eine Produktidee nicht hoch genug eingeschätzt
werden, da der Kunde oder die Kundin damit erstmals signalisiert, dass ihm/ihr eine
Idee tatsächlich etwas Wert ist. Gleichzeitig sei Verkauf eine Tätigkeit, die insbe-
sondere Innovatoren mit technischem Background schwerfällt. Verkaufen sei aber
erlernbar, für Herrn Fittl haben sich in Zusammenhang mit Running Lean folgende
Techniken bewährt:
o Bereits in den problem interviews fragen, wieviel der/die Interviewte an Zeit
und Geld zur Lösung des Produktproblems ausgibt. In den solution
interviews darauf zurückkommen („Sie verwenden 20 Stunden und 80 Euro
im Monat, um Ihre Fotos im Internet zu präsentieren. Mit Trelew werden es
nur 40 Euro und 10 Stunden sein“)
o Geld-zurück-Garantie anbieten
o Es erscheint logisch, problem/solution interviews mit Experten des Prob-
lembereichs durchzuführen, um ausführliche Informationen über die Prob-
lemstellung und existierende Lösungen zu erhalten. Aus Verkäufersicht
sind diese Profis aber ein schwieriges Klientel, da sie von vielen Anbietern
umworben werden oder das in der Produktidee aufgegriffene Problem durch
ihr Experten-Know-How lösen können. Für die solution interviews sollte da-
her auch auf EinsteigerInnen des jeweiligen Fachbereichs zurückgegriffen
werden (z.B. Fotografie-SchülerInnen statt Fotografie-Lehrenden). Diese
sind oft sehr an professionellen Werkzeugen interessiert.
o solution interviews können und sollen auch noch während der „MVP“-Phase
durchgeführt werden, einerseits um den Kontakt zu den Interessenten nicht
zu verlieren und neue Produkthypothesen abtesten zu können, andererseits
um zahlende Kunden und Kundinnen zu akquirieren.
o Anfangs simple Preismodelle (Monatspauschale) anbieten, diese können
einfach in das applikationsinterne Abrechnungssystem implementiert wer-
den. Nutzungsabhängige Preismodelle (wie die für Trelew angedachten
Fotopakete) sollten erst nach ausführlichen Akzeptanztests umgesetzt wer-
den, da sie sowohl für den/die AnbieterIn (hoher Implementierungsaufwand)
als auch für die Kundschaft (Gebühren bei unbeabsichtiger Nutzung) Risi-
ken bergen.
110
Bezüglich der in der Fallstudie verfolgten Produktidee des Autors regte Herr Fittl an, bei
der Formulierung der Marketingbotschaften genauer zwischen der nutzenden und der
zahlenden Kundschaft zu unterscheiden. Fotoschaffende bilden zwar die mögliche zah-
lende Kundschaft von Trelew, benutzt würde der Dienst aber in erster Linie von deren
Kundinnen und Kunden, die in Auftrag gegebene Fotos betrachten und nachbestellen
möchten. Das Produktversprechen „View your images up to 96% faster“ müsste daher
umformuliert werden zu „Let your customers browse your photos 96% faster“. Er empfahl
weiters, die Upload-Funktion mit JPEG XR weniger technisch zu vermarkten, sondern
mehr unter dem Gesichtspunkt des Termindrucks von Fotoschaffenden zu betrachten
(Beispiel-Slogan: „Deliver your work 50% faster“)
Zu den Einsatzempfehlungen für Running Lean merkt Herr Fittl an, dass beim betrieblichen
Einsatz der Methode das „Branding“ eines Running-Lean-Projektes eine große Herausfor-
derung darstellt: darf den Befragten in den problem/solution interviews der Firmenname
genannt werden? Wie wird das Projekt firmenintern „verkauft“, ohne dass Missverständ-
nisse und Kompetenzstreitigkeiten entstehen?
Für Fittl besteht ein Ausweg in der Vermarktung als „Hackathon für Produktideen“. Der
Begriff „Hackathon“ bezeichnet eine auf wenige Tage begrenzte Veranstaltung, in deren
Rahmen SoftwareentwicklerInnen intensiv an neuen Programmfunktionen arbeiten und
diese abschließend präsentieren – im Vordergrund steht dabei die prototypische Umset-
zung experimenteller Funktionen. Damit könne man sowohl in der Unternehmensumwelt
als auch bei den Befragten Missverständnisse und falsche Erwartungen verhindern.
7 Ausblick
Diese Masterarbeit illustrierte anhand einer ausführlichen Fallstudie den Ablauf eines agi-
len Produktentwicklungsprozesses unter Verwendung der Running-Lean-Methode. Die
dabei gewonnenen praktischen Erfahrungen erlaubten die kritische Beurteilung der Me-
thode selbst, die Darstellung ihres Potentials für die moderne Produktentwicklung sowie
die Formulierung konkreter Anwendungsempfehlungen für den betrieblichen und privaten
Einsatz.
Im Zuge der Auseinandersetzung mit Running Lean stieß der Autor auf neue Forschungs-
fragen, die den Rahmen dieser Arbeit sprengen würden, aber Inhalte für zukünftige Mas-
terarbeiten im Bereich „agile Produktentwicklung“ darstellen:
Die vorliegende Masterarbeit konnte zwar Anwendungsempfehlungen für
„Running Lean“ aussprechen, aber nicht feststellen, wie weit verbreitet diese und
verwandte Methoden in der betrieblichen Praxis sind. Eine branchenübergreifende
111
Befragung von Innovations- und Produktentwicklungsbeauftragten könnte diese
Frage beantworten und zu einer Verfeinerung der best practices beitragen.
Wie die Lean Startup Conference 2013 zeigte, werden agile
Produktentwicklungsmethoden nicht mehr nur von „Garagenfirmen“ eingesetzt:
Großunternehmen wie der IT-Konzern Microsoft zählen ebenso zu den Anwendern
wie diverse Non-Profit-Organisationen oder die New Yorker Schulbehörde. Sie alle
möchten in Lean-Startup-Labors Produkte, Prozesse oder Dienstleistungen entwi-
ckeln, die noch besser auf die Bedürfnisse ihrer Kunden eingehen. Interessant
wäre in diesem Zusammenhang die Erforschung des beruflichen Hintergrunds der
österreichischen Lean-Startup-AnwenderInnen: in welchen Branchen und Organi-
sationen sind sie tätig? Für welche Zwecke setzen sie Startup-Methoden ein? Als
„Untersuchungsobjekt“ für eine Umfrage bietet sich die Anwendergruppe
„Lean Startup Circle Vienna“ an, die aktuell 413 registrierte Mitglieder umfasst52.
In der Fallstudie zeigte sich an einigen Stellen fachlicher Vertiefungsbedarf bei der
Anwendung von Running Lean, etwa im Customer Development, bei dem potenti-
elle AnwenderInnen einer Produktidee zu tatsächlichen, zahlenden Kunden entwi-
ckelt werden. Auch Umsetzungsstrategien für Prototypen im Sinne von
Running Lean könnten wissenschaftlich untersucht werden: vom optimalen Um-
gang mit technischer Schuld bis hin zur Anwendbarkeit des hochiterativen Prototy-
penkonzeptes außerhalb der Softwareentwicklung.
Mit diesem Ausblick auf anknüpfende Forschungsfragen beschließt der Autor seine Aus-
führungen. Er hofft, mit seiner Arbeit zu einem besseren wissenschaftlichen Verständnis
von Running Lean und verwandter Methoden beigetragen zu haben. Sein ultimativer
Wunsch wäre es jedoch, wenn sich der/die LeserIn nicht nur theoretisch mit dem Thema
beschäftigen würde. Unserem Land würden mehr kreative und innovative Köpfe guttun, die
ihre Ideen als Entrepreneure oder Intrapreneurinnen umsetzen, anstatt „unselbstständig“
die ewiggleichen Rituale, Prozeduren und Prozesse abzuarbeiten. Um den vielleicht schon
länger mit eigenen Produktideen kokettierenden und dann doch immer wieder zögernden
Lesern und Leserinnen Mut zur Umsetzung zu machen, endet diese Arbeit mit dem Run-
ning-Lean-Leitspruch:
„practice trumps theory!“
52
http://www.meetup.com/Lean-Startup-Vienna/ (abgerufen am 19.12. 2013)
112
Anhang
Abschrift der Problem Interviews
Die nachfolgenden Seiten enthalten eine Abschrift der in Kapitel 4.1 diskutierten problem
interviews zum Online-Fotodienst Trelew. Auf den Aufbau der Interviews wird ebendort
eingegangen. Die Interviews wurden von Juli bis September 2013 durchgeführt, die getä-
tigten Stellungnahmen zu Arbeitsweisen, Produkten und Technologien sind also im Kon-
text dieses Zeitraums zu sehen. Die Interviews fanden ausschließlich in Form persönlicher,
ein- bis zweistündiger Einzelgespräche statt. Diese Abschrift muss sich daher aus Platz-
gründen auf die zusammengefassten Aussagen der Interviewten beschränken. Die Na-
men der befragten Personen wurden geändert, alle weiteren Angaben entsprechen den
tatsächlichen Aussagen der Interviewten. Damit diese Aussagen möglichst unverfälscht
wiedergegeben werden, wurde – wie in den Vorbemerkungen zu dieser Arbeit bereits
erwähnt – von einer nachträglichen Ergänzung geschlechtsneutraler Bezeichnungen ab-
gesehen.
Interview mit Bernhard Anders, Konzertfotograf
Demografische Fragen
Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich erstelle in meiner
Freizeit künstlerisch hochwertige Bilder von Kleinkunst-Events und Konzerten, da-
neben widme ich mich der Porträtfotografie.
Welches DSLR-Modell besitzen Sie? Eine Nikon D90
Wieviele Fotos schießen Sie durchschnittlich pro Monat? 300 Fotos
Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW
Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,
Adobe Lightroom
Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? Facebook,
500px.com
Wünschen Sie ein Cloud-Backup Ihrer hochauflösenden Fotos?
Ja, diese Funktion ist mir wichtig. Ich schieße 300 - 500 Photos pro Konzert und veröffent-
liche nur ein "Best Of" davon im Internet. Alle Bilder in RAW-Qualität im Netz zu veröffent-
lichen erscheint mir aber aufgrund des hohen Datenvolumens unrealistisch. Die von
Trelew angedachte verlustbehaftete RAW-Komprimierung mit dem Adobe DNG Format ist
umstritten, da dadurch der nachträgliche Weißabgleich beeinträchtigt wird. Eine verlust-
freie Kompression der RAW-Bilder bringt meiner Erfahrung nach max. 50% Speicherplatz-
ersparnis.
113
Zusammengefasst bin ich mir deshalb nicht sicher, ob Trelew mit einer Backup-Funktion
für alle geschossenen Fotos werben soll. Sehe es eher als Backup-Dienst der besten
Bilder.
Möchten Sie auf Ihre hochauflösenden Fotos von unterwegs zugreifen, um
beispielsweise ad hoc Abzüge zu bestellen?
Ja, diese Funktion ist mir wichtig. Der mobile Zugriff auf hoch aufgelöste Bilder gefällt mir
gut, mich sprechen oft Bandmitglieder an, ob sie ein im Internet veröffentlichtes Konzert-
foto nicht in nativer Auflösung bekommen können. Es ist oft gar nicht so leicht, die zugehö-
rige RAW-Datei zu finden. Es wäre toll, wenn der Dienst für alle User die niedrig aufgelöste
Version des Bildes bereitstellt und man dann für ausgewählte User die RAW-Version frei-
schalten kann. Aber: der mobile Zugriff auf Originaldateien ist ein heikles Thema für kom-
merzielle Fotografen, es muss klar und einfach feststellbar sein, wer auf welche Versionen
Zugriff hat und was die Nutzungsbedingungen sind.
Möchten Sie ausgewählte hochauflösende Bilder ins Internet stellen, um da-
mit Geld zu verdienen oder einen guten Zweck zu unterstützen?
Ich betreibe Fotografie als Hobby und möchte dies frei von ökonomischen Zwängen tun,
daher hat diese Funktion keine Relevanz für mich.
Möchten Sie grundlegende Bearbeitungen Ihrer Bilder online durchführen,
um nicht jedesmal auf Photoshop & Co zugreifen zu müssen?
Diese Funktion sehe ich eher problematisch. Wo beginnt "grundlegendes Bearbeiten" und
wo hört es auf? Ich mache mit meinen RAW-Bildern oft Belichtungskorrekturen in
Lightroom und dann Retuschearbeiten in Photoshop. Ich halte es für unrealistisch, dass
mir ein Online-Dienst die Funktionen in derselben Qualität bieten kann. Könnte mir aber
ein Vorschautool für professionelle Fotografen vorstellen: der jeweilige Endkunde (z.B.
Hochzeitspaar) legt ein paar Filter über das Bild (z.B. Sepia) übers Bild und teilt so dem
Fotografen seine Wünsche mit. Dieser vollzieht die Bearbeitung dann in Photoshop nach.
Haben Sie noch weitere Ideen für den Online-Dienst?
Wenn es ums Drucken geht, müsste Trelew Proofing/Colormanagement-Funktionen mit-
bringen. Einen Plugin für Adobe Lightroom oder Photoshop sollte man auf jeden Fall an-
denken, um den direkten Upload aus diesen Programmen zu ermöglichen.
114
Priorisierung der Funktionen
Funktion Priorität nach dem Schulnotenprinzip
Cloud-Backup von RAW-Bildern 1
Grundlegende Bearbeitungsfunktionen 5
Verkauf von Bildern 4
Anbindung von Fotodienstleistern 3
Online-Zugriff auf hochaufgelöste Bilder
(auch von mobilen Endgeräten)
2
Interview mit Daniel Ortner, Fotografie-Dozent
Demografische Fragen
Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich unterrichte das
Freifach „Digitale Fotografie“ an einer technischen Fachhochschule und bin freibe-
ruflicher Porträtfotograf.
Welches DSLR-Modell besitzen Sie? Mehrere Modelle der Firma Nikon
Wieviele Fotos schießen Sie durchschnittlich pro Monat? 100 Fotos
Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW
Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,
Adobe Lightroom
Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? Keine
Wünschen Sie ein Cloud-Backup Ihrer hochauflösenden Fotos?
Die Funktion klingt interessant, aber ich fürchte, die Upload-Zeit für die Bilder ist zu hoch.
Auf Reisen wäre ein solches Cloud-Backup nützlich, um die erstellten Bilder redundant
speichern zu können. Erfahrungsgemäß ist die Upload-Geschwindigkeit dann aber noch
geringer, da die mobilen Datenleitungen nicht so gut ausgebaut sind.
Möchten Sie auf Ihre hochauflösenden Fotos von unterwegs zugreifen, um
beispielsweise ad hoc Abzüge zu bestellen?
Üblicherweise führe ich meinen Kunden erstellte Portraits auf meinem iPad vor, dafür
reichen auch niedrig aufgelöste Versionen der Fotos, die ich mit Adobe Lightroom erstelle.
Für Landschaftsfotografie oder detailreiche Motive können hochaufgelöste Bildversionen
aber nützlich sein.
115
Möchten Sie ausgewählte hochauflösende Bilder ins Internet stellen, um da-
mit Geld zu verdienen oder einen guten Zweck zu unterstützen?
Ich wäre schon an alternativen Vermarktungsmöglichkeiten für meine Bilder interessiert,
allerdings müssten die investierte Arbeit und der mögliche Ertrag in einem sinnvollen Ver-
hältnis stehen.
Möchten Sie grundlegende Bearbeitungen Ihrer Bilder online durchführen,
um nicht jedesmal auf Photoshop & Co zugreifen zu müssen?
Ich bin vor allem daran interessiert, meinen Bildbearbeitungsworkflow zu beschleunigen,
um die Bilder noch schneller zum Kunden zu bekommen. Aktuell habe ich in SSD-Lauf-
werke investiert, um die Datenübertragung zwischen Kamera und Bearbeitungsrechner zu
beschleunigen. Ich finde zwar den Gedanken interessant, die mitunter rechenintensive
Bildbearbeitung an leistungsstarke Cloud-Server auszulagern, aber die kreative Freiheit
der Fotografen darf nicht darunter leiden. Ich bin eher skeptisch, ob mir ein Online-Dienst
dieselben Bearbeitungsmöglichkeiten wie Adobe Photoshop und Adobe Lightroom zur
Verfügung stellen kann.
Haben Sie noch weitere Ideen für den Online-Dienst?
-
Priorisierung der Funktionen
Funktion Priorität nach dem Schulnotenprinzip
Cloud-Backup von RAW-Bildern 2
Grundlegende Bearbeitungsfunktionen 4
Verkauf von Bildern 1
Anbindung von Fotodienstleistern 3
Online-Zugriff auf hochaufgelöste Bilder
(auch von mobilen Endgeräten)
3
Interview mit Paul Meier, Event-Fotograf
Demografische Fragen
Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich betreibe Fotogra-
fie als mein Hobby und fotografiere vor allem auf Feiern und Veranstaltungen im
Familien- und Freundeskreis. Ich sehe mich als ambitionierten Freizeit-Fotografen
und versuche, mein diesbezügliches Wissen laufend über Workshops zu erweitern.
Welches DSLR-Modell besitzen Sie? Canon 1000D
Wieviele Fotos schießen Sie durchschnittlich pro Monat? 100-200 Fotos
Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW
116
Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,
Adobe Lightroom
Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? Flickr.com (kos-
tenpflichtiger Pro-Account), Dropbox.com (kostenloser Basis-Account)
Wünschen Sie ein Cloud-Backup Ihrer hochauflösenden Fotos?
Derzeit verwende ich eine externe Festplatte zur redundanten Speicherung meiner Bilder.
Ich würde allerdings ein Backup in der Cloud begrüßen, auch um via Internet auf die Bilder
zugreifen zu können. Dem DNG-Format, das in Trelew für den beschleunigten Upload der
RAW-Dateien eingesetzt werden sollte, stehe ich grundsätzlich positiv gegenüber. Dieses
Format stellt schließlich eine zukunftssichere Form der Datenspeicherung dar, außerdem
vermeidet es die den RAW-Formaten anhaftenden Kompatibilitätsprobleme. Mein Bildbe-
arbeitungsprogramm konnte einmal das RAW-Format einer Leihkamera nicht lesen, eine
Konvertierung nach DNG schaffte Abhilfe. Die verlustbehaftete DNG-Variante sehe ich
allerdings skeptisch, da ich nicht weiß, inwiefern ich dadurch Bearbeitungsmöglichkeiten
opfere.
Möchten Sie auf Ihre hochauflösenden Fotos von unterwegs zugreifen, um
beispielsweise ad hoc Abzüge zu bestellen?
Ein Online-Zugriff auf meine RAW-Bilder via Tablet oder Smartphone wäre ein tolles Fea-
ture, um beispielsweise meiner Familie die Bilder zu zeigen und sofort Abzüge zu bestel-
len.
Bisher wollten sich Familienmitglieder meine Bilder direkt nach dem Fotografieren von der
Speicherkarte "ziehen", was ich aber im Hinblick auf meine künstlerische Freiheit abge-
lehnt habe. Durch die angedachte Bildkachelung in Trelew könnte ich anderen "read-only"
Zugriff auf die hochauflösenden Bilder geben, ohne ihnen die Originaldatei selbst auszu-
händigen. Optionen wie Download oder Nachbestellung würde ich dann selektiv freischal-
ten wollen.
Möchten Sie ausgewählte hochauflösende Bilder ins Internet stellen, um da-
mit Geld zu verdienen oder einen guten Zweck zu unterstützen?
Ich fände es gut, wenn ich mit Trelew RAW-Bilder ins Internet stellen kann und sowohl für
freie als auch kommerzielle Nutzung freigeben kann (verschiedene Creative-Commons-
Lizenzen). Die Integration von existierenden Fotohandelsplattformen wie istockphoto.com
wäre sehr nützlich. Würde aber nie die originale RAW-Datei selbst freigeben, sondern im-
mer die entwickelte/bearbeitete Version davon, um die künstlerische Freiheit zu behalten.
117
Für den Erfahrungsaustausch mit anderen Fotografen könnte ich mir die Freigabe einzel-
ner RAW-Bilder aber vorstellen, damit andere Benutzer durch Online-Bearbeitung das
Optimum aus meiner RAW-Datei herausholen.
Möchten Sie grundlegende Bearbeitungen Ihrer Bilder online durchführen,
um nicht jedesmal auf Photoshop & Co zugreifen zu müssen?
Ich finde es sehr schwer, "grundlegendes Bearbeiten" für RAW-Bilder zu definieren. Bei
einigen meiner Fotos reichen minimale Belichtungskorrekturen, bei Porträtfotos greife ich
gerne zu Photoshop-Retusche-Techniken (Kopierstempel,...).
Wäre eher enttäuscht wenn mich Trelew nach dem langen Upload nur mit minimalen Be-
arbeitungswerkzeugen (z.B. Helligkeit/Kontrast/Gradationskurven) erwarten würde. Durch
die RAW-Fotografie erwartet man sich ja ein "Mehr" an Bearbeitungsmöglichkeiten. Viel-
leicht könnte man das durch intelligente Voreinstellungen kompensieren, mit denen gleich
nach dem Upload ein paar gute Bearbeitungsvorschläge umgesetzt werden. Denkbar wäre
der Upload und Einsatz von Photoshop-Voreinstellungen (.acv-Kurven, Aktionen).
Haben Sie noch weitere Ideen für den Online-Dienst?
Auf Flickr.com habe ich die Gästepass-Funktion schätzen gelernt: damit kann ich auch
nicht bei Flickr registrierten Anwendern einen zeitlich beschränkten Zugriff auf bestimmte
Alben geben. Diese Funktion setze ich vor allem für Familienmitglieder gerne ein.
Nützlich fände ich auch einen Plugin für Adobe Lightroom, der den Bildupload für Trelew
direkt aus Adobe Lightroom ermöglicht.
Bezüglich der Bearbeitungsfunktionen sehe ich maximale ein Einsatzgebiet in der Kunden-
kommunikation: der Kunde sieht Foto in Trelew, wendet einfache Presets wie Sepia an
und gibt so dem Fotografen zu verstehen, wie er das Bild gerne hätte. Dies könnte aber
der Fotograf als Beschneidung seiner künstlerischen Freiheit auffassen.
Priorisierung der Funktionen
Funktion Priorität nach dem Schulnotenprinzip
Cloud-Backup von RAW-Bildern 4
Grundlegende Bearbeitungsfunktionen 5
Verkauf von Bildern 3
Anbindung von Fotodienstleistern 2
Online-Zugriff auf hochaufgelöste Bilder
(auch von mobilen Endgeräten)
1
118
Interview mit David Anger, Fotograf und Dozent
Demografische Fragen
Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich bin ausgebildeter
Berufsfotograf und fotografiere freiberuflich Events und Fotogeschichten. Daneben
gebe ich Workshops zu verschiedensten Themen der Fotografie in staatlichen und
privaten Bildungseinrichtungen.
Welches DSLR-Modell besitzen Sie? Nikon D700, Nikon D35
Wieviele Fotos schießen Sie durchschnittlich pro Monat? Über 200 Fotos
Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW
Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,
Adobe Lightroom
Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? Facebook,
selbstentwickelte Fotogaleriesoftware für meine Kunden zum Bestellen von Abzü-
gen/Fotobüchern.
Wünschen Sie ein Cloud-Backup Ihrer hochauflösenden Fotos?
Aktuell verwende ich einen lokalen Dateiserver mit RAID-System zum Speichern und zur
Datensicherung meiner Bilder. Nach dem Abschluss eines Auftrags landen die Bilder auf
dem Server, auf der lokalen Platte verbleiben nur niedrig aufgelöste Bilder in einem Light-
room-Katalog. Zur späteren Bearbeitung wird das Katalogbild mit dem hochauflösenden
Bild vom Server verknüpft. Die performante Anbindung des Dateiservers erleichert das
Arbeiten ungemein, allerdings bleibt die Angst vor einem Diebstahl oder Systemausfall.
Ein Cloud-Backup der RAW-Daten finde ich sehr sinnvoll, aber nur unter folgenden Vo-
raussetzungen:
vertrauenswürdiger Anbieter (kein Amazon), am besten regional etabliert, persönli-
cher Support
performante Anbindung, schneller Datenzugriff, postalische Übermittlung größerer
Datenmengen auf Wechseldatenträgern
höchste Ansprüche an Datensicherheit (meine Rohdaten sind wie mein Haustor-
schlüssel)
darf ruhig etwas kosten, aber Preis/Leistungsverhältnis muss stimmen.
Mit dem zur Speicherung herangezogenen DNG-Format habe ich noch wenig Erfahrung
gesammelt, verwende das proprietäre Nikon-RAW-Format, sehe aber die DNG Archivie-
rungssicherheit positiv. Wer weiß, ob die Bildbearbeitungsprogramme in 10 Jahren noch
mit meinen Nikon-RAWs umgehen können.
119
Möchten Sie auf Ihre hochauflösenden Fotos von unterwegs zugreifen, um
beispielsweise ad hoc Abzüge zu bestellen?
Aktuell verwende ich den Online-Dienst Dropbox.com zum "mobilen" Präsentieren meiner
Bilder auf meinem iPad. Die Bilder werden vorher in Adobe Lightroom bzw. Adobe
Photoshop bearbeitet und über die Lightroom-Exportfunktion unter einem Dateinamen im
Format <Datum>-<Kürzel Auftraggeber>-<laufende Fotonummer> abgespeichert. Über
diesen eindeutigen Dateinamen kann ich die Vorschaubilder aus Dropbox.com jederzeit
meinen Originalbildern zuordnen. Die exportierten Vorschaubilder werden durch synchro-
nisierte Ordner automatisch in Dropbox eingebunden. Sollte Trelew die Erstellung der Vor-
schaubilder beschleunigen oder ihre Qualität verbessern, wäre dieser Dienst interessant
für mich.
Ich bin allerdings skeptisch, ob zum Erstellen der Vorschaubilder tatsächlich die originalen
RAW-Dateien in den Online-Dienst hochgeladen werden sollten. Ich fotografiere mit Voll-
format-Sensor und 12-16 Megapixel-Auflösung, die daraus resultierenden RAW-Dateien
sind zwischen 21 und 25 MB groß. Diese Datenmenge erscheint mir zu gewaltig, um für
jedes Bild eine RAW-Datei hochladen zu können. Vielleicht sollte sich Trelew auf den Up-
load hochauflösender JPEG-Dateien beschränken.
Möchten Sie ausgewählte hochauflösende Bilder ins Internet stellen, um da-
mit Geld zu verdienen oder einen guten Zweck zu unterstützen?
Meine Aufträge bestehen ausschließlich aus privaten Fotodokumentationen bzw. Fotoge-
schichten, meine Auftraggeber und ich haben daher kein Interesse an einer Veröffentli-
chung der Bilder.
Möchten Sie grundlegende Bearbeitungen Ihrer Bilder online durchführen,
um nicht jedesmal auf Photoshop & Co zugreifen zu müssen?
Wenn es um die Bearbeitung von Bildern geht, sind mir professionelle Einstellungsmög-
lichkeiten wichtig, die deutlich über das Niveau von Einsteigerprogrammen wie Google
Picasa oder Photoshop Elements hinausgehen sollten. Ich bezweifle, dass mir ein Online-
Dienst einen derartigen Funktionsumfang bieten kann, zumal mich die Bearbeitungsfunkti-
onen der existierenden Photosharing-Dienste überhaupt nicht überzeugen.
Was ich mir noch am ehesten vorstellen könnte, wäre ein Online-Viewer für in Photoshop
oder Lightroom bearbeitete Bilder, der sowohl das Originalbild als auch die einzelnen Be-
arbeitungsschritte in „Schnappschuß“-Form anzeigt (Vorher/Nachher-Ansicht jedes Bear-
beitungsschrittes). Einen solchen Viewer könnte ich einsetzen, um die Kursarbeiten meiner
Schüler zu kommentieren oder zu korrigieren. Keinesfalls würde ich aber damit Kunden die
120
von mir aufgenommenen Bilder bearbeiten lassen – das würde meine kreative Freiheit
inakzeptabel beschränken.
Haben Sie noch weitere Ideen für den Online-Dienst?
Der Dienst müsste auf jeden Fall einen professionellen Eindruck vermitteln, über eine gute
Performance verfügen und einen echten Mehrwert zu oder für Adobe Lightroom bieten,
damit ich ihn einsetzen würde.
Priorisierung der Funktionen
Funktion Priorität nach dem Schulnotenprinzip
Cloud-Backup von RAW-Bildern 1
Grundlegende Bearbeitungsfunktionen 2 (sofern damit der vorgeschlagene Online-
Viewer gemeint ist)
Verkauf von Bildern 5
Anbindung von Fotodienstleistern 4
Online-Zugriff auf hochaufgelöste Bilder
(auch von mobilen Endgeräten)
3
Interview mit Tobias Krammer, Mediengestalter und Fotograf
Demografische Fragen
Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich bin freiberuflicher
Mediengestalter und fotografiere in erster Linie, um visuelles „Rohmaterial“ für
meine Print- und Webdesignprojekte zu erhalten. Mein Wissen als Mediengestalter
und Fotograf vermittle ich auch in Fachbüchern und Videotrainings, wobei ich im-
mer wieder mit professionellen Fotografen verschiedenster Disziplinen zusammen
arbeite.
Welches DSLR-Modell besitzen Sie? Canon EOS 60D
Wieviele Fotos schießen Sie durchschnittlich pro Monat? Circa 100 Fotos
Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW
Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,
Adobe Lightroom
Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? Flickr.com (kos-
tenloser Basis-Account), Facebook
Wünschen Sie ein Cloud-Backup Ihrer hochauflösenden Fotos?
Ein Cloud-Backup für RAW-Bilder erscheint mir sehr wichtig, aber durch die Größe der
RAW-Bilder schwierig (22-30 MB/Bild). Ich lösche oft "schlechte" RAW-Bilder und behalte
nur die JPEG-Versionen von ihnen, um den Speicherbedarf zu minimieren. Der RAW-
Speicherhunger ist auch schon während des Fotografierens ein Problem: ich und einige
121
mir bekannte Fotografen verwenden lieber mehrere "kleine" Speicherkarten (z.B. 8 GB)
statt einer großen (z.B. 64 GB), um das Ausfallrisiko durch Schäden an der Speicherkarte
zu minimieren. Hier wird RAW schnell zum Kapazitätsproblem. In der Studiofotografie wird
zudem häufig "Tethered Shooting"53 eingesetzt, die Kamera ist hier direkt mit dem Lap-
top/Rechner verbunden, der auch als Vorschaugerät fungiert. Die Cloud-Backup-Lösung
müsste diese Szenarien berücksichtigen.
Möchten Sie auf Ihre hochauflösenden Fotos von unterwegs zugreifen, um
beispielsweise ad hoc Abzüge zu bestellen?
Diese Funktion erscheint mir sinnvoll. Ein mobiler Zugriff ist zur Qualitätsbeurteilung der
Bilder wichtig, aber nur für ausgewählte Fotos denkbar. Alle Bilder als RAW hochzuladen,
wäre aufgrund des Upload-Volumens wohl illusorisch. Ein Online-Viewer liefert aber sehr
gute Möglichkeiten zur Qualitätsbeurteilung (vgl. vergrößerte Ausschnitt-Funktion auf
Photocase.de). Die direkte Anbindung an Druckdienstleister finde ich gut, man sollte aber
einen offenen Authentifizierungsstandard finden (OpenAuth?) statt mit Doppel-Accounts zu
arbeiten (d.h. einen erneuten Login beim Online-Dienstleister vermeiden).
Möchten Sie ausgewählte hochauflösende Bilder ins Internet stellen, um da-
mit Geld zu verdienen oder einen guten Zweck zu unterstützen?
Diese Funktion erscheint mir sinnvoll. Ich kenne einige Fotografen, die sehr erfolgreich
Stock-Photos54 im Internet verkaufen55, meine jährlichen Stock-Foto Einnahmen bewegen
sich im einstelligen Euro-Bereich. Ich vermute, man muss sich auf Stock-Photografie spe-
zialisieren und für guten und regelmäßigen Output sorgen, um in diesem Bereich Erfolg zu
haben.
Möchten Sie grundlegende Bearbeitungen Ihrer Bilder online durchführen,
um nicht jedesmal auf Photoshop & Co zugreifen zu müssen?
Ich halte Online-Bildbearbeitung für eine spannende Technologie, sehe aber momentan
noch zuviele technische Hürden für ihren professionellen Einsatz. Das Bearbeiten von
Fotos auf Tablets ist problematisch, da die Tablet-Displays meist zu kontrastreich einge-
stellt sind. Wechselnde Lichtverhältnisse machten die nötige Farbkalibrierung des Displays
nahezu unmöglich.
Für den amateurhaften Einsatz könnten einzelne Cloud-Bearbeitungsfunktionen durchaus
spannend sein, man könnte sich z.B. an der populären Smartphone-App Instagram orien-
53
vgl.: http://de.wikipedia.org/wiki/Tethered_Shooting 54
Dieser Terminus bezeichnet Bilder von häufig nachgefragten Motiven (beispielsweise Sehenswürdigkeiten), die auf Vorrat
(engl. stock) produziert und über Bildagenturen verkauft werden. 55
Einer dieser Fotografen ist der vom Autor ebenfalls interviewte Thorsten Brenner. Dieser verneint aber nennenswerte
Einkünfte aus dem Verkauf von Stock Photos und rät Fotografen ab, sich in diesem Marktsegement zu engagieren.
122
tieren und auf dessen Funktionsumfang aufbauen. Allerdings stellt sich dann die Frage,
warum man angesichts der rudimentären Bearbeitungsmöglichkeiten auf RAW-Dateien
setzt.
Viele Fotografen in Ausbildung erhalten gerne Feedback auf ihre Arbeit, ein Foto-Review-
Tool, das die RAW-Datei und alle darauf angewandten Bearbeitungsschritte darstellt,
würde sicher den Geschmack vieler Nutzer treffen.
Priorisierung der Funktionen
Funktion Priorität nach dem Schulnotenprinzip
Cloud-Backup von RAW-Bildern 1
Grundlegende Bearbeitungsfunktionen 5
Verkauf von Bildern 4
Anbindung von Fotodienstleistern 3
Online-Zugriff auf hochaufgelöste Bilder
(auch von mobilen Endgeräten)
2
Haben Sie noch weitere Ideen für den Online-Dienst?
Das vorhin genannte Photoreview-Tool könnte man um ein Modul für Fotografiewettwerbe
ergänzen, bei denen es div. technischen Beschränkungen gibt (z.B. nur Photos mit
8er/9er-Blende oder Festbrennweiten-Objektiven geschossen, wie beispielsweise die von
Ansel Adams geprägte f64-Fotografie56)
Interview mit Thorsten Brenner, Panoramafotograf und Dozent für
Mediengestaltung
Demografische Fragen
Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich habe mich auf
den Bereich Panoramafotografie spezialisiert. In dieser fotografischen Gattung
werden Landschaften oder Sehenswürdigkeiten mit sehr großem Blickwinkel bis hin
zur Rundumsicht (360°-Panorama) fotografiert. Mein diesbezügliches Wissen setze
ich einerseits in Kundenaufträgen um, andererseits gebe ich es in zahlreichen
Schulungen an öffentlichen und privaten Bildungseinrichtungen weiter. Daneben
bin ich auch als Fachbuchautor für Panoramafotografie und das Bildbearbeitungs-
programm Adobe Photoshop tätig.
Welches DSLR-Modell besitzen Sie? Canon 7D, Canon 600D, Canon EOS 5D
Mark III (leihweise)
Wieviele Fotos schießen Sie durchschnittlich pro Monat? Mindestens 200
56
vgl.: https://de.wikipedia.org/wiki/F/64
123
Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW
Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,
Adobe Lightroom, Adobe Bridge sowie die Spezialprogramme PTGUI und Enfuse
zum Erstellen von Panoramabildern.
Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? Zum Präsentie-
ren meiner Panoramabilder verwende ich mein privates Blog, das mit einem spezi-
ellen Viewer ausgestattet ist. Außerdem bin ich im Panorama-Portal
http://www.360cities.net/ vertreten.
Wünschen Sie ein Cloud-Backup Ihrer hochauflösenden Fotos?
Cloud-Backup sehe ich als sehr wichtig, Knackpunkt ist aber die Upload-Geschwindigkeit
(ca. 25 MB pro Bild sind eine Menge Daten). Die Wahl von DNG als Archivierungsformat
(im Online-Dienst Trelew, Anmerkung des Verfassers) sehe ich positiv, da damit
Zukunftssicherheit geschaffen wird. Wenn sich kleinere DSLR-Kamerahersteller aus die-
sem Marktsegment zurückziehen, werden auch ihre RAW-Formate nicht mehr unterstützt.
Möchten Sie auf Ihre hochauflösenden Fotos von unterwegs zugreifen, um
beispielsweise ad hoc Abzüge zu bestellen?
Für mich wäre mobiler, internetbasierter Zugriff auf RAW-Bilder oder hochaufgelöste
JPEGs vor allem wertvoll in der Kundenkommunikation, nur in voller Auflösung lassen sich
Schärfe und Bilddetails gut beurteilen. Wichtig ist aber, dass Dritte niemals auf die Origi-
naldaten zugreifen dürfen, sondern auf entsprechend runtergerechnete oder mit Wasser-
zeichen geschützte Ansichten, um die unberechtigte Weiterverwendung des Bildmaterials
zu verhindern. Sollte der Online-Dienst auf ein professionelles Publikum zielen, darf das
Thema „Farbmanagement“57 natürlich nicht ignoriert werden, ich empfehle diesbezüglich
einen sRGB-basierten Workflow.
Möchten Sie ausgewählte hochauflösende Bilder ins Internet stellen, um da-
mit Geld zu verdienen oder einen guten Zweck zu unterstützen?
Am klassischen Anwendungsfall für diese Funktion, der Stockfotografie, bin ich nicht inte-
ressiert, da in diesem Segment nur sehr wenige, hochspezialisierte Fotografen Geld ver-
dienen. Meine eigenen Jahresumsätze mit Stockfotografie bewegen sich im Bereich von
200-300 US-Dollar. Von der Anbieterseite her ist dieses Marktsegment gesättigt für mich.
57
Farbmanagement bezeichnet die möglichst originalgetreue Wiedergabe der von der Kamera festgehaltenen Farbwerte auf
verschiedenen Ausgabemedien durch den Einsatz von Farbprofilen. [vgl. (Gockel, 2011, p. 93)]
124
Viel wichtiger finde ich das Thema "Kundenkommunikation und Bildbestellung" in der Auf-
tragsfotografie58: Kunde betrachtet Bilder seines Fotoauftrags im Webbrowser, wählt die
gewünschten Aufnahmen aus, bezahlt im Online-Shop und lädt sich die Bilder runter. Der-
zeit ist mir noch kein Anbieter bekannt, der diesen Prozess vollständig abbildet und in das
Bildverwaltungsprogramm Adobe Lightroom integriert. Es gibt zwar einige „halbautomati-
sche“ Lösungen, diese erfordern jedoch die manuelle Intervention des Fotografen beim
Bestellvorgang (beispielsweise müssen bei der Lightroom-Galerielösung „The Turning
Gate“59 die per E-Mail angeforderten Bilder manuell herausgesucht werden). Mit einer voll-
automatischen Lösung könnte Trelew sicher einen Treffer landen.
Möchten Sie grundlegende Bearbeitungen Ihrer Bilder online durchführen,
um nicht jedesmal auf Photoshop & Co zugreifen zu müssen?
Aus technischer Sicht ist eine cloud-basierte RAW-Bearbeitung eine spannende Sache,
aber es ist schwierig eine genaue Zielgruppe für diese Funktion auszumachen. Die Quali-
tät und der Umfang der Bearbeitungsfunktionen müssten an jene von Adobe Lightroom
herankommen, was ich bei einem Startup für unrealistisch halte. Zudem müsste auch der
Bildschirm des Bearbeitungsgeräts einer Farbkalibrierung unterzogen werden, was bei
Tablets noch nicht möglich ist. Zumindest mittelfristig werden Online-Dienste die etablier-
ten Programme Adobe Photoshop und Lightroom nicht ersetzen können. Eventuell könnte
man eine HTML5-Oberfläche für das OpenSource-Bildbearbeitungsprogramm darktable60
stricken und damit experimentieren. Ich bezweifle aber, dass es kommerzielles Potential
für diesen Ansatz gibt.
Haben Sie noch weitere Ideen für den Online-Dienst?
Grundsätzlich sehe ich zwei wesentliche Anwendungsfälle für Trelew: einerseits eine per-
formante Online-Vorschau auf hochaufgelöste Bilder mit integrierten Werkzeugen für die
Kommunikation zwischen Fotografen und Kunden. Andererseits ein Cloud-Backupdienst
für RAW-Fotos, der die Bilder in unterschiedlichen Auflösungen und Formaten verfügbar
macht.
58
Anlassbezogene und exklusive Produktion von Fotos für einen Kunden, der Fotograf erhält entweder eine vorher
vereinbarte Pauschale oder ein Basishonorar sowie eine Vergütung pro tatsächlich bestelltem Bild. 59
siehe: http://ce3.theturninggate.net/galleries/02-ttg-ce3-client-response-gallery/ 60
siehe: http://www.darktable.org/
125
Priorisierung der Funktionen
Funktion Priorität nach dem Schulnotenprinzip
Cloud-Backup von RAW-Bildern 1
Grundlegende Bearbeitungsfunktionen 5
Verkauf von Bildern 3
Anbindung von Fotodienstleistern 4
Online-Zugriff auf hochaufgelöste Bilder
(auch von mobilen Endgeräten)
2
Abschrift der Solution Interviews
Für die Durchführung der in Kapitel 5.3 vorgestellten solution interviews griff der Autor
überwiegend auf die Teilnehmer der problem interviews zurück. Die Befragung erfolgte in
den meisten Fällen per E-Mail, nur die Fotografen Paul Meier und Oskar Magenschab
wurden persönlich befragt. Im Rahmen der Interviews wurde den Teilnehmern der in den
Kapiteln 5.3.1 und 5.3.2 vorgestellte Prototyp vorgelegt, anschließend fragte der Autor die
Teilnehmer nach ihrer Bewertung der vier „Schlüsselfunktionen“ von Trelew (kachelba-
sierte Schnellanzeige, neue Bildformate, automatisierte Fotobestellung und dateibasierte
Bildsuche), die auf der den Prototyp begleitenden Marketingseite vorgestellt sind (siehe
Abbildung 29 auf Seite 82).
Interview mit Paul Meier, Event-Fotograf
Wie wichtig ist Ihnen die kachelbasierte Schnellanzeige für hochauflösende
Bilder?
Sehr tolles Feature, besonders wenn man unterwegs mit schlechter Internet-Verbindung
seine Bilder in voller Qualität herzeigen will.
Sehe es als wichtiges Differenzierungsfeature zu anderen Diensten, leider wird es auf der
Startseite des Trelew-Prototyps nicht optimal präsentiert. Der für diese Funktion gewählte
Slogan lautet "Show full resolution pictures on any device" - das können Flickr, Picasa und
andere Photosharing-Dienste auch. Würde den Slogan umformulieren in “View high-
resolution images up to 90% faster than conventional photosharing services“, so kommt
der Zeitvorteil durch den kachelbasierten Bildaufbau besser zur Geltung. Man sollte die
Ladevorgänge von konventionellen und kachelbasierten Bildern in einem Balkendiagramm
gegenüberstellen – auf diese Weise wird für den Benutzer der Zeitvorteil anschaulich.
126
Wie wichtig ist Ihnen die Unterstützung innovativer Bildformate für schnellere
Uploads oder hochwertigere Bildvorschauen?
Kannte die angesprochenen neuen Bildformate JPEG XR bzw. lossy DNG noch nicht.
Finde es sehr gut, dass Trelew diese Bilder für Uploads unterstützt und man dadurch Up-
load-Zeit sparen kann oder bessere Qualität als im JPEG-Format liefert. Bin oft auf Reisen
und würde Bilder gerne auch über schlechtere Internet-Verbindungen möglichst rasch
hochladen.
Von der Präsentation dieses Features bin ich nicht so angetan - "Efficient Photo I/O" klingt
zu abstrakt-technisch für einen Fotografen. Es wäre besser, die Formate konkret zu er-
wähnen und die durch sie mögliche Verkürzung der Upload-Zeit mittels einer Animation zu
zeigen.
Wie wichtig ist Ihnen als Fotograf ein Tool zum automatischen Handling von
Fotobestellungen?
Dieses Feature ist mir mit Abstand das wichtigste und sollte unbedingt prominenter plat-
ziert werden. Fotografiere viel auf Events und erhalte oft E-Mail-Anfragen nach einzelnen
Bildern. Das Problem dabei: die Anfrager schicken falsche oder unvollständige Dateina-
men, was die Suche mühsam macht. Ein Tool, das den ganzen Bestellungsprozess auto-
matisiert (Nachbestellung durch Kunden - Verständigung Fotograf - Automatisches Hoch-
laden) wäre Gold für mich wert.
Allerdings ist auch hier die Präsentation zu verwirrend - man müsste mit einer Animation
arbeiten, um den Ablauf besser darzustellen. Die Darstellung des Prozesses als Komman-
dozeilen-Skript schreckt viele grafisch orientierte User ab.
Wie wichtig ist Ihnen die Bildsuche anhand downgeloadeter Vorschauda-
teien?
Sehe den Nutzen: Man hat ein Bild downgeloadet, nach zwei Wochen die Quelle verges-
sen, benötigt aber nun die Copyright-Informationen für eine Veröffentlichung. In diesem
Fall wäre es schon praktisch, die downgeloadete Datei einfach in das Trelew-Fenster zu
ziehen und man wird zur Informationsseite des Bildes weitergeleitet. Für mich als „Bildpro-
duzent“ hat das Feature aber nur untergeordnete Bedeutung.
Priorisierung der Funktionen
Funktion Priorität nach dem Schulnotenprinzip
Schnellanzeige hochauflösender Bilder 2
Automatisches Handling von Fotobestel-
lungen
1
127
Funktion Priorität nach dem Schulnotenprinzip
Dateibasierte Bildsuche 4
Unterstützung innovativer Bildformate 3
Interview mit Tobias Krammer, Mediengestalter und Fotograf
Wie wichtig ist Ihnen die kachelbasierte Schnellanzeige für hochauflösende
Bilder?
Das finde ich eines der spannendsten Features. Bis jetzt musste man ein Bild vollständig
herunterladen und in einem Bildbearbeitungsprogramm öffnen, um es in allen Zoomstufen
zu betrachten. Wenn sich dies nun wesentlich schneller direkt im Webbrowser bewerkstel-
ligen lässt, ist das wirklich ein Feature mit Mehrwert, zumal Schärfe und Farbgebung sich
am besten in voller Auflösung beurteilen lassen.
Ich habe allerdings noch nicht verstanden, ob die Bearbeitung der Bilder nun auf den Ser-
vern von Trelew oder auf dem Rechner des Fotografen erfolgt. Auf der Präsentationsseite
des Prototyps sollte man daher den Workflow besser erläutern (beispielsweise Bearbei-
tung in Adobe Photoshop/Lightroom → Upload des hochaufgelösten Bildes nach Trelew
→ Kachelung → Schnellansicht). Für den professionellen Einsatz wäre ein Schutz der im
Viewer angezeigten Bilder mit Wasserzeichen wichtig, um unerlaubter Verwendung vorzu-
beugen. Außerdem wäre ein Bild-Navigator nützlich, der den gerade angezeigten Aus-
schnitt des Gesamtbildes kenntlich macht und seine Änderung erlaubt.
Wie wichtig ist Ihnen die Unterstützung innovativer Bildformate für schnellere
Uploads oder hochwertigere Bildvorschauen?
Finde es sehr gut, dass Trelew auch neue Bildformate unterstützt und den Benutzer von
Ihren Vorteilen profitieren lässt. Bei der Euphorie gegenüber neuen Dateiformaten sollte
man aber beachten, dass damit oft Konvertierungsprozesse verbunden sind, die Bildbear-
beitungsworkflows verlangsamen und komplizieren können. Wenn beispielsweise die
Konvertierung nach JPEG XR sehr zeitaufwendig ist, relativiert sich der Geschwindigkeits-
vorteil dieses Formats beim Upload wieder. Ich bin aber zuversichtlich, dass sich die Up-
load- und Konvertierungsfunktionalität von Trelew mit der sehr leistungsfähigen Export-API
von Adobe Lightroom umsetzen lässt.
Wenn mit dem Upload von RAW-Dateien geworben wird, sollte man betonen, dass RAW-
Dateien nicht 1:1 durch Dritte downgeloadet werden können. Dieser Punkt ist professio-
nellen Fotografen sehr wichtig.
128
Wie wichtig ist Ihnen als Fotograf ein Tool zum automatischen Handling von
Fotobestellungen?
Mir gefällt die Idee eines privaten „Photo-Shops“ für Auftrags- und Stockfotografie sehr gut,
besonders wenn eine Bezahlfunktion integriert ist. Man sollte aber den Workflow des „se-
lektiven Hochladens“ besser erklären. Ich verstehe diese Funktion so, dass man als Foto-
graf zuerst eine größere Anzahl von Auswahlbildern in hoher Auflösung, aber mittlerer
Qualität hochlädt. Erst wenn der Kunde ein Bild bestellt, wird das Bild in bestmöglicher
Qualität und Auflösung hochgeladen. Muss der Fotograf diesen Upload anstossen oder
wird er automatisch von Trelew durchgeführt (vergleiche dazu die Idee der synchronisier-
ten Ordner von Dropbox)? Wenn das Feature noch nicht programmatisch umgesetzt ist,
könnte vielleicht eine kurze Workflow-Animation helfen.
Wie wichtig ist Ihnen die Bildsuche anhand downgeloadeter Vorschauda-
teien?
Ebenso sehr praktsich, besonders in Hinblick auf einen Publishing-Hintergrund. In einer
Redaktion mit Previews arbeiten, nach Entscheidung für dieses Bild soll es schnell und
einfach (automatisiert) gehen mit dem Download. Im Optimalfall wäre das sogar ein kleines
Applet oder ähnliches, das mir automatisch meine Preview-Dateien mit dem Original er-
setzt (overwrite policies?). Möglicherweise wäre hier ein Zusatzfeature ganz toll, das mir
schnell und einfach zeigt, welche Metadaten in meiner Bilddatei schon enthalten sind im
Moment. Oder gar ein Zusatzrequest. Also z.B. eine Art Drag&Drop Zone, auf die ich ein
Bild ziehe. Dann wird mir rechts davon (iconographisch) gezeigt, welche Metadaten vor-
handen sind (ausgefüllte Icons) und welche fehlen (ausgegraute Icons). Wenn ich auf ein
ausgegrautes Icon klicke, kann Trelew dieses fehlende Metadatum on demand herunter-
laden und überschreibt im Hintergrund automatisch die Datei. Das wäre ein etwas anderer
Ansatz als bei anderen Bildbetrachtern (Adobe Bridge oder Lightroom z.B.), aber durchaus
sinnvoll.
Priorisierung der Funktionen
Funktion Priorität nach dem Schulnotenprinzip
Schnellanzeige hochauflösender Bilder 1
Automatisches Handling von Fotobestel-
lungen
2
Dateibasierte Bildsuche 3
Unterstützung innovativer Bildformate 4
129
Interview mit Daniel Ortner, Fotografie-Dozent
Wie wichtig ist Ihnen die kachelbasierte Schnellanzeige für hochauflösende
Bilder?
Die Möglichkeit der kachelbasierten Schnellanzeige finde ich sehr gut. Durch immer bes-
sere Sensoren und Optiken sind die Megapixel-Werte heutzutage wieder im Steigen be-
griffen, ohne dass man zwangsläufig Probleme mit dem Bildrauschen bekommt. Auch bei
den Handy-Kameras ist Qualität und Bildauflösung starkt gestiegen. Es fehlt aber eine
Technologie, um diese hochaufgelösten Bilder übers Internet präsentieren zu können –
Trelew könnte eine interessante Lösung darstellen. Bei der Wiedergabe auf mobilen End-
geräten oder Büromonitoren sollte man aber mögliche Probleme mit der Farbwiedergabe
beachten. Zur ungefähren Farb- und Belichtungskontrolle könnte die Darstellung eines
Histogramms helfen.
Wie wichtig ist Ihnen die Unterstützung innovativer Bildformate für schnellere
Uploads oder hochwertigere Bildvorschauen?
Ich finde es sehr gut, wenn Trelew den Fotografen durch Unterstützung neuer Dateifor-
mate Produktivitätsvorteile und Archivierungssicherheit bietet. DNG ist wegen seiner Stan-
dardisierung und Unterstützung durch Adobe eine gute Wahl für die Langzeitarchivierung
von RAW-Dateien. Mit JPEG XR habe ich mich noch nicht befasst, möchte dies aber in
naher Zukunft tun.
Wie wichtig ist Ihnen als Fotograf ein Tool zum automatischen Handling von
Fotobestellungen?
Ich finde das Fotobestelltool mit Bezahlschnittstelle sehr gut. Sollte Trelew für die Bezahl-
abwicklung auf externe Anbieter zurückgreifen, möchte ich mir die für meinen Trelew-
„Photo-Shop“ zugelassenen Anbieter aussuchen können. Ich habe in der Vergangenheit
als Käufer und Verkäufer sowohl gute als auch schlechte Erfahrungen mit Internet-Bezahl-
anbietern gemacht. Daher ist es mir wichtig, unkooperative Anbieter aus meinem Shop
verbannen zu können.
Wie wichtig ist Ihnen die Bildsuche anhand downgeloadeter Vorschauda-
teien?
Die Suche über downgeloadete Vorschau-Dateien finde ich sehr gut, auch die Möglichkeit,
diese Vorschaudateien später über ein Skript automatisch durch die hochauflösenden Ori-
ginaldateien zu ersetzen. Für mich stellt sich nur die Frage, ob diese Übersetzung aus je-
der Layout-Applikation heraus funktioniert.
130
Priorisierung der Funktionen
Funktion Priorität nach dem Schulnotenprinzip
Schnellanzeige hochauflösender Bilder 1
Automatisches Handling von Fotobestel-
lungen
3
Dateibasierte Bildsuche 2
Unterstützung innovativer Bildformate 4
Interview mit Thorsten Brenner, Panoramafotograf und Dozent für
Mediengestaltung
Wie wichtig ist Ihnen die kachelbasierte Schnellanzeige für hochauflösende
Bilder?
Die kachelbasierte Schnellansicht ist mit Abstand mein Lieblingsfeature. Hochauflösende
Bilder im Browser zu betrachten und quasi in Echtzeit ihre Schärfe beurteilen zu können,
ist schon ein potentielles Killerfeature. Kachelansichten kenne ich zwar vereinzelt von
Stockphoto-Anbietern, aber die Version von Trelew glänzt durch gute Performance und
intuitive Navigation.
Ich würde dieses Feature als erstes umsetzen und es entsprechend vertiefen, damit es
auch für Profis gut einsetzbar ist. Darunter verstehe ich den ohnehin schon angedachten
Lightroom-Plugin, der einen Direktupload aus diesem Programm erlauben soll. Wichtig
sind auch gute Navigationsmöglichkeiten innerhalb des Bildes sowie in größeren Bildkol-
lektionen (hier sollte man keinesfalls auf Tastenkürzel vergessen, Profis lieben so etwas).
Auch eine mobile Version des Trelew-Kachelviewers (entweder als Mobile-Website oder
App) wäre wichtig. Nicht vergessen sollte man auch auf „ästhetische“ Wasserzeichen, um
unberechtigte Weiterverwendung der Bilder zu verhindern.
Wie wichtig ist Ihnen die Unterstützung innovativer Bildformate für schnellere
Uploads oder hochwertigere Bildvorschauen?
Der beschleunigte Upload durch das JPEG-XR-Format ist natürlich ein Nice-To-Have und
gutes Differenzierungsmerkmal, ich würde mich aber zuerst auf die kachelbasierte
Schnellanzeige konzentrieren.
131
Wie wichtig ist Ihnen als Fotograf ein Tool zum automatischen Handling von
Fotobestellungen?
Die dateibasierte Bildsuche oder das Handling von Fotobestellungen klingen für mich sehr
brauchbar, ich würde aber zuerst die Bildanzeige gut umsetzen und dann mit diesen Fea-
tures starten. So überfordert man weder die Anwender noch die Entwicklermannschaft ;).
Wie wichtig ist Ihnen die Bildsuche anhand downgeloadeter Vorschauda-
teien?
Siehe vorige Antwort.
Funktion Priorität nach dem Schulnotenprinzip
Schnellanzeige hochauflösender Bilder 1
Automatisches Handling von Fotobestel-
lungen
3
Dateibasierte Bildsuche 3
Unterstützung innovativer Bildformate 3
Interview mit Oskar Magenschab, Fotografie-Dozent
Demografische Fragen
Wie würden Sie Ihre fotografische Tätigkeit beschreiben? Ich betreibe seit
Jahrzehnten Fotografie als ambitionierter Hobbyist und habe bereits einige meiner
Werke ausgestellt. Daneben unterrichte ich das Freifach „digitale Fotografie“ an ei-
ner technischen Fachhochschule.
Welches DSLR-Modell besitzen Sie? Nikon D700
Wieviele Fotos schießen Sie durchschnittlich pro Monat? Circa 100
Schießen Sie im RAW-Format oder in JPEG? Überwiegend RAW
Welche Tools verwenden Sie zum Bearbeiten Ihrer Fotos? Adobe Photoshop,
Adobe Lightroom
Welche Online-Dienste verwenden Sie zum Teilen Ihrer Fotos? SmugMug.com
Wie wichtig ist Ihnen die kachelbasierte Schnellanzeige für hochauflösende
Bilder?
Finde das Feature sehr wichtig. Würde hochauflösende Bilder gerne im Netz präsentieren,
das scheiterte aber an den langen Ladezeiten bzw. der schwierigen Navigation auf mobi-
len Endgeräten. Für mich stellt sich aber die Frage nach der Farbverbindlichkeit der Bilder
im Browser. Es müsste möglich sein, den Bildern eigene Farbprofile mitzugeben und diese
so umzurechnen, dass der Browser zumindest eine annähernd korrekte Farbdarstellung
132
liefert. Bei Browsern, bei denen das nicht möglich ist, sollte ein Warnhinweis angezeigt
werden.
Wie wichtig ist Ihnen die Unterstützung innovativer Bildformate für schnellere
Uploads oder hochwertigere Bildvorschauen?
Finde es sehr positiv, wenn der Fotograf durch die Wahl des richtigen Bildformats die Up-
loadgeschwindigkeit und/oder Bildqualität steuern kann - viele Photosharingdienste sind
hier sehr intransparent. Wichtig ist mir die Unterstützung von RAW-Formaten neuerer Ka-
meras - bei solchen Bildern kam es bei mir in Lightroom schon öfter zu Anzeigefehlern
(falsche Farben, Verpixelung).
Wie wichtig ist Ihnen als Fotograf ein Tool zum automatischen Handling von
Fotobestellungen?
Ist für mich wichtig, allerdings nicht so dringend wie die Schnellanzeige der Bilder im Web.
Wie wichtig ist Ihnen die Bildsuche anhand downgeloadeter Vorschauda-
teien?
nettes Zusatzfeature, sehe ich aber nicht als „kaufentscheidend“.
Haben Sie Ideen für zusätzliche Funktionen?
Die Unterstützung von Kamerafarbprofilen wäre sicher wünschenswert, mir sind außerdem
ansprechende Diashows wichtig, die im Webbrowser laufen sollen. Die Anordnung der
Thumbnails muss nicht immer in einem strengen Zeilenraster erfolgen, mir wäre die fle-
xible Anordnung per Drag-and-Drop auf einem virtuellen Leuchttisch fast lieber. Die Größe
der Thumbnails sollte sich flexibel einstellen lassen. Zudem sollten Trelew-Alben unter
Kundendomains laufen können bzw. in Blogs integrierbar sein.
Funktion Priorität nach dem Schulnotenprinzip
Schnellanzeige hochauflösender Bilder 1
Automatisches Handling von Fotobestel-
lungen
3
Dateibasierte Bildsuche 4
Unterstützung innovativer Bildformate 2
133
Literaturverzeichnis
Adobe Systems Incorporated, 2008. Digital Negative (DNG) Specification 1.2.0.0, San
Jose: Adobe Systems Incorporated.
Adobe Systems Incorporated, 2012. Adobe Digital Negative (DNG) Specification Version
1.4.0.0, San Jose: Adobe Systems Incorporated.
Bayer, B. E., 1975. Color Imaging Array. USA, Patentnr. 3,971,065.
Birklbauer, V. & Karner, T., 2007. Erfolgsfaktoren österreichischer Jungunternehmen.
Statistische Nachrichten, Ausgabe 12.
Blank, S., 2013. The Four Steps to the Epiphany - Successful strategies for products that
win. California: K & S Ranch.
Bockaert, V., 2009. DPReview Glossary: Dynamic Range. [Online]
Available at: http://www.dpreview.com/glossary/digital-imaging/dynamic-range
[Zugriff am 08 09 2013].
Bockaert, V., 2009. DPReview Glossary: Sensor Sizes. [Online]
Available at: http://www.dpreview.com/glossary/camera-system/sensor-sizes
[Zugriff am 08 09 2013].
Brown, T. E. & Ulijn, J. M., 2004. Innovation, Entrepreneurship and Culture: The Interaction
Between Technology, Progress and Economic Growth. Cheltenham: Edward Elgar
Publishing.
Busch, S., 2013. Squeeze Chart 2013 - Camera RAW Compression Benchmark. [Online]
Available at: http://www.squeezechart.com/craw5.html
[Zugriff am 01 09 2013].
Fraser, B., 2004. Understanding Digital Raw Capture. [Online]
Available at: http://www.adobe.com/digitalimag/pdfs/understanding_digitalrawcapture.pdf
[Zugriff am 06 09 2013].
Gianforte, G. & Gibson, M., 2007. Bootstrapping Your Business: Start and Grow a
Successful Company with Almost No Money. Seattle: BookSurge Publishing.
Gockel, T., 2011. Kompendium digitale Fotografie - Von der Theorie zur erfolgreichen
Fotopraxis. Berlin Heidelberg: Springer.
Hubbard, D. W., 2010. How to Measure Anything: Finding the Value of Intangibles in
Business. 2. Hrsg. Hoboken: Wiley.
134
ITU Consultative Comitee, 1993. JPEG ISO/IEC 10918-1 ITU-T Recommendation T.81,
Genf: ITU.
Klaff, O., 2011. Pitch Anything - An innovative method for presenting, persuading and
winning the deal. New York: McGraw-Hill Professional.
Liker, J., 2003. The Toyota Way - 14 management principles from the world's greatest
manufacturer. New York: McGraw-Hill.
Maurya, A., 2012. Running Lean - Iterate from a Plan A to a Plan That Works. Sebastopol:
O'Reilly61.
Mullins, J. & Komisar, R., 2009. Getting to Plan B: Breaking Through to a Better Business
Model. Boston: Harvard Business Review Press .
Nielsen, J., 2000. Why You Only Need to Test with 5 Users. [Online]
Available at: http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
[Zugriff am 20 10 2013].
Ookla, 2013. Ookla Netindex: Upload Speed Index Austria August 2013. [Online]
Available at: http://www.netindex.com/upload/2,20/Austria/
[Zugriff am 01 09 2013].
Osterwalder, A. & Pigneur, Y., 2011. Business Model Generation - ein Handbuch für
Visionäre, Spielveränderer, Herausforderer. Frankfurt am Main: Campus Verlag.
Pearson, B., 2011. Cameras that write DNG. [Online]
Available at: http://www.barrypearson.co.uk/articles/dng/products_cameras.htm
[Zugriff am 14 09 2013].
Pearson, B., 2011. DNG support, to end-December 2010. [Online]
Available at: http://www.barrypearson.co.uk/articles/dng/products_y7.htm
[Zugriff am 14 09 2013].
Ries, E., 2012. Lean Startup - Schnell, risikolos und erfolgreich Unternehmen gründen.
München: Redline Verlag.
Schumpeter, J. A., 1926. Theorie der wirtschaftlichen Entwicklung: eine Untersuchung
über Unternehmergewinn, Kapital, Kredit, Zins und den Konjunkturzyklus. 2. Hrsg. Berlin:
Duncker & Humblot.
61
Die in den Zitaten dieser Arbeit genannten Seitenzahlen beziehen sich auf die eBook-Ausgabe von „Running Lean“ und
wurden mit dem kostenlosen eBook-Reader calibre Version 0.9.12 ermittelt (http://calibre-ebook.com/). Sie können von
den Seitenzahlen der gedruckten Ausgabe abweichen.
135
Shankland, S., 2012. news.cnet.com - Adobe offering new reasons to get DNG religion.
[Online] Available at: http://news.cnet.com/8301-30685_3-57371809-264/adobe-offering-
new-reasons-to-get-dng-religion/
[Zugriff am 14 09 2013].
Srinivasan, B. S. & Pande, V. S., 2013. Stanford Startup Engineering Course. [Online]
Available at: https://class.coursera.org/startup-001
[Zugriff am 11 11 2013].
Tan, L., 2006. Biomed Imaging and Intervention Journal. [Online]
Available at: http://www.biij.org/2006/1/e6/
[Zugriff am 06 09 2013].
Vogel, R., Koçoglu, T. & Berger, T., 2010. Desktopvirtualisierung: Definitionen –
Architekturen – Business-Nutzen. Wiesbaden: Vieweg+Teubner Verlag.
136
Abbildungsverzeichnis
Abbildung 1: Schematische Darstellung des Toyota-Produktionssystems .........................16
Abbildung 2: Die Rolle von Entrepreneuren im Wirtschaftssystem ....................................18
Abbildung 3: Die Bauen-Messen-Lernen Feedbackschleife ..............................................19
Abbildung 4: Der Business Model Canvas nach Pigneur und Osterwalder ........................21
Abbildung 5: Modell "EOS 5D Mark II" von Canon ............................................................27
Abbildung 6: Lichtwege bei DSLRs ...................................................................................28
Abbildung 7: DSLR-Modell Sony A230 mit Wechselobjektiven und weiterem Zubehör .....29
Abbildung 8: Interpolation von Farbwerten im Raw-Konverter ...........................................30
Abbildung 9: Adobe Lightroom mit integrierte mCamera RAW Konverter ..........................30
Abbildung 10: Visuelle Artefakte bei der verlustbehafteten JPEG-Kompression ................32
Abbildung 11: Eine auf flickr.com veröffentliche Fotogalerie ..............................................35
Abbildung 12: Tag Clouds visualisieren die Popularität von Schlagworten. .......................37
Abbildung 13: Struktur des RAW2Cloud-Dienstes .............................................................40
Abbildung 14: Aufbau einer Bildpyramide ..........................................................................41
Abbildung 15: Ausgangsbild für den Test des Bildbearbeitungsdiensters cloudinary .........43
Abbildung 16: Der URL-Parameter e_contrast:80 erhöht den Kontrast des Fotos. ............43
Abbildung 17: Leerer Lean Canvas mit Ausfüllhilfen .........................................................45
Abbildung 18: Das Pirate-Metrics-Modell von Dave McClure ............................................50
Abbildung 19: Der Plan "A" als Lean Canvas ....................................................................52
Abbildung 20: Erfolgskriterien der Bauen-Messen-Lernen Feedbackschleife ....................53
Abbildung 21: Ideenlabyrinth - auf eine "Grobidee" passen viele Ausführungen ................55
Abbildung 22: Die Risikoarten und ihre Entsprechung im Lean Canvas ............................56
Abbildung 23: Dauer des dcraw-Konvertierungsvorgangs auf verschiedenen Servern ......64
Abbildung 24: Zielsetzungen eines Startups vor und nach dem Product/Market-Fit ..........70
Abbildung 25: Aktualisierter Canvas nach durchgeführtem Pivot .......................................75
Abbildung 26: Wireframe-Darstellung einer Dialogbox ......................................................77
Abbildung 27: Demoseite des CSS-Frameworks Twitter Bootstrap ...................................79
Abbildung 28: Der Prototyp der Schnellansicht im Webbrowser ........................................80
Abbildung 29: Vollumfänglicher Screenshot der Trelew-Marketingseite ............................82
Abbildung 30: Aufbau eines Solution Interviews nach Maurya ..........................................91
137
Tabellenverzeichnis
Tabelle 1: Vergleich verschiedener DNG-Varianten. .........................................................34
Tabelle 2: Camera-RAW-Unterstützung der wichtigsten Photosharing-Sites .....................39
Tabelle 3: Preismodelle der Konkurrenzanbieter ...............................................................87
Tabelle 4: Preisstaffel für das Grundprodukt .....................................................................89
Tabelle 5: Preisstaffel für Tiled Viewing .............................................................................89
Tabelle 6: Preisstaffel für Download ..................................................................................89
Tabelle 7: Preisstaffel für Watermarking ............................................................................90
Tabelle 8: Preisbeispiel für die monatliche Nutzung von Trelew ........................................90
Tabelle 9: Einsatzempfehlungen für Running Lean ......................................................... 106