Product Strategy for Enterprise Software: Avoiding User Research Pitfalls

October 30, 2010

I am a big advocate of incorporating user research into the product management process. As I noted in an earlier article on market research tools, while in the past, this was a costly process only performed by large software organizations, the rise of remote user testing and complex web site tracking tools paved the way for many expansion stage software companies to implement the same tests and acquire a lot of user feedback for little cost.
Why not advocate this to every product manager at all times? Are not rich user feedback and user experience research the panacea to the typical issues that plague enterprise software such as lack of user friendliness, long implementation, complex configuration and customization processes?

From my own experience performing user research, I found a few significant errors when applied to enterprise software, that is, business purpose software designed to serve large organizations with complex needs.

Here are the three issues that typically undermine an inexperienced product manager’s user research efforts:

1. Not having the right goal for user research:

Typically, user research helps to uncover the discrepancy between the user’s mental model when they interact with the software. It also identifies how the software interface is organized. Conversely, it does not help uncover intrinsic, persistent issues within the software’s interface, as various users with different knowledge and experience levels will be using the software interface in totally different manners. This is particularly true for enterprise software, for it is designed for a very specific purpose and set of users, and typically includes a richer user interface than modern consumer software tools (with the exception of Microsoft Office). Novice users are expected to suffer from confusion in such an environment, thus negating the discovery power of user research.

Therefore, user research serves a very specific goal that contributes to the product management process, and it usually succeeds when it is held to that very narrow objective. Utilizing user research for other goals might not be optimal.

2. Performing user research in a “vacuum”

With remote user research tools available, it is very easy to do DIY user research projects. While this democratizes the field, it also allows a lot of people to do user research on their own without consulting others or trying to put the results in context with other customer research data. Here is the issue: User research results often live in a vacuum with no context (i.e. possible reasons that might rationalize the results, or other results that corroborate it).

3. Product management teams making decisions based purely on user research
Even the rich insights gleaned from user research need to be tempered with other viewpoints, such as a heuristics evaluation by UX experts. The data to which the users are responding might not reflect the most important or the most commonly used feature of the product. By prioritizing the fixing of a usability defect over adding new functionality, you can cause the product to stagnate unnecessarily. This is particularly true for more complex software. Due to the limited nature of user research, only a small subset of features can be exposed to the test participants. Their feedback is then invariably confined to those features and related ones, while more important issues or functionality might be missed.

It is not hard to avoid these pitfalls – one just needs to possess the right perspective on the use and abuse of user research today.

Chief Business Officer at UserTesting

Tien Anh joined UserTesting in 2015 after extensive financial and strategic experiences at OpenView, where he was an investor and advisor to a global portfolio of fast-growing enterprise SaaS companies. Until 2021, he led the Finance, IT, and Business Intelligence team as CFO of UserTesting. He currently leads initiatives for long term growth investments as Chief Business Officer at UserTesting.