Do we finally have the ability to have true “international” products?

May 24, 2010

Did you see the recent article about Google making its real-time translation tool available for the Android phone?  If not, you can read it here.

While this implementation will undoubtedly be fun for a number of cell phone users, imagine the impact if a number of enterprise software companies incorporate this technology into their products.

We have long talked about “localized” software products that are available in a number of single languages.  In other words, users in France interact with the software in their native language — French.   We also talk about “internationalized” software products that display numbers and other elements using the format that is appropriate for each user — which is important when users from different locales are sharing the same application.

However, we have not yet seen applications where free-form text entered by one user in one language can be read and understood by another user in a different language.  Google’s tool offers the promise of this capability.

Granted, any “automatic translation” tool will have problems in accurately conveying the content, context, and subtleties of a language.  And I suspect this problem will be especially difficult when translating between languages that have different origins (for example, English and Japanese).   However, as more applications incorporate this type of technology, more investment (and resulting technology improvements) will follow.

Consider the following situations where this technology would literally “change the rules”:

  • PDM, PLM, ERP Systems — Product descriptions, instructions to suppliers, questions on design intent from part manufacturers, etc.  In today’s global environment where a supply chain may include companies in multiple locales, the ability for each member of your supply chain to communicate in their language could significantly improve your ability to design and produce quality parts.  It also makes it easier for you to find additional suppliers because they no longer have to communicate in your language.
  • Twitter, Blogs, and Other Social Media Tools — You could interact with customers and potential customers in their language.  This would allow you to review a product idea with potential customers in a wide variety of locales and thus avoid problems like giving your new product a name that means “toilet” in another language.  And wouldn’t you like to know whether a product is interesting to a particular locale before you pay to translate the product’s screens, documentation, marketing, and sales materials into that language?  I know I would.
  • CRM and Other Customer Feedback Tools — As with the social media tools, imagine how much your customer service might improve if you could actually exchange information with your current customers in their language.  Today, companies rely on small teams of customer support specialists with multiple language skills.  However, this approach can introduce another layer of “interpretation” between the customer who is describing the problem and the Development engineer who has to fix it — which increases the difficulty (and cost) of providing timely bug fixes.  How much could you improve your service and reduce your costs if reliable and accurate real-time language conversion was available?

There are many other categories of commercial (and even military) applications that could benefit from this technology.  What is your favorite?  Or perhaps this problem is too complicated to be solved by any technology, even one from the guru’s at Google.   What do you think?


Is a Product Manager responsible for preventing corporate identity theft?

May 19, 2010

As product managers, we are responsible for identifying and prioritizing the features for our products.  Then we spend time with Development to create new capabilities and with Marketing, Sales, and customers extolling the benefits that these capabilities will provide.

One of our key assumptions is that each new capability is valuable to some (and hopefully, all) of our customers and potential customers.

However, in today’s litigious environment, shouldn’t product managers also be concerned with protecting their own company?

In an enterprise software application, a wide variety of users perform various functions, including many that could expose their company to risks.  For example, new product designs are reviewed and approved in Product Lifecycle Management or PLM systems,  raw materials are acquired in ERP systems, and confidential legal matters are managed and reviewed in document management systems.

Each of these systems have one thing in common — it is possible for an “authorized user” to perform an action that could put their company in a compromising situation.  And if someone has stolen this user’s identity and a terrible situation results — do you think that they will attempt to hold the enterprise software vendor responsible?

Of course they will.

If today’s legal system allows the manufacturer to be held liable when someone falls off the top of one of their step ladders, it will be easy to hold the enterprise software company responsible when the strategy of a defense team in a high-profile legal matter is downloaded and released to the public by someone who guessed the lead counsel’s password.

And what about a situation where a new part in an automobile is approved by a well-meaning administrative assistant who misunderstood which part their boss said to approve.  When this approved part is later discovered to be faulty and results in the deaths of a number of people, don’t you think that the company will complain that it was “too easy” for the assistant to pretend to be her boss and that the software should have done a better job of detecting and preventing this action?   Unfortunately, the answer is probably “yes”.

Thus, I believe Product Management needs to expand the criteria that we use to evaluate potential product capabilities, as follows:

  1. Riskiness — Capabilities that the product absolutely must have to protect the viability of “our” company.
  2. Must Have — Capabilities that the product must have in order to be effective in the market place.
  3. Should Have — Capabilities that the product should have, but are not required.
  4. Nice to Have — Capabilities that we would like to have, but are not required.

This approach will result in more time being spent resolving “Risk” issues and less time on user-visible features that could generate revenue — which could also threaten the continued existence of the software company.  Oh joy!!   Yet another trade-off for Product Management to balance.

So, what do you think?  Does this topic ever come up in your product planning?  Or does your company depend on the fine print of your license agreements to protect itself?

What UI characteristics are necessary when adding functionality to an existing product?

May 13, 2010

I happened across my copy of “The Design of Everyday Things” the other day while I was helping a client specify how to add new functionality to their existing product.

As I browsed through some of the key sections of this book again, I got to thinking — What user interface (UI) characteristics are necessary when adding functionality to an existing product?

First, let’s establish a couple of obvious assumptions:

  1. Appropriate Functionality — We’ll assume that the new functionality actually addresses a real need or requirement.  Otherwise, it wouldn’t (or shouldn’t) be added in the first place.
  2. Appropriate Performance — We’ll assume that the new functionality will perform about the same as the rest of the existing functionality.  It wouldn’t make sense to add a new function that was extremely slower than the rest of the application because nobody would use it.  And if you added new functionality that was extremely faster, the rest of the application would suffer by comparison.

Now, let’s define the necessary characteristics for the UI for our new functionality:

  • Must Fit — The new functionality must” fit” into the existing product.   In other words, users should not be able to tell where the existing functionality ends and the newly added functionality begins.  So, even if the rest of the product has got a horribly ugly color scheme that you’ve been dying to change, don’t change it only for that new button that you just added.
  • Intuitive — The new functionality must be intuitive to use.  We often assume that our users are very sophisticated and understand completely every button, menu choice, and operation.  Thus, we often don’t think twice about adding new functionality that only our most experienced users will understand (or appreciate).  However, the goal should be to drive down the level of knowledge required to use our products so that more users, including those that only use our products infrequently, can benefit from the functionality that we are providing.   Repeat after me:  “If you have more users, you usually have more revenue, which is a good thing.”
  • Multiple Paths — The new functionality must be accessible through multiple paths, or sequences of steps.   We sometimes assume that all users will only use a particular function in a specific sequence.  For example, we might assume that the user “Saves their work and then Exits”.   So if the user decides to “Exit” first, should their latest work be lost?  Of course not.  We should detect that they have not saved their work and prompt them.  This simple example illustrates the importance of allowing users to perform each new function in variety of ways and in a number of different sequences whenever it is possible.

Each of these characteristics seem pretty clear (and somewhat obvious) to me.  So, why is it that too many of the software products that we use everyday continue to violate these fundamental concepts?   Is it a question of laziness or do we simply lack the resources to do something right, so we band-aid something together quickly with the idea of fixing it later and “later” never comes?   Or perhaps our users have gotten so used to applications that are clunky and difficult to use, that we don’t feel the need to give them anything better.

What do you think?


%d bloggers like this: