48 Hours as Mintlify's Founding PM — Right Before Their $45M Series B

Mintlify just raised $45M to become knowledge infrastructure for AI agents. Here is the product strategy I built during their founding PM interview, and the upstream gap I think nobody has solved yet.

Published: 2026-04-22

Last week, Mintlify announced a $45M Series B at a $500M valuation, led by a16z and Salesforce Ventures. Their CEO, Han Wang, describes the thesis as "Documentation isn't something people read anymore. It's infrastructure that agents run on" in his LinkedIn post. AI agents now account for nearly 50% of traffic across Mintlify's 20,000+ customer documentation sites. That number was 15% at the start of 2025.

I read the announcement with a particular kind of recognition. A few weeks earlier, I had spent two days doing exactly the work a founding PM at Mintlify would do: customer discovery, hypothesis mapping, competitive analysis, a product bet. All of it as part of their interview process for that role.

I did not get the job. The thinking stayed.

I'm sharing this because the Series B gave a public timestamp to a set of questions I had already been sitting with. The most interesting tension in Mintlify's story, the one the announcement doesn't fully address, is still unresolved. That gap is where I think the next important product gets built.

How I Got in the Room

I was in conversation with Mintlify for a founding PM role. Before my first interview, I did what I'd do before any serious early-stage conversation: read everything public I could find. Mintlify had quietly acquired Trieve, a RAG and search infrastructure startup, just months earlier, which suggested they were building deeper into the retrieval layer. Recently, their co-founder also shared on LinkedIn that they had refactored their assistant away from semantic search entirely, toward a faster grep-based file system approach. Two signals pointing in different directions. What they agreed on was that Mintlify was actively rethinking how AI consumes knowledge at a fundamental level, and the founding PM role sat right at the center of that question.

For the take-home assignment, I was given access to a real customer discovery session and asked to do what a founding PM would actually do with it: extract the signal, identify what was left unexplored, form hypotheses, and propose a product bet with a validation path.

What I actually did was treat it like a real discovery sprint rather than an interview exercise. I ran my own informal interviews with engineers, engineering managers, data scientists, and product managers across the industry to pressure-test what I was seeing. I built an affinity diagram and a hypothesis map before landing on a product bet. The result was a 3,000-word structured response with supporting visual attachments.

The process gave me a sharper view of Mintlify's opportunity than I expected. Here's what I found.

What the Assignment Sent Me Looking For

The take-home centered on a customer discovery session Mintlify had conducted with one of their power users. I won't share specifics from that interview. It was shared as part of a confidential hiring process, and the customer spoke candidly to a vendor rather than to the public. That line feels worth respecting.

What I can say is that the interview surfaced a set of signals that didn't feel fully explored, which is enough to send me down a research path of my own by talking to engineers, engineering managers, data scientists, product managers, and non-technical SMEs at tech companies ranging from early-stage to large enterprise. What came back was consistent enough to expose broader patterns implicating product opportunities.

What My Own Research Added

Four patterns came up repeatedly, independent of company or role.

1. Knowledge isn't created completely in the first place.

A data scientist described the problem precisely: in cross-functional projects, information doesn't get lost in transit, it was never complete to begin with. An engineer and a data scientist working on the same product may share vocabulary around code but diverge entirely on ML terminology, and neither understands the infrastructure layer. The result is a web of partial understanding across roles, with no shared surface to reconcile it. A software engineer working on recommendation systems described the same dynamic at the data layer: tables lack metadata, source-of-truth ownership is unclear, and the design decisions behind a schema often live only in the head of the engineer who wrote it years ago.

There is a subtler version of this problem worth naming. A staff engineer in LLM infra observed that writing documentation is often not a knowledge-transfer exercise at all. In many companies, design docs have become organizational artifacts, written to claim scope or demonstrate output, rather than genuine attempts to transfer understanding. The act of structuring knowledge for others is slow, politically loaded, and frequently deprioritized the moment the code ships.

2. The breakdown happens in translation across roles, not in retrieval.

A senior engineering manager noted that the core challenge in cross-functional collaboration sits in the gap of logical structure between how different roles organize their thinking. Non-technical stakeholders surface fragmented requirements that technical teams struggle to generalize from. Many people also lack the ability to synthesize and structure their own thinking before committing it to writing, which no tool alone can fix. A product MLE described the best cross-functional collaborator she had worked with as someone who could extract the essence of an engineering conversation and translate it into language other stakeholders could act on. That skill is rare, valuable, and almost entirely unaddressed by current tooling.

3. The most important knowledge lives in the most ephemeral places.

Across conversations, this pattern was consistent: drafts start in Google Docs, decisions live in Slack, context gets buried in meeting recordings. An engineering manager described wanting something that gathers those fragments and converts them into a doc update recommendation for a human to confirm rather than an autonomous workflow. The bottleneck is less about AI's ability to surface information and more about the absence of a workflow that brings scattered fragments together and makes the confirmation step low-effort enough to actually happen.

The implication for product design is direct: the best knowledge tools don't ask users to context-switch. A software engineer reflected that his preference was always IDE-integrated agents that have direct access to the codebase and can generate documentation where the work already happens. The tools that win are the ones that reduce the distance between where knowledge is created and where it gets structured.

4. AI's highest-leverage role in this workflow is translation, not generation.

The most underappreciated insight across these conversations was that AI's value in knowledge workflows comes from translating knowledge across roles and formats, rather than writing documentation from scratch. From engineering discussions into language a PM can act on, from a domain expert's explanation into something an engineer can implement, from a Slack thread into a structured doc a team can trust. A supply chain specialist noted that communicating domain expertise to engineers is slow, error-prone, and often happens only after the product is already built. The cost of that translation gap compounds through every iteration cycle.

The Product Bet That I Made

Given the discovery work, my proposed bet was this:

Build a cross-functional knowledge capture and translation workflow, starting with Google Docs and Slack, that turns messy work-in-progress content into structured, AI-ready knowledge.

The workflow has three steps.

The key design principle is that AI handles translation while humans confirm before anything becomes the record. This is a workflow play, not an automation play. The goal is reducing the cost of going from rough input to structured output while preserving the human judgment that makes organizational knowledge trustworthy.

Why this, and why now?

Mintlify already has the right destination surfaces: a browser-based web editor built for non-technical contributors, an internal knowledge-base product, a Slack integration that captures knowledge from conversations as well as answering questions, and an agent that monitors pull requests, flags outdated content, and drafts updates from multiple sources. The infrastructure for the downstream layer is being actively built. What is missing is the upstream bridge from how knowledge is actually created, by people in tools they already use, to the structured format that agents and teams can rely on.

The AI opportunity here is specifically in structuring, not generating. The people I spoke with were not asking for AI to write their documentation from scratch. They were describing workflows where raw material already existed but the cost of converting it into something structured and publishable was too high to do consistently. That is a tractable problem, and no current player has solved it well.

Who to target first?

One engineer from a big tech company I spoke with made an observation worth sitting with. Large enterprises have already built internal solutions. The real market is the long tail of mid-size and non-tech companies who cannot build their own. That shapes the go-to-market significantly. Rather than leading with enterprise deals, the better wedge is cross-functional champions at small to mid-sized software companies: product managers, program managers, internal knowledge owners, and customer-facing teams who feel the translation gap every day but have no dedicated tooling to address it.

Who Mintlify Is Now Competing With

The Series B repositioning as "knowledge infrastructure for AI agents" didn't just upgrade Mintlify's narrative. It put the company on a collision course with multiple categories simultaneously.

Before mapping the live competitive tensions, one zone is worth naming and setting aside. Docusaurus, ReadMe, and open-source alternatives like VuePress lack the AI-native features that are now table stakes. Mintlify has largely won this zone. The Series B is about what comes next rather than defending against these players. The competitive map below organizes what does matter by the layer of the knowledge stack each player owns.

Competitive landscape on the knowledge stack

Creation: where Google is already entrenched.

Google Workspace is where most non-technical knowledge creation already happens, and since January 2025 Gemini AI features have been embedded directly into Google Docs, Sheets, Slides, Drive, and Chat across all Business and Enterprise editions at no additional cost. As of March 2026, the assistant can synthesize information by scanning storage, emails, and chat history to build comprehensive first drafts, turning Google Docs from a writing tool into an active knowledge surface. Gemini Enterprise goes further, functioning as an intranet search, AI assistant, and agentic platform with prebuilt connectors for Confluence, Jira, Microsoft SharePoint, and ServiceNow. Notion rounds out this layer as the collaboration-native alternative, deeply embedded in how cross-functional teams draft and share knowledge. The strategic implication is direct: if Gemini makes content AI-ready from within the tool where it was created, the case for moving it into a separate structured platform becomes harder to make. Google is not attacking Mintlify's developer documentation stronghold. It is surrounding the upstream creation layer that Mintlify has not yet built a strong claim on.

Translation: the layer with no clear owner.

Several tools touch pieces of this space. Slack AI captures and summarizes threads but keeps knowledge inside Slack. Automation connectors like Zapier and Runbear can move raw text between platforms but do not structure or translate it. Ecosystem-native tools like Notion AI bridge Slack conversations into Notion pages and keep knowledge within their own platform. What does not yet exist is a dedicated, cross-platform workflow that takes Google Docs drafts, Slack threads, and meeting recordings and converts them into structured, human-confirmed, AI-ready knowledge that lands in a durable destination. The product bet in the previous section was built around closing exactly that gap.

Structure and publish: Mintlify's core strength, under pressure from fast followers.

Mintlify's web editor, internal knowledge-base product, Slack integration, and agent workflows that monitor pull requests and flag outdated content represent a meaningfully differentiated position in this layer. Other players are following fast. GitBook has quietly built a WYSIWYG block editor that lets non-technical users contribute without touching Markdown, and has added a proactive AI agent that connects with Slack and Intercom to surface knowledge gaps. Documentation.AI, launched in late 2025, undercuts Mintlify's Pro tier on pricing while explicitly targeting mixed technical and non-technical teams. These players are not threatening Mintlify's developer base. They are competing for the non-developer TAM that Mintlify's editor investment and founding PM hire were both meant to unlock, and that is a meaningful flanking risk on exactly the side of the market Mintlify is actively trying to grow into.

Retrieval: converging on Glean's territory.

Glean approaches enterprise knowledge from the retrieval side, indexing what already exists across more than 100 enterprise tool connectors including Slack, Confluence, Google Drive, GitHub, and Jira, then surfacing it on demand with permission-aware controls. Mintlify approaches from the structure side. They are converging on the same enterprise buying decision from opposite directions. The scale gap is still significant: Sacra estimates Glean at roughly $208M in revenue in 2025 versus Mintlify at $10M. But Mintlify's structural advantage is that it starts from documentation quality and maintenance rather than pure storage and retrieval, which matters more as the accuracy of agent-consumed knowledge becomes a competitive differentiator. Notion AI also competes here, with external connectors on Business and Enterprise tiers pulling results from Slack, GitHub, and Google Drive directly into the Notion interface.

AI agent delivery: Mintlify's Series B bet, the most contested layer ahead.

The llms.txt standard and MCP server support by Mintlify signal its intent to become the protocol layer through which products communicate with AI agents. The acquisitions reinforce this: Trieve in July 2025 deepened RAG infrastructure, and Helicone in March 2026 added LLM observability and AI gateway capabilities. These are infrastructure moats, not feature additions.

Note that Mintlify is not building into an empty layer. Glean now powers more than 100 million agent actions per year and has launched a full agentic platform with its own MCP capabilities, SDKs, and a second-generation agentic engine that enables agents to plan, execute, and adapt across enterprise workflows. Glean spans both the Retrieval and AI Agent Delivery layers simultaneously, building upward from retrieval while Mintlify builds downward from structure. They are approaching the same destination from opposite ends of the stack. The longer-term ceiling risk comes from the hyperscalers: Microsoft Copilot embedded across SharePoint and Teams, and Gemini Enterprise at scale, could absorb the agent-facing knowledge layer narrative at enterprise level before either Glean or Mintlify fully consolidates the space.

What the Series B Validates — and What It Leaves Open

The $45M round validates several things clearly.

The Series B also surfaces a tension the announcement doesn't resolve.

Mintlify is going deep on the bottom of the knowledge stack: retrieval, structure, and observability. That is a defensible technical moat and the right bet for serving AI agents. But the top of the stack, how messy human-generated knowledge gets created, translated, and maintained in the first place, is still largely unsolved and increasingly contested.

GitBook is competing there. Notion AI is encroaching from the collaboration side. Google Gemini is surrounding the creation layer from within the tools people already use. And the non-developer users that Mintlify's editor investment was meant to serve still have no clean workflow for getting content from Google Docs into Mintlify without significant manual effort.

I think the founding PM role Mintlify was hiring for was to help navigate exactly this tension: how do you expand the content creation surface to non-developers while simultaneously repositioning as AI infrastructure? Those are not the same product problem, and they do not necessarily share the same roadmap.

That conversation between Mintlify's leadership and myself is where things got complicated. I had arrived with a bet on the upstream creation and translation layer. The direction of the conversation suggested that Mintlify's primary focus was the infrastructure layer downstream. We were not talking about the same time horizon, and possibly not the same user.

I don't think either view was wrong. I think they were optimizing for different parts of a problem that is genuinely large.

Where the Next Product Gets Built

Here is the tension I keep returning to.

Every company that wants to compete in an agent-first world needs a knowledge layer that is accurate, structured, and continuously updated. That is Mintlify's thesis and it is correct. However, AI systems are only as good as the knowledge they are built on. Most organizations' knowledge today is not structured. It is scattered across Slack threads, Google Docs comments, meeting recordings, and the working memory of people who have not written anything down.

Mintlify is building the infrastructure for knowledge that has already been structured. The harder, messier, more human problem, which is how organizations actually get their knowledge into that state, remains largely unsolved.

Glean retrieves what already exists. Mintlify publishes what has been organized. The gap between raw human knowledge and machine-ready content is the layer nobody has cleanly owned. That gap does not require a new category. It requires a product that starts where knowledge is actually created, in the tools people already use and in the formats that already capture their thinking, and reduces the cost of translation to near zero.

The companies that get this right will not just help teams write better documentation. They will become the connective tissue between how humans communicate and how AI systems understand. That is a much larger surface than developer documentation.

For Mintlify, it is an adjacent problem. For a new entrant, it is the whole product.

A Note on Method

I want to be transparent about something structural in how I approached the Mintlify opportunity, because it reflects how I think about 0-to-1 problems generally.

I didn't just prepare for the interview. I did the job. I ran customer discovery, synthesized signals, built hypotheses, stress-tested them against additional research, and arrived at a product bet I could defend. The interview was the occasion, not the point.

This is how I evaluate any early-stage opportunity I am serious about: by doing enough of the actual work to know whether the problem is real, whether the timing is right, and whether I have something genuine to contribute. The Mintlify process gave me two days of focused immersion in a market I found genuinely interesting. What came out of it was a sharper conviction about where the next important product in this space gets built, and a clearer sense of the kind of problem I want to work on next.

Sometimes that results in a hire. Sometimes it results in an article. Either way, the thinking is worth doing.