3 Things Every Product Manager Should Know

May 17, 2011
Wikipedia "W" Award

Image via Wikipedia

Someone asked me recently how they could determine if their product manager was doing a good job or not.

I think this is always a tricky question.  There are lots of statistics that you can use — number of new customers, percentage of retained customers, revenue, revenue versus development cost, etc. — but some of these require information that may not exist.  For example, if your company hasn’t shipped your first product yet, you can’t really determine the number of new customers or the amount of revenue.

And sometimes, you simply want a quick and dirty way to reassure yourself that your product manager is doing a good job — that they are the “winner” you hope that they are.

So I suggest that a product manager needs to know the following three things.  If they do, then they are likely doing a good job.  If not, then something needs to change…

1.  What key business problems do your target customers have?

The product manager must know who your target customers are, some of the problems that they have, and which of those business problems the customers consider to be “key” or important.

Customers (and potential customers) will always have numerous problems — but only some of them are worth solving.  Some are simply irritants that your customers have decided to live with.   Others are so overwhelming that your customers don’t have the will (or money) to attempt to solve them.

Thus, “key business problems” have 2 characteristics:

  • Your customers want to solve them, and
  • Your customers believe your product can provide at least a partial solution.

These are the problems that a good product manager will understand thoroughly and can describe clearly whenever asked.

Say you’re talking to an e-commerce prospective customer whose web site is getting too many complaints from consumers trying to purchase products.  As a result, their revenue is declining and their support call center is overwhelmed.

If you were to talk to them, they might describe their situation like this:

  1. Consumer complaints are increasing,
  2. Sales revenue is decreasing
  3. Support call times are increasing (because they have to deal with irate consumers)
  4. Ad revenue is decreasing (due to reduced click-through rates)

But all of these complaints could be symptoms of a single “key business problem” — that the time required to purchase a product through their e-commerce website is taking far too long.

A good product manager will know what the “key business problems” are and will be able to tell the difference between “symptoms” and “problems”.

2.  How is your product approaching these key business problems?

OK, you have your list of key business problems from your target customers.  And you have your product which you hope to sell (or are selling) to these customers.  Before any customer gives you some of their hard-earned money, they will want to understand how your product makes their life better by solving one or more of their key problems.

They don’t want (or need) the gory details right away — they just want to understand the approach that your product is taking and be comfortable with the limitations (or risks) associated with using your product.

Consider our example e-commerce prospective customer…  Their problems could be due to traffic delays with their ad provider, network bandwidth limitations from their ISP, performance issues in their application, the number (and quality) of the images that they display for each product, the performance of their credit card processing partner, etc, etc, etc.

Perhaps your product collects statistics by monitoring each component’s performance.  Or perhaps you add a hardware device to a customer’s network to monitor communication between servers.  Or perhaps you monitor the application’s performance using simulated web browser client sessions.

Any of these approaches could diagnose the problem(s) with this prospective customer’s e-commerce system — but each approach also has potential limitations and/or risks.

A good product manager will understand how your product is intended to solve one or more key problems, be comfortable articulating your solution approach to a wide variety of audiences, and be well-versed in handling objections about the limitations and/or risks of your product’s approach.

3.  How well (or poorly) does your product solve these key business problems?

Once you present your product concept to a potential customer, you will have some feedback on how well (or poorly) they think your product will solve their key business problems.  You will get more information each time you interact with a potential customer and even more information when a customer starts using your product.   Once you have collected information from a dozen or so customers and potential customers — some patterns will begin to emerge.

Did you identify your target customers and their key problems correctly?  Do you actually understand their key problems and why they are important to your target customers?  Does the approach of your product appeal to them?  Do they think that your product can actually help them?  How well does your product actually help them?

If your product manager knows the answers to these questions — and a bunch more just like them — then your product manager can easily tell you how well (or poorly) your product solves the key business problems of your target customers.

Or put differently, a good product manager can tell you whether your product is likely to be successful or not in the marketplace and where your product needs to be improved to attract a larger share of the market.

Conclusion

Evaluating a product manager is not easy because there are a myriad of company cultures, product types, personalities, and business situations in this world and no two situations (or product managers) are identical.

However, a good product manager will always know:

  • What customer problems their product is attempting to solve,
  • How the product intends to solve these problems, and
  • How well (or poorly) the product solves these problems.

In addition, a good product manager knows that customer situations continue to evolve — so they will maintain contact with current and prospective customers, anticipate future needs, and provide timely product solutions — instead of reacting after the fact with something that doesn’t match what their customers need, want, or will buy.

Advertisements

Does Agile development work for ALL software products?

November 2, 2010

I think most people involved in developing software have a reasonable understanding of what Agile / Scrum development is all about.  The general idea is to get customer feedback early and often so that you can adjust the finished product to something that is almost guaranteed to be what the customer wants.

The Scrum project management method. Part of t...

Image via Wikipedia

This is clearly a much better idea than the traditional, or waterfall, approach where you spend months figuring out what the customer wants, more months building it, and then hope (or pray) that the customer hasn’t changed their mind or that the market hasn’t moved while you were doing all the work.

And history is full of examples of products developed using the traditional way that didn’t get close to living up to their original market expectations because they were obsolete or out of touch with their market the day they were introduced.

However, when you listen to some Agile zealots talk — you will hear things like “there never was a product that couldn’t be developed using Agile”.   Frankly, this reminds me of “one size fits all” which anyone over the age of 5 knows is simply not true — especially in today’s market where every customer wants it “their way”.

So with your help, I would like to identify products (or situations) where Agile development may not be the best approach.  The goal is to avoid trying to force-fit Agile where it clearly won’t work and to identify how to adapt Agile concepts in other cases so that we can get the best possible product in every situation.

OK — I know this is ambitious and possibly not achievable.  But a journey of many miles begins with a single step.  So let’s get started by talking about some product types where Agile will have problems:

  1. Embedded Software — The software that runs all of the “electronic” modules in your car are a good example, including the ABS system, the throttle control system, and the fuel injection system.  Obviously, you can’t ship an interim version of this software to your customers and ask for their feedback — they wouldn’t know how to test it.   And imagine if the software had a bug, the car accelerated out of control and someone was injured or killed.   How would the manufacturer explain that it was only a “test” version of the software? (Hmmm, this sounds vaguely familiar for some reason…)   Lastly, it takes a long time to ship a product like this to a customer.  So even if you could get customer feedback, it would come so long after the development had been completed as to be nearly useless to the development team.
  2. Enterprise Software that Requires Customization — This is an idea that I described previously, so I will summarize.  Imagine that you provide a customer with software that takes them 6 months (or more) to customize and deploy, how will they ever be able to provide you with timely feedback?
  3. Real Mission Critical Systems — The software that monitors and manages the nuclear reactor in a power plant is a good example.  How could any software provider explain away an interim software release that allowed a catastrophe to occur because a feature wasn’t “finished”?    I mean before they lost everything in the inevitable flood of litigation.

There are only a few examples, but they seem to have a few things in common.  Perhaps Agile / Scrum development only works with products / situations without these characteristics:

  • No Timely Feedback — It is not possible to obtain feedback from the customer / end user sufficiently fast enough for the Development team to review and incorporate it into the product.
  • No Ability to Fail — It is not possible for the product to fail, due to a feature that is incomplete, incorrectly designed, or improperly implemented, without subjecting the customer / end user to unacceptably high risks.
  • Not a Standard Product — It it not possible for customers to effectively use a “standard” version of the product.  Every version must be customized before it can be used (or tested) by a customer which makes it very difficult to detect whether a failure is in the product or a customization.

I’m sure I’ve only scratched the surface, so feel free to add your comments.

And next time, we’ll look at a few ideas for using Agile Development practices for products which have one or more of these characteristics…


Documenting Requirements — the Tools you will need to be successful.

November 2, 2010

I wrote previously about an approach that I have used to manage requirements.  Subsequently, I have been asked to elaborate on the tools and rationale, so here goes…

As previously discussed, “requirements” consist of a wide variety of inputs from numerous internal and external stake holders.   Yet all requirements suffer from 2 problems — (1) It is impossible to address all of your open requirements in a given software release, and (2) things change.

So, that very carefully defined requirement from that key customer that was documented in year 1 may be significantly different from what that same customer needs in year 2 (or year 3).  You obviously don’t want to spend time developing something that doesn’t meet a business need and you also don’t want to lose any of the knowledge about that requirement that you have collected from this customer (and others).  Lastly, if you are going to reconnect with a customer to review the details of a particular business need — you MUST have a good understanding of what they have said before — or they will dismiss you as a waste of their time — which is not helpful on many fronts.

In other words for every requirement, you need some method to gather, track, and maintain its “definition” and the features that you will need to address it over time.  A document management system (such as Alfresco) is an ideal tool for this purpose.

You may ask — “but why not use a source code control system like Subversion or CVS?”   The simple answer is “they are not the right tools”.   Source code control systems are designed to help multiple people work on source code files that often overlap with one another.   Thus, these systems have sophisticated tools for identifying the differences between two versions of the same source code file and allowing them to be merged together.  In my experience, these tools do not work with documents — especially Microsoft Word documents — and can even corrupt the formatting and content in some cases.  In addition, source code control systems typically require each user to maintain a local content repository that must be synchronized on a regular basis to ensure that each user is always looking at the most current copy of a document — which is counter-intuitive, at best, for most non-Engineering personnel.

By contrast, a document management system is designed for editing, sharing, and managing “documents”.  It uses a simple check-in and check-out model that allows users to view any accessible document but requires all updates to be done using an exclusive write approach.  A document management system also provides tools for managing the maturity of each document so that preliminary feature ideas can be shared with some people and more mature feature definitions can be shared with others.   (Have you ever had a situation where a very early version of an idea was sold to a new customer by an overly aggressive sales person?  If so, then you should appreciate the ability to control when requirement and feature information is shared with different audiences.)

In other words, a document management system is the best tool for “managing documents” whereas a source code control system is the best tool for “managing source code”.  (Apologies if this seems redundant.)

You also need a method to plan a software release that will (hopefully) include numerous features that each address one or more requirements.  You need a method to select which features will be included in each release and a way to obtain estimates from Engineering on what it will cost to develop each feature.  You also need the ability to iterate the definition of each release numerous times — adding or subtracting different features — trying to get the “perfect” balance between features, schedule, and Engineering capacity.

You also need to capture all of the assumptions and dependencies that Engineering identified while creating their estimates for 2 very important reasons:  (a) Engineering spent time (and money) creating these estimates and if a particular requirement isn’t addressed now, it may be later.  You don’t want to pay twice for the same thing. (b) If you know how each estimate was derived, you are much more able to verify previous estimates or anticipate problems with current estimates, based upon$ its assumptions and dependencies — even if your Engineering personnel change over time.

You could plan each software release using a spreadsheet — but why would you want to?   Do you really want to continually update the spreadsheet, circulate it to numerous internal people, and then consolidate all of their inputs?   And even if you want to operate this way — do you really have the time?  Or are you assuming that you will get each release planned perfectly the first time?

This is where an issue tracking system (such as Jira) can (help) keep you sane.  You can use a field (such as “Specification”) to include a link to the relevant requirements document within your document management system.  You can use another field (such as “Target Release”) to designate the features that you want Engineering to review and have them include their estimates and assumptions in other fields — based upon the information on the feature and its underlying requirement(s) maintained in your document management system.  So when you generate a report (or Excel export) for a given software release — you will be able to immediately determine whether you have under or over defined the release based upon your Engineering capacity.

You are almost done — all you need now is a “plan” for this release.   If you are using the waterfall method, I suggest creating a project plan with Microsoft Project using the feature, dependencies, and estimate information from your issue tracker.   Update it regularly (I suggest weekly) and provide copies to all team members.  (I suggest using a PDF print driver so that you can easily share the project plan with everyone without requiring them to have access to Microsoft Project.)

If you are using Agile, I suggest using the GreenHopper plug-in for Jira — or something similar — to plan each sprint.

That’s all for now.  I hope this has been helpful.   As always, comments or questions are welcome.


Managing Requirements — One Approach That Works

October 3, 2010

I’ve had some recent conversations with colleagues and clients about “managing requirements”.  I was surprised at some of the approaches that had been tried — largely unsuccessfully.

And while I don’t claim to have THE answer on this subject, this approach has one significant advantage — it has worked in the past.

Some Background

I believe that “requirements” consist of many different things, including:

  • Issues reported by customers that highlight a need for better capabilities
  • Problems discovered by internal resources that highlight product gaps
  • Market opportunities that identify broad functional capabilities that could be targeted
  • Customer / prospect discussions that contribute specific product needs.  Often this includes “gaps”.
  • Enhancement requests that explain (sometimes in great detail) specific functions where the product needs to be improved

Thus, there is a wide range of specific and broad “requirements” provided by all sorts of internal and external people — and many of the requirements need to be grouped together — either because they logically go together or because without enough critical mass, none of the smaller items could justify the effort to address them.

Lastly, requirements change over time — either because your understanding of what is needed evolves or because the need itself changes.   (For example, if  a requirement specified that your software should support a dual-core processor and a quad-core processor was introduced before the requirement was addressed — you would probably want to update the requirement.)

Required Tools

I believe strongly in using tools for the function they were designed for.  So, I don’t use a hammer to “drive in” a screw — that’s what a screw driver is for.

Thus, I believe that you need the following tools to manage your requirements:

  • Issue Tracker — a tool for collecting, prioritizing, scheduling, and tracking all sorts of issues, including many of the requirement types discussed previously.  My favorite is JIRA, but there are many others just as good.
  • Document Management System — a tool for collecting, tracking, sharing, and managing all sorts of documents.   My favorite is Alfresco, but there are many others.

You may wonder — Why a Document Management System?   Because some requirements require more than a few paragraphs to adequately describe and as previously discussed — requirements may change.  If these “larger requirements” are captured in one or more documents and linked to the issue within the Issue Tracker — you can update the requirements whenever it is necessary without having to update the issue within the Issue Tracker.

My Approach

Here’s the “short” or “cookbook” version…

System Setup

1.  Create issue types (in the Issue Tracker) for the types of information you need to track.  This could include:

  • Bugs
  • Enhancements
  • Product Improvements
  • Major Features
  • Use Cases
  • Stories (and Epics)  — If you’re using Agile.

2.  Add fields to each issue type so that you can capture planning information.  For example:

  • Dev Estimate — how long it would take to implement this issue (or requirement)
  • Dev Estimate Assumptions — any assumptions that were used to estimate the level of effort.  (This is critical unless you plan to re-estimate each task just before you do it, because situations and people change — and you won’t be able to remember the details of each estimate unless the person who made the estimate keeps notes.  And if they are going to keep notes, why not put them in the system?)
  • Dev Estimate Confidence — how confident is the Development organization in this estimate?  “High, Medium, and Low” are often enough, but you may wish to use a percentage.
  • Reference Doc — a field where you put the link to the reference document (within your Document Management System).   You can also create a separate issue type of “Reference Document” so that you can link multiple documents in your Document Management System to the issue — if you commonly need to refer to multiple documents.

3.  Add “planning” capabilities to your Issue Tracker

You need a method to plan which issues (or “requirements”) will be developed next.  If you are using JIRA and Agile, you could use the GreenHopper planning plug-in.  Or you could add a “Target Release” field and pre-populate it with the names of your next 3-4 release vehicles.

The specific tool is unimportant — as long as it is easy enough for you to use, so that you can (and will) use it regularly.

Using the System

1.  Create documents for anything that can’t be described in a couple of short paragraphs or when the description might change over time.

Use your Document Management System to circulate the documents to appropriate internal (and external) stakeholders — so that each requirement is described appropriately.  You don’t want to waste Development time on poorly defined requirements — so spend the time to get them right.

2.  Create issues for each requirement and establish links to their respective documents.

3.  Create higher level “Major Feature” issues

Group related smaller enhancements and improvements under each Major Feature.  JIRA makes this easy with Links.   Other systems offer similar capabilities.

4.  Create individual issues for each customer request

Each time a customer requests a given feature or enhancement, you should record it as an enhancement issue.  And link each customer enhancement issue to an appropriate Major Feature issue.  Thus, when you are evaluating which features to do — you will have a record of the number of customers who requested something, who they are, when they requested it, etc. — which is incredibly valuable.  Imagine your credibility when you contact your favorite customer to ask them if they would like to test a new feature that they specifically requested… (Of course, they will be happier if you are providing their feature sooner than later — but that’s a different issue.)

5.  Plan each release

Plan each release based upon the content that you want to include, the amount of customer interest, and the roll-up of the estimated development effort.

And since YOU decide how frequently you want to launch new releases, you can use this approach for Agile sprints (3-4 weeks) or for major multi-year waterfall releases.

Conclusion

In summary, all requirements (or issues) get recorded in the Issue Tracker system.  All documents belong in the document management system (such as Alfresco).  Documents are written using standard tools (Word, Excel, Powerpoint, etc).  The Issue Tracker becomes your planning tool and you use the workflow and revision control tools of your document management system to manage the distribution, review, revising, and approval of all relevant documents.

I won’t pretend that this is a perfect system — but it DOES work.  And since these types of tools are already being used within a given company — it is MUCH easier to share information with others in the company and to capture data that already exists. Otherwise, you have to convince people to use “yet another system” and duplicate data between your bug tracking and requirements management system — which is simply too much work, invites multiple (and different) definitions of each issue, and makes it far too easy for things to fall through the cracks.

Next time I’ll discuss the benefits of using a Document Management System (such as Alfresco), instead of a source code control system (such as Subversion), to manage documents.

Thanks for reading this far and now it’s your turn…   How do you manage requirements?  How well (or poorly) does your system work?   Is there anything about my approach that needs improvement or concerns you?

Let’s hear what you think…

-dave-


Creating Product Features Instead of Feature Elements — a Key Agile Environment Challenge

July 11, 2010

Ever have one of those situations where multiple events all pointed you in the same direction?   Recently this happened to me on the topic of “feature elements versus product features” in an Agile development environment.

First I had a discussion with a potential client, then a friend was lamenting about incomplete features in his company’s latest sprint, and then there was the presentation by David Hussman on this topic at the July meeting of the Agile Bazaar.   So this is what I learned…

One of the fundamental ideas behind the Agile development methodology is that your development process is divided into small cycles or sprints.  The idea is that each sprint is sufficiently well-defined to allow it to be delivered to your customers.  And then your next sprint could focus on refining previously completed or new capabilities — depending on what the market (and your customers) need.  In this way, your product is theoretically ready to go to market at the conclusion of any sprint, so you don’t have to wait until all of your “planned development” for a given release has been completed (and tested).

However, this approach doesn’t accommodate situations where your product must include a certain set of related features (we’ll call them “feature elements”)  which cannot be completed in a single sprint and which your product really must include.

For example, assume that you are creating a word processing application which will allow users to create, save, edit, format and print documents in a variety of ways.

Your product MUST have the ability to “create a new document”.  Likewise, without the ability to “save” your changes and then “load” or “open” a previously saved document — the value of your product will be minimal.   This is why, most applications that deal with “objects” provide feature elements for performing “CRUD” (Create, Read, Update, Delete) operations.

Yet, some of these feature elements are much more challenging to implement and thus take longer to complete — often requiring multiple sprints — which is at odds with the Agile concept of being able to deliver the results of any sprint to your customers.

A modified Agile approach known as Kanban appears to resolve this conflict, because the focus is on delivering complete product features and not just feature elements.  In essence, a sprint is not suitable for delivery to customers unless all of the key elements of a product feature are completed.   Thus, to return to our word processor example, you might implement “Create”, “Save”, and “Open” in different sprints, but your product would not be distributed to potential customers until all of these product feature elements had been completed.

This development approach seems nearly ideal to me — but few companies seem to be using it and some strong Agile proponents seem extremely reluctant to embrace it.

So what do you think?   Is Kanban simply too new for many people to have tried it?  Or is it better in theory than in practice? Or is it simply not “Agile enough” for you to consider?

Do you have any experience with Kanban or know of any companies that have used it?  If so, what did you (or they) learn?


Evolving from service-oriented s/w products to a common product platform

June 16, 2010

A potential client wanted advice on evolving their service-oriented software products to a common product platform. Their plan was to revise their application using a popular cloud computing toolkit, migrate all of their customers to this new product version, and retire their current offerings.  So, with all of the attention that cloud computing is getting these days, I thought I would share some of what we talked about and see what your thoughts are…

First, two quick definitions so that we can start on the same page:

Service-oriented products — You host customized versions of your software for each of your customers, typically using a single instance for each customer.  As a result, you may even have situations where different customers are using different versions of your software.   Since each customer’s data resides on a different system, the risk of co-mingling data between customers is low.

Common product platform — You host a single generic (or common) version of your software that is shared among multiple customers and configured to provide them with individualized capabilities and user interfaces.  You use enhanced security mechanisms to ensure that data from your customers is not co-mingled.  Once a user logs into your system, you use their login credentials to present them with a customer-specific user experience.

The key advantages of a service-oriented product approach are that (a) each customer gets exactly what they need, (b) data co-mingling between customers is nearly impossible, and (c) you can roll-out additional capabilities to selected customers very easily — which makes it easy to do specialized testing and to write contracts for individualized capabilities.

However, service-oriented products also have (a) increased maintenance, development, and upgrade requirements because everything must be applied to each implementation individually, (b) severe scalability issues as you get more and more customers — each with their own implementation, and (c) escalating cost issues because each new customer is a new installation without any of the economies of scale that normally come with commercial software.

Thus, it’s easy to see why many software companies start by offering their products as a service and then want to evolve to a common product platform over time.

However, this “evolution” also brings a number of key challenges, as follows:

  • Product Capabilities and Complexity — It is pretty easy to create a software product that can be customized.  The Development team removes the standard routine and plugs in the new, highly customized routine and Voila!, the product now does something significantly different.  “Plug-Ins” like this have been used for years in a wide variety of applications.  However, creating a framework that allows multiple plug-ins to be executed, based upon the user’s profile is much more challenging to architect, develop, test, and deploy.  And you also have to identify all of the places in the framework where a plug-in is necessary.   Lastly, since multiple customers will be sharing the same software instance, your framework has to be sufficiently robust to allow a plug-in for one user to fail gracefully without impacting any of the other users on the system.
  • Company Culture — If your company has been selling highly customized product versions for a while, you have an entire culture devoted to this concept.  So just imagine the conversation when a key sales rep wants “just one more” highly customized product version so that they can bring in a huge order near the end of your fiscal year.  And of course, how will your company handle a number of “just one more” situations?
  • Customer Migration — Even if the capabilities of your common product platform encompass all of the capabilities from all of your customer-specific product versions AND you have migrated all of your customers’ data into the new system, migration will still be an issue for your customers.  At the very least, they will have to retrain all of their users and their system administrators will have to understand how the platform has been configured for them.
  • Product Development Process — Every software product fails at some point in its life.  With a service-oriented product, the failure is normally limited to a single customer implementation.   With a common product platform, a failure will most likely affect multiple customers.  Thus, you may need to re-evaluate a number of aspects of your product development process to ensure that failures of this type are caught during the design, development, and testing of the system.  In some cases, you may need personnel who have different skills / experiences than your current staff so that you can prevent problems before they occur.
  • Product Architecture — Every “technology stack” that is used to develop and deploy a software application has a certain amount of capabilities and a number of limitations.  This is especially true with cloud computing platforms where many of the architecture elements of the system are provided by others and cannot be changed by you.   Thus, you need to verify that your common product platform can be implemented using the technology stack that you have selected (or your cloud computing partner is provided).  You should also cross-check your planned product roadmap against the technical limitations.  You don’t want to spend a ton of money (and time) building a common product platform using a new technology stack only to find out that you will reach a dead-end in 3 years — or just about the time you get all of your current customers happily (you hope) using your new platform.

In summary, evolving from a service-oriented software product to a common product platform can be very challenging.  However, the rewards are worthwhile and you can reduce much of your pain if you (a) take the time to create good quality plans, (b) consistently execute your plans, and (c) clearly communicate among all of the internal participants.

Finally, your customers are your most important asset.  So while you are developing your common product platform, you MUST continue to aggressively support their customized versions and help them see the benefits they will derive from the common product platform once it is available.  You don’t want to EVER announce that you are getting out of the customized software business in favor of a not-yet-available product platform and hope that your customers (and your competitors) will wait patiently for your to execute on your vision — because they won’t.

Just ask all of those customers who used to buy Prime minicomputers how “patient” they were when Prime announced they were going to minimize their hardware efforts in favor of software…


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?


%d bloggers like this: