Sympathetic Developers - Good thing for everyone

Most developers live shielded lives away from customers and users. They're typically heads down in their own piece of the puzzle and rarely do they actually have a chance to use the product as their intended users would. Their interaction is limited to other developers and product management. Every so often, when things get really critical with a support case, they may get pulled in to resolve an issue but they're still very protected and are not exposed to customers directly.

While you can argue that it's not their job to interact with customers directly and they should indeed focus on their piece of the puzzle, this would only serve to limit developers' appreciation for customer needs (and pain) and how the product is actually used (or not used). A little direct exposure to the front line can only serve to help them grow to a more well rounded contributor. You may also find that some direct customer contact can help your developers be more empathetic with your support and services staff too.

So how do you get your engineering team enough direct exposure without totally disrupting your product development?

I would recommend 2 different approaches.

1. Create a program where by each developer will spend 2 weeks (1 week every 6 months) a year in either a support or services role. During this time, they are fully immersed in the role they're taking and responsible for any and all customer interaction that the job entails from logging new incidents to working with engineering to resolve issues to communicating with the customer. It may be hard at first for some and they may resist it but they'll eventually see the light.
2. Make 5-10% of the compensation dependent on overall customer satisfaction. Satisfaction starts with a quality product so why not have a portion of an engineer's compensation based on it. To make this happen, you need to put in a process where by you solicit feedback and rate customer satisfaction as objectively as possible (i.e. forget all the marketing on your external web page).  You can use a combination of data collected from logged incidents to periodic surveys to determine level of satisfaction at any given time period and with specific product releases. I would actually recommend creating an active dashboard using (preferably) a cloud-based analytics solution (Try GoodData) and display it some where your engineering team (and the rest of the company) sees it every day. 

Familiar Excuse: It works as designed.

You get a long awaited product release and dive right in to find the feature you were most interested in only to find utter disappointment. The feature is there but it doesn't quite work as it should. It's either entirely useless or requires a workaround right from the get go which is absurd.

You walk down the aisle to talk to the developer to see what's going on but you find a defensive developer that gives you the familiar (and illogical) "it works as designed" excuse. Well, the design had a BUG that no one caught! The developer probably realizes (you hope) that there is a genuine issue but instead of owning up to it, he/she directs you to the product manager responsible for the feature. Well, the PM gives you a more tactful answer by telling you that what you're asking for should be filed as an enhancement that YOU should file and they will work on including it in some future release (not patch) depending on the level of effort and timing. So, a new feature sits there useless till some future release for it to actually be useful and work. Who signed off on that?!

There are such things as design bugs and should be addressed with the same sense of urgency as coding errors, asap. The ownership falls with product management and engineering both to make sure function/features make sense and actually work. If in doubt, ask your customers. I'd rather a feature be delayed and work right then be released and require an immediate workaround.

Integrating Google Contacts with Your Enterprise App for better UX

Integrating Google Contacts with your enterprise application can be more challenging than you'd think but it's critical to a better user experience.

To keep a consistent level of data quality across your contact, consider selecting an application like your CRM (e.g. Salesforce) as your "system of record" and create a one way integration to Google Contacts.

Google Contacts doesn't have the notion of a common enterprise level object which can be uniformly extended by adding custom fields. It also doesn't support data validation rules to enforce consistent data quality across the enterprise. Custom fields are supported but through "free form" key/value pairs called Extended Properties. It's up to you to maintain consistency and data quality.

• When creating a contact through the API, you can add any number of Extended Properties but make sure that Keys are consistently named.
• To Make the UX better, provide a Google Gadget that will allow users to directly update or create (enterprise) contacts. The Gadget will update the enterprise app's contact which in turn will trigger the sync with Google Contacts. You can place small Gadgets in the main Mail page.
• Google's premium editions provides a Shared Contact feature which is equivalent to a Global Address Book. It's much easier to sync all enterprise data with this list vs. trying to sync with every user's Contact list.

Google, are you serious about Enterprise Apps or not?

I'm not seeing any significant improvements to Google's basic enterprise applications namely, Mail, Contacts, Calendar, and Documents. They started fast and heavy building out the features or buying companies with existing products but lately, it seems they're in almost maintenance mode. They're far from done and still (way) behind Microsoft Office. So, what gives?

I host my own domain (standard) on Google and use it for personal needs. I love the Calendar app, the sharing features in Calendar and Documents, and the corresponding apps for my Android phone (wish my iPad had the same apps).  There's enough functionality to satisfy me "the consumer" but not me "the enterprise user". 

For the enterprise, I look at every application from 2 perspectives, UI and API. You need both for a great UX. Users want a great UI and all their apps to work seamlessly together. Google's UI is improving, albeit slowly, but their APIs have stalled. There hasn't been any new versions in over a year now. The APIs were just OK to begin with so you'd expect to see a ton of improvements. Better support for structured data and a usable search capability are just a couple that come to mind. Can you believe that you still cannot search contacts using name, email, or phone #?

I like the idea of hiring a team to develop an application they've never built before. They're not bound by previous experiences so they can create a new (and hopefully better) experience.  BUT, at some point you'll need to hire some folks with experience to complement the team and build out the features users need. 

Are you developing API for your APIs (API4API)?

Huh!? Enabling automation of API consumption and adapting to application changes will play a crucial role in your API adoption. It's great to have your API's documented but it would even be greater if you allowed your API (metadata) to be introspected programmatically.

The new trend in applications (and API) is all about on-demand and self-service. Web 2.0 (Cloud) applications are more adaptable and powerful. Being able to integrate applications quickly will be key to their success. If you're only providing hard-coded documentation, then you're a speed bump to your application's success.

Exposing a set of standard metadata API for your APIs will allow developers to build tools to auto-magically consume your APIs and keep up with changes much more efficiently. Integration tool vendors often write connectors for applications which allows them to expose the various API in a standard way in their tools. Customers then use those tools to build out their integrations without having to worry about the low level details of every API call they plan to use. If you expose a standard set of APIs that would allow these tools to auto-discover your APIs and auto-react to changes in your application schema and services, your API consumers will love you for it!

When WSDLs were created, every one cheered for the fact that there was a standard way to describe interfaces. You can programmatically consume it and the very least, create stubs to provide/consume the service. It made getting started easier. Unfortunately, most implementation that I encountered only offered statically generated WSDLs that either only changed when the application was upgraded or required frequent exporting/importing to capture on-demand customizations. Painful at best. Now we have REST-ful services which are easier(?) to consume but you 1st have to read the often lengthy documentation to get started. I don't see anyone running to support WADL (WSDL equivalent for Rest-ful services). Do we need another static interface definition?

Forget WSDLs and WADLs! I propose, we create a standard metadata API for APIs (API4API). The key is to keep it simple so it will be adopted. All it needs to do is to describe objects and services you're planning to expose. For every service, defines the inputs and outputs. If you add more objects or services, a simple call would reveal them. It should also indicate the Authentication methods that are supported (e.g. Basic Auth, OAuth).

If your applications are evolving, If your application are customizable, then you need to give developers the ability to create dynamic integrations to keep up. 

Why Yammer can't compete with Chatter!

Security! I'm not talking about general privacy and security that all SaaS vendors provide like SSL, data center security, etc. I'm referring to much more granular level of data access control which is defined and controlled at the enterprise application layer. Most companies want to control data that their users access. Take a SFA system as an example. You typically see policies that allow sales reps to  see information about their own accounts and opportunities (only), sales managers to see data belonging to their teams, regional managers within their region, ... so on and so forth. So, you'd only want your users to see Enterprise "Tweets" that they should see.

Independent Enterprise Social Networking services, like Yammer, lack visibility into external system data and the data access control policies in those systems to control who should see what. Sure you can create logical groups and confine private posts to those in the group. You can even integrate in SAP, Salesforce, Oracle EBS, etc. as members of a group but you're still not going to know which specific data updates some one should have access to, at least not very easily and not without external and custom code.

Application administrators go to great lengths to set access control rules so it would be great if the Enterprise Social Networking service could enforce those same rules. Unfortunately, they really can't. First,  they would need access to the rules which is not easy to come by (not their fault). Second, they'd need a standard way of defining the external application objects and access control rules which doesn't exist today (again, not their fault). 

Chatter has an unfair advantage by being native to Salesforce. The same data access control rules you configure for your objects are also valid for Chatter feeds. Users can only subscribe to data that they have access to. No additional work required! However, Chatter will the have the same limitations as Yammer when it comes to data objects external to Saleforce. Salesforce does provide for the flexibility of adding custom objects and associated access control rules but you'll then need to make sure you synchronize the data with your custom object(s).

I'd say that CubeTree's sale to SuccessFactors was certainly a good move on their part. Once they're integrated into SuccessFactors, they'll be in the same position as Chatter but for HR related data objects contained within SF modules.

I hope you don't take this as a beat down on Yammer and like services but when it comes to Enterprise Social Networking, they're going to lack the necessary controls to be widely adopted.

Salesforce.com Chatter: Tips for Integrating External Enterprise Events

Integrating external events can be very straightforward (from Salesforce.com's perspective). Here are a few tips to help get you going quickly.

1. Every parent object in Saleforce is Chatter Feed enabled. By default, the standard objects have been configured to create Chatter events (or feeds) as result of creates and updates (of certain key fields). To make changes, go to Setup>Customize>Chatter>Feed Tracking. You can configure feed tracking for each object (custom included) to track changes to standard and custom fields. For more information, check out this link.

2. Any existing external data integration into Salesforce can instantly be Chatter enabled. Simply go to the feed tracking page for the object of interest and enable tracking for the fields you're updating.

3. For child objects like the Opportunity Line Items, you'll notice that there's no feed tracking capability. This makes sense as you would typically want to track an Opportunity as a whole and not just individual line items. If you're updating the line items with external data such as a "Ship Date" from your ERP, add an extra step to your process to create a Chatter Feed post for the line item's parent opportunity. It's a simple Create call to add a single record to the FeedPost object.

4. Avoid creating additional custom objects and synchronizing external data if all you're interested is being notified of updates from your external applications. It not only creates more work to create and maintain the integrations, it will also require users to subscribe to additional data objects. If you only need to present data from the external systems to the users, consider building a quick mashup instead.

5. Avoid creating a User Update or Post on behalf of an external system as it will potentially bypass the security rules you have in place and may expose sensitive data to your entire org. Since users can only subscribe to Chatter events for data they have access to, it would be a best practice to create feed posts associated with specific data objects.