Tag: response

  • email ain't work.

    email is one of my favorite topics when it comes to modern ways of working. There were a few articles on this blog concerning email to be abolished by major organizations in favour of social media (which won’t solve the underlying problem…)

    Communication is essential to most jobs, but so is productivity. Claire Diaz Ortiz wrote a nice comment on why it is both work and why it ain’t at the same time.

    email ain’t work.

    This is the opinion that I tend to prefer, coming from an engineering education. email will distract anybody trying to focus on some real problem, will create an obligation to do something non-productive. email can be considered something additional, that should not become the majority of the actual work. To send designs, architecture, plans or status updates, but it is for sure outside the scope of engineering centric job descriptions.

    unless you’re paid for it.

    The situation is much different should you work in customer support, service, sales or even product marketing or management. These roles live off the conversation with customers, clients, partners and peers, sometimes even competitors. These roles need to know what others, the market, wants to see as a product or a service, and this is something you can get off a drawing board.

    So it depends (a bit)

    After all, email has a very different meaning, depending on the role someone is in. Still the medium itself is very difficult to handle and too time consuming, even for roles depending on communications. Just imagine all the (obvious) spam, newsletters, notifications and so on. Not to say about the increasing practice to CC everybody and his brother. This is what makes email an ultimate productivity killer for everybody.

    In response to: Why Email Isn’t Work. (And Why It Is.).

  • Telekom Tropo RevShare

    Gedenken an einem Feiertags-Morgen. Revenue Sharing ist sicher ein Anreiz für Entwickler, die API oder Technologie eines Drittanbieters zu verwenden.

    In dem dargestellten Modell sieht der Endbenutzer sich aber mit der Situation konfrontiert, mit dem Drittanbieter unmittelbar in Kontakt treten zu müssen, einen zusätzlichen Account eröffnen oder pflegen zu müssen. Die Akzeptanz für die Applikation kann dadurch sinken.

    Proposed Model
    Proposed Model

    Telekom Tropo RevShare – A product proposal | www.cu-0xff.de.

    Schöner und einfacher für Endkunden ist ein Modell, in dem die Applikation diese Abrechnung übernehmen kann. Für den Benutzer ist das transparenter, weil er unmittelbar sieht wie Gebühren mit der App und seinen Interaktionen zusammenhängen.

    Revenue Share Model
    Revenue Share Model