How Drupal and Wordpress Mirror the Commerce Buyers Journey

In my last article, I talked about why product-led growth (PLG) in commerce looks slightly different. To sum it up, having multiple stakeholders in the buying process makes commerce a somewhat less straightforward PLG play. Traditional GTM motions still hold a critical role in nurturing the business buyer, while technical buyers can gain a lot of ground testing products in a hands-on manner via PLG.

I also covered how many commerce buyers use off-the-shelf products like Shopify as a sort of sandbox for testing the feasibility of new ideas, yet move on when they encounter the upper limits of what the platform can do. 

In my previous role at Acquia, I lived this dynamic over and over again. Here’s how it was similar to what we’re seeing in commerce.

Web Content Management and Commerce Similarities 

Much like commerce, there’s a multi-stakeholder buying process in the content management system (CMS) space. Typically a business stakeholder like a marketer gets frustrated with the limitations of the current website and digital ecosystem surrounding it. Legacy CMS platforms make it difficult to spin up new pages for campaigns, for example.

That means the marketer usually has to go to the developer to get a new page set up. With a massive queue for requests, development teams are often unable to meet marketers’ requirements for speed. As with commerce, developers are responsible for figuring out how to execute on a barrage of business stakeholder requests and associated pain points.

To get around some of these challenges, we saw a lot of developers experimenting in Wordpress. While the Wordpress platform was simple to onboard and allowed for low-risk trial and error, many of these developers hit limits when it came to flexibility and technical requirements. We saw a lot of “snowflake” situations where certain teams went rogue in Wordpress to develop their own workarounds and later abandoned them, which led to problems further down the road. 

Enterprise Capabilities With Experimentation Built In

Drupal ended up being a great solution in larger, more complex enterprise deployments or when a customer had a mix of websites large and small and wanted a single CMS platform to address a range of needs. With Acquia, Drupal offered enterprise capabilities (e.g. security, scalability, resilience, etc.) without abandoning the experimentation that came with open source. As a result, brands like Pfizer turned away from their legacy Oracle platform and Wordpress experiments, using Drupal to solve problems big and small. 

Drupal’s capabilities became even more powerful as the world moved toward dynamic “digital experiences” involving more channels, new marketing and personalization needs, and more. Today, marketers and developers work as a team, rather than throwing a business requirement over the fence and hoping for a technical solution weeks (or even months) later. 

We’re seeing the same pattern happening in the commerce market here at Elastic Path. Business stakeholders like merchandisers demand new capabilities as their business evolves. They want the flexibility to branch out into new channels, bring on new brands, create new product combinations, merchandise micro-moments, and more. They’re hitting limitations with their legacy commerce platforms. And they’re hitting the upper boundaries of what they can do in off-the-shelf products. 

Similar to Acquia, Elastic Path addresses a rapidly evolving set of enterprise commerce needs. Our customers get the speed and flexibility of composable application development, (as compared to their clunky legacy platforms) without the limitations of off-the-shelf SMB options. While the path toward PLG may not be as straightforward due to the multi-stakeholder buying process, addressing the needs of both business and technical users doesn’t have to be difficult. A combination of enterprise sales, technical presales and support can prove invaluable for solving problems. It’s about teaching and enabling the customer to meet their unique requirements, helping them experience the art of the possible.

Combining that hands-on expertise with the freedom to experiment with the product is key.  For example, there’s a lot of experimentation that can be done with the Elastic Path platform, starting with the product catalog. New products like EP Product Experience Manager (PXM) help quickly meet the technical requirements of business users – making it much simpler for both merchandisers and developers to collaborate and innovate together. 

In a modern PLG motion, it’s critical to give buyers the room they need to test and try your platform before expanding to an enterprise-wide deployment. Having PLG and enterprise sales and support work harmoniously together helps build trust in your product and your team to meet even the most complex needs. 
 

Next Up: Elastic Path PLG

We've Got Our Own Product-Led Growth Initiative Under Way. Sign Up Here For Early Access So You Don't Miss Out

You'll receive a confirmation email shortly.