Orchestrating Three Pathways into Business Customers
Around Tech Guardians of Growth
This is Part 3 in a blog series on Customer Relationship Marketing. You can find Part 1 here and Part 2 here.
In the previous two posts, we discussed how the dynamic between the customer quartet and tech product offering determines the three growth pathways into a business customer. This can simplify and help manage complexity of many GTM plans. These three pathways are not mutually exclusive. In fact, with proper orchestration, tech companies can drive growth in customer segments. In this post, I explore these orchestration patterns. I also classify the various types of tech guardians inside an enterprise and how they can set the limits to growth for a tech product.
Orchestrating the Three Growth Pathways
For Business Apps or Tech Tools
Ultimately, for revenue growth, B2B marketers need to target both the user and buyer for the tech product. In the case of business apps, marketers should target the employees with key jobs that the product gets done and the business buyers with value messaging.
For software infrastructure and tools, marketers should target the developers and data engineers who benefit from the tool and the tech buyers with architectural advantages and tech economics of the software infrastructure.
In both cases, the orchestration of sales and marketing to both users and buyers needs to happen. This can happen in parallel or sequentially, but must happen by the time the company is ready to scale revenue.
The common orchestration pattern for the new generation of SaaS applications and cloud-native developer tools is as follows:
- Begin with product-led growth strategy with users (e.g. core app user persona or developer persona).
- Iterate on product-user fit until product managers find repeatable user growth. Product-user fit means users get personal value through using the product.
- Once user growth takes off, or in parallel, begin account-led growth strategy with buyers.
- Iterate on product-buyer fit until sales identifies repeatable account growth. Product-buyer fit means buyers get economic value from product use.
This pattern works as long as buyer and user teams are aligned within the customer organization. For instance, the Salesforce buyer (revenue leader) is aligned with users (sales reps using CRM); the Workday buyer (payroll) is aligned with users (employees using payroll); and the Splunk buyer (infrastructure security) is aligned with IT operators (users who monitor security).
However, technology adoption within companies no longer fits within neat org boundaries. What happens when we have tech products that are built by tech users (e.g. developers) for business users (e.g. marketers) and when tech buyers (e.g. heads of data) can generate value for business buyers (e.g heads of e-commerce)? This is where business platforms come in.
For Business Platforms
Business platforms require engaging multiple customer dyads (business and tech) with well orchestrated product-, account-, and channel-led GTMs. This increases the complexity of relationships and value propositions that a tech company has to create, deliver, and manage across internal teams and channels for every target company — and eventually across the market. This is one of the main reasons why a new business platform is hard to scale.
Nonetheless, there are powerful advantages to business platforms: they link and deliver value across tech tools and the business use cases.
A business platform facilitates the cross-over between business and tech/IT as follows:
- A tech user directly enables a business user: For instance, a developer builds a new marketing workflow on a martech platform (Adobe) for the marketing team. A data engineer builds portfolio dashboards on a data analytics platform (Looker) for financial analysts.
- A tech buyer directly enables a business buyer: For example a Chief Data Officer (tech buyer) of a bank settles on the Google Cloud AI platform to build several customer support use cases for the VP of Customer Care (business buyer). Or the VP of Infrastructure of a merchandiser store chain chooses Shopify platform to build an online channel.
- Platform network | marketplace enables business or tech users: A strong business platform offers extensibility of its core technology with a network of products and services that go beyond their own use cases. For example, Stripe has a partner network that offers apps & extensions for their developers. Slack offers a directory of apps that can extend the core user experience.
This dynamic among multiple customer subtypes can determine whether the business platform takes hold, and if so, what are the best directions for its adoption. Not all platforms need to focus on all four subtypes.
These are the two common patterns of how business platforms evolve.
Pattern #1: Tech User To Business Crossover
- Stripe: The platform is built for developers (tech users) to deliver a narrow business use case (adding payments to an app) for the business buyer (commerce leader), who cares about business benefits of the better payment experience with Stripe. In fact, the business user is the end-consumer who is not even aware that the experience is powered by Stripe. Over time, Slack platform added more business use cases for the same business buyer (such as fraud detection). A robust partner network grew as use cases grew.
- This pattern has been repeated by all API business companies (e.g. Twilio, SendGrid, Checkr, and Segment).
- This is the same pattern for AI-data companies as well, such as Automation Anywhere, which helps developers build bots for process automation with an increasing set of business use cases and solutions for different industries. Another example is PeopleAI, a platform that lets IT tech users capture and automate contacts for helping sales and marketing manage revenue.
Pattern #2: Business User To Tech Crossover
- Freshworks: The platform began as an app built for specific business users (customer support) funded by an aligned business buyer (Head of Customer Support). Over time, they added more apps for adjacent business users (e.g. sales and marketing) as they expanded to broaden buyer value proposition. To support technical enablement of this expansion, they added more tools for tech users (e.g. design tools for developers). Eventually, Freshworks built a broader AI-based tech platform for the developer community to unify customer experiences. And around this platform, they grew a partner community and an app marketplace as well.
- This pattern of business app-to-tech platform is now common for many cloud-native business app companies.
Of course, these are not the only two patterns possible. Many other patterns can be tested and scaled based on the framework above.
In all these cases, business platform patterns work best when:
- The platform has a user-focused adoption, either for business users or developers.
- If the user is a developer, then it helps to deliver a narrow business value proposition to a single business buyer before scaling.
- If the user is a business, then it helps to deliver a narrow tech value proposition to the tech buyer before scaling.
- The focus is on a single buyer — business or tech — to reach scale.
- The business buyer is clear on how to grow the business value proposition.
- The tech buyer is clear on how to scale the platform to production.
- Regulatory and compliance issues are not roadblocks to user adoption.
- IT enablers can activate the platform for users for trial and adoption.
By identifying the three growth strategies and orchestrating them with customers, companies can drive strong adoption of their tech products.
Tech Guardians and Limits to Growth
Now we come to this question: even if a company executes flawlessly, is there a limit to how far a company can push its product-led, account-led, and channel-led growth within a customer segment? Are there any natural limits inherent in business customers that constrain the growth of a tech product?
The answer is yes. Let’s look at the customer quartet and see how each of the customer subtypes is constrained within a business.
- Business User & Functional Limits: For a business application, a key metric is user growth. However, a business user is circumscribed by support, permissions, and policies set by the company. The business user may get limited IT support for the product curbing its usage, or the product may only be permitted for a few users due to business policy reasons (e.g. need-to-know, confidentiality, and IP). Such functional limits on user growth are often placed by business necessities.
- Business Buyer & Corporate Limits: To a business buyer, the key measure of an application is the business value generated and the metrics affected over time. Even if the technology is effective initially, its impact may be limited if the business buyer does not obtain corporate approvals over time, such as ongoing investment approval by the CFO, risk approval by Chief Risk Officer, or approval for the variety of industry regulations and compliance necessary for the product. Such corporate limits of business value are placed upon the company by internal and industry norms.
- Tech User & Community Limits: The key metric for a software tool is its adoption by tech communities of developers, data engineers, and other practitioners. There are factors that limit this adoption: support for the tool in the open source community, the training and evangelism available around the tool, and the developer incentives to use the tool. Such community limits on tool adoption depend much on the promise and support of the underlying technology of the tool.
- Tech Buyer & IT Governance Limits: For a tech buyer, the key metric of a tech infrastructure or a tool is its adoption as an architectural standard or platform of choice within the customer IT/tech landscape. This may be constrained by security approvals by CISO, data and privacy approvals by policy and regulation teams and by architectural agility and roadmap reviews, and its economics in the short and long term. Such IT governance limits on tech adoption depend on the current tech landscape within the company and its industry norms and regulations for security and data privacy.
Collectively, these limits can be seen as guardrails or fences set up by tech guardians (e.g. CIO, CFO, CISO, and Risk Officer) that prevent runaway adoption of a technology — however good or valuable — within a company. These are very different from consumer products, which do not have similar constraints. For new entrants, these guardians can be seen as gatekeepers who provide barriers to entry for technologies that do not meet minimum requirements for a company. In such cases, these tech gatekeepers have the veto power for tech products during the sales process.
This is how it should be. Unlike consumers, business managers and their guardians have to protect the business interest, have legal and compliance obligations, and need to mitigate security and shareholder risks. Therefore, marketers need to view tech guardians as a critical audience since they are the shadow influencers (and sometimes influencers in the open) who limit what tech products are available to users and buyers and constrain their adoption over time.
Key Takeaways
- The three growth pathways into a business customer are product-led growth, account-led growth, and channel-led growth.
- These three pathways are complementary and can be orchestrated with a customer segment.
- There are many orchestration patterns for these strategies for business user/buyer and tech user/buyer dyads.
- For business platforms, orchestrations across business and tech customer subtypes may be needed, adding complexity but offering strong growth.
- Business platforms can evolve from either tech users to business users or from business users to tech users like developers. There are many patterns of evolution.
- There are natural limits to all these growth strategies based on legitimate roles various tech guardians (e.g. CFO, CRO, and CISO) play within an account.
References
- Product-Led Growth Institute
- Account-Based Marketing — Practice
- Platform Strategy Explained — MIT
- Software DevOps LifeCycle blog; and article
- Jobs To Be Done; Competing Against Luck, Clayton Christensen; JTBD — Anthony Ulwick
- Value Chain — Michael Porter
This is Part 3 in a blog series on Customer Relationship Marketing.
