A Tale of Two Gadgets

For someone who’s an avid reader, I came into the world of ebook readers screaming and kicking. The smell of a book, transitioning from the crispness of the new to the musty of the aged, always had a special place in the hall-of-fame of my olfactory senses. Plus the physical action of turning a page, which to me is like a deliberate step forward in the acquisition of knowledge. Not to mention my habit of writing on the fly-leaf a note of where I bought the book (for example, the book Dark Sun, Making of the Hydrogen Bomb by Richard Rhodes has the ironical inscription – Borders, Pentagon City Mall, Arlington, Virginia, 2005). In a manner of speaking, I test drove the Kindle using the app on my iPad 1. The advantages were immediately obvious (no more half suitcase full of books from my US trips, for instance) but I finally decided to buy a Kindle Paperwhite to make it easier for me to read outdoors – a very important use case for me. And that – the Kindle Paperwhite – is my favorite gadget of 2014, largely because it has none of the advantages of a feature rich iPad. Let me explain.

In a world afflicted with almost incurable attention deficit disorders and gadgets making multi-tasking easier, the Kindle paperwhite’s single use-case focus is like the whiff of a new book bright ray of internal hope. The device does just one thing – downloads books over a Wi-Fi connection and presents the first chapter for you to start reading. That’s it. Get done most efficiently the stuff the user is looking to do and then get out of the way. Yes, the device steps in time to time, in a manner very unobtrusive, to adjust screen brightness, dictionary for words to look-up and highlight portions of text – and all these make that single use-case, reading, a much more enjoyable activity. But alas, there is no way to quickly check if that inconsequential email has arrived, if someone has posted a world changing 140 character tweet or if the first cousin’s daughter’s birthday pics have been uploaded onto Facebook. What a sense of liberation. Someone did mention that the Paperwhite carries an “experimental browser”. This is one experiment I’d be very happy to see fail. I have noticed that I fidget around apps much less on my phone after a longish stint of reading on the Kindle. That is the power of simple devices and software in changing user behavior for the better. This is also a great lesson for product designers who often get swayed by the SUV approach to design – pack so many features, bells and whistles that the user gets swayed by their shiny (albeit of little or no use) allusion only to have the core use cases suffer. Thank you Amazon for such a simple device – and yes, Kindle, I’ll get you the leather cover for Christmas – it is a long overdue gift of gratitude

Before I move to the next gadget a quick mention of a simple and (almost) single-use case service I use regularly. If you are into investing – minus the masochism that you are the world’s best fund manager – then check out scripbox. Their single focus in business is to make investing simple. They do all the non-simple work of asset-class identification, research and monitoring but hide it cleverly away from the user. Quick disclosure – the founders are known to me. And I, in my misplaced product management of hosepipe information systems exuberance have advocated several times numerous features and functions that the founders have patiently heard and politely ignored. They ask of every feature – “does this make investing easier?”. And if there isn’t an intuitive affirmative answer, they pass the idea. Try them – you’ll not be disappointed

Now to the other device. I wanted to add a gadget to my fitness routine that was smarter than a pedometer. As I do with experimental devices, I was loathe to burn a lot of money for it. Just around Diwali I noticed GoQii was selling their devices on Amazon with a three month contract that brought the price down to my range. I bought one and my nightmare with the delivery started. Long story short, the consignment was delayed and finally arrived at a time when I was leaving town (and in-between I discovered how you can track on Amazon orders delivered but not those in transit). I vented my frustration on Twitter and immediately the COO of GoQii joined in the conversation. Right through the Diwali holiday week, a single customer support rep, aware of the details of the situation, kept touch with me. GoQii shipped an additional consignment to the address where I was about go even when the first was not delivered (the problem was actually with the delivery partner though GoQii never tried to disown the problem by apportioning blame, like Amazon did). When I finally got the gadget, they shipped me two premium straps absolutely free of cost – one each to the two delivery addresses. The product itself, I must confess, is quite buggy – flaky syncing of date/time sometimes, shows distance covered even when idle and the battery drains rather fast. Now all these bugs are fixable with firmware upgrades – and I am sure the company is working on it. But what sets this gadget apart is the exceptional customer centricity that comes bundled along with it. The company is quite famous now and it really could have ignored an irate dissatisfied customer buying the less than $70 device from a partner website. But they did not – their CEO left his personal email ID so I could get this resolved. I never had to use it (if a CEO has to resolve an issue then that to me is good enough indicator that the company is best avoided for business). The lesson in all this is simple – a product with bugs will be acceptable to users if there are other aspects of the relationship – things more permanent in nature than software bugs – that delight

Endnote: That’s it my dear readers – thanks for being with me in 2014. I wish you and your families the best for the season and may 2015 be healthy and prosperous for both the mind and soul. Take care.

Containers and Payload

Any system/tool/platform/product that combines content with workflow has two components. Let’s call them the container and the payload. Each requires something from the other to be of any worth together. And either of the components can be worked on – though not entirely independently – for betterment. But sometimes strange things happen. Take for instance e-mail. The e-mail ecosystem has the client as container and the mail (the stuff we write) as payload. E-mail client developers assumed they had not much control on the payload so they went about making the container smarter. Search, labels, keyboard shortcuts, themes, threaded conversations and so on. Later providers like Mailbox (and I am told Inbox, though I am still waiting for an invite) attempted at taking the payload and infusing smartness into it. But in reality for e-mail ecosystems no matter how smart the containers became, the payload was slowly moving towards extinction. Conversations had started moving away to instant messaging platforms of various forms (IM clients) and delivery mechanisms (like WhatsApp). No matter how smart the container became, the payload was getting irrelevant by the day and those with their necks immersed in the containers (no pun) never saw that happening

This presents a rather interesting situation for those building content and workflow combos. The conundrum – which should be made smarter – containers or payloads? One way to examine this is to ask the question – what would reduce friction between the user and the task outcome? (Just pause a minute to consider that strikethrough. Very often we focus on the task and become oblivious to why the task is performed). Workflow and content combos in enterprise software invariably play to productivity and efficiency. The question for a product manager finally boils down to how can those two be improved

Product managers have different levels of leverage on the container and payload (example, email client developers have less control on the payload. Imagine a mail client asking email senders of recipients to add tags to their text before they can be processed). Control over payload is usually less. And this is where effort should be directed to make the payload smarter over the condition in which it arrives even before we start looking at smart containers. For example

• Text mining to improve contextual understanding of unstructured content
• Interlinking of entities for multi-dimensional content
• Algorithmic understanding of relationships
• … and so on

As we work through the layers of containers and payload, it is useful to remember that it takes two to tango. And their could be work to do at either end

Private Company Information: The Opacity Conundrum

Anything that does not change hands very often becomes scarce. As much as it applies to things like art, it finds use in things that are otherwise rather fluid – financial data for example. Take the case of private company information. Private companies are not listed and hence do not have any regulatory compulsions to divulge information about themselves – especially their financial performance. A deluge at the supply side  goes on to complicate things – there are way too many private companies for anyone to create a business model to bring their data together. Data vendors have tried to solve for this problem but an optimum solution is still lurking somewhere – undiscovered

Stripped of all frills, scarce data is scarce because – one, the originator does want to readily part with the information and two, any secondary holder does not wish to pass it along. However, there does exist incentives – standalone incentives for both parties to change their going-in stance. For example, a private company may need bank funds for working capital and for that will readily share quarterly sales and inventory numbers with the bank. The Bank (in our definition, the holder of this information) will also share the same information onwards if there is an effort by someone to securitize these working capital loans. So incentives exist – but they are not shared incentives

I believe there is space for creating a clearing house of sorts for private company data. The platform provider – the clearing house that is – must invest in either creating shared incentives or invent shared economics for fluidity to resume in the dataset. In a manner of analogy (not a very tight one, I must warn), app stores are equivalent vehicles that bring the supply and demand side for apps together by creating shared incentives (and economics). As this platform builds up and the dataset becomes richer, the economics will tilt towards transactions that happen on the platform based on the data. This is something that traditional data vendors should understand – the data by itself (like unmined natural resources) have little value. The value of data is unlocked by actions of economic agents and these actions make economics. Facilitating economics will facilitate the fluidity in private company – and other such scarce – information

KYC Is Dead

Deepa Bachu of Intuit has a fabulous post on designing awesome products. (no, don’t skip. Click the link, read the article and come back here. I’ll wait)

I think time has come for product managers (and designers) to stop using the term Know Your Customer. Before you reach for your cudgels to beat me up – my intent is not to stop people from knowing their customers but to get a couple of layers deeper in the engagement. Let’s look at some specific problems with this “know your customer”phrase

1. The phrase has been bastardized. It happened the moment KYC as a TLA emerged from the fertile crescent of product management and got dragged – kicking and screaming – into the muddy waters of banking. In its most sophisticated form in that industry, KYC is a bunch of entity identifiers and descriptive text about the entity. To be updated at intervals and filed away only to be brandished if a regulator came calling
2. The word “customer” – I have a problem with. It is very common in my industry of enterprise information and I am sure it happens elsewhere too – the customer is not the user. The customer is the one who disintermediates vendors from the user (example, IT departments strike deals with capital market data vendors and often chooses the most cost effective vendor. The market data users are dealing room staff who do not participate in the choosing process). If it is the user that we care about then we must not confuse her with the customer
3. The word “know” – I have a problem with that too. I know too many people on Facebook – I care for only a fraction of them. I know many more people on LinkedIn than I could really care for. The word “know” has diluted the sense of affinity in relationships. In its pristine form, Know Your Customer is not really “know” – it is living with him, sharing his daily joys, pains and frustrations. A closeness much deeper than just that cursory “know”

So what should the new phrase be? How about User Affinity (UA). Besides addressing some of the problems I mentioned above, this is a smaller acronym and easily segues into what should be a logical next step – User Experience (UX). UX should build out what UA discovers – that is the relationship

I’ll leave this post here just so you can let me know your thoughts about this new paradigm of User Affinity. In the next post of this series I will look at ways to develop affinity and insights. Till then keep the comments coming

Platforms & Openness

There is a rush currently underway in business to become a platform company – provider of an ecosystem. Platforms make intuitively good business sense. The openness of a platform attracts many more participants who either by their presence or their expertise (often both) enhance the base value of the platform. And the platform always gets paid for the facilitation. Consider the Kindle platform of Amazon for example – writers, publishers, readers using the platform pay Amazon for either end of the reading transaction (Kindle is not such an open platform really though writers can self publish on it – perhaps Salesforce is a better example. But you get the drift)

Primary and most significant cornerstone of a platform offering is its openness. That is what attracts participants and builds out the ecosystem at scale. Viewed differently, openness is also a culture. This unique intersection of culture and business model is what makes successful platform companies. If the internal culture of a company is that of opacity, parochialism and fights over turf it is very likely the company will bring the same behavior in the way they run the platform. This pisses off participants (like Facebook a few years back was alienating “partners” by building out on their core platform what the partners were bringing in to the ecosystem. This is – besides plagiarisation – a culture of turf build out, which leads to a culture where no one shares anything for the fear of the idea getting stolen). Once partners on a platform shy away, there is no way the firm can reap benefits of providing the platform at scale. The consequence is mostly a regression into becoming a product company earning one time license fees

Remember the saying – culture eats strategy for lunch? It is true. If you are aspire to becoming a platform company ensure the cultural revolution of being more open, collaborative and tolerant (even for disruptive ideas) starts happening closer home

 

Small and Medium Aspirations

Small and Medium Enterprises (SMEs) represent the vast middle earth in the Indian business ecosystem. And as I write this, a gruelling war is getting fought by a multitude of firms to win this middle earth. Win relationships, win mandates, win contracts, win engagements – all so that when these SMEs become adults, businesses who have won now have prominent seats at the table

In a way we think of SMEs as a different class of businesses altogether. During a requirement analysis phase – for building a product or a service – the trap is in hastening to believe that SMEs have very unique businesses issues and try solving them. Quite the contrary – SMEs most often have the same set of challenges that large established players have. So rather than focusing on the challenges of SMEs, a better approach is to focus on their aspirations. Every small and medium business wants to become like – and be treated like – the big guys. The last thing they want is a condescending salesperson turn up at their doorstep and explain how – almost out of pity – they put together a product or solution for them

If a business is serious about serving SMEs it needs to work to help the SME get rid of that very tag. Help the small business to become as competitive – if not more – than the big business. Help the medium sized business break through the growth ceiling. In short, do just two things – one, align to aspirations and, two, help the Davids beat the Goliath (yes, even if Goliath happens to be your client)

Seed Client

Finacle and Flexcube are two very successful, homegrown (India) core banking applications. The quick differentiation between the two goes like this – if it is handling complex instruments and features it is Flexcube but to scale with number of accounts handled, choose Finacle

I can only give you one side of this comparison. Having worked at Oracle, I confirm that Flexcube can indeed handle really complex instrument and accounting situations. Looking around in India though – where it is commonplace for Banks to have several million accounts – it is easy to notice that Finacle has more installs. So there is circumstantial evidence that the second part of the comparison is valid as well. But of higher interest is WHY the two systems are how they are. It is – as people close to the companies will narrate – because of the seed customers of the two products. Flexcube had Citibank (complex corporate bank) as seed and ICICI Bank (large retail bank) was seed for Finacle

The seed customer approach for building a product is a fine art to master. One the one hand there is a firm willing to buy the story and help the product be built out for real life, while on the other hand there is a clear and present danger that what gets architected is skewed for a particular (restrictive) set of use cases (and assumptions). This where Product Managers have to play larger than life roles (and this is one reason why even startups need product managers). Abstracting requirements away from specific, narrow use cases and making them generic fit-for-wider-purpose is a key responsibility of the Product Manager in such a situation

Young companies should rightly remain ever grateful to seed customers and go above and beyond to satisfy them. While doing that it is important to understand the difference between bespoke solutions and generic products. Choices made at this early stage will stick around for much longer than you think

Appshakes

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

The “Business” Side

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

Communication Analytics

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