The most important part of helping buyers is identifying who the buyer is. In many cases, the user is the buyer. In a large organizational context, there may be multiple stakeholders such as a technology evaluator, economic buyer, executive sponsor, and so on. To bring them over the line, I’ve found it crucial to address what they will need to change to make the product work (technology, process, people, etc.) and what the buyer stands to lose if it fails (capital, time, credibility, etc).
I intentionally don’t cover the traditional sales-led approach in helping buyers in a top-down context where contracts run into millions of dollars. In this post, I focus on bottom up GTM approaches for growing revenue.
Products for Individuals
For products designed for individuals, any change in process is limited in scope and blast radius. GitHub is an example of a developer focused product where repositories are primarily scoped to an individual.
Such products usually benefit from a free tier pricing plan that makes it easy for users to sign-up and get started within minutes. A quick onboarding experience widens the product’s appeal to a large number of users, where a percentage may turn into paying customers – forming the basis for the ‘freemium’ business model.
Productivity tools (e.g. Notion, Coda), API-led experiences (e.g. Mapbox, SendGrid), and several cloud services (e.g. Lambda, DynamoDB) target individuals and offer perpetual free tier plans (see below). These free tier plans often trigger charges based on usage thresholds.
Products for Teams
Products designed for teams usually require the manager or a strong team influencer to propose or approve usage. PagerDuty is an example of a product designed for teams where different team members may be on-call at different times.
A mid-level manager has more budget than individuals though if the product fails, she risks impacting the whole team and hurting her credibility with the team and her leadership. This raises the adoption barrier for these products. On the other hand, such products enjoy faster growth as team usage begins to compound.
PagerDuty, Slack, and Jira are intentionally priced based on the number of users in the team to avoid triggering purchase approvals beyond the manager.
Products for Organizations
Several products must be implemented uniformly across the company and cannot be chosen independently by each team. Auth0 is an example of a product that an organization adopts for SSO, access controls, and permissions across hundreds of applications supporting various business functions. As the central decision maker, IT generally wants to minimize impact on org-wide processes and employee productivity. IT also bears the risk of the solution failing, say with org-wide security breaches and exploited vulnerabilities. IT has the ability to write larger checks but it’s not the most eager agent of change in a large organization.
In some cases, where a large number of teams have already adopted the product (e.g. Slack, PagerDuty), a central IT or procurement unit may step in to consolidate purchasing and reduce the overall cost for the company. This reflects the bottom-up GTM path (individual -> team -> organization) that we commonly see with modern cloud services.
While Auth0’s pricing includes developer ($276/yr) and developer pro ($12,840/yr) plans, a majority of their revenue comes from the Enterprise plan.
Decision Making
‘Clicking the buy button’ becomes progressively harder as the distance between the user and buyer increases – there are more people to convince, more processes to change, and more to lose with the growing blast radius. The distance between the user and buyer also reduces direct accountability and transparency in the selection and evaluation process. When helping internal champions build their case internally, arming them with competitive information and product differentiators often deepens their trust in the product from the outset and helps them improve transparency around the evaluation process internally.
Overall, pricing should aid adoption and help buyers who are already bought into the product rather than address objections from various stakeholders. Don’t let pricing be the reason to lose business from a customer. To avoid being blocked on pricing, identify a compelling event that converts the user into a paying customer before discussing custom pricing.
Are there other topics around product evaluation and buying that you’d like me to cover? Write me a note…