I installed – like a few thousand others – the LinkedIn app on my ipad a few weeks back. The first thing the app did after installation was grab data from the native contact and calendar app that exists on the device. Quite natural – LinkedIn is all about connections so it was normal for it to start chasing apps that provide productivity help on that social intent. But then, Mr. LinkedIn app, if you are so smart, why don’t you chase the Twitter app as well? Or for that matter the imessenger app?
Therein lies the accessibility hierarchy of apps. There are apps that come bundled with operating systems – these are nascent to the device and does not have much content until you start using them. These are tools. Browser, Email client, Contact management, phone/calls management are apps that most devices come with. That these are OS level programs, another app that runs on the same OS possibly has the hooks to start romantic relationships with these. But not so with other apps that are “outside” of the OS bundle (Funny that in the Indian context this might be looked upon as trying to forge a relationship outside one’s caste or religion – a matter that has received enormous attention of late). However there are apps that can enormously benefit from such associations. Imagine you have a market data app on your mobile device on which you consume news, monitor stock prices and capital markets movements (and I surely can recommend you the best in that category – MarketBoard. Full disclosure: I work for Thomson Reuters!). And on the other side, you have your colleagues, clients, prospects and a vast people-ecosystem sitting in your LinkedIn app. If these two apps could speak with each other then the market data app could automatically mark up those stories that are hot with your LinkedIn connections, making it easier for you to stay informed with relevant news. The social app would benefit from a crowd recommended information engine rather than merely show what my immediate connections are sharing
Making apps work with each other requires effort to create alliances and partnerships that go beyond just understanding of operating systems. Alliances are by nature unstable – they are political in nature and power shifts continually between the partners. But I suspect – rather hope – there will be a few pioneers who will come up with ideas, which if successful could make in-device-intra-app cooperation more natural than it currently is
By the way, I am sure there is a possibility to have Talking Tom integrate with your LinkedIn app and do naughty stuff with your boss, but I haven’t quite nailed the use cases as yet
This Techcrunch article has been doing the rounds recently – if the solitary founder of a startup cannot code, what does she do? The way the sentence is framed is immediately apparent that – cet par – the solitary founder of startup who can code should find herself at a significant advantage over one who cannot. This sounds reasonable as startups never execute on known business models – they are looking to find a business model. So what good is a business guy who will dip into his hat for known tricks. Rather have someone who can discover her way to the MVP and write mean code – and keep pivoting – all along the way. This truism however does not reflect in my experience of having a fair number of technology folks who walk up to seek career advice. “How can I come over to the business side”, they invariably ask me
So what’s so great about this business side? It is not entirely apparent if you don’t dig a little deeper. The main reason is not to come over and start running with sales targets or marketing campaigns but a much ingrained desire to work with customers and users. Work, as in continue with what they are doing but understand the customer context behind all that. And if there are trickles of customer context flowing in, how can that be bettered to put the customer or the user at the center of what their primary job functions are. Sadly – and I am writing this from an Indian standpoint – careers of technologists have become relegated to back office functions, pushing them to seek out. They see their current engineering functions as a cul-de-sac and want to take an exit to a different lane before it is too late. Not able to sometimes articulate their desires correctly or in their naivete of picking up whatever comes their way that smells of a customer, solid engineering talent can easily get wasted in filling up RFPs, running account plans or going around asking users to fill up surveys. What a colossal waste
So if you are an engineer and have this desire to work with customers, the first thing you must do is congratulate yourself. You are thinking in the right direction. But at this stage do not take the wrong turn to walk to the nearest “business” guy you know. The better approach is to look into your chain of command and those adjacent in the same function to identify who in that is working with – or has the chance of working with – customers (and please, ditch that definition of “internal customer”. A customer is only those who write checks for the firm you work with. All the rest are your partners). Now this guy you reach might not be your boss (in most cases he will not be your boss as in that case you would be working with customers and not have this issue to start with) but that should not worry you
As an engineer who wants to work more with customers (or users) you should leverage your strengths, which I am assuming is in building technology solutions to customer problems. Hit that sweet spot with all you have. That’s much better than walking across to the “business” side trying to figure out how much discount to give a customer so he will buy a substandard, poorly engineered product
My friend and now entrepreneur, C R Mahesh, pointed me to a Google announcement this morning. The GMail team at Google has created a shiny new toy – GMail Meter. The service looks into your email history, scrapes out metadata from your communications and then presents back to you Communication Analytics (CommAn). Those familiar with Xobni will instantly associate this as an ape – well, somewhat – of that service
But Xobni is a cul-de-sac product – it is destined to hit a wall with no turns in its future unless it navigates into the murky world of alliances (someone I respect said recently – “alliances are naturally unstable”). Google however has downstream assets like Google+ that it can potentially marry this service with. And the key with successful Communication Analytics is the efficiency with which it can be partnered with one or multiple social activities. It is not necessary for builders of CommAns to have a clear line of sight into the downstream activities so long as their architecture is open enough to accommodate and analyze different classes of metadata. For example, an extensible CommAn system should be able to satisfy social commerce serving up specific metadata as elegantly as it does for social self directed investing use cases
CommAns by itself is not the holy grail – it is the means to an end. The end is Social Activity
On 23rd November, 2011 – day before that is – Google announced it will close down Knol. A few days after its launch in 2008, I had ranted about Knol being a rip-off on Squidoo. Seth Godin – pretty much the insider at Squidoo – explains how they dealt with it.
Plagiarized products do not work, even if you throw in weight and technology behind it.
In my earlier post, I had ranted about the icons that go against feed identifiers in Google Reader (that wasn’t the only thing I ranted about but yes, they did look like 1990s). I was pleasantly surprised today morning that Google has started showing brand thumbnails against the feeds. That’s good.
Before: 1990s style icons
With Brand Icons
Google was the pioneer of simplicity in UI. The company that made billions had a rather strange website – a big text box to accept your search string. It later went on to doodles, which became an instant hit. Simplicity was key, which was fine so long as someone was zealously guarding that cornerstone of design philosophy
Google’s approach to product development has been a mixture of organic and inorganic development. Google unleashed its engineering expertise in the form of Labs onto assets, extending their capabilities. In that process it succumbed to the “UI is too important to be left to engineers” syndrome. The Gmail user interface looked very different from Google docs (which had inconsistent UIs amongst its own components as some of them came via acquisitions) and Google Reader had a different look, feel and navigation. So it was natural that Google stepped into an area not exactly its strength – designing UIs to make them consistent. It dealt itself either a weak hand or set for itself a low bar by defining the coverage of consistency to imply just the look
Google users were slowly pushed these UI updates with the login page to a Google service being the first. Then other services took over. Notice the first inconsistency in this consistency drive – the login page has a big blue button while other services have red. Users ignored such glitches up until Google brought out the new-look “Reader” – a service that allows RSS aggregation and sharing
My Twitter timeline was a first warning that things did not go as planned for Google. After a quick check, I can understand why. The first rule of UI refresh is not to apply lipstick on a pig. The user interaction on Google Reader was always dated – one reason why services like Flipboard and Zite pretty much took up the reading experience leave Google with just the menial task of fetching. And Google passed up an opportunity to redo the design to not just make the service consistent with its brothers but also more modern and egg the reader to stay on by making reading easier. Instead, other than changes in fonts (oversized ones in the main column – Jesus Chirst!) the only other thing I see is a shroud of white all around. Improving user experience to induce more reading (or more +1’ing if Google was after that) was surely not a design objective
(click to see larger, clearer image)
And Google, for reasons they know best, chose to retain a list of keyboard shortcuts on the right panel, leaving the rest of the real estate – copious one – totally blank (adding to the already dominating whiteness of the page)
Ability to aggregate content from publishers that expose them via a common protocol was a tough problem to solve several years ago. No longer so, unfortunately. As Google bets big on its social gambit it has to understand somewhere that it is effortless usability much rather than astute engineering that greases the wheels of social interaction
And then do what with them?
The first fallacy of creating a community is just this. The mindset of a hoarder. Gathering anything without a purpose places the cart in front of the horse – or, the business model in front of the raw material. People are the raw material in a Community. Just as a steel manufacturing business does not hoard up strawberries, a Community must eschew the lure of mindless “customer” acquisition at the cost of defining upfront who are being served and with what purpose
Hoarding impacts your community in two equally destructive ways. One, once the purpose of the community is established (post membership acquisition) members discover they do not have intersecting interests or expectations with the rest of the gang. There is no tribe to speak of. They quit. Secondly, a few acquired members are perhaps of the correct profile who would quickly discover there are a sprinkling of non-conforming audience engaged in community activity and will quickly disappear
What about multi-interest communities then? Yes, they do exist. If that is what you have in mind then it is better to think in terms of platforms. A Platform with different communities as tenants. It is perfectly possible – and correct – to design a handful of services as horizontals that each tenant feeds off. Then get onto community (tenant) specific services.
Irrespective of tenancy plurality, member acquisition should not broadbrush to pixalate the specific community picture. The rule of member acquisition remains unchanged
Photo courtesy Broadmoor Community Church