Weapons of mass distraction

In his book, The Shallows: What the Internet Is Doing to Our Brains” Nicholas Carr explains how hyperlinks alter our experience of media: “links don’t just point us to related or supplemental works; they propel us towards them.”

This came to mind as I was reflecting on my recent move from Amazon’s device to Apple’s. The Kindle is a wonderful ebook reader, it’s easy on the eyes, works in the sun and incredibly light. However, the “tumble sensitive” e-ink display eventually caused a move to apple’s tablet.

Moving from a single purpose device to a multipurpose one is more than just getting used to the quirks of iOS. Now, I can also receive email on my iPad. Now, I can actually google references and quotes in other locations. The deep immersion in a book that I felt with the kindle now requires much more discipline.

To emphasise: In a 2001 study, two Canadian scholars asked seventy people to read “The Demon Lover,” a short story by the modernist writer Elizabeth Bowen. One group read the story in a traditional linear-text format; a second group read a version with links, as you’d find on a Web page. The hypertext readers took longer to read the story, yet in subsequent interviews they also reported more confusion and uncertainty about what they had read. Three-quarters of them said that they had difficulty following the text, while only one in ten of the linear-text readers reported such problems. (source).

It is all about exercising maturity and patience – if you are reading a book, read a book. Turning the wi-fi helps the weak-willed as well. Switching over to the web, videos etc – that’s a different form of entertainment – so keep that in mind.

I still manage to consume a hefty amount of books in a month, so it’s all good. Also – the backlight rocks. However – you have to work for the same total immersion experience you get from e-ink, or actual ink.

Partnership (via thinkpanama, on Flickr)

Working in Online Video, I am enlightened daily by the amount of innovation going on in this space, and how much inter-company collaboration is going on. In the video industry, co-innovation is ingrained.

Consider how much technology is involved in taking the output of your HD cam and streaming it to your iPad:

• content must be uploaded (quickly!)
• Transcoding takes place to retrofit the source to any device (2048-by-1536 iPad/480-by-320 Palm Pre/1920-by-1080 HDTV) and format (no flash on iOS..)
• Content tagging, via speech to text, for example, can take place in order to index it and make it searchable.
• Recommendations based on the content are made to link other content items together.
• Distribution to multiple platforms (youtube, hulu, itunes) or social sharing (Facebook, twitter, gigya, addThis)
• Content delivery in high quality around the globe is also a profitable business.

I just returned from a transatlantic trip, where I had the misfortune of being delayed for four hours, while they replaced a valve on the left-wing engine. Wonder how I know (in excruciating detail) exactly what was wrong with the plane? the captain kept us passengers informed.

The principle of giving customers more information, even if they cannot act on it, is sound product practice. Even if I am not able to answer to  ”is there an aircraft engineer on the plane” call, I feel comforted that something is happening, and I vaguely can understand what and why.

Imagine replacing generic “error” messages with a little more information, hopefully useful. Just knowing if the problem is with connectivity, internal server state, bad configuration or software bug all have immediate next step actions you can take like calling support and alerting them to the bug, giving relevant information.

Even if you cannot take action upon getting the error message, there are other messages conveyed by giving more information:

• “We know what we are doing”: we are on top of the situation, we have a probable diagnostic, and we are working to fix this, you are in good hands. Sharing a bit more info allows for instilling confidence in the other side.
• “We trust you, we are working with you”: We are not isolating you but rather doing the opposite – including you as a viewer to our problem solving process.
• “There is a deep reason, this is not a triviality”: We are sharing the tech details with you, not to confuse, but to explain. Share these in simple English and be truthful, to gain your customers trust.

I was still unhappy about the delay, but being able to understand the cause relieved a some of the feelings accompanied with waiting.

Insomnia

As I prepare for a great video event next week, I am constantly reminded why I like video. Out of all the industries I had the good fortune to take a part of, video remains more of an art form than a science.

Before you jump: yes, video delivery, video performance and even viewer analytics are pretty deterministic. But there are deep questions core to this industry:

• What is exactly a “great video experience”?

• How do you know if the video was relevant to the user?

• Can you unlock what makes a video viral?

• So, can we detect patterns in video usage?

The above so far  attempts to highlight characteristics that, in my opinion, are key to great video. The next step in the puzzle would be to be able to create a repeatable process. Is that even possible, or is this an art form? can we take the video performance, the video relevance ranking, the length watched and the number of views and build a process to make sure that viewers are loving it, and sharing the joy?

Working together

I recently came across a LinkedIn survey asking the  above question – what is the most important qualification for a product manager. Curiously, the answers were:

• Energy and Passion
• Visionary
• Demonstrate Leadership
• Multitasking
• Problem Solving

Granted, all of the above are great qualities for any employee, especially a leader in a cross functional organization (like most product managers are). Having hired and nurtured product managers, and doing product management for over a decade, there is one missing element screaming out to me from this posting: Being able to differentiate between the must-haves and the nice-to-haves. That is what I look for in new hires.

To explain: often, in product management, it is a matter of doing more with less. While a great team of engineers can churn out remarkable products very quickly, once the first release is out there, you have to constantly struggle between: support(solving bugs), sales support(those one-off features to close a deal) and your own vision of the product (roadmap). This is a hugely difficult struggle.

A good product manager can focus on when and where  the effort can make the greatest impact:

Is it OK to tell a customer to wait for another release, at some time in the future? You plan to have this capability at that time – but the future in software is a dynamically moving target. Your commitments, given honestly, can change with the shift of priorities or larger deals materializing.

Is it OK to postpone fixing a critical bug, if it only recreates for 1% of the customers? how about 5%, 10%? Software, at least until we solve the Alan Turing’s halting  problem, will always have bugs.  Do we need to fix everything now, can we leave known bugs with published workarounds? can we have limitations on some behaviors where the software will not behave correctly?

Is it OK to reduce content of a planned release, assuming we captured the main customer pain-points and delivered the correct value? How about minimizing the content of the release  in order to meet the target date? What’s more important – the date (we promised a release with these bug fixes at date X) or the content (this release cannot go out without this strategic feature)?

A product manager’s day is spent torn between compromises. Making the right ones makes for a great product. Consistently making the right ones, makes you a great product manager.

• Recall how the iPhone came out without cut&paste or multitasking.
• Recall how the first Kindles came out without color
• Windows 3.1 came out without (*gasp*) a TCP/IP stack (even though OS/2, Unix, Linux all had it) [Yeah,I know this is ancient history].

Like many of my colleagues, I love the conceptual idea of agile software development – forgo with the ancient ways of a long release cycle and move forward with quick bursts, course-correcting when needed. The lure, for the feature greedy product manager, is immense: you quickly “see” results, and have higher transparency into the product development cycle.

Are you also aware of the risks?

Getting “something out, quickly” (be honest, that’s the name of the game) means you draw short-term plans, even if by priority. That can mean that the “early features will get the worm”. In places where you just can’t issue partial features to customers, the early features will get completed and perfected while the features coming later into the game will remain “dark” – waiting for a later iteration before seeing the light of day.

There are distinct advantages to having the full “project plan” out, with rough estimations. Those “pesky customers” will need visibility (and sometimes commitment”) to roadmap. That means setting a date, communicating it, and sticking to it. If the capabilities being developed are complex (i.e. can be sold for a high margin) they cannot really be perfected in a matter of weeks, and need to be placed on a calendar. Good plans will need estimations (rough as they may be before starting to code). Good estimations will require good, detailed, product specifications and good end-to-end product specifications will require time.

On the other hand, the situation where  all knowledge needed for development, including customer requirements, is available beforehand is rare. In the real world you want to get a certain capability out there, and quickly. You (and your customers) are not always sure of the finer details of the capability. Very often, the capability can be sold before both parties realize the full extent of the project. Even more often, it is very worthwhile getting real world traction with initial products and expanding where you can effectively benefit from the 20/80 rule.

For me, it’s all about value to the customer: if the customer can rarely upgrade, and needs the product down per spec (imaging an on-premise university system you can upgrade only during summer break) – be wary of cutting corners the agile way. However, if the customer is a SaaS user, and you can benefit from iterating, measuring customer behavior – by all means get results out there, quickly, and iterate.

I have worked in “main train release” companies – where the release is once every 18 months, and installation is on-premise. I also participated in wild startups where the releases came twice a month. One last thing – agile is usually more fun, too!

I love the “big data” trend: the possibilities of  being able to fully collect and analyze user behavior are tremendous.

However, we must not take the human factor out of the equation. Big data is not all intelligent algorithms tirelessly seeking connections – Humans are very much the key part – the part of interpretation and translation of the results into real-world meaning. Even more – the dark charm of statistics can very easily cause us to forget the “real world” meanings and arrive very quickly at very wrong conclusions.

A well-known example is “Simpson’s Paradox“, aptly named after its discoverer Udny Yule . The phenomena basically states that is it very easy to fall into the wrong conclusion if you group different samples without looking for causality in the same time.

A few easy examples are in the Wikipedia entry, and in Product Management we actually encounter similar effects all the time, when performing A/B testing or when observing user behavior.

A recent example came across when I was alerted to strange behavior at a customer site, where the admins could not figure out why certain media content was far more popular than other content. We spent hours digging through web site analytics, building funnels for in and out flows, and wracking our brains.

Finally, we discovered that on certain conditions, the video player loads slowly. So slowly in fact, that users simple abandoned the page before the video even started player. This caused a dent in the data, totally unrelated to the actual media content, the page styling, etc cetera.

Being able to track all possible conditions, and all possible analytics, creates a huge pile of data. Machines  will help sorting through it, and will present possible correlations, but it is up to the human at the helm to use common sense and rule out the irrelevant correlations, and dig for more inputs (e.g. video player load time) when the results are not satisfactory.

Be aware of the “lurking variables” and use intuition and imagination to flush them out.

Finally, an example on a related topic, of how being presented with numbers can drive perception, even if the whole picture is not revealed. From the Washington Post: Gas prices are indeed soaring… until you take into account the (not-so-lurking) variable of inflation.

When running a complex SaaS, in today’s world, an expected part of the service is detailed analytics that provide customers with the ROI of the subscription to your platform.

But you should not focus on customer-facing analytics alone. Even if improved service analytics and monitoring don’t result in improved cash flow, that does not mean they should be de-prioritized. Being able to stay ahead of every aspect of your service, provides valuable business and operating intelligence on many levels:

I’ve written before about how monitoring customers use can result in an improved product. But that is just one (important!) aspect of the overall picture. Another aspect, paramount to your own operating expenses, is the service infrastructure and how it is used: what is the consumption rate of the SaaS base infrastructure? these are usually the three elements of Iron, Silicon and Glass – otherwise known as Storage, CPU and networking. Most SaaS providers pay for these, either as their own OPEX (renting) or buying their own (CAPEX) and monitoring usage will allow predicting expenses as well as optimizing.

Another important aspect is performance – which should be monitored daily and must include alerts when the performance drops below a threshold. Performance means different things to customers and engineering. For customers – it can be responsiveness of the web pages, while for engineering, this can be the CPU load a in the database cluster. The two are related, but should be monitored independently – to expose other mission critical elements often overlooked (runaway third party JavaScript anyone?). Keep in mind the huge advantage of Saas – when customers call to complain about “lag” – you can have the tools at your disposal to immediately detect the root cause. Even better – you don’t need to wait by the phone – you can be proactive.

Finally, keep in mind that monitoring, analytics and customer facing reports/SLA are not a “feature” but a continuous process. Reporting, both internal and external, should be in the core of every feature added. In addition, benchmarks should be set for the service and periodically updated (taking advantage of plummeting prices and moore’s law)

Recent news tell the story of the FBI’s rules targeted at securing and governing cloud providers servicing federal institutions.

It appears that the rules include clearing all administrators who may have access to sensitive information. That is understandable – but why does this problem exist?

Even if your data is physically hosted offsite, the technology exists to make it inaccessible to anyone without the right encryption keys. This level of security must be built-in to any system – and surprisingly – it is not being debated.

While I can encrypt my personal hard drive to my hearts content, most communication providers keep the information out there for anyone with the right level of access to retrieve – be it email, CRM or anything else. One has to ponder why?

If I am a paying subscriber, the equivalent of “full disk encryption” should be available to me. There are reasonable options for making backups in a secured way, and processes can be instituted for having a “master-key”

Once the above precautions are in place, the focus should not be on where the data is – the data itself will be a useless pile of bytes without the correct key. The focus and attention should be on who has the keys, and how are those secured. Keys are easier to control, replace and secure.

Going down this path should eliminate the very real worry of misconduct by people with administrative access, and provide policy makers with a sound solution.

Let’s update those policies people! - At least after that, we can stop worrying about the cleaning staff, and others.

A recent conversation brought to light a common misconception that should be the forefront of every product manager when coming to set pricing – however you charge for your product, it must be tied to the value you are bringing to the customer.

A simple example – in SaaS services, it is easy to fall into the concept of charging “per user”. This is expected and valid. However, if (for a large organization) you charge per user while the same value can be gained from a single user shared among several different people – and the target is missed.

Social capabilities , per user customized reports and hierarchical user management  are all features which contribute to per-user value. These will allow the customer to understand the value of purchasing in bulk and will shift the discussion from “let’s save a buck” to “I see the value in every user having access”.

How do you apply this concept in the world of backend, or B2B services, where the service is not consumer facing?

Well, consider how your customers employ your capabilities – for example, what differentiates a large customer from a small customer:

• Is it by the number of assets stored on the system?
• Is it by the amount of customization?
• Maybe it is by the frequency of use?

All of the above are measurable, can translate into dollar value and can be used to keep both you and the customer focused on the value (and joy!) of using your product.