Michael Wegener

Michael Wegener

(3 Kommentare, 21 Beiträge)

Product Manager

Gründer und Gf talentformation.com GmbH

Beiträge von Michael Wegener

Kommentar zum Beitrag “Product vs. IT Mindset” von der Silicon Valley Product Group

0

Der aktuelle Beitrag von Marty Cagan zeigt seine Wahrnehmung der Unterschiede zwischen Product Management getriebener und klass. Software-Entwicklung. Folgende 10 Aspekte werden dabei beleuchtet, jeden einzelnen habe ich nach dem Zitat auf Basis meiner Erfahrungen kommentiert:

 

1) Purpose.  In an IT mindset organization, the staff exists to service the perceived technology needs of “the business.”  In a technology-enabled product organization, the staff exists to service the needs of your customers, within the constraints of the business.  This is a profound and far-reaching difference.  Most of what is below stems from this difference.“

Mit anderen Worten: Eine klass. IT arbeitet auf ein abstraktes Ziel hin. Das ist wie “Schießen im Nebel“!

2) Passion.  In an IT mindset organization, product and tech are mercenaries.  There is little to no product passion.  They are there to build whatever.  In a product organization, product and tech are missionaries.  They have joined the organization because they care about the mission and helping customers solve real problems.

Mit anderen Worten: Braveheart-Kämpfer vs. Legionäre. Sicher gibt es Ausnahmen, Menschen, die versuchen, sich besonders einzubringen und das Beste zu geben. Diesen Teil klass. IT-Organisationen trifft das Schicksal am härtesten.

3) Requirements.  In an IT mindset organization, requirements are “gathered” from stakeholders, prioritized in the form of roadmaps, and implemented.  In a product organization, we must discover the necessary product to be built.  Moreover, we know that most ideas will not work with customers the way we might hope, and we also know that those that do work will require several iterations to achieve the necessary business results.  IT mindset methods are simply too slow, too expensive and generate far too much waste (see http://www.svpg.com/the-inconvenient-truth-about-product/).  Moreover, we also know that more often than not, the technology enables the solution as much as the solution driving the technology (see http://www.svpg.com/the-end-of-requirements/).

Mit anderen Worten: Auf der einen Seite besteht der Glaube, man müsse nur von möglichst vielen sog. Experten aus Fachabteilungen Anforderungen sammeln und diese zusammenfügen und dann ergäbe sich automatisch ein tolles Produkt. Auf der anderen Seite ist man sich darüber im Klaren, dass der Kern eines neuen Produktes zu Anfang noch unbekannt ist und erst über das Verstehen der Nutzerprobleme „entdeckt“ werden muss. Kurz: Technokratentum vs. Entdeckertum oder Arroganz vs. Demut.

@Marty: Thanks for pointing out the damned focus of all these people on stakeholders instead of users.

4) Staffing.  The IT mindset shows up very visibly in the staff and the roles.  The lack of true product managers (especially strong product managers), the lack of true interaction designers, the prevalence of old-style project management, engineers unfamiliar with the demands of scale and performance, the existence of old-style business analysts, and heavy use of outsourcing, are all clear examples of this.  I would argue the most telling manifestation of the IT mindset problem is that the product managers in IT mindset companies are typically very weak, and at true product companies they are necessarily very strong (see http://www.svpg.com/the-product-manager-contribution/).

Mit anderen Worten: Alleine an den Rollentiteln und dem Outsourcing-Grad lässt sich das Alter einer IT-Organisation erkennen.

5) Funding.  In IT mindset companies you find them still funding projects (output) rather than product teams measured by business results (outcome).   There are many serious problems with this antiquated model, and it generates all kinds of bad behavior in the organization as they try to work around the constraints of this system, but most importantly, it results in very poor ROI for the company because of the very high cost of finding out which ideas work and which don’t.

Mit anderen Worten: Die häufige Verwendung des Begriffs Projekt zeugt von fehlender Ziel/ und Business-Orientierung.

Oder: Das Projekt ist der Heilsbringer statt das Produkt.

Der Begriff Programmpolitik wird in diesem Zusammenhang leider auch von Vielen falsch verwendet. Er kommt aus dem Produktmanagement (Konsumgüterindustrie), wird aber von klass. IT-Organisationen im Kontext eines Multiprojektmanagements verwendet. Ursprünglich meint es aber das Programm aus vielen Produkten, das es in einem Portfolio aus betriebswirtschaftlicher Sicht optimal zu kombinieren gilt.

6) Process.  In IT mindset companies, you usually find very slow, heavy, Waterfall processes, even when the engineers consider themselves Agile.  The only part that would be considered Agile would be at the tail end of build, test and release.  Much of this stems from the Funding issue above, but deciding what areas to invest in, staffing a team, defining and designing the solution, and release planning are all typically very Waterfall.  Technology-enabled product organizations simply must move much faster, and work differently, in order to deliver the necessary solutions for our customers and our business.

Mit anderen Worten: Je später im Entwicklungsprozess einer Organisation mit agilen Prinzipien begonnen wird, desto eher handelt es sich noch um ein Unternehmen der Old Economy.

Oder: Gibt es ein Anforderungsmanagement und ein Product Management in einer Organisation, deutet es darauf hin, dass der Grad der Agilität und Kundenzentrierung noch sehr gering ist.

7) Silos.  In IT mindset companies, people align by function, creating silos between the different areas of the business, product, user experience design, engineering, QA and site operations.  In contrast, in a product organization, we depend on true collaboration between product, user experience design, technology and the business units.  In a product organization we optimize for product teams, not for the individual functions.

Mit anderen Worten: Je mehr Matrix in einer technologie-basierten Organisation desto mehr findet sich dort die alte Welt „in neuen Kleidern“.

8) Organization.  In IT mindset companies, engineering is often under a CIO, and “product” (if it exists at all) is often under marketing or absorbed directly in the business units themselves.  In product organizations, there’s a big difference between the engineers that support “true IT” and those that work on the commercial products,  The True IT engineers usually report to the CIO, and the commercial product engineers report to a CTO.  Similarly, product is not a sub-function of marketing.  It is a top-level activity on par with marketing and technology.  It is not so much the org chart that matters here, as much as a recognition that the way we manage True IT work is very different than how we manage commercial product efforts.

Mit anderen Worten: CIOs mit funktionaler Verantwortung und Head of Products auf zweiter oder dritter Ebene eines technologie-basierten Unternehmens zeugen von der falschen Denkhaltung im Top-Management. Noch extremer formuliert: Die oft zu findende Einordnung von Product Managern unter 1. Ebene GF Support 2. Ebene CIO 3. Ebene Head of Product Mgt. zeigt wie weit das Top Management noch von der neuen Welt entfernt ist.

9) Accountability.  In IT mindset companies, accountability frankly is a farce.  The people actually working on a project typically have no real say in what they are building, and sometimes even in how it’s built, and even when it’s due.  In theory, the leadership team could try to hold the requesting stakeholders accountable for the results, but if they do they immediately hear complaints that they didn’t get what they actually wanted, and because of delays and costs, critical things had to get cut, and so it’s certainly not their fault.  So management writes it off as yet another failed technology initiative.  In contrast, in a product organization, we are measured by results.

Mit anderen Worten: In tradierten technologie-basierten Organisationen wird der Schwarze Peter für das Scheitern von Software-Entwicklung immer zwischen IT und Business hin und her geschoben.

10) Leadership.  As with so many things, much of this boils down to leadership.  In IT mindset companies, the technology is viewed as a necessary evil.  It is a source of fear more than a source of inspiration.  Leadership in IT mindset companies is always looking for a silver bullet when it comes to technology.  Maybe they should outsource the whole mess?  Or maybe they can acquire someone else that hopefully has a better track record than they do.   In contrast, in a product company, technology enables and powers the business.  It is embraced and valued.  The people that create the technology are respected as the key contributors they are.  Leadership in a commercial product company understands that it’s their job to create the culture and environment necessary to nurture continuous innovation.

Mit anderen Worten: Die einen sehen Technologie als Benzin, die anderen als Motor ihres Business. Benzin ist immer zu teuer, ein Motor bringt Leistung.

 

Social Commerce kommt (langsam)

0

Seit Jahren wird das Thema Social Commerce gehypt, vornehmlich von Agenturen. Statt zunächst an ihren Grundleistungen zu arbeiten, sind aus meiner Sicht zu viele eCommerce Neulinge/ Follower zu früh auf diesen Zug aufgesprungen und haben ihre knappen zeitlichen und monetären Ressourcen in diese neuen Formen der “Freundschaftswerbung” gesteckt.

Jetzt kommt der SC-Zug lansam in Fahrt. Bewusst wurde es mir gerade wieder als ich auf der Design-Plattform monoqi.com ein cooles Fahrrad entdeckte, das nicht nur preisreduziert € 635, sondern um weitere € 31,75 günstiger zu haben ist, wenn man den Kauf bei FB liked.

Nicht erwartungskonform ist der Prozess: Als Nutzer gehe ich davon aus, dass ich im/ nach Kauf das Produkt like. Es muss jedoch vor der Bestellung geliked werden.

monoqi

Die größere (analytische und technische) Herausforderung aus Anbietersicht liegt sicher darin, den Betrag für das Liken optimal zu berechnen und entsprechend produkt- und zielgruppenbezogen dynamisch anzupassen.

 

Erfolgsfaktoren von Online-Organisationen

0

Ich wurde gerade durch ein (frustrierendes) Kundengespräch wieder an die ”4 Fundamentals for Online Org Chart Success” von Sally McKennzie erinnert. Sie ist eCom-Experten mit langjähriger Erfahrung in der Organisationsgestaltung und bringt die größten Herausforderungen bei den “Old Playern” auf den Punkt:

1. Stellenwert in der Organisation: eCommerce ist Chefsache und nicht, wie so oft, nur das Anhängsel einer Fachabteilung. “Very often, that means the CEO. It can also mean a strong COO or leader of Direct. If you instead choose to make the online team an offshoot of merchandising, marketing or (even worse) IT, it’s unlikely that you’ll realize the broader opportunities of the online channel.”

Woran liegt es, dass eCom nicht den Stellenwert bekommt, den es verdient? Meine These: Die Geschäftsführung des “alten” Geschäftsmodells ist oftmals in vielerlei Hinsicht mit den Herausforderungen des eCommerce überfordert. Je nach Ausbildungshintergrund hängt es daher das Thema entweder im Marketing oder in der IT auf. Ihm ist nicht bewusst, dass eCommerce alle Wertschöpfungsbereiche betrifft. Die Folgen sind zum Teil verheerend, da die eingeschränkte Sichweise und daraus resultierende Steuerung, kaum ein nachhaltig rentables eCommerce Geschäft hervorbingen kann.

2. Spezialisierungsgrad: Da eCommerce ist vielen Unternehmen eine relativ neue Funktionseinheit darstellt, wird ihr Spezialisierungsgrad, insbesondere vom Management, unterschätzt. “Most solid online teams are increasingly comprised of specialists that are skilled in critical disciplines. Think about marketing channel specialists (email, SEO, SEM, Affiliates, CSEs), think about online merchants, who have a growing set of sophisticated search, recommendation and product presentation tools to master. Think about data analytics and A/B testing (in my view, one of the most consistently under-resourced functions on e-commerce teams), and think about the information architecture, interaction design, visual design and user experience disciplines needed to have a first rate site. I am frequently surprised at how few executives are familiar with these important roles. Understand them, and be prepared to invest in the specializations that are the most important for your online business.”

Die Folge ist, dass die eCommerce Units der Unternehmen sehr klein sind und sich stark über Agenturen verlängern. Entweder bestehen die Abteilungen aus Generalisten oder einigen wenigen Spezialisten. Den Generalisten fehlt das Know-how, um die Agenturen effektiv und effizient zu steuern, die wenigen Spezialisten beherrschen zwar ihr Thema, vernachlässigen aber naturgemäß und aus Überforderungen die anderen wichtigen Bereiche.

3. Prozessorientierung: Unternehmen mit kleinen (gekapselten) Teams versuchen oftmals irgendwann das Wachstum und die dafür notwendige Mehrarbeit über eine Integration in die Restorganisation mit ihren Fachabteilungen sicherzustellen. Es werden Schnittstellenverantwortliche in den angrenzenden Fachabteilungen geschaffen. Aber diese Vorgehensweise “is causing many organizations a great deal of stress as they struggle to integrate the online team with the company as a whole. From my experience, it’s usually not integrating the organizational design that solves this challenge. Instead, it’s integrating the strategy, planning and business processes to include online. Brace yourself. It takes a lot of time and roll-up-your-sleeves working sessions to figure out how to make things work across channels and functional groups, what meetings need to take place, where the teams need to intersect and hand off.”

Eine agile Vorgehensweise wie z.B. Scrum sollte daher aus meiner Sicht auf die komplette Organisation und nicht nur auf die Software-bezogenen Bereiche ausgerollt werden. Klare Verantwortlichkeiten, Führung im Sinne eines Scrum Masters und Methoden wie Retrospektiven könnten die Integration der wertschöpfenden Kompetenzen und damit die Produktivitätssteigerung enorm beschleunigen.

4. Haltung gegenüber Mitarbeitern: Manager tayloristischer Schule haben noch nicht erkannt, dass der Ressourcenengpass an eCommerce-fähigen oder zumindest -talentierten Mitarbeitern eine andere Einstellung gegenüber potenziellen und bestehenden Mitarbeitern erfordert. Mittlerweile müssten sich in vielen Aufgabenbereichen die Unternehmen bewerben. Und die Top-Kandidaten sind anspruchsvoll: “They want to be in a company that has a strong vision for the role of e-commerce. They want a direct line of communication to the person who can help them be successful (in other words, they want to report to the CEO or a senior influential leader). They want to know that the company has solved, or is willing to solve some of the issues that have made e-commerce and multi-channel initiatives flop in other places, namely, internal “channel conflict”, long IT queues to get basic customer facing needs addressed, underinvestment in critical functions needed to run a digital business well (see #2 above). In other words, they want to work for someone who “gets it” and will help them clear the runway.”

 

Learnings aus der Scrum-Einführung bei amazon.com

0

Im Blog  ‘The Agile Excecutive’ von Israel Gat und Michael Coté berichtet Alan Atlas als Scrum Coach über seine Erfahrungen und Erkenntnis bei der Einführung von Scrum bei amazon US (Scrum at Amazon):

“Agile practices were present at Amazon.com as early as 1999, but it wasn’t until the years 2004 – 2009 that widespread adoption of Scrum occurred throughout Amazon’s development organizations. Amazon.com’s unplanned, decentralized Scrum transformation is of interest because it is different from the current orthodoxy regarding enterprise Scrum transitions, and its strengths and weaknesses reveal some fundamental lessons that can be applied to other enterprise Scrum transitions.

Here are the major forces that played in the transition.

Permission

Teams (including local management, of course) at Amazon have historically been given wide latitude to solve their problems (coupled with responsibility to do so without waiting for outside help) and are usually not overburdened with detailed prescriptive practices promulgated by centralized corporate sources. The emphasis is on creating, delivering, and operating excellent software in as streamlined and process-light a way as possible. Teams at Amazon have permission to choose.

Teams

The corporate culture at Amazon.com has always been surprisingly consistent with and friendly towards Agile practices. The 2 Pizza Team concept has been written about many times over the years (click here), and a close look shows that a 2 Pizza Team is basically a Scrum team without the Scrum. Teams at Amazon, especially 2 Pizza Teams, are stable and long-lived. Usually a development team reports to a single direct manager.

Knowledge

All it took to light the fire was someone who was willing to spend a little time educating interested parties about Scrum. Teams who learned about Scrum were able to make local decisions to implement it. Results were demonstrated that kindled interest in other teams.

Impetus

Over time, an email-based Scrum community formed. Scrum Master training was provided on an occasional basis by someone who simply wanted to do so. Basic Scrum education continued on an ad hoc and voluntary basis. Eventually enough teams had adopted Scrum that a need was seen and a position of Scrum Trainer/Coach was created. Having a full-time Trainer and Coach available made adoption easier and improved the quality of scrum implementations. By mid-2008 the community was able to support an Open Space Scrum Gathering within the company.

What was (and one assumes is still) missing was higher level engagement at the organization and enterprise levels. No executive support for Scrum ever emerged, and the transition was therefore limited primarily to the team level, with many organizational impediments still in place.

The success of Scrum at Amazon validates one easy, frictionless way to begin a Scrum transition.

Establish stable teams
Make Agile and Scrum information widely and easily available
Give permission to adopt Scrum
The advantage of this approach is that it requires a minimum of enterprise-wide planning and it allows teams to select Scrum, rather than mandating it. All of the rest of an enterprise Scrum transition can be accomplished by simply responding to impediments as raised by the teams and providing management support for change. Based on experience, the impediments raised will include demand (pull) for coaching, scaling, training, organizational change, a Transition Team, PMO changes, and all of the other aspects of an enterprise transition that many organizations labor so mightily to plan and control. Leadership for this kind of transition can only be Servant Leadership from the C-level, which is exactly the right kind for an Agile initiative, isn’t it?

The only impediment to Scrum adoption at Amazon was lack of knowledge. Teams were in place, and permission was part of the culture. When knowledge was provided, teams adopted Scrum. The strength of this process was based on the fact that only teams that were interested in trying Scrum actually tried it. There was no mandate or plan or schedule for this uptake.  Nobody was forced to use Scrum. Teams made an independent, informed decision to try to solve some of their problems. Lean and Agile thinkers will recognize that this as a pull-based incremental approach and not a plan-driven, command and control, push-based approach.

What about the things that didn’t happen at Amazon? The transition stalled at the team level due to failure to engage either middle or upper management in a meaningful way.  Both of those groups are required to bring a transition to its full potential. Training for middle managers, in particular, is crucial, but will usually reach them only with executive sponsorship.  A Transition Team is crucial when organizational and enterprise-wide impediments begin to be unearthed. Support from a source of advanced knowledge and experience (trainer/coach) is key.

Was Scrum good or bad overall for Amazon? There is only spotty, anecdotal data to report. Certainly there are many stories of teams that used Scrum very successfully. The Amazon S3 project, which not only delivered on time after about 15 months of work, but nearly achieved the unusual result of having the entire development team take a week’s vacation leading up to the launch day. It was not the crunch-time, last minute, panic-drenched effort that is common with projects of this scope and complexity. There was the team that “hasn’t been able to deliver any software for 8 months” that, sure enough, delivered some software a month later at the end of their first sprint. Another team reported that their internal customers came to them some time after the team had adopted Scrum, asking that they implement a whole list of random features. “We know these aren’t your responsibility, but you’re the only team that is able to respond to our requests.” Finally, there was the platform team that had literally dozens of internal customers. When that team adopted Scrum, they organized their customers into a customer council of sorts and let them simply decide each month what the team would work on, for the good of all, in order of value to Amazon overall. But even if none of these anecdotes were available to tell, the mere fact that teams opted on their own to adopt Scrum implies that something about Scrum helped them be more successful and more satisfied professionally. If that were not true, then they would not have stayed with it at all, right?”

 

Erlösformen und -quellen: Inspiration mit Beispielen

0

Eine häufige Frage in unseren Bootcamps ist die nach weiteren Erlösquellen und -formen neben den gängigsten, wie z.B. Transaktions- und Provisionserlöse auf Basis von Warenverkäufen oder -vermittlungen.

Folgende Sammlung von Erlösquellen auf http://hackpad.com/ ist zwar nicht immer stringent, aber gerade die konkreten Beispiel können bei der Weiterentwicklung von Geschäftsmodellen, die in einer Sackgasse stecken, sehr inspirierend wirken.

1. Advertising
- Display Ads – ex. Yahoo!
- Search Ads – ex. Google
- Text Ads – ex. Google
- Video Ads – ex. Hulu
- Audio Ads – ex. Pandora
- Promoted Content – ex. Twitter, Tumblr
- Paid content links – ex. Outbrain
- Recruitment Ads – ex. LinkedIn
- Lead Generation – ex. MoneySuperMarket, ZocDoc
- Affiliate Fees – ex. Amazon Affiliate Program
- Classifieds – ex. Craiglist
- Featured listings – ex. Yelp, Super Pages;
- Email Ads – as done by Yahoo, MSN
- Ad Retargeting – ex. Criteo
- Real-time Intent Ad Delivery
- Location-based offers – ex/ Foursquare
- Sponsorships / Site Takeovers – ex. Pandora
- Wait time screenfillers ex. Wetransfer.com
- Sponsored transaction (bank/loyalty) statements ex. VEMT
- Targetted offers – ex. Beintoo

2. Commerce
- App Sale – ex. Instapaper
- Retailing – ex. Zappos
- Marketplace – ex. Etsy
- Crowdsourced Marketplace – ex. Threadless
- Excess Capacity Markets – Uber, AirBnB
- Vertically Integrated Commerce – ex. Warby Parker
- Aggregator – ex. Lastminute.com
- Flash Sales: Gilt Groupe, Vente Privee
- Group buying – ex. Groupon
- Digital goods / downloads – ex. iTunes
- Virtual goods – ex. Zynga
- Training – ex. Cloudera (??), -> Coursera
- Pay what you want – ex. Radiohead
- Commission – ex. SharesPost
- Commission per order – ex. Seamless, GrubHub
- Auction – ex. eBay
- Reverse Auction – ex Priceline
- Opaque Inventory – ex Hotwire
- Barter for services – ex. SwapRight
- Pre-payment – ex. Kickstarter

3. Subscription
- Software as a Service (SAAS) – ex. Salesforce
- Service as a Service – ex. Shopify
- Content as a Service – ex: Spotify, Netflix
- Infrastructure/Platform As A Service – ex. AWS
- Freemium SAAS – ex. Dropbox
- Donations – ex. Wikipedia
- Sampling – ex Birchbox
- Membership Services – ex Amazon Prime
- Support and Maintenance – ex 10gen, Red Hat
- Full Paywall — ex. The Times of London
- Metered Paywall – ex. NYTimes
- Freemium Paywall – ex. The Economist
- Voice and video-conferencing – ex. Uberconference

3. Peer to Peer
- Peer-to-Peer Lending – ex. Lending Club
- Peer-to-Peer Gambling – ex. BetFair
- Peer-to-peer buying – ex Etsy
- Peer-to-peer insurance/home/car – ex AirBnB, Getaround
- Peer-to-peer computing (CrasPlan storage, or SETI@home)
- Peer-to-peer service – ex. Mechanical Turk, TaskRabbit
- Peer-to-peer Mobile WiFi/Tethering – ex Open Garden

4. Transaction processing
- Merchant Acquiring – ex. PayPal (Online / Offline), Stripe (Online), Square (Offline)
- Intermediary – ex. IP Commerce (POS 2.0), CardSpring
- Acquiring Processing – ex. Paymentech
- Bank Transfer – ex. Dwolla,mPaisa
- Bank Depository Offering – ex. Simple, Movenbank (spread on average deposits)
- Bank Card Issuance – ex. Simple (interchange fee per transaction)
- Fullfilment – ex. Amazon
- Messaging – ex. Peer-to-Peer SMS, IM, Group Messaging
- Telephony – ex. termination/origination in public telephony networks (skype out/in)
- Telephony – ex. termination/origination within private telephony cloud (e.g. native skype)
- Payment Gateways: Mobile -ex. Braintree

5. Licensing
- Per Seat License – ex. Sencha
- Per Device/Server License – ex. QlikView
- Per Application instance – ex. Adobe Photoshop
- Per Site License – ex. Private cloud on internal infrastructure
- Patent Licensing – ex. Qualcomm
- Brand Licensing – ex. Sesame Street
- Indirect Licensing – ex. Apple Volume Purchasing

6. Data
- User data – ex. BlueKai
- User evaluations – ex. The Eatery
- Business data – ex. Duedil
- User intelligence – ex. Yougov
- Search Data – ex. Chango
- Real-time Consumer Intent Data – ex. Yieldbot
- Benchmarking services – ex. Comscore
- Market research – ex. GLG

6. Mobile
- Paid App Downloads – ex. WhatsApp
- In-app purchases – ex. Zynga Poker
- In-app subscriptions – ex. NY Times app
- In-app Advertising – ex. Flurry, AdMob
- Out-of-app Advertising – ex. AppKey, StartApp
- Push Advertising – ex. Airpush
- User conversion e.g. fom link to appstore to app use – ex. Distimo
- Coupons – ex. Beintoo
- Digital-to-physical – ex. Red Stamp, Postagram

7. Gaming
- Freemium – Free to play w/ virtual currency – ex. Zynga
- Subscription- ex. World of Warcraft
- Premium – ex. xBox games
- DLC – (Downloadable Content) – ex. Call of Duty
- Ad Supported – ex – addictinggames.com
- Online Education
- Crowd sourcing education – skillshare / Udemy
- Tutoring – http://www.tutorspree.com

espirt

Optimierung der Newsletter-Frequenz

0

Wen nerven wöchentliche oder sogar täglich versandte Newsletter nicht? Nur was ist die richtige Frequenz? Kommen die Anstöße zu selten, wird Umsatzpotenzial verschenkt, kommen sie zu häufig steigt die Abmelderate.

Esprit wählt zwar nicht den aus Kundensicht optimalen Weg, dennoch hat man sich im Sinne des Kunden Gedanken gemacht. Will man sich vom Newsletter abmelden, wird der Nutzer nach den Gründen gefragt:

 

Wählt er als Grund die zu hohe Häufigkeit, folgt die Frage, ob er Interesse habe, den Newsletter weniger häufig zu erhalten:

Danach kann man zwischen vier Optionen wählen:

Es stellt sich dabei jedoch die Frage, ob die Minimalfrequenz von 1x im Monat ausreicht.

amazon_logo

Führungsprinzipien bei amazon.com

0

Aus meiner Sicht bemerkenswert und zumindest im US-Geschäft nicht nur Bullshit-Bingo: die Amazon Leadership Principles:

 

Whether you are an individual contributor or a manager of a large team, you are an Amazon leader. These are our leadership principles and every Amazonian is guided by these principles.

Customer Obsession
Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.

Ownership
Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job”.

Invent and Simplify
Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here”. As we do new things, we accept that we may be misunderstood for long periods of time.

Are Right, A Lot
Leaders are right a lot. They have strong business judgment and good instincts.

Hire and Develop the Best
Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent, and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others.

Insist on the Highest Standards
Leaders have relentlessly high standards – many people may think these standards are unreasonably high. Leaders are continually raising the bar and drive their teams to deliver high quality products, services and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.

Think Big
Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.

Bias for Action
Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.

Frugality
We try not to spend money on things that don’t matter to customers. Frugality breeds resourcefulness, self-sufficiency and invention. There are no extra points for headcount, budget size or fixed expense.

Vocally Self Critical
Leaders do not believe their or their team’s body odor smells of perfume. Leaders come forward with problems or information, even when doing so is awkward or embarrassing. Leaders benchmark themselves and their teams against the best.

Earn Trust of Others
Leaders are sincerely open-minded, genuinely listen, and are willing to examine their strongest convictions with humility.

Dive Deep Leaders operate at all levels, stay connected to the details and audit frequently. No task is beneath them.

Have Backbone; Disagree and Commit
Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

Deliver Results
Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle. ”

Besonders Bemerkenswert finde ich folgende Kriterien:

 

Have Backbone in Verbindung mit Vocally Self Critical: D.h. z.B. Entscheidungen treffen statt sie zu umgehen!

Dive Deep in Verbindung mit Customer Obsession: D.h. z.B. wirklich das Online-Geschäft verstehen wollen und zwar aus der Kundenperspektive kommend!


Bei allen schwankenden Old Stars der Deutschen Handelslandchaft kann man sich fragen, ob sie diese sinnvollen Ansprüche auch an sich und ihre Führungskräfte stellen und inwieweit sie sie erfüllen. Aus meiner Sicht sind sie im e-commerce erfolgsbestimmend.

 

1_click_d

1-Click next step

0

Lange hat sich im Bereich der Bestellbeschleunigung nichts getan. Jetzt zeigt sich amazon erneut als Innovator: Auf der Artikeldetailseite lässt sich die Lieferadresse im direkt sichtbaren Bereich auswählen bzw. die Standardeinstellung verändern.

Eigentlich eine banale Funktion, aber sehr effektiv. Warum?

1. Immer mehr User legen bei immer mehr Shops immer mehr Lieferadresse an, so dass sie nicht mehr auf Anhieb wissen, was die Standardeinstellung ist. Eine geringe Unsicherheit genügt und der User entscheidet sich gegen den 1-Click-Kauf.

2. Immer mehr User lassen sich regelmäßig Ware an unterschiedliche Adressen schicken, nicht nur nach Hause, sondern auch zur Arbeit, je nachdem wo sie am Liefertag sein werden. Wenn die Standardeinstellung nun gerade auf der anderen Adresse liegt, muss der längere Weg durchlaufen werden.

Fazit: Mit dem Vorziehen relevanter Funktionen auf die Artikeldetailseite vereinfacht und vor allem beschleunigt amazon den wahrgenommen Kaufakt. Da hier zudem die Lade- und Lieferzeiten am geringsten sind, verankert sich im Bewußtsein der User noch tiefer: Amazon, wenn’ schnell gehen soll!

wasserfall_agile

Know-how: Agile vs. Wasserfall (Live-Session)

0

Autor: Martin Seibert

Live+Sessions+zur+Online-Beratung

Martin stellt Ergebnisse einer umfangreichen Studie aus 2010 vor, die bekannte Thesen zu den Vorteilen agiler Methoden bestätigen und konkretisieren.

Es ist allerdings keine Schwarzweiß-Malerei: auch der Wasserfallansatz wird unter definierten Bedinungen empfohlen.

chris_cox

Software Engineer Talent Chris Cox – Facebook

0

Autor: Ellen McGirt

Zu seinen Leidenschaften:

A math nerd who learned to program computers early and loved science fiction: “Yeah, I was that kid,” Chris Cox offers as explanation (by way of confession) of how all roads inevitably led to his role as Facebook’s product chief and keeper-creator of the social network’s culture of relentless innovation. Yes, in some ways he hails from central casting. But it was his early studies of jazz piano and the attendant dives into theory, patterns, and abstraction that helped Cox see the world through the lens of cognitive mystery, not merely as an engineering challenge. “Math and music try to solve some of the same problems,” he says. “I wanted to learn more about how it all worked in the brain.”

His quest took him to the legendary Symbolic Systems program at Stanford, and into post-graduate work in the university’s natural language processing group. “I loved artificial intelligence — it seemed like the craziest and most expansive thing in the Stanford course reader,” laughs Cox.

When Facebook came calling, Cox passed at first. “I didn’t think they were working on solving a serious problem.” But after a series of meetings, a picture emerged in his mind. “I could see an unencumbered ability for people to communicate with each other,” he says. “I saw it as a map — a modern form of cartography, but of relationships and people.” After Cox abandoned Stanford for Facebook in 2005, his inaugural assignment was to create Facebook’s

Zu seiner Quelle für Inspiration:

I read a lot about adjacent fields, like architecture, fashion, or music. It’s not the obvious place to look for inspiration. Some of the most grounding stuff for me has been Marshall McLuhan who talked about the evolution of mediums and Stewart Brand, who is another sort of thinker, talking about the way that communities and places could be built. Christopher Alexander is a famous architect from Berkeley who talked about building a language of patterns that you can teach a designer to make something as massive as a new building. A lot of that thinking goes into how to create a home page for a social networking site.
“I’ve never met Steve Jobs. I don’t think I’d ask him a question; I’d probably just want to hear his story. Let’s face it, he’s the reason a lot of us have come to do what we do.”
Michael Wegener's RSS Feed
nach oben