Friday 25 November 2011

It's not Email vs Social Media, it's tools for jobs


This post http://t.co/pTgTLA79 got me thinking and talking to a couple of customers this morning. In it:
  • Mark Zuckerberg talks about replacing email with something more immediate and clearly, for him, Facebook's new messaging service is it. 
  • The Microsoft guy then pours cold water on it - understandable given the amount of revenue Microsoft get from licensing Outlook, Exchange and the servers that power corporate mail all over the world. 
  • The (ex IBM) guy who invented MIME points to (IBM's) LotusLive, which is lovely and largely irrelevant to most corporates for whom Notes is a tainted if not poisonous chalice of end user computing proliferation.


I totally buy a few things in this article. I think the move towards conversations in a shared, protected environment is going to continue as users see the benefits of being passive participants in conversations; the 'ambient information transfer' argument. Users will also become more comfortable in such an environment, meaning they'll contribute more.

The argumemt, "email vs social media" strikes me as a bit bizarre. It's like saying, "Is a letter better than going to the pub with your mates? Or having a meeting?". 

Well, it just depends what you want to achieve.

For a start, the idea that email is somehow going away doesn't fly - but there are plenty of things done with email today which it isn't that great at. Products will come along that replace things users currently do with email.

This is already happening; before Twitter, how else would you share an interesting link? Blog it? Email out your blog?

And it will happen in other areas.

For example, it gives users control of their workflow; often users will create filing structures within email to allow them to rapidly locate information. I did it myself until around 2008, at which point search and filtering got good enough for me to find what I wanted without filing it. Normally, if I can remember the context of an email then it can be retrieved, even if if means searching on a name, then spinning through a couple of pages. Better than being a filing clerk.

Another example: email is a singularly terrible way to talk about anything to any volume of people. If you're not on the list, you don't know it's happening. If it's in your inbox and nowhere else, it's impossible to share the knowledge. Replies get crossed all the time ("with respect to Dave's point in his third para"). 

A decent collaborative enterprise platform kills both of these uses of email. But it will have to ensure that:
  • Collaboration has to be based around work; it has to be in shared data & communication environment rather than simply a messaging environment - it has to be real-time, capable of dealing with multiple conversation threads
  • Communities of users are able to freely form and create new knowledge from existing data, so the user community becomes the filing system
  • Enterprise search is powerful enough to render filing a waste of time


Email remains pretty good for private communications - personal or enterprise confidential items you don't want to broadcast. (Of course, it's sensible to assume that everything gets leaked eventually.)

But in all other areas, it just needs the right product to topple it.

Friday 11 November 2011

Lessons from teaching myself to run again


I've been running on and off for nearly 30 years - but more off than on. My whole family have had been runners at some point, undoubtedly due to Dad who's still a dedicated runner now as he gets towards 70. In my teens I was quite into it and could do an 11 mile run over pretty serious terrain at the drop of a hat.

So I've always been working off a base of assumed competence - like a lot of organisations. No-one ever taught me to run - certainly not Dad, who could 'just do it'. As so often seen in other disciplines, if it comes easy to you, you've probably not gone through a learning process to become expert in it, and so you're not best placed to teach excellence in it.

But my running has been more off than on. Allowing for a mis-spent late adolescence and early adulthood, it's been off and on for two reasons; lack of pace and recurrent injuries.

Over the last few months we've finally nailed the right asthma medication for me. Of course, my asthma was fine; I was running every other day, usually comfortably. But the nurse said, 'all very well but you're running to your limits', i.e., without the right meds there was no knowing what my potential was.

The other breakthrough was finally teaching myself to be a forefront striker; I now land and push off on the balls of my feet rather than being a heavy heel striker. Heel striking is all very well but you have to roll forward onto your forefoot to push off which increases the risk of pronation/supination, but also seems to massively increase the shock to your system with every step. Every time you land on your heel it's like a car crash; the force travels straight up your leg.

So forefront striking has really reduced the injuries. I've been running for a couple of months now without injury.

The final key is not to overdo it. Instead of thinking, 'yeah, 11 miles used to be no problem…', the right way for me has been to limit it to half an hour every other day of walk/run, building up to complete sessions of running. The aim is to get the muscles and mental capability developed gently. 

I think these lessons have relevance for organisations too.
  1. What medication does the organisation need? Is there a tool or process that will delimit the capacity of a process?
  2. Can we make simple changes to reduce friction and risk at the point where work is actually done?
  3. Can we make lots of small steps to increase capacity, rather than a single, high-risk change?

Saturday 5 November 2011

How we made the 'minimum viable product approach' work



Seth Godin describes why the minimum viable product approach doesn't always work; you can't go through the try/fail loop without support of a community of users.

This is borne out by our experience at Sabisu. In our case, what we had to do was build the community before the product; find something that meets a community's needs, pitch the idea and perhaps a prototype and construct a community to support you.

That community is essential for a few reasons:
  1. It's validation - plenty of people will tell you your crazy, so it's nice to have some people around of a different opinion.
  2. It's a feedback network - so you can be sure 
    1. You start by addressing a real problem rather than something vague and perceived.
    2. You continue to address real problems instead of going off at a tangent.
  3. If it's a great idea then users may support you in other ways (expertise, for example) in return for early adopter benefit.
  4. You get case study opportunities very early, as opposed to launching then waiting a year.