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.

A recent local campaign for a newspaper classifieds claims that “many people will see your status and click “like” – but when you want to sell – publish with us” (I’m paraphrasing, and will appreciate a link).

Will Facebook ads work for a private person trying to sell a real commodity? in this case, a swanky apartment in the south end of the central region of Israel? As the real estate market was down, I set forth to find out.

Opening a Facebook Ads account is remarkably easy. They accept international credit cards, and placing the ad took place without a hitch.

Narrowing the focus to bid only on relevant population was scary easy as well.
As a landing page for this ad, I chose a custom-built WordPress.com site: easy to create, has excellent analytics and it is free. The analytics enabled me to track which Ad worked by following how people navigated the site.

Facebook adds detailed analytics of its own:

• I learned that my apartment was extremely popular with people from Jerusalem (a new trend?)
• Young couples from Tel Aviv (confirming theories of young families vacating that city).
• I got slightly better conversion with women than men (taking care of the home?).

Some top-level results: The Ad was exposed on Facebook almost half a million times, and I got 87 clicks – bringing me to a 0.0019% CTR. My cost, per click, was $0.36.

To perform a controlled experiment, I decided to publish on twitter, Facebook, google+ and even LinkedIn as well: The site got 256 hits from those social networks. So – social postings trumped the for-pay ads.
However, while more than 300 people browsed the site, very few went to the “how much” page – internal conversion stood at ~30%

Eventually, the very nice couple who now own the apartment actually saw the ad on a traditional online classifieds – bringing the win to the “old-fashioned” classifieds.

to conclude:

• Facebook ads are a great, easy to use product.
• Reaching out to your own social network is better. I finally am starting to see the logic in all those “shop with your friends” startups.
• At least in Israel, people are very much inclined to use regular, old-fashioned, classified ads (maybe even in a newspaper?) that industry is not dead yet.
• In my case – I had one property, and needed one customer, the game changes greatly when you need to reach multitudes of customers
• Getting out of the game of real estate in these unstable times is a relief.

A few social networks

Do you have a social strategy for your product?

“The world is becoming more social!” “users want to interact with peers!” “it’s the new age of web 2.o!” – if these topics have been circulating the watercooler, beware.

Before jumping in and adding that “person” entity, implementing a “feed”, allowing people to put each other in “circles” and post on “walls” – lets pause for a sec:

There is only one Facebook, there is only one twitter, and one shubiduba (or whatever the next thing will be). You can aspire to  become the next social app: but keep in mind that is a goal in itself. If your goal is a new level of engagement or attracting more users – lets consider. We have quite enough of “social” apps, and you don’t have to take my word for it – others say it better.

Consider first what you want to accomplish – usually it is not taking ownership of the users social graph. Quite likely, the user will not be very agreeable to importing it to your site without significant motivation. Case in point – Apple iTunes Ping - not a huge success..

Better discoverability, however, has a lower threshold and can be accomplished by tying into the user’s existing Facebook, twitter, google+, yammer or whatever other social apps. That way, users will win (getting the feedback of their peers) and you will gain access to the social graph, without needing to enter the battle to own it.

Ratings and comments on user content can also be accomplished either as an integration or internally – consider the pros and cons of either. Owning “comments” has the implication of jailing the commenters to your site – you may want this the other way around – publishing content to outsiders – allowing outsiders a sneak peek - and a subscribe button.

So before you jump ahead and develop your own feed – consider integrating with the assets the user already has, even if they are owned by external parties.

This post is instigated by Adobe discontinuing mobile Flash. With this move, Adobe did one of the bravest, most difficult moves a company can do: venturing away from a safe market and into an uncharted future. It is also clear this move affects every one - it will dictate how video and all other rich content will be consumed on the mobile web.

There are many reasons why flash failed, and many opportunities going forward with new technology. Lets focus on the innate conflict  relevant in other cases as well: the break with backward compatibility and an existing customer base in order to move forward with a new technology.

One of the issues faced by Adobe was the fact that there were many Flash Players in the wild, and Adobe had to maintain backward compatibility. In my mind, this held them up from offering new technologies  (e.g. GPU access) to all platforms, and that held the platform back.

When looking at a mature product, with a large installed base, and deciding on new features, you have to keep the same lesson learned in mind: “do I make another ‘add-on’ to my product, or is it time to break away and consider something new”. For example:

• Do you really need the mobile version to offer the same functionality as the desktop version? are these the same use cases?
• Do users consume content the same way on phones, tables, PCs and television? is it a “one app to rule them all” game, or is it a different flavor for each platform?
• Do different verticals need the same UI/UX, or does each of your verticals care about different aspects, maybe offer different products to them, maybe even integrate with their existing platform, and not force them to learn a new paradigm

Server Rack by Kusumsiri, on Flickr

So you have a successful SaaS business, and you come across that first customer who has a unique security need, demanding an “On Premise” version of your product. Before you start off that path, a few important things to consider:

You may say that today’s world is shifting towards SaaS, and you may point at SalesForce.com as the flag bearer, saying that if companies trust the cloud with sensitive data such as their leads, contracts and customer database, that On Premise is a thing of the past. Well, surprisingly, even the mighty SalesForce maintains an On Premise version (and they seem unhappy about the cost).

Having an On-Premise solution is much more than the sum of the parts: Sure, you can package the software today running in your datacenter, slap on an installer, and you are done. Or are you really?

A few of my past companies were “pure” On Premise companies, in the security area. I recall how the person in charge of hotfixes in Check Point is allowed to bring the entire R&D to a halt for when an urgent security-related patch for a release dated three years back is needed. In fact, every R&D plan included time allotted to developing cumulative hot fixes. The organization dedicated to packaging these (apart from the usual R&D) was sizable, and included dedicated QA.

Each instance of that On Premise package actually incurs debt. Debt in the form of customers expecting upgrades. Most SaaS companies update their software very frequently, but those updates are different from the world of On Premise customers. Consider cumulative patches, support for several past major releases, zero-downtime upgrades, monitoring and administration, training for support personnel – these imply a huge investment in creating operations and R&D organizations.

On thing that worked well for many companies is the appliance idea. Most software began as an installer package. Packaging in a big beige (or black) box actually works better, since you can control the entire configuration of the machine, including RAM/Disk/Motherboard and even the make of the network interfaces – avoiding driver hell. Nowadays, with the virtual appliance, there is no need to support a complex shipping operation.

So, what to do?

• Make sure that customers have an inventive to buy the SaaS package. Pricing is everything.
• Communicate the expected upgrade/patch cycle.
• Communicate the investment the customer must make in terms of manpower to support the shiny new server(s) in their data center. You can charge for “support services” but remember to require remote access.
• Work as hard as possible on a standard package, preferably an appliance. Having a standard solution means standardized upgrades, easier installations and less overhead.
• Remember the hidden costs, prepare for them and build the proper organizations to properly bear these costs.

Product Owner

For many organizations, most especially ones that are project driven, or just any company with customers    – the product manager becomes the epicenter for many decisions regarding the product, much like the CEO with regards to decisions at the company level. The product manager assumes all responsibility for feature completeness (and sometimes, timely delivery) and often has to struggle for funding (R&D time) sales (getting management to agree on a feature) – much like a CEO.

Much like “feature ownership” described by my good friend Ophir, ownership implies passion, excitement and a burning desire to make sure all ends are met. What I want, nay – need, from a product manager is that glint in the eye when he speaks about the product, that detailed understanding that comes only from intimate knowledge and keeping in mind, against the odds (external influences such as customers, time constraints) all those little bits that make a product complete.

How do you foster ownership in a product team member?

First, cater to their interest – entitle the product manager with not only the responsibility but the authority to make these decisions. Make sure that the product manager is never surprised – no requirements should pass from the business to the  developers without the PM being aware. Further, the PM should be able to suggest to company executives as well as customers to wait for a different release, or a different solution. Empowering is the side of responsibility that makes it stick – you don’t want someone to blame, you want someone to take ownership. Make sure the product manager is able to define the roadmap (in line with the guidelines set by the business).

Getting good product owners, means having someone in the company whose entire focus is the product – making it whole and not just a set of requested features. How many of these are there in the company – truly?

Tune in for my next post – how product ownership drives innovation

It happens constantly, all over the world. An application is out there, usually making money, with an unassuming roadmap of features. Suddenly, there's a commotion in the engineering dept. A dev rushes in: "the code is useless! we can't find our way in this spaghetti soup! we need to rewrite!"

It’s a constant temptation, in software, to rewrite from scratch. The empty screen of the IDE calls out for every creative person. However, is it always worth it?

I recently read a provocative article on gigaom, where the same sensationalist claims are repeated: “Facebook trapped in MySQL ‘fate worse than death’” etc. etc. In reality, it seems Facebook is happy to support mysql, enhance it for their needs, and even maintain an open knowledge base of their experiences. If they can reach 750 Million subscribers, I guess that the application is very (very!) robust.

The key thing, that most people forget when coming to recode, is that the “spaghetti” is usually chock full of hard lessons learned: edge cases, weird configurations, support for some specific customer deals, etc. Removing those (and no, they will never be documented well) will cost those hard-earned lessons – which will have to be relearned.

There are, on the other side, good things to be said about re-coding once the requirements is clearer, but bear in mind that careful documentation of the existing assests is mandatory. And maybe, just maybe – proceed with caution? baby steps.. refactor only specific modules, and always, always, contain the scope of the project.

Packaging for the iPhone 4

This is why, when I got the device, I was surprised at the way the (forever nameless, unless you have sharp eyesight) telco decided to package it:

iPhone 4 box, you're not doing it right

Starting by covering the image of the product itself with a radiation and roaming charges warning (4) through covering the apple logo with a bar-code label, applying an unnecessary sticker to keep the box shut(2) and topping it all off with a scary RFID sticker shaped like an orange eye with a foreboding dark pupil(1).

Apple will probably spank these folk, but the point is more general and applies to your product management efforts: When launching any kind of product, make sure to give thought to packaging.

In software products, this means that not only the downloadable should be there, but also consider what happens after download: the instructions, the support methods, the quick start guide – the works. Make sure customers know the benefits if it is an upgrade, and how to get access to those benefits.

In SaaS, make sure to communicate new capabilities not just by email, but by visibly highlighting the change. Some people will figure it out, but you want them to actually use your product. Moreover, you want them to use it right.

Examples to doing this right are abundant, I find the best practices are:

• Making the installation part painless (a non-issue in SaaS) – this includes not only having a downloadable, but providing a downloader for big packages, or maybe an Amazon AMI, if relevant.
• Highlighting the new stuff : a what’s new pop-up is always nice, actually providing some animation to instruct people along is even cooler.
• Monitoring afterwards – make sure people actually use the capabilities, and if not, try to understand why.

As for me – the wife is happy with the new toy and I am using the best in breed smartphone available today

Most places have clear regulations about how and where exit signs should be posted.(and apparently, there’s a company for that, too). The same should apply to your SaaS subscribers: you should not be vague about how people can unsubscribe.

Hubris aside, some people will pay for a term, and then decide the subscription is not for them. For those people, be kind and clearly mark the way to gracefully depart. It makes sense and is good business to be fair and treat your customers with respect by allowing them to painlessly unsubscribe. This should be, of course, governed by easy to understand terms. For example, you pay in advance for one month, cancelling before the month is out incurs the full charge, and you can use the service until the month ends.

Case in point: LinkedIn.

Now, I love LinkedIn, they really nailed down how to make social networks useful and nicely monetized it. I am also an avid user.

I recently subscribed to a premium account. After a month, I decided to revert back to my free subscription. So, I headed over to the account settings:

Uri Gilad LinkedIn settings

Can you spot the unsubscribe button? There’s a golden “upgrade button”, which is fine, but no unsubscribe. After reading the entire page (lots of text!) I found the close your account link. I don’t want to close my account, and I was leery of clicking that link – but I went ahead anyway. Apparently, this takes you to a place where you can email LinkedIn support requesting to revert back to basic. They promised a 24-hour turnout and within 7 hours my account was reverted.

But still, do you really want your customers to go through all that angst?

My recommendation is to include that big, chunky, unsubscribe button in a visible place instead.