AMA with Anagh Prasad | Scaling Your Vertical AI Startup

Company evaluation framework for Vertical AI (Anagh Prasad, Axel)

High-level lens

Evaluate problem fit + buyer + architecture for differentiation/defensibility + early traction rather than “AI model quality” alone.

---

1) Picking the right problem, market, and timing

Timing and risk weights

• Timing (low risk / already favorable): Foundation models are “good enough” to provide a strong head start across many verticals now.
• Team (highest priority): ~50% weight.
• Right problem (very high priority): ~30% weight.
• Long-term defensibility via system architecture: ~15% weight.
• Risk from foundation models: ~5% weight (Incumbents will enter, but execution + architecture can offset.)

What to look for in the vertical/problem (2-layer view)

• AI-friendly workflows for knowledge workers (where AI helps with unstructured data).
• Unstructured data + stitching/synthesis/summarization across sources to complete a professional task.

“80/10/90” workflow insight (operational reality)

• Most value = 80% from pre-processing / grinding:
  • fetching history
  • past actions
  • preparing inputs
• Model inference time = 10% of the work
• But pre-processing can be 90% of the time effort → Vertical AI assistants can win by automating this.

Adoption / friction lens

• How does the assistant affect the existing workflow?
• Does it reduce friction or require workflow disruption?

Founder expertise principle

• Prefer deep domain expertise early (co-founder/adviser; exceptions exist).
• Example: for healthcare, prefer someone with:
  • healthcare software sales/ops/medical background
  • plus AI expertise from founders

Concrete example (investment rationale)

• Axel excitement about Bridgetown / Hush:
  • unique combination of an Amazon AI research scientist + McKinsey consultant + consulting builders
  • hard to find in one person
• Axel also looks for complementary skills (e.g., deep AI + healthcare ops/sales)

---

2) Early MVP execution + GTM (don’t separate execution from distribution)

All-at-once requirement

• You can’t do “MVP only” without GTM—they must move together.

Core MVP characteristics

• UI embedded into the target professional’s workflow.
• Right data loops / feedback mechanisms to improve differentiation/defensibility over time.
• High model performance expectations:
  • avoid shipping with low accuracy.

Accuracy bar (practical fundraising/retention risk)

• Expectation: ~75–80–90% accuracy for most verticals.
• Low accuracy (e.g., 30–60%) makes it hard to retain patience while improving.

Customer discovery + iteration process

• Criticism of “building in a silo” and restarting after limited conversations (e.g., “40 customer conversations” → rebuild).
• Instead: keep customers close via design partner feedback for every feature release.

Sales timeline expectations + momentum

• Some cycles are long (e.g., ~6 months in large healthcare contexts).
• But it should not stretch to ~12 months early on.
• Slow early sales can kill the business by harming momentum for:
  • revenue
  • further funding
  • hiring
  • team growth

Traction definition (more than revenue)

Prioritize:

• Usage
• Whether it creates ROI
• “Customer love” signals (customers smile / feel it helps when you call)

Monetization caution

• Avoid too much monetization too early—can harm long-term prospects.

Design partners as “co-creators”

• Pick carefully.
• Don’t over-optimize to avoid churn.
  • Example logic: if you have 5 design partners and lose 4 after 6 months, that can be healthy because you learned what fits your ICP and found the right one.

Sales “wedge” strategy (simple and direct)

• A revenue wedge (increases revenue) unlocks more business model options:
  • revenue share
  • usage-based
  • outcome-based
• A cost wedge (decreases costs) works best when you cut direct costs (especially if the workflow is already outsourced).

Concrete revenue wedge example

• AI receptionist for hotels/restaurants that drives more conversions (capture late/night/busy-time calls).

Common trap: selling what enterprises want vs what customers need

• Enterprises may push “AI initiatives” as a board-level agenda and treat pilots as internal training.
• Founders should ensure product/customer fit:
  • if a customer isn’t the right fit, don’t onboard (even if it risks losing the customer).

PLG vs sales (often confused)

• PLG requires user autonomy and minimal onboarding delay (self-serve).
• Many vertical workflows don’t allow users to try freely.
• If users aren’t allowed to use tools, aren’t searching for tools online, or lack autonomy → classic sales motions fit better (top-down outbound/inbound).

Go-to-market geography advice

• Start global-minded, but target the largest market (often US) early.
• Target the US as soon as possible because it’s the largest software market.
• Starting in India is okay with strong partners, but avoid overcommitting to a geography that’s too small (risk: competitors enter from a larger market).

---

3) Competitive landscape + “traps” (how to avoid being outflanked)

Incumbents will enter—differentiate anyway

• Foundation models/incumbents will enter.
• Focus on defensibility via:
  • architecture
  • ongoing differentiation

Example: Cursor vs GitHub Copilot

• Cursor competes with GitHub Copilot (first mover with Microsoft resources).
• Takeaway: niche doesn’t fully constrain application success when users love the product.
• Differentiation levers:
  • evaluation mechanisms
  • feedback loops / data improvements

Business-side capability matters

• Technical credibility isn’t enough.
• Look for whether the team understands the business/evaluation/feedback system.
• Advisory stance: back founders who either:
  • build the business themselves, or
  • partner with someone for the business side.
• Warning: “Best tech no one wants” problem:
  • teams may spend a year building something unusable if business thinking is missing.

---

4) Moat/defensibility + scaling (and why timing beats premature “castle building”)

Moat-too-early caution

• Don’t obsess over moat at “paper stage” or with only a few customers.
• Moat = castle defense, which becomes real only after you build the castle.

How moats build

• Customer love + early brand (often becomes the moat)
• Switching costs grow by capturing deep workflow actions over time
  • example archetype: SAP/Salesforce system-of-record playbook
• Platform centrality / super-stikiness
  • if stakeholders must use your platform to communicate, switching becomes harder
  • analogy: “Slack for this vertical”
• Incremental technology via proprietary feedback/eval
  • usage improves the platform over time

Speed vs perfect proprietary build

• Sometimes ship faster rather than building “perfect full stack proprietary” immediately.
• Velocity + timing can matter more early.

Illustrative case: Harvey (legal vertical)

• Harvey began with an email to OpenAI after good results for lawyers using earlier GPT versions.
• It attracted OpenAI interest and became an investor.
• Takeaway: early market timing + workflow focus can drive early share, then proprietary data/tech can compound.

---

KPIs / targets explicitly mentioned

• Accuracy expectation (model quality):
  • 75–80–90% (implied threshold)
  • 30–50–60% is considered too low to sell confidently
• Sales cycle guardrails:
  • Example long cycle: ~6 months in large healthcare
  • Avoid stretching early sales to ~12 months
• Design partner engagement example:
  • Starting with ~5 design partners; losing 4 after ~6 months can be acceptable if you’re learning ICP fit
• Traction (not quantified):
  • usage + ROI + “customer love” signals prioritized early (even if revenue is absent)

---

Actionable recommendations / playbooks extracted

• Fundamentals to prioritize early
  • Put 50%+ weight into team, ~30% into the problem, ensure architecture enables long-term defensibility.
• Design the workflow-first product
  • UI embedded in the professional workflow
  • engineer data loops to collect feedback and improve over time
• Meet accuracy and adoption requirements
  • target 75–90% quality to avoid churn/sales resistance
  • reduce workflow friction; adoption depends on fit with existing work
• GTM tied to execution
  • keep design partners in the loop for every feature release
  • define traction as usage + ROI/customer love, not only revenue
• Use “wedge” logic
  • revenue wedge > cost wedge (cost wedge strongest when cutting direct costs)
• Avoid the enterprise AI pilot trap
  • only onboard customers with strong problem/ICP fit; board-level “AI initiatives” can misalign incentives
• Choose the right motion
  • PLG only when users have autonomy and can self-serve immediately
  • otherwise use classic sales
• Geography strategy
  • default to the US market early unless a strong partner makes another market strategically viable

---

High-level investing/valuation notes (kept general)

• Examples across ARR/valuation ranges suggest no single required Series A scale:
  • < $1M ARR raising at ~$200–$300M valuation
  • ~$4M ARR raising at ~$40M valuation
• Conclusion: outcomes reflect investor demand/supply and whether earlier fundamentals (problem, architecture, traction) are in place.

---

Examples / case studies referenced

• Bridgetown / Hush (Axel investment excitement; founder background mix)
• Harvey (legal AI): outreach to OpenAI, workflow-first approach, early GTM/timing
• Cursor vs GitHub Copilot (coding vertical competition + differentiation via platform/evals)

---

Presenters / sources

• Anagh Prasad (Investor, Axel)