GTM, UX, and Governance

The core issue is a structural mismatch: a sales-led motion at a cost basis that requires a much shorter sales cycle to be sustainable. At $2.2M/month burn, the company needs approximately $26M ARR to break even. Getting from $8M to $26M on a 14-month sales cycle requires either a massive sales team expansion (which accelerates burn) or a fundamental change to the motion (which is the right answer).

Diagnostic (first 30 days):

1. Why is the free trial converting at 2%? Three possible root causes: (a) wrong audience for self-serve — enterprise procurement can't start on a free trial anyway; (b) time-to-value is too long — users don't reach an "aha" moment before the trial ends; (c) the free tier has the wrong feature set — missing one critical capability that would make it worth adopting. Understanding which of these is true determines the fix. Run 10 user interviews with free trial abandoners in the first two weeks.

2. What is the sales cycle bottleneck? 14 months is not the sales process — it is the decision-making process. Map the procurement journey: who is involved at each stage, what evidence they need at each stage, and where deals slow down. Most 14-month cycles have 2–3 months of actual selling and 10–12 months of waiting for procurement, legal, and budget cycles.

3. Where does individual usage exist inside enterprise accounts? If any existing enterprise customers have employees who use the product individually, map how they use it and whether that usage generates the kind of ROI evidence that procurement teams need.

90-day plan:

Weeks 1–4: Redefine the PLG tier with a specific ICP. Not "anyone can sign up" — define the role and workflow that can reach value in a single session without IT approval. If the product requires data connections to work, build a sandbox with representative sample data that lets the target user complete a real workflow without their own systems. Target: user can reach a meaningful result within 30 minutes of signing up.

Weeks 5–8: Add usage analytics visible to users. For every session, show the user what they accomplished and how long it took. Compare this to a baseline (industry average for the same task done manually). This data becomes the user's business case when they bring the product to their manager. Target: 25% of active free users have a shareable ROI summary within 45 days.

Weeks 9–12: Build enterprise triggers from individual usage. When a free user reaches a usage threshold (3 sessions, meaningful output generated), trigger a lightweight enterprise conversation — not a full sales process, but: "three people at your company are already using this; want to see how it works at the team level?" The individual usage signal is the qualifier; the enterprise conversation is the natural next step. Target: 15 enterprise inbound leads from PLG in the first 90 days.

What not to do: Cut the sales team. The sales team closes the deals that PLG identifies. The problem is not sales — it is the absence of the demand signal that makes sales efficient.

Self-assessment checklist:

• Did you diagnose the 2% free trial conversion before prescribing a fix?
• Did you identify that the 14-month sales cycle is a symptom (procurement process) not a cause?
• Did you design the PLG tier with a specific ICP and time-to-value target, not a generic "free trial"?

This is a governance design question disguised as a feature request. The answer is not "yes, build it" or "no, don't build it" — the answer is "not yet, and here's the specific evidence required to unlock it."

What the customer is asking for: Fully autonomous mode on a consequential, partially irreversible action (claim status update). Once a claim status changes in the core insurance system, it triggers downstream effects — adjuster notifications, payment processing eligibility, customer communications. Some are reversible (status can be updated again); some create commitments (payment processing initiation) that are harder to reverse.

The governance analysis:

1. What is the current error rate on the agent's recommendations? If the agent generates a recommended status update that the human approver changes 8% of the time, removing the human approval step means 8% of claim status updates in the core system are wrong. At scale, this is thousands of incorrect status changes per month — each requiring investigation and correction.

2. What is the cost of an incorrect status update? An incorrect "approved" status on a fraudulent claim releases payment. An incorrect "denied" status on a legitimate claim triggers a regulatory complaint in most insurance jurisdictions. These are not equivalent to a wrong item in a shopping cart — they have legal and regulatory consequences.

3. Is there a partial autonomy path that captures most of the latency improvement? The 48-hour-to-4-hour improvement is not purely the human approval step. Break down the current 48-hour cycle: how much is human approval time, how much is queue wait time, how much is processing time? If queue wait time is 36 hours and human approval is 2 hours, removing the approval step doesn't get to 4 hours — it gets to 38 hours. The correct solution may be straight-through processing for a defined subset (claims below a dollar threshold with high-confidence scores above 98%) while retaining approval for the rest.

The recommendation: Build tiered autonomy, not full autonomy. Propose: claims with confidence score above 98% AND claim value below $5,000 process automatically. All other claims retain the approval step. Start with a 60-day pilot on the autonomous tier, measuring error rate and downstream correction rate. After 60 days, evaluate expanding the autonomous scope based on measured outcomes.

Present this as the governance-responsible path that gets the customer to most of the latency improvement without the regulatory risk of full autonomy on the first deployment.

What not to do: Build full autonomy in 2 weeks because the customer asked for it. The first incorrect automatic status change on a fraudulent claim that results in a payment is a contract review event — potentially a contract cancellation. The customer is asking for speed; your job is to give them speed in a way that doesn't create a liability.

Self-assessment checklist:

• Did you analyze what percentage of recommendations currently differ from human approval decisions?
• Did you identify that incorrect status updates have regulatory consequences specific to insurance?
• Did you propose tiered autonomy as the responsible path to the latency improvement rather than binary yes/no?

This is a market positioning decision with a governance investment threshold question embedded in it. The framework has three components:

Component 1: Is the mid-market expansion genuinely a different ICP, or an extension of the current one?

Small business accounting (1–20 employees) and mid-market accounting (50–200 employees) have fundamentally different requirements:

• Small business: owner-operator who trusts the tool, low compliance overhead, willing to accept some error rate in exchange for cost savings
• Mid-market: finance team, controller, external auditors who review the books, potentially investor oversight, state and federal regulatory filings that must be auditable

This is not a pricing change — it is a product architecture change. Mid-market customers need the agent's actions to be auditable because their books are reviewed by third parties (accountants, investors, tax authorities) who were not present when the agent made decisions. The audit trail is not a nice-to-have — it is what makes the product usable in a mid-market context.

Component 2: What does SOC 2 Type II actually require, and is it the right starting point?

SOC 2 Type II certifies that a company has maintained specific security, availability, and confidentiality controls for a 6–12 month period. It requires:

• Formal security policies (access control, incident response, change management)
• Logging and monitoring infrastructure
• Annual penetration testing
• Employee security training and background checks

The certification timeline is typically 12–18 months: 6 months to implement controls, 6–12 months of audit period. Cost: $30,000–80,000 for the first year including audit fees and tooling.

For accounting software, the more relevant certification path may actually start with SOC 1 Type II (controls over financial reporting) rather than SOC 2. Many accounting software buyers ask for SOC 2 because it is what they know to ask for, but what they actually need is evidence that the system's outputs are reliable and auditable for financial reporting purposes. SOC 1 + immutable audit trail + documented reconciliation procedures may address the underlying requirement faster than SOC 2.

Component 3: What is the revenue case for the investment?

At $3.2M ARR with an 800-customer SMB base, the current average ACV is $4,000. Moving to mid-market at $15,000–$40,000 ACV means each new mid-market customer is worth 4–10 SMB customers. The SOC 2 investment becomes rational when: (number of mid-market customers won per year × incremental ACV vs. SMB) > (SOC 2 annual cost + opportunity cost).

At 10 mid-market customers per year at $25,000 ACV: $250,000 incremental ARR per year. At 20% churn: $200,000 net. SOC 2 cost: $60,000/year ongoing after certification. Net return: $140,000/year. Break-even: within 18 months of first mid-market revenue.

Recommendation:

Start with the governance infrastructure that mid-market customers actually require (immutable audit trail, permission controls, documented rollback procedures), which is a 4–6 week engineering investment. This is valuable regardless of SOC 2 and addresses the underlying requirement.

Simultaneously, begin the SOC 2 preparation process — it is a 12-month minimum commitment, so starting now means certification in approximately 18 months. Don't delay it, but don't gate the mid-market motion on it. Close the first mid-market deals with the audit trail + documentation package while the SOC 2 audit period runs.

Self-assessment checklist:

• Did you distinguish between what SOC 2 certifies and what mid-market accounting customers actually need?
• Did you calculate the revenue return on the SOC 2 investment with specific numbers?
• Did you identify a path to the first mid-market deals that doesn't require waiting 18 months for certification?

The founder is conflating who makes the final purchase decision (GCs and CLOs, who do buy through relationships) with who generates the proof of value that enables that decision (individual attorneys and paralegals, who do self-serve). This is a common enterprise GTM mistake: optimizing for the decision-maker instead of the value-generator.

Is the claim true? Partially. GCs and CLOs do not sign up for free trials and self-serve to an enterprise contract. But they also do not buy something their teams have not already tested and validated. The question is not "do GCs self-serve?" — it is "how do GCs get the evidence they need to approve a purchase?"

In legal technology specifically: individual associates evaluate tools on their actual work, share results with partners, and partners bring them to GC attention. Harvey's growth pattern — 42% of Am Law 100 firms — was not driven by GC cold outreach. It was driven by associates using the product, partners seeing the output quality, and management formalizing the adoption.

The PLG motion for legal AI:

• Free tier for individual attorneys: limited queries per month, no firm-wide data access, no SSO required
• Result sharing: attorneys can share research outputs (with citations) as links to colleagues — this is the natural share mechanism for legal work product
• Team analytics: once 3+ attorneys at the same firm are using the product, surface a "your firm" usage summary that the managing partner or GC can see
• Enterprise triggers: usage above a threshold (10 attorneys, 50 queries/month) triggers an automatic enterprise conversation with the firm's administrator

The 22-month sales cycle diagnosis: Almost certainly caused by: (1) no usage data from individual attorneys to accelerate procurement trust; (2) security and compliance review that takes 6+ months without SOC 2 / confidentiality documentation; (3) firm IT approval required before individuals can even test.

The fix: unblock individual evaluation first (sandbox with anonymized case examples), parallelize the compliance documentation (SOC 2 preparation, attorney-client privilege considerations for data handling), and let the individual usage pull the enterprise procurement forward.

What I would not do: Add more enterprise sales reps. At 22-month sales cycles and $3M runway, more sales reps extend runway by 0 months and add burn. The only lever that shortens the sales cycle structurally is individual usage data that the procurement team trusts more than vendor claims.

This is the "invisible autonomy on high-risk systems" anti-pattern from Chapter 05, applied to external communications. The answer is not "never build this" — the answer is "not without specific governance architecture that the VP hasn't described."

Why this is high risk: External communications are irreversible by definition — once an email is sent, the recipient has it. The failure modes are serious: (1) personalization errors that reference incorrect information about the prospect create reputational damage and signal poor data quality; (2) outreach to contacts who have unsubscribed or requested no contact creates legal liability (CAN-SPAM, GDPR); (3) outreach to contacts in active deals where the sales team has established a specific communication strategy can derail the deal.

The 10x volume claim is correct — but 10x outreach volume with a 5% error rate is also 5x the outreach errors. The question is not the volume multiplier; it is the error multiplier.

The governance architecture required:

1. Send queue with review window: Drafted emails are queued for 4 hours before sending. The sales rep receives a notification with a preview and a one-click approve/defer/cancel action. If no action is taken in 4 hours, the default behavior (send vs. hold) should be configurable — but for new contacts, the default should be hold.

2. Suppression list integration: Before any email is drafted, check the contact against: unsubscribed list, active deal contacts, blocked domains, and contacts flagged as "relationship managed directly." If any flag is set, skip the contact and log why.

3. Personalization validation: The personalization fields (company name, recent news, relevant products) should be validated against the CRM record before they appear in the draft. If the CRM record is incomplete or the personalization confidence is below threshold, the draft should flag the uncertain fields rather than hallucinating data.

4. Audit trail: Every AI-drafted email, with the CRM data that drove the personalization, should be logged immutably. If a recipient complains about incorrect information, the audit trail shows exactly what the agent knew when it drafted the email.

The version I would approve: Draft → review → send, with the 4-hour review window and suppression list integration. Not automatic send. The marginal productivity loss of a 4-hour window is small; the reputational and legal risk of fully autonomous external outreach is not.

The CEO's framing is correct — governance as competitive advantage — but the two lost deals to SOC 2 are a symptom of a broader gap, not the root problem. SOC 2 is an output of a governance discipline; building the discipline produces SOC 2 as one artifact among several.

My answer to the CEO:

"Two deals lost to SOC 2 is telling us that our customers have reached the procurement stage where they're doing security reviews, and we can't pass them. That's actually a good sign about deal quality — these are serious buyers. SOC 2 is the right investment, but it's not the only investment we need to make in the next 12 months.

Here's how I'd think about it:

Immediate (0–3 months): Close the gaps that are losing deals today. SOC 2 takes 12–18 months to certify. But security questionnaires are won or lost on the underlying controls, not the certification alone. I'd audit which specific questions on those security questionnaires we're answering 'no' or 'in progress' to, and fix the ones that can be closed in 90 days: immutable audit logging, access control documentation, incident response playbook, penetration test completion. These are also the SOC 2 prerequisites — we're not wasting work.

Medium term (3–12 months): Build governance into the product, not just the company. Governance controls embedded in the product — audit trail, permission scoping, sandbox mode, rollback capability — are a sales asset we can demo. When a CISO asks 'what happens if your agent takes a wrong action,' we show them the rollback capability, not describe it. Product-level governance is more persuasive than policy documentation.

Ongoing: Use the governance maturity model as a sales qualification tool. Most of our enterprise prospects are at 'Ad Hoc' or 'Defined' governance maturity. We're building toward 'Managed.' The gap between where they are and where they need to be for their own compliance obligations is a reason to choose us — we're helping them advance their governance maturity, not just selling a product.

SOC 2 certification by month 15 is a clear milestone. But I'd measure success earlier by: number of security questionnaires where we're scoring 'yes' on all major controls, and deal velocity improvement in regulated verticals."

Both arguments are partially correct, and the decision turns on a question neither side has asked: where does the user need the agent's output, and is mobile the surface for that need or just a discovery channel?

Evaluating the "for mobile" argument: The argument is valid as a distribution claim — users are on Slack on mobile, so they're already in a workflow context where agent output would be useful. But Slack is the notification surface. The question is whether the action the user needs to take on finding a relevant document requires a mobile-optimized interface, or whether the notification ("here's the answer to your question") is sufficient to render in Slack without a native app.

For knowledge retrieval use cases (find the relevant document, surface the answer to a question), a mobile-optimized result view within the existing Slack integration may capture 80% of the mobile value without a native app.

Evaluating the "against mobile" argument: The Microsoft and Google failures in enterprise search are instructive: they failed because enterprise search on mobile produces the same results as enterprise search on desktop, but on a smaller screen with less precise interaction and less context about what the user is currently working on. Mobile enterprise search failed because it was desktop search on mobile — not because mobile is wrong for the product category.

A modern agent with awareness of the user's current context (active meetings, recent Slack activity, recent documents opened) can provide a meaningfully better mobile experience than desktop search simply ported to mobile. The failure mode is "desktop search on mobile." The success mode is "what do you need right now, given what I know you're doing."

The recommendation: Don't build a native mobile app as the first investment. Instead, optimize the Slack integration for mobile consumption (result formatting that renders well on mobile, answer-style responses that don't require clicking through to a full search interface, action buttons that work on mobile). Instrument mobile usage of the existing product to determine: how many users are accessing Glean on mobile, what queries they're running, and whether the current desktop-first interface creates frustration on mobile.

Build a native mobile app only after validating that mobile usage is a significant share of total usage AND that the Slack integration cannot adequately address the mobile use case. The development cost and maintenance overhead of a native mobile app is significant; validate the demand before committing to it.

This is a governance, legal, and product strategy question that is being framed as a feature prioritization question. The VP of Sales characterization ("table stakes") and the CTO characterization ("4-week build") are both potentially correct and both miss the more important question: what exactly is the feature doing, and what are the legal implications of each version of it?

First, decompose what "Agent-Led Growth" means in practice: There are multiple versions of this feature with very different legal profiles:

Version A: The agent identifies users who are not currently using certain features and sends them an in-product nudge (a contextual suggestion: "You might also want to try X — here's how it works"). This is a personalization feature. It uses data generated within the product. It is not a communication to a third party. GDPR implications are minimal for users who have consented to the product's data processing.

Version B: The agent analyzes user behavior to identify potential internal champions and notifies the sales team (the vendor's sales team) that contact X at company Y should be targeted for expansion. This involves the vendor processing the customer's users' behavioral data to generate sales intelligence for the vendor. This is a more significant GDPR implication — the customer has to consent to their users' behavioral data being used by the vendor for the vendor's own commercial purposes.

Version C: The agent automatically sends expansion outreach to internal users at the enterprise customer, without those users having opted into receiving such communications. This is the highest legal risk version and almost certainly the one the VP of Legal flagged.

The decision:

Build Version A immediately — it is a personalization feature with minimal legal complexity and directly addresses the product usage gap. If users are not using features that would make them champions, in-product education and contextual nudges address that.

Build Version B with explicit customer consent in the contract. Some customers will grant the vendor permission to receive champion identification signals; many will not. Make it an opt-in analytics feature with a clear data usage description in the contract.

Do not build Version C without a legal review that confirms it is compliant with GDPR, CAN-SPAM, and the customer's employee communication policies.

How to respond to the VP of Sales: The three stalled deals need decomposition. What specifically did the prospects ask for — is it in-product expansion nudges (Version A) or vendor-side champion identification (Version B)? Build Version A, close those deals with it, and determine whether Version B with opt-in is needed.

How to work with the VP of Legal: Ask for a written opinion on each version with timeline. "Raises GDPR issues" is not an answer; "Version A is compliant, Version B requires customer consent in the DPA, Version C is not viable" is an answer. The legal team needs to give you a specific ruling, not a flag.