Produktmanagement Lesetipps: Gründen ohne technischen Co-Founder, Design Thinking, Reflective Thinking, Peer Reviews

Eine Ladung Informationen für Produktmanager gefällig? Wir haben Euch wieder eine Reihe von Lesetipps zusammengestellt. Diesmal geht es um’s Gründen ohne technischen Co-Founder, um den Ansatz „Design Thinking“, etwas Zeit zum Reflektieren, sowie die Kraft von Peer Reviews. Viel Spaß beim Lesen!

  • Why you should stop looking for a technical co-founder – at least for now von Andreas Kwiatkowski kann all denjenigen Nicht-Techies Mut machen, die denken, ohne das Erlernen einer Programmiersprache oder einen technisch versierten Co-Founder ließe sich die eigene Idee nicht realisieren. Die ersten Artikel auf seinem Blog Kwiat.com sind sehr vielversprechend und machen ihn zu einem Lesetipp für alle Internet-Produktmanager.
  • Ahmet Emre Acar stellt bei Gründerszene in seinem Artikel „Die Welt des Design-Thinking“ die Grundlagen des Design Thinking-Ansatzes dar. Dieser Innovationsansatz stellt in den Vordergrund, Dinge mit dem Menschen im Fokus neu zu erschaffen.
  • Don’t be Too Busy to Do Some Reflective Thinking – Wer sich täglich einem Information Overload aussetzt, sollte von Zeit zu Zeit ganz bewusst zurücktreten und sich die Zeit für etwas Reflektion nehmen. Marty Zwilling gibt uns ein paar Tipps, wie wir dabei vorgehen können, ohne auf der anderen Seite in ein „over-thinking“ zu verfallen.
  • Sebastian Schneider betont in seinem Beitrag zu „Peer Reviews“ die Bedeutung einer frühen Feedbackschleife durch die direkten Kollegen, die sehr kostengünstig ist und eine zeitnahe Qualitätssicherung ermöglicht, die spätere teure Korrekturen meidet.

Foto: 0xMatheus

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben: Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder den RSS-Feed.

Werbeanzeigen

Produktmanagement Lesetipps: Architekturvision in Scrum, Top 10 Startup-Erfolgsregeln, Kundenfeedback, Kostenplanung in agilen Projekten

Die Produktmanagement Lesetipps enthalten diesmal eine Mischung aus Beiträgen zu agiler Softwareentwicklung, Startup-Vermarktung und der Nutzung von Kunden-Feedback. Viel Spaß dabei! Falls Ihr in letzter Zeit einen spannenden Artikel aus diesem Themenbereich gefunden habt, teilt es doch über einen Kommentar mit.

Die Architekturvision in Scrum

Auch wenn ein Team nach den Leitsätzen und Prinzipien der agilen Softwareentwicklung arbeitet, ist eine initiale Architekturvorstellung wichtig, um nicht ständig alles umbauen zu müssen. Sie muss aber Raum lassen, um inkrementell von Sprint zu Sprint weiterentwickelt werden zu können.
Stefan Roock und Roman Pichler stellen in einem Artikel das Konzept der Architekturvision vor und beschreiben Kriterien und Techniken für ihre Erstellung: „Die Architekturvision in Scrum: Vorausplanung und emergentes Design balancieren“. Er kann als PDF heruntergeladen werden.

Richtig groß rauskommen

Reid Hoffman, Co-Founder und Vorsitzender von LinkedIn hat auf Greylockvc.com 10 Regeln für Gründer veröffentlicht, zu denen er beim diesjährigen South by Southwest vorgetragen hat.
t3n hat diese 10 Regeln wie man richtig groß rauskommt auf deutsch übersetzt. In seiner 10. Regel stellt Hoffman selbst klar, dass solche Regeln nicht als Naturgesetz, sondern als Richtlinie verstanden werden sollten. Wenn man den Erfolg von Hoffman bedenkt, der neben der Mit-Gründung von LinkedIn und PayPal auch in Facebook, Flickr und Zynga investiert hat, lohnt es sich, sich ein paar Minuten Zeit für seine Erkenntnisse zu nehmen.

Warum Kundenfeedback wichtig ist

Evan Hamilton, Community Manager des Kunden Engagement Tools Uservoice, stellt seine Präsentation vom Online Community Meetup in San Francisco zur Verfügung.
Darin präsentiert er, warum Kundenfeedback so wichtig ist, wie es erhalten und gesammelt werden kann. Er gibt auch einen kleinen Einblick, wie am besten mit Kundenwünschen umgegangen wird, gegen deren Umsetzung sich das Unternehmen entscheiden hat.

Kostenplanung in agilen Projekten

Bei Scrumology schreibt Kane über die Kostenplanung in agilen Projekten. Sein zentraler Punkt: Kostenplanung wird durch agile Softwareentwicklung unglaublich viel einfacher.

There are two important facts about Agile projects that I need to make clear before I continue.

  • Agile project teams are cross functional. What this means is that Agile teams are comprised of Analysts, Developers, Testers etc.
  • Agile teams are dedicated for the duration of the project. At the risk of repeating myself, this means that everyone (Analysts, Developers, Testers etc) are 100% allocated to the project for the entire duration of the project.
    • Given these two ideas, it should now be obvious how to cost an Agile project. We have static team compositions and the team is dedicated 100% of the time, so there is a fixed cost for the team per day.

Mit einer Beschätzung durch das Team und das Abschätzen der benötigten Sprints kann somit eine wesentlich bessere Schätzung abgegeben werden als in Projekten, bei denen zahlreiche Übergabepunkte mit einem Wechsel der beteiligten Personen bestehen.

Weitere Ausgaben der Produktmanagement Lesetipps:

%d Bloggern gefällt das: