Product adoption: It’s tough to get return on investment with something that isn’t used

Product adoption: It’s tough to get return on investment with something that isn’t used

My path to martech was through tech. I focused on managing websites, functionality, integrations, software development, business requirements and so on. Marketing came into the scene when I joined a website team within a marketing department. Due to this, my bias historically has leaned towards optimizing the technical side, but I’ve learned that the business side is also very important. Duh! From the technical vantage, it is important to focus on things like feature sets, fit within an existing stack and the nature of product maintenance, but that’s far from the entire picture. 

For instance, there are many advantages to a free, open source content management system (CMS) like Drupal, which – in the right hands – can create robust websites and applications.  However, it is a developer’s CMS, and it has a steep learning curve out-of-the-box even for developers. While a very user-friendly Drupal interface is possible, it requires significant investment. On the other hand, there’s another free, open source platform like WordPress. From the start, WordPress is more friendly and intuitive to a broader user base than just developers.  If you need a largely informational site or personal blog, it’s a wonderful choice. However, its potential set of viable uses cases is smaller than Drupal’s. Then there are the closed CMSs that come with licensing fees. These are typically easier to use than default Drupal but have broader capabilities than WordPress. Each class of CMS has its own sets of pros and cons.

A technical person may favor a CMS platform (free, open source or not) that’s more flexible development-wise allowing it to better interact with an existing and future stack. It may require less effort to add features, integrate with other systems and offer the organization more control.  This could (emphasizing the possibility, not certainty) yield less frustration, technical debt and difficulty meeting development goals. However, if business users find it burdensome to use effectively, they’ll likely resist it. Thus, any investment into the system risks going to waste. No one wins in this scenario. 

Out of fairness, it is important to note that business people don’t like it (understandably) when the techies tell them that a request isn’t feasible or will require a lot of time to accomplish. The challenge goes both ways. Balancing technical and business objectives is both an art and skill that rarely provides clear answers.

The CMS space isn’t the only one that requires balancing technical and business needs. Systems for digital asset management (DAM), marketing automation, analytics and conversion testing are just a few other examples. 

Further, great UI/UX is just one factor in this tricky balance. Another factor is past experience. Everyone brings different things to the table. It shouldn’t surprise anyone if a stakeholder who just joined an organization resists a favored solution. That stakeholder may have worked at another company that tried unsuccessfully to implement that solution. Perhaps the reason for the failure was a mismatch between capabilities and requirements or maybe there was a lack of the necessary institutional investment (training people, integrations, etc.). Regardless if the reasons from their former employer apply to the current situation or not, that stakeholder will more likely resist adopting the solution. If they’re peripheral to the solution’s core team, then hearing and considering their input is worth doing. If they’re central to the solution’s usage, then more is required  Their resistance to product adoption is a threat to its ROI.

Fortunately, there are some tactics to boost or address lackluster product adoption. These include:

  • Sponsorship – Products need internal champions who monitor their performance, advocate for their needs, and address issues that arise to make adoption easier.
  • Evangelization – Sponsors should also educate their colleagues about how they could benefit from a product’s offerings.  For example, an SEO tool that monitors links and keyword mentions could benefit PR. Get more bang for your buck.
  • Training – An organization may have skilled employees, but they require training to better harness what’s available to them — especially as systems change or add new features.
  • Informal Working Sessions – These sessions can have different purposes. One purpose is allowing users to huddle to discuss and help each other with their projects, and another is providing a time when a developer can tackle simple requests so that tasks don’t get caught in project management purgatory.   

There are many obstacles to product adoption. However, with an understanding of these impediments, one can address them. This work is not just nice; it’s essential to establishing and maintaining a martech stack that yields a great ROI.