This post is for our Paid Subscribers. If you haven’t subscribed yet,
Clarifying Questions
Before diving in, I would want to align on scope across a few dimensions that will meaningfully shape the product direction.
What content sources need to be indexed? “Enterprise search” could mean searching across internal documents and wikis (competing with Glean, which was founded in 2019 and last valued at roughly $4.6 billion, or Microsoft Search), searching across connected SaaS tools like Slack, Salesforce, Google Drive, and Confluence, or a hybrid of both. The integration surface area differs dramatically and resolves where we invest first in the engineering roadmap.
Is the core problem findability or synthesis? Findability means the employee knows something exists and cannot locate it. Synthesis means they want a single coherent answer assembled from multiple scattered sources. These point toward fundamentally different technical architectures: traditional index-and-retrieve versus an AI-native question-answering layer on top of retrieval.
What company size is this built for? A 300-person startup and a 60,000-person enterprise have very different existing tooling, procurement cycles averaging 6 to 9 months for large organisations, security review depth, and integration complexity. The answer shapes pricing model, self-serve versus sales-led go-to-market, and which integrations to prioritise at launch.
How central is compliance to the buying decision? Industries like financial services, healthcare, and legal have regulatory overlays (SOC 2, HIPAA, FedRAMP) that elevate permission handling from a product quality concern to a legal one, and would require a different certification roadmap and potentially a separate, isolated deployment model.
Are there existing search tools in place? If the target customer is already paying for Microsoft Search or Elastic App Search internally, we need to understand what gap we are closing rather than assuming a greenfield deployment, which affects both positioning and the switching-cost hurdle in sales.
For this answer I will assume we are building a unified enterprise search product targeted at mid-size to large companies (roughly 500 to 20,000 employees), indexing across the five most common SaaS surfaces: Slack, Google Workspace or Microsoft 365, Confluence, Salesforce, and internal wikis. Permission-aware retrieval is a foundational, non-negotiable architectural requirement given the sensitivity of enterprise content. The primary user problem is findability, with synthesis as a medium-term layer on top. We are operating in a sales-led model with IT and security teams as the primary buyers.
Product Description
The global enterprise search software market was valued at approximately $3.9 billion in 2023 and is projected to grow at a compound annual rate of around 11 percent through 2030, driven largely by the explosion in SaaS adoption over the past decade. The average knowledge worker now uses 9 to 12 distinct software tools per day, and McKinsey research has estimated that employees spend roughly 20 percent of their working week, close to one full day, searching for information or tracking down colleagues who have it. That structural inefficiency is the market opportunity this product is designed to close.
The product gives an employee a single search surface across every connected company data source: Slack messages and channels, Google Docs and Drive folders, Confluence spaces, Salesforce records and opportunity notes, and internal wikis. Results are ranked by relevance and recency and are filtered in real time through each source system’s existing access controls, so a user only ever sees content they already had permission to view in the originating system. The product competes most directly with Glean (which charges roughly $25 to $30 per user per month at scale), Microsoft Search (bundled into Microsoft 365 at no incremental cost, creating a significant pricing headwind for any standalone product), and to a lesser extent Notion AI and Guru. The primary differentiator is permission fidelity: any leakage, surfacing a document a user should not see, is not a product quality miss but a security and compliance failure, which is why the access-control architecture is the first and most important engineering investment before any other feature work begins.
Revenue is generated on a per-seat, annual-contract SaaS model, typical for this category, with enterprise deals often including a professional services component for integration setup and security review. The central strategic tension is speed of integration breadth versus depth of permission reliability: expanding to more source connectors faster drives sales conversations, but any permission failure in a newly added connector can undermine trust in the entire platform, making the expansion-versus-reliability tradeoff the central ongoing product decision.
Define Goal
The core problem is that enterprise information is fragmented across a growing number of disconnected SaaS tools, and employees lack a reliable, single place to search across all of them simultaneously, leading to wasted time, duplicated effort, and decisions made on stale or incomplete information.
The goal I want to focus on is increasing the frequency with which employees successfully find the information they need through the unified search product, rather than falling back to manual multi-tool hunting, within the first 90 days after deployment at each customer.
The north star metric I would track is weekly search success rate: the percentage of search sessions in a given week where the user clicks a result within the first three results and does not immediately reformulate the query or abandon the session, measured across all active users. I prefer this over raw weekly active users (WAU) because WAU can be inflated by employees who try the tool once out of curiosity and then abandon it. It is more meaningful than total search volume because volume grows with adoption but does not tell us whether searches are actually resolving user intent. And it directly captures the product’s core promise: that one search reliably finds what you are looking for. A reasonable target for a maturing deployment is a session success rate above 78 percent within 60 days of go-live, based on benchmarks from comparable enterprise search deployments in the knowledge-management category.
User Segmentation
Knowledge Workers
High-frequency searchers (individual contributors, all departments): typically 25 to 45 years old, using 8 to 12 SaaS tools daily, spending an estimated 1.5 to 2 hours per day context-switching between tools to find information. High churn risk if the product consistently returns irrelevant or stale results, since they will revert to habitual workarounds within 2 to 3 weeks of a bad experience.
New employees (0 to 90 days tenure): any age, but lacking the accumulated institutional knowledge that longer-tenured employees use to shortcut information-finding (”that’s always in the old Confluence space”). They have an especially acute version of the core pain and represent the highest-value, easiest-to-convert segment because they have no competing habits to displace yet.
Executive and cross-functional leads: typically VP-level and above, searching less frequently but for higher-stakes synthesis rather than single-document lookup. They want a summary of “what is the current status of Deal X” more than a list of 15 matching documents, pointing toward the AI-synthesis layer as a later-stage priority specifically for this segment.
IT and Security Administrators
IT and security gatekeepers: typically 30 to 50 years old, responsible for approving and maintaining enterprise software deployments. Their primary concern is access control correctness and audit logging, not search relevance. They do not use the product daily but their confidence in the permission architecture is the single biggest determinant of whether the product is approved for company-wide rollout. They represent roughly 2 to 5 percent of a customer’s seat count but carry disproportionate influence on the buying decision.
I will focus this answer primarily on high-frequency knowledge workers and new employees, because they represent the largest volume of daily search sessions (and therefore the most direct signal on whether the core product is working), and because new employees offer a natural, habit-free entry point for driving initial adoption before extending to longer-tenured employees who have existing workarounds to displace.
Pain Points
The following pain points are synthesised from published research on enterprise knowledge management, user research patterns reported by tools in this category, and common themes from enterprise productivity literature. I am separating by user type given the meaningfully different pain profiles on each side.
