PLG and sales should share the customer, not fight over the lead.

A person trying your software should be able to get value without an unnecessary sales call. An organisation making a complex purchase should be able to get human help before it gets stuck. A useful SaaS growth model makes room for both.

My starting point is the customer's buying task. Company size is useful context, but it should not decide the whole journey. A small regulated business may need a detailed review. A team inside a large enterprise may be able to adopt a simple product through self service.

Two motions with different jobs

In product led growth, the product experience does much of the work of attracting, activating and retaining customers. A free trial or free plan can support that approach, but simply offering one does not make the business product led. People still need to discover value and have a workable route to paying for it.

Sales becomes useful when a purchase needs help with requirements, stakeholder agreement, technical questions or commercial terms. That support can follow product adoption, a direct enquiry or an account based campaign. It should not require the customer to repeat everything already learned elsewhere.

Atlassian provides a documented example of growing investment in enterprise sales. Its January 2025 shareholder letter describes stronger sales execution, larger contracts and hiring to support its biggest customers. Those are company reported observations, not evidence that every SaaS business should copy its structure. Atlassian Q2 FY25 shareholder letter

Connect product adoption with sales support, with a clear role for each.

Let onboarding respond to completed work

Consider an illustrative accounting software trial. One customer has created an invoice but has not connected the data needed for their next task. Another has completed setup and invited a colleague. Sending both the same reminder wastes an opportunity to help.

The first customer might need setup guidance. The second might benefit from a shared working feature. The product team should define the events that distinguish those needs, then check that the events actually arrive and match the correct account.

I would begin with a small set of workflows:

• Welcome and setup, with instructions that change as tasks are completed.
• Activation support tied to the product's agreed first value event.
• Trial conversion that explains what the customer can do next.
• Adoption and expansion messages based on demonstrated use and need.

Email can bring someone back. An in product prompt can help them complete the task. Support should be available when neither resolves the problem. The channel serves the task, rather than becoming a target in its own right.

Measure activation by a defined account cohort and time window. Track time to first value, trial conversion, retention and expansion. Avoid counting all logins as success or reporting a conversion percentage without stating which accounts were eligible.

Give sales a reason to get involved

A product qualified lead should represent an agreed combination of product evidence and customer fit. The threshold will differ by business. A new user alone is unlikely to justify the same treatment as a growing team asking about security or a commercial plan.

For a more complex purchase, the account view needs to connect people with different jobs. Finance may need a business case. IT may need evidence about security and how systems connect. A user may need to test the workflow. Those needs should shape the follow up, without assuming that job title tells you everything about a person.

An explicit request for a demonstration should create a clear action and owner. Repeated page visits are weaker evidence. They can justify a review of the account, but should not automatically trigger simultaneous emails, calls and adverts.

Agree the handoff with sales before building it. Define the context they receive, the response expectation and what happens if the account is not ready. Include a route back to useful education. Otherwise the CRM becomes a queue that someone else is expected to clear.

One customer view does not mean one application

The required information may live across CRM, product analytics, a customer data platform and support tools. Decide which system owns each field and how changes move between them. A shared identifier and trustworthy customer status are more useful than another dashboard showing disconnected totals.

In the proposed flow below, product and commercial signals are checked against account context and communication preferences before a treatment is selected. Outcomes return to the account record so the next decision can use them.

When a customer enters an active sales conversation, pause or adapt the relevant prospecting messages. Keep necessary service communications separate. When a deal closes, use the confirmed customer status to move the account into adoption. Do not make the customer wait for an old prospect list to be manually refreshed.

Add AI where the decision benefits

AI could help summarise account context, suggest the next useful piece of content or identify a case that needs a person. Those are proposals to test. They are not reasons to remove the rules around consent, eligibility or who can make a commercial commitment.

Begin with an approved set of actions and content. Review cases where the recommendation differs from what the team would do. Then measure whether the change improves activation, accepted opportunities or retention against a suitable comparison.

Adobe describes AI ranking and eligibility controls in Journey Optimizer. These features give teams choices to test. Their availability alone does not establish that they will improve conversion. Adobe decisioning capabilities

Start with the handoff that customers feel

I would choose one place where the two motions currently meet, such as a growing trial account asking for help. Map the signals, owner, messages and outcome. Remove duplicate contacts and conflicting instructions before adding another campaign.

The practical test is whether the customer can move from trying the product to getting expert help without losing context. If that works, the business has a sound basis for extending the model.