Achievements this week included:
- preparing content for the CIM webinar in a fortnight
- good catch ups with a few old colleagues
- a structure for a presentation for a big media agency taking place in two weeks
- a bit of content for my UBelly chums
- and some interesting chats about how executive and enterprise engagement are intertwined
Next week: Wem Ber Ley. Which is hopefully something I’ll be able to talk about after Monday’s match against The Eagles.
I’ve got a couple of public events coming up in the next month if you’re interested:
I’m running a short online presentation for The Marketer magazine on the subject of Online Communities on June 5th 1-2pm London time. You can register for that here, and if you are a CIM member it can count towards your continuing professional development.
On the evening of June 18th I’m going to be running a webinar to test out some of the concepts behind my side project stamp. The hour-long session looks at some tools and techniques to enable you to take control of your own personal digital strategy. More details and registration here: http://www.stamplondon.co.uk/
If you spend any time amongst people in the London tech startup scene, it won’t be long before you pick up on the influence that Eric Reis’ 2008 book The Lean Startup has had on many people in fledgling businesses.
The book describes a methodology for running a new (tech) venture that draws on both the lean manufacturing movement pioneered by the Japanese car industry in the 1980s, but also from agile software development methodologies.
Overall, Lean Startup argues that if you want to build a business you need to change your product or service to reflect what your customers need, rather than building the “perfect product” and releasing it to market.
There are a few core concepts at the heart of Lean Startup:
Minimum Viable Product (MVP) encourages releasing a new product or service as early as possible, rather than waiting for the whole to be developed. This feels quite similar to time boxing and working releases in agile methods.
Continuous deployment encourages all software written to be released into production immediately.
Split testing (also know as A/B testing) is an experimental method of testing multiple versions of an application to see which is most preferred by users. It’s been a very common technique in commercial web development for many years.
Actionable metrics are measures that allow for meaningful business decisions to be made, as opposed to vanity metrics which tend to just paint a rosy picture of a business’s position.
Pivot, which is when a business changes it’s fundamental business proposition on realising that it’s original hypothesis isn’t necessarily a great idea. Nokia, for example, started as a rubber products business, moved into producing cables as part of that product set, then into electronic components and from there into mobile phones and networking equipment.
Lean Startup came about in the world of the Web, and there are (it seems to me) a few challenges that need to be thought about when it comes to building a business that is focused on apps rather than a browser:
You need to think a bit harder about what you want to measure
The world of Web applications, and Web analytics is such that there is a lot of data about people’s use of your application generated at the server side which can be analysed using off-the-shelf tools (Google Analytics, for example). Those analytical tools provide so much information that you will probably have data that can provide actionable metrics.
If you are delivering an App, that changes: you can find out information automatically about the demographics of people downloading your app, and maybe some very limited usage data (time of use, for example), but that will be about it. Help is at hand though from services like Flurry.com which enable you to build flags to report on specific sorts of activity within your app.
A/B testing becomes more challenging
Within a browser environment you can deliver different versions of the same service to different people at the same time – having two entirely different versions of your site being tested concurrently is perfectly possible without the end user being much aware of their experimental subject status. Building that kind of testing model into an app becomes more challenging unless you have a level of complexity built into your app (or potentially can find a way to deliver two different versions of basically the same thing to your customer base).
Alternatives might include testing versions in a lab, but that can be costly or runs the risk of strange results from using small samples of experimental users and the impact of lab testing in the first place (this, in fact, is kind of what led to the New Coke debacle in the 1980s).
Continuous deployment versus app store submission processes
The idea of releasing multiple versions of code in quick succession works well in the Web world – code is released to a server, and can be rolled back quickly as well. In an app environment where there are submission processes and quality control on behalf of the app store owners, it’s slightly more challenging: if it takes a day (or a week, or whatever) to deliver an update to an app, then releasing every hour into the live environment is just impractical. Larger releases on a weekly or longer basis potentially bridge the divide (a week or even a month is a short time in comparison to application release schedules of old…)
There’s a lot of sensible advice in Ries’ book, but some of the concepts might need a bit of flex in a world where Apps become an increasingly important facet of a tech startup’s business.
Twitter have announced the launch of a two-factor authentication service to try to reduce down the numbers of incidents of accounts being hacked. It’s a good step for consumers, but in my view fails to address the fundamental issue that companies who use Twitter for corporate accounts face: if there is only one account, there’s only one password, and that gets shared across multiple users.
Actually, adding in two-factor adds more challenge. The way it will work is that you will need to enter a PIN that is sent to your mobile via SMS before logging in at a new machine can be verified. So, for a team using the same Twitter account, they’ll also now need to share a mobile phone as well as a password.
Multiple-user Twitter accounts need to be able to be accessed by different people authenticated by themselves, not on a shared identity. It’s only at that point that organisational Twitter accounts will become properly secure.
The “light-hearted” final story on the Radio 4 Today programme this morning brought together Brett Rogers, director of the Photographers Gallery, and Rachel Campbell-Johnston, chief art critic at The Times to discuss the issue of people taking photographs in art galleries. Given Rogers’ role, it’s not too surprising that she’s against it, whilst Campbell-Johnston doesn’t see a problem.
Towards the end of the debate there was a fascinating exchange: the art critic argued that visiting galleries was a Buzzword obscurity social experience, and so it’s not surprising these days that people wanted to extend it by sharing images of what they had seen. Rogers responded that we shouldn’t drive everything to the lowest common denominator, and that visiting an art gallery wasn’t a social experience.
What struck me was that the two of them were working to totally different definitions of the word “social”; Campbell-Johnston meant in the original term of the word, and experience shared with others, and that these days social experiences extend from the physical to the online world. Rogers heard the word social and, it seemed, immediately thought Facebook.
I don’t think I’ve seen quite such a stark illustration about how the use of a word as a hyped-up buzzword can lead to such differences of opinion. If art galleries aren’t a social (old sense) experience, we’d only be allowed in one by one (or possibly even only allowed to visit our own personal art galleries). But the term social has become loaded as a result of it’s use in reference to online services. No doubt we’ll be seeing a new term emerge soon to re-describe the old: it’ll probably be something terribly long winded and buzzwordy in its own right – physical human interactivity or some such waffle. Oh well, I guess this is how language evolves…
There is a business that I pass on my drive to work most mornings that sells signs. Big signs, small signs, signs for the side of a van, signs for putting in a window. I know all of this because you can’t help but notice that they sell signs because of all of the signs that festoon the front of their property. If you wanted a sign, you would know that you could buy one there.
If I wanted a sign, it’s the very last place I would go. Whilst they obviously make and sell signs, it strikes me that they don’t have the first clue in how to use them. And if I wanted something to have a sign on it, I’d go somewhere that was a little bit more, well, subtle.
And yet the front of this sign shop reminds me of far too many sales presentations I’ve seen over the years. “Look at my product! NO LOOK! It’s GREAT!! It’s A PRODUCT! AND I HAVE LOTS OF THEM!!!!”
Would a more appropriate starting point for the sign shop be a subtle (yet visible) question: Do you need a sign?
A couple of weeks ago we organised an interesting event – The Consumer at Work – that brought together people from traditional business software houses, some of our larger business customers, and some folk from digital and design agencies. The aim of the event was to explore themes around the impact that changing consumer expectations of consumption of technology will have on systems used within organisations.
The challenges of consumerisation in the workplace, with concepts like Bring Your Own Device, seems to have been fairly well-centred on the devices that people use to access information systems. Undoubtedly the way in which we use technology and smart devices outside of work is dramatically changing our expectations of how we should consume technology in the workplace. But it isn’t just a simple matter of making business apps accessible from within a touch environment: consumer-focused apps have a very different, user-centric design approach that is a large part of the overall experience.
From the conversations we had at the event it strikes me that there are three elements to bringing touch-based, “consumer-like” apps into the workplace:
For traditional business software vendors, and for larger IT departments who deliver their own internal applications, this potentially means rethinking application or product lifecycle management quite significantly and developing sets of user personae for the development of a series of apps, depending on the type of users and the context in which they’d be using the app. From an architectural perspective, it will be vital to ensure that business logic hasn’t crept into client software so that APIs can be deployed from the back-end services to deliver multiple apps to multiple platforms.
Given all of this technical legacy, this also means that there is potential opportunity for new entrants in the start-up world: developing services to address specific business needs in ways designed from the ground-up in line with the Cloud/apps/devices models that we see in the consumer space gives the opportunity to be of much fleeter-foot potentially than established providers in the market today. It’s interesting, though, that most startups I come into contact with are set firmly in the consumer rather than enterprise space.
