Salesforce Shows That The Cloud Begins With The App

Blog post info and actions

Blog post body

Tom Grant

One of the face palm moments I had while researching PM's role in SaaS was the timeline for platform and app development. The traditional path for on-premise products was platform first, then application. The cloud products flip this sequence, putting the applications first, then the platform. We're so used to seeing this pattern that it's easy to take it for granted, or mistake the reasons why it exists (hence the face palm).

There were two reasons for this evolution in the natural history of a tech vendor's portfolio. The first is distance from the customer. In an on-premise world, where there's a lot of geographic and organizational distance between the producers and consumers of technology, the collection mechanisms about customer adoption (infrequent "How ya doin'?" conference calls, cryptic bug reports, etc.) are labor-intensive. For however much effort you put into this research, the information returned is often incomplete, distorted, or just plain wrong. For example, the game of Telephone played among product teams, customers, and the salespeople in between often leaves PMs with more questions than answers about what a customer really wants. 

Therefore, the product strategy for on-premise products have to accommodate a lot of uncertainty about how customers use the technology. While it's not the only reason for customization and custom application development, it's certainly an important one. Rather than guess wrong about customer adoption, on-premise vendors tend to say, "Here's a toolkit. Go build what you want."

Read more

For ISVs, Technical Debt Is A Serious Business Issue

Blog post info and actions

Blog post body

Tom Grant

When you were a child, you may have played with a paper fortune teller (a.k.a. cootie catcher). By folding and unfolding this origami-like construct, you produced answers for questions you posed.

The topic of technical debt is a lot like the paper fortune teller: the more you unfold the topic, the more interesting observations emerge. Israel Gat wrote two recent posts (click here and here) at his blog, The Agile Executive, that illustrate the sort of costs that technical debt imposes. His second post focuses on the most conspicuous cost: The more you develop, heedless of the technical debt you create, the harder and harder it becomes to make further changes. While this may seem like an obvious conclusion, it's not one that has the impact on software development that it should. In their rush into the future, building code that is supposed to expand choices, many teams are actually constraining their choices.

For ISVs, technical debt has a lot of important ramifications. Here are just a few:

  • For startups, aggressive product road maps can be counterproductive. The more you develop, the more competitive your product, right? That formula seems obvious to most insurgent vendors, but there's definitely a point of diminishing marginal returns, when the cost of maintaining all that aggressively-developed code exceeds the company's ability to continue developing and supporting it. 
Read more

Twitter: It's Like Catnip For Social Media Mavens

Blog post info and actions

Blog post body

Tom Grant

Obviously, as a regular blogger, I think social media are the cat's meow. However, when I use social media, I don't lapse into that blissed-out state that cats enjoy when they bust open a jar of catnip. Your experience may be different:

If you believe that Twitter is of net-benefit for the world, and only someone who hasn't used it much would say otherwise, then what's good for Twitter is good for the rest of us, too. Costolo's adventures with the last world-changing messaging system he [led] may have worked out better for himself than for the rest of us in the long run, but his work at Twitter so far has been key at building staying power for this new, more accessible way for people around the world to speak with each other.

That's the concluding paragraph from a ReadWriteWeb story about Twitter's new CEO. It's just the sort of gushy, overblown statement that plays well in the pocket universe of people with a vested interested in social media using social media to sign hosannas on the highest about social media. Outside the pocket universe, it's just the sort of hyperbolic prose that makes people who are on the fence about Twitter, who don't necessarily see it as good for the rest of us, nervous that anything sold that hard must not be as good as advertised. For people who still look at their email inbox with despair, Twitter may be one more channel of communication that they don't need.

Read more

A Switch And A Miss

Blog post info and actions

Blog post body

Tom Grant

You might be surprised to find out how worked up I can get about an issue like switching costs (a.k.a. lock-in). It's a question worthy of at least a little emotion, since it affects the fortunes of technology companies: Under what conditions would a customer switch to a different vendor for the same product or service?

The question has returned with a vengeance with the increased adoption of SaaS and PaaS technologies. Tech vendors are happy to use the cloud as an easy way to attract customers, as long as it doesn't turn into an equally easy way to lose customers. 

What gets my dander up is the simplistic, puerile way in which people sometimes discuss this issue, particularly in regard to SaaS implementations. Here are a couple of examples.

Cost Of Switching
How do the switching costs of an on-demand solution compare to an on-premise alternative? Clearly, the cost of switching from an on-demand solution is not zero, and yet you still find in some discussions of SaaS the assumption that customers will leave willy-nilly. Nor is the cost of switching the same as an on-premise solution, but you'll find people speaking about the two as if they presented the same migration and implementation challenges.

Read more