What technologies are you thankful for?

May 31, 2010

This Memorial Day, I spent some time remembering just how lucky I am to live in the United States and how the sacrifices of many others, including some people I know, have helped to make this possible.   I hope you did too.   The dedicated and brave men and women of the US military who have enabled this life that we all enjoy are certainly worthy of our respect and appreciation.

Then it occurred to me — a large number of similarly dedicated pioneers have been responsible for the technology that we use everyday — you know, the stuff that we often take for granted.   I don’t mean to imply that these technology pioneers have sacrificed anything close to what our military personnel have done.  However, a moment or two of appreciation for the efforts of our technology pioneers is appropriate — especially since some of this same technology is relied upon by our military personnel to keep themselves, and us, safe.

So, here’s a list of some of the technology that I’m thankful for (in no particular order):

  • BBN — for their work on Arpanet which eventually became the internet.
  • Xerox Labs — for their user interface and user interaction work (including the “mouse”) that established the basis for the way we use computers today
  • IBM — for defining and publishing the specifications for the Personal  Computer so that a multitude of vendors could create interchangeable parts that all worked together.
  • Intel — for all of the CPUs that have been incorporated into the countless personal computers and embedded systems.
  • Microsoft — for providing a multiple window operating system with a consistent user interface that made it easier for millions and millions of people to use computers.
  • Apple — for providing truly easy to use computers and forcing others to spend even more time improving the ease of use of their computers (and applications).
  • Cisco (and all of the other networking companies) — for providing high-speed network equipment that makes it possible (and affordable) for individual people to have high-speed access to almost everything on the internet.
  • Google (and all of the other search companies) — for making it possible for individual users to “find” almost anything.
  • HP (and other printer companies) — for making it possible for companies and individuals like me to easily and cheaply print almost anything that you could imagine.
  • Computervision (and the other early CAD companies) — who made it possible for companies to digitally design, modify, and manufacture a wide range of products much more quickly and accurately than before.
  • CJ Date (and other early relational database proponents) — who did the research that resulted in the relational database products that nearly every system that we use today rely on.
  • NASA — for developing the technology that put all of the satellites we depend on in space.

I’m sure this list is nowhere near comprehensive, but now it’s your turn.  What technologies are you thankful for because they have helped define and/or shape your life, environment, or even your profession?


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?


What type of software product is the riskiest to develop?

May 4, 2010

A number of us product management types were talking about various types of software products with the goal of identifying which type is the riskiest to develop.

To help frame our discussion, we decided to classify all software as belonging to one of 4 categories:

  • Embedded — Software that is embedded within a physical device.  For example, the code that is used within various control systems for automobiles, major appliances, cell phones, etc.
  • Desktop — Software that is installed on individual laptop or desktop computers and each copy is used by an individual.  For example,  anti-virus utilities, word processors, spreadsheets, web browsers, and personal database products.
  • Enterprise — Software that is installed at a company and is used by a number of users at that company.  For example, ERP systems, PLM (product life cycle management) systems, multi-user database systems, and web servers.
  • SaaS — Software that is offered by a provider as a service to multiple users from multiple companies.  For example, sales force automation services, ERP services, medical trial monitoring services, and PLM services.

Then we asked the following question…. “If a major software product from each of these categories experienced a significant failure, which type of software would pose the greatest risk to its customers?”  Or if you prefer, “Which type of software is the riskiest to develop?”

Embedded software is very difficult to update / repair once it is in the hands of the consumer.  And because it does not contain the same sort of user interfaces as other software types, it can be more difficult to troubleshoot.   Thus, if your PDA locks up when your address book has too many entries — your only remedy is to reboot your device, try to avoid the problem, or acquire a replacement device.  However, if your automobile were to accelerate out of control due to an error in the throttle control systems — you, your passengers, and others around you could be endangered.

Desktop software is used on an individual basis.  And unfortunately for most over-worked IT staffs, individual users often upgrade or customize the software that they are provided to meet their own needs.  As a result, if a particular software revision or update fails, only those users who have installed that software are affected and they can often revert to a previous version.

Enterprise software affects all of the people at a company who are using it.  Thus a failure can severely impact the company’s ability to perform its business.   I remember a situation years ago where an automobile manufacturer was carefully monitoring an upgrade to their enterprise PLM system because any failure could have halted production in their manufacturing plants and sent thousands of workers home.

Software-as-a-Service software is typically provided to users from multiple companies.  Thus, any failure could severely impact the ability of multiple companies to perform their business.

So, here are our conclusions as to the riskiest software to develop, in rank order:

  1. Embedded Software — because a failure could result in injury or death to users of our products, which would be very difficult for our company to handle and recover from.
  2. Software-as-a-Service — because a failure could affect multiple companies, including some companies that we might never know were impacted until after they failed to renew their services contract.
  3. Enterprise — because a failure could impact the business of an entire company.  The short-term impact could be mitigated through high-level corporate support and aggressive fire-fighting, but our company would still need to apply additional longer term efforts to repair its relationship with each affected company.
  4. Desktop — because individual users could uninstall the latest update or revision and continue using the previous version of the software.  The impact to the company would depend on how widely used the faulty version was and how much individual users depended on it.   However, it is unlikely that the company’s business would be severely affected or that lives might be lost.

So what do you think?  Have we categorized software correctly?   And if so, do you agree with our rankings?

%d bloggers like this: