DEV Community: Mariam Narimanidze

Documentation Review for Mixed Teams: I Tested Theneo, ReadMe, GitBook, and Mintlify (2026)

Mariam Narimanidze — Thu, 17 Sep 2026 15:55:54 +0000

Here's a situation you've probably lived through. An engineer updates a spec, the docs publish, and three days later a developer opens a support ticket because the endpoint doesn't behave the way the docs say. Nobody really did anything wrong. There just wasn't a checkpoint between "someone edited this" and "developers are reading this."

That checkpoint is a documentation review workflow. When only engineers touch the docs, a pull request usually does the job. It gets messier when the people reviewing a change include a technical writer who'd rather not open a terminal and a PM who just wants to confirm the behavior matches what shipped.

As a PM, I own the developer experience, which means I'm accountable when the docs are wrong, even when I didn't write them. And I've learned that accountability without a review gate is just blame after the fact. What I actually need is for everyone with something useful to say about a change — the engineer who shipped it, the writer who explains it, the PM who signed off on the behavior — to be able to see it and sign off on it before developers read it. Not everyone reviews the same way: the engineer wants a diff, the writer wants the rendered page, I want to ask a question on the parameter itself. So the tool I'm looking for isn't the one with the best editor. It's the one flexible enough that no role gets locked out of the review. I took one realistic API change and walked it through ReadMe, GitBook, Mintlify, and Theneo to see which one manages it.

Which documentation platform is best for mixed teams?

For the workflow I tested, where engineers, technical writers, and PMs approve API reference and prose changes through one Git-free gate, Theneo covers more of the requirements natively than ReadMe, GitBook, or Mintlify. It was the only one of the four where every reviewer works without Git, API reference content and guides share one enforced approval gate, and comments attach to individual endpoints and parameters.

That's a specific scenario, not a verdict on every team. If your docs are owned entirely by engineers who live in GitHub, the answer may be different, and I cover why below.

Results at a glance

Platform	Could all three reviewers work in one place?	Did it block publishing until approval?	✅ in the matrix (of 8 capabilities)
Theneo	Yes, one Git-free branch for the endpoint and the guide	Yes, merge rules enforce approvals (Enterprise)	8
ReadMe	Yes, on one branch	Only on Enterprise, and admins can skip	4
GitBook	For the guide, but spec updates skip the change request	Yes, for change requests (Pro and Enterprise)	4
Mintlify	Yes, in one pull request, inside a Git workflow	Only if branch protection is set in the Git host	2

The walkthrough for each platform follows, and the detailed matrix is near the end.

How I compared these platforms

Hands-on testing. I ran the same API change, described below, through each platform's review workflow in September 2026.
Documentation check. I verified what I saw against each vendor's public documentation, linked inline throughout the post. Features and plan availability were last checked on September 17, 2026.
Plan-gated features. Where a capability requires a specific plan, I say which one.
Scope. I focused on review and approval for mixed teams. I didn't score pricing, integrations, SEO, analytics, or docs-as-code extensibility.

What does a mixed team need from documentation review?

Before looking at any platform, it helps to be clear about what "good" means when reviewers have different skill sets. Every item below is really the same requirement viewed from a different angle: nobody should be excluded from a review because of the tool they're comfortable in.

Git-free participation. If a writer or PM has to open a pull request to weigh in, they'll often send a Slack message instead, and that feedback never makes it into the review.
Comments pinned to the content. "Line 42 of the YAML" means nothing to a PM. Comments should sit on the sentence, example, endpoint, or parameter they're about.
One approval gate for API reference and prose. An endpoint change and the guide that explains it should be reviewed together, not on separate tracks.
Rules the docs platform enforces. "Two approvals for public API changes" only works if the tool blocks the merge, rather than relying on everyone remembering.
A diff and a rendered preview. A diff shows what changed. A preview shows what developers will actually see, including broken formatting a text diff hides.

The API change I used to test each platform

I picked a change most API teams will recognize: an optional scope parameter added to the POST /oauth/token endpoint. Three people are involved:

The engineer updates the endpoint in the API reference.
The technical writer updates the authentication guide to explain when to use scope.
The PM needs to confirm both match what actually shipped before anything goes live.

For each platform, I asked two questions. Can all three people review this in one place? And will the platform stop it from publishing until the right people approve?

How does ReadMe handle documentation review?

ReadMe offers optional branches and in-product reviews, with AI Linter checks, on its Pro plan ($250/month, billed annually). Enforced approvals and merge restrictions are Enterprise features. (ReadMe pricing)

How review works in ReadMe

Branches in ReadMe are opt-in. You can keep editing published docs directly, or save your work to a branch instead: from the Branches page, from the versions menu, or with Save to Branch while you're editing a guide or an endpoint. If you use bi-directional sync with GitHub or GitLab, branches show up on both sides. (ReadMe Branches)

When the changes are ready, review happens in the Review tab:

The author marks the branch ready for review. That adds a badge in the versions menu, starts the AI Linter, and notifies the whole team.
Reviewers see every changed file, a line-by-line diff for each one, and the Linter's results. They can also open the branch preview, or share a link to it, to check the rendered docs.
A reviewer approves, and the branch owner gets notified.
Someone merges from the Review tab or the branch menu. ReadMe checks for conflicts first, and the team is notified when the merge lands.

For the OAuth change, the engineer and writer can put the endpoint edit and the guide update on the same branch, and the PM can review both diffs in one tab. For API-first teams, that's a genuinely pleasant flow.

Where ReadMe shines, and where mixed teams hit friction

The AI Linter is the standout. It checks each branch against your style guide, so human reviewers can focus on accuracy instead of catching terminology slips.

The friction is enforcement. On Starter and Pro, every teammate is an Admin, and approval requirements aren't available, so the PM's approval is a signal rather than a gate. Enterprise lets Group Admins require a teammate approval or zero lint errors and restrict merging to certain roles, but admins can still skip requirements at any time (ReadMe Reviews). And with GitHub sync turned on, ReadMe's own docs note that a merge made in GitHub bypasses ReadMe's merge restrictions.

Two smaller things matter for mixed teams, too. ReadMe's review docs don't describe a way to comment on a change, so the PM's "is scope really optional?" question may end up outside the review itself. And if the writer reorders pages, the diff shows it as edits to an _order file, which isn't the friendliest thing to hand a non-engineer.

Best for: API-first teams already on ReadMe that want a lightweight review step with AI linting and don't need strict enforcement.

How does GitBook handle documentation review?

GitBook routes edits to published content through change requests and, on Pro and Enterprise plans, can block merges with some of the most flexible merge rules available. (GitBook Merge rules)

How review works in GitBook

GitBook makes review the default for published docs. Live editing can't be unlocked on sections published as public or unlisted, so changing anything means opening a change request, which is a branch-like copy of your content.

Click Edit to open a change request, or let GitBook Agent open one for you.
Make your changes in the visual editor. Teammates can edit alongside you in real time.
In the Overview tab, tag reviewers. If you don't tag anyone, everyone with reviewer permissions in that section is notified.
Reviewers open the Changes tab. It shows a split view by default, old version on the left and new on the right, with a floating navigator that jumps between changed blocks. Preview loads a deploy preview of the actual site.
Reviewers comment on specific content blocks or on the change request as a whole, then approve or request changes. GitBook Agent can review, too.
Once the merge rules pass, click Merge, and the changes go live immediately. (GitBook Change requests)

GitBook's docs note that a merge itself can't be undone. If something slips through, though, Version history lets admins, creators, and reviewers roll the space back to an earlier version.

Where GitBook shines, and where mixed teams hit friction

Merge rules are GitBook's superpower. You set organization defaults, then override them section by section. Rules can require at least one review, require every completed review to be an approval, require sign-off from specific people, or require the change request to be up to date. If none of those fit, you can write a custom JavaScript expression, such as requiring two approvals, and name the people allowed to bypass rules in an emergency.

The friction for the OAuth change is the spec. GitBook manages OpenAPI specs at the organization level, and you update them by uploading a new file, pointing at a URL that GitBook re-checks every six hours, or running gitbook openapi publish from the CLI. When the spec updates, GitBook pushes the changes into your docs without a change request (GitBook announcement). Adding API reference pages to a space still happens in the normal editor. After that, though, the writer's guide edit waits behind merge rules while the engineer's new scope parameter reaches the docs without passing through one.

Best for: Product and knowledge-base teams whose docs are mostly prose and who want fine-grained merge rules.

How does Mintlify handle documentation review?

Mintlify brings Git pull requests into its web editor, so writers can branch, preview, and merge without a terminal, but the approval rules themselves live in your Git provider.

How review works in Mintlify

Everything in Mintlify's editor saves automatically as pending changes. What happens when you click Publish depends on whether your deployment branch is protected (Mintlify Publish changes):

No branch protection: Publish commits your changes and deploys them to the live site right away. If auto publish is on, edits commit shortly after you stop typing, with no review step at all.
Branch protection that requires pull requests: the editor offers Create branch to move your pending changes to a feature branch, then Create pull request to open a PR against the deployment branch.

Once the pull request is open:

The publish menu shows a review panel with the PR title and description, source and target branches, the number of changed files, the approval requirement, and the current review status.
Reviewers click any changed file to see its diff, which is a visual diff in visual mode. They can also use the live preview or open the preview deployment Mintlify builds for the branch.
Teammates discuss in comment threads, @mention each other, or switch to suggestion mode to propose edits the author can accept or reject. Mintlify adds a summary of open threads to the PR description.
On GitHub, anyone with review permissions can click Approve pull request without leaving the editor. On GitLab or Bitbucket, they approve in the Git provider (Mintlify Review changes).
After approval, Merge and publish merges and deploys from the editor.

For the OAuth change, the spec file and the guide both live in the repo, so they can travel together in a single pull request. That's a real plus.

Where Mintlify shines, and where mixed teams hit friction

Mintlify's editor is genuinely collaborative. Real-time co-editing, suggestion mode, preview deployments, and an in-editor review panel make pull requests far less intimidating for writers.

The friction is where the gate lives. The review step only exists once someone with admin access to your repository sets up branch protection, and required reviews and code owners are maintained in the Git provider, not in Mintlify. If your team isn't on GitHub, the PM leaves the editor to approve. And if nobody configures protection at all, Publish goes straight to production.

Best for: Engineering-led teams on GitHub that want documentation to follow the same pull request rules as code.

How does Theneo handle documentation review?

Theneo Documentation Review runs a branch, review, approve, and merge workflow entirely in the web editor, with no Git concepts for any reviewer, and it treats API reference content and guides the same way. It's available on Enterprise plans. (Theneo Documentation Review)

How review works in Theneo

Create a branch off your live docs. What developers are reading stays untouched.
Edit and discuss. Change guides and API reference content in the browser. Leave inline comments right where a question applies, including on a specific endpoint or parameter (Theneo API Reference), and general comments for feedback on the change as a whole.
Request approval and assign approvers, who see exactly what changed.
Review the diff. Approvers compare the branch to the live docs in the side-by-side Split view, then check Preview to see the page exactly as readers will. They approve, request changes, or comment.
Satisfy the merge rules. Theneo enforces rules, such as a minimum number of approvals, before the branch can merge.
Merge and publish in one step, with an auditable trail of who approved what.

If another branch gets published while yours is still in review, Pull latest base brings the current live content into your branch, so you don't ship on top of stale docs. (How Theneo built Documentation Review)

For the OAuth change, the endpoint update and the guide edit sit on the same branch. The PM leaves a comment directly on the scope parameter asking whether it's really optional, and the writer sees it in context while updating the guide. The engineer checks the rendered endpoint in Preview. With a merge rule requiring two approvals, nothing publishes until both sign off.

On the engineering side, Theneo's GitHub Action can import an updated spec with auto-publish turned off, so the change waits for review in the editor instead of going live. Its merge strategies can also keep descriptions a writer already polished in Theneo when a new spec version arrives. (Theneo GitHub Actions)

Where Theneo shines, and what to know

The biggest difference is that nobody meets Git. There are no commits, pull requests, or branch protection settings in another tool, so the writer and PM review in the same place, the same way, as the engineer.

The diff is also built for documents rather than code. Theneo compares versions block by block, so a moved section shows up as a move instead of a wall of red and green, and a lightly edited paragraph highlights only the words that changed.

Best for: Mixed teams of engineers, writers, and PMs who all review API reference and guides and need one enforced, Git-free approval gate.

Documentation review comparison matrix

Here's how the four platforms line up on what mixed teams care about most. The last row summarizes the others. Scoring reflects my hands-on testing and each vendor's documentation as of September 17, 2026.

✅ Supported · ⚠️ Partial, depends on another tool, or not documented · ❌ Not supported

Capability	Theneo	ReadMe	GitBook	Mintlify
Every role reviews without Git concepts	✅ Branches, approvals, and merge in the web editor	✅ Branches and reviews in the UI	✅ Change requests in the UI	⚠️ Editor opens pull requests; approval happens on the Git PR
API reference and guides in one approval gate	✅ Same branch, review, and merge flow for endpoints and prose	✅ UI edits to endpoints and guides both use branches	⚠️ Spec updates reach the docs without a change request	⚠️ Only through Git pull requests on spec files
Comments on individual endpoints and parameters	✅ Inline comments on endpoints and parameters	⚠️ Comments not described in review docs	⚠️ Comments on endpoint-level not documented	⚠️ Page comment threads; endpoint-level not documented
Approval rules configured in the docs platform	✅ Merge rules set in Theneo	⚠️ Enterprise only	✅ Merge rules set in GitBook	❌ Branch protection in your Git provider
Diff that understands document structure	✅ Block-level diff shows moved sections as moves	⚠️ Line-by-line diff; page reorders appear as `_order` file changes	⚠️ Split-view diff; move detection not documented	⚠️ File diff with visual mode; move detection not documented
Rendered preview during review	✅ Preview alongside side-by-side Split view	✅ Branch preview	✅ Deploy preview	✅ Live preview and preview deployments
Spec updates from CI held for review	✅ GitHub Action can import without auto-publishing	✅ Via GitHub or GitLab branch sync	❌ Spec updates flow into docs without a change request	✅ Via pull requests
Approval record in the docs platform	✅ Record of who approved what	⚠️ Audit logs on Enterprise only	✅ Version history, including merged change requests	⚠️ Lives in Git and PR history
Fit for mixed teams reviewing API reference and guides	✅ All of the above in one Git-free flow	⚠️ Review comments not documented; enforcement Enterprise-only	⚠️ Spec updates sit outside the approval gate	⚠️ Approval gate depends on Git host setup

Plan availability differs: Theneo Documentation Review is an Enterprise feature, ReadMe includes reviews on Pro with enforcement on Enterprise, and GitBook's merge rules are on Pro and Enterprise.

Verdict: which platform handled the mixed-team review best?

Go back to the OAuth change for a moment.

In ReadMe, all three reviewers can look at the endpoint and the guide together, but the review docs don't describe a place for the PM's question, and on Pro nothing stops the branch from merging before the PM approves. In GitBook, the guide edit waits politely behind merge rules while the spec update reaches the API reference without a change request. In Mintlify, everything travels in one tidy pull request, but the gate is whatever someone configured in the Git provider, and the PM is working inside a Git workflow whether they realize it or not.

In Theneo, the engineer, writer, and PM review the endpoint and the guide in one Git-free flow. The PM's question sits on the parameter it's about, reviewers see both the diff and the rendered page, and the merge rule holds until everyone who needs to approve has approved. For this workflow, each of the other platforms does some of that well. Theneo is the only one that does all of it in one place.

Where the other platforms have the edge

A fair comparison should say where Theneo isn't the obvious pick.

Mintlify inherits your Git host's full toolkit. Required reviews, code owners, required CI status checks, and complete commit history all come along for free. If your engineering org already governs everything through the repository, a separate approval system in the docs tool can feel like duplication.
GitBook's merge rules are more expressive. Custom JavaScript expressions, per-section overrides, and designated bypass actors go further than the approval-count rules Theneo documents today.
ReadMe builds linting into review. Its AI Linter checks every branch against your style guide, which is useful for any team that struggles with consistency.
Plan access varies. GitBook's merge rules and ReadMe's reviews are available on Pro plans. Theneo's Documentation Review requires Enterprise.

Frequently asked questions

What is a documentation review workflow?

A documentation review workflow is a process in which documentation changes are drafted on a branch, reviewed and commented on, approved by designated reviewers, and merged before publication. Think of it as code review for docs: nothing reaches readers unchecked, and there's a record of who approved each change.

Can non-engineers review API documentation without using Git?

Yes. Theneo, ReadMe, and GitBook let reviewers approve changes in the web UI without touching Git, and Theneo also lets reviewers comment directly on endpoints and parameters. Mintlify makes pull requests approachable from its editor, but the underlying gate is still a Git pull request.

Which platforms enforce approval before documentation goes live?

Theneo (merge rules, Enterprise), GitBook (merge rules, Pro and Enterprise), and ReadMe (review requirements, Enterprise) enforce approvals inside the product. Mintlify relies on branch protection rules in your Git provider.

Do OpenAPI spec updates go through documentation review?

It depends on the platform. In Mintlify, spec files live in the repository, so changes go through pull requests. ReadMe lets endpoint edits be saved to a branch. Theneo's GitHub Action can hold spec imports for review instead of auto-publishing. In GitBook, spec updates flow into the docs without a change request.

Every vendor claim links to the relevant documentation inline. Features and plan availability were last checked on September 17, 2026.

Product Managers Should Vibe Code (With One Strict Rule)

Mariam Narimanidze — Wed, 16 Sep 2026 07:23:20 +0000

I wrote a spec last year for a feature that seemed obvious. Three paragraphs, a few acceptance criteria, a rough sketch. The engineer read it, nodded, and built exactly what I asked for. It was wrong. Not wrong in the details — wrong in the shape. The thing I described made sense as a sentence and made no sense as a screen.

That mistake cost about a week. A month later I hit a similar fork and did something different: I spent forty minutes getting an AI to build me a fake, non-functional version of the screen. I looked at it for ten seconds and immediately knew it was wrong. Same discovery, fifty times cheaper.

That is the entire argument for product managers vibe coding. Not that we should write production code. That being specific has become cheap, and being vague is now a choice.

What I mean and what I don't

By vibe coding I mean describing what you want in plain language, letting a model produce something runnable, and iterating by reaction rather than by engineering. You are not reviewing the code. You often cannot review the code. You are reacting to the output.

What I do not mean: PMs opening PRs against the production repo. I will come back to this, because it is the part that determines whether your team finds this useful or infuriating.

1. It moves the moment of discovery earlier

Specs fail silently. Everyone reads the same document, everyone believes they agree, and the disagreement surfaces in code review three weeks later. A prototype fails loudly and immediately. You put it on the screen and someone says "wait, why does it do that," and now you are having the real conversation at the point where changing your mind is free.

This is the same principle behind every cheap-experiment method product people already believe in. Vibe coding just lowered the price of the artifact from days to an afternoon.

2. It turns your opinions into questions engineers can answer

There is a specific kind of meeting where a PM says "it should feel instant" and an engineer says "what does instant mean" and neither person can close the gap because the PM is describing a feeling and the engineer needs a number.

A rough prototype collapses that. Instead of arguing about the word, you put a clickable thing on the table and ask: this, or not this? Engineers are extremely good at answering concrete questions about a concrete artifact. They are understandably tired of answering vague ones about a paragraph.

The prototype is not a proposal for how to build it. It is a question about what we are building, phrased in a way that can be answered.

3. It rebuilds technical intuition that the PM role erodes

The longer you sit in product, the more your technical understanding turns into vocabulary. You learn to say "rate limit" and "webhook" and "idempotent" correctly and you slowly stop knowing what any of it feels like.

Building small throwaway things fights that. When I wired up something against our own API to mock a flow, I finally understood what our onboarding actually asks of a developer, because I had to do it myself with no internal knowledge to shortcut the confusing parts. Reading the documentation had never given me that. Being annoyed by the documentation did.

For anyone working on developer tools this is close to mandatory. You cannot have good judgment about a product you have never used in the way your users use it.

4. The unglamorous stuff is where it actually saves time

Prototypes get the attention, but most of my use is duller: a script to pull and reshape data for a release report, generating realistic test fixtures for QA, a quick tool to diff two API specs, throwaway parsing of a customer's messy export. Small, boring, self-contained, and previously either an engineer's interruption or my two hours of copy-paste.

This category has almost no downside. Nobody depends on it, it runs once, and if it is wrong you find out immediately because the output is nonsense.

Where it goes wrong

I want to be honest about the failure modes, because the version of this post without them is the reason developers roll their eyes at PMs discovering AI.

Confusing a demo with a build. The prototype works because it has no auth, no error states, no concurrency, no migrations, and four rows of fake data. If you then tell your team "it only took me an afternoon," you have damaged something real, and you deserve the reaction you get. The prototype tells you nothing about effort. Never use it as an estimate.

Unearned confidence. Getting something on screen feels like understanding. It is not the same thing. I have been wrong about feasibility more often since I started prototyping, because the working demo makes the hard parts invisible rather than visible.

Security and data. Do not put customer data, credentials, or anything from a private repo into a prototype. This is the fastest way to turn a productivity habit into an incident.

Scope creep into the engineer's job. If your prototype starts accumulating features and you start defending your implementation choices, you have crossed from asking a question to doing someone's job badly.

The rule

One rule makes all of this safe, and it is short:

My code is a question, not an answer. It never ships.

Everything I build this way is disposable by default. It exists to be looked at, reacted to, and thrown away. The engineers on my team know that when I bring something in, I am not proposing an implementation, I am showing them what I could not explain in words. That framing is the whole difference between a PM who prototypes and a PM who is now a liability in the codebase.

Worth trying

If you are a PM who has never done this, the lowest-risk starting point is not a feature. It is one boring internal script that only you will use. You get the reps, nobody is affected if it is bad, and you find out quickly whether this fits how you think.

The skill being unlocked here is not programming. It is specificity. The cost of showing instead of telling dropped by an order of magnitude, and product management is a job that is mostly about being precise in the face of ambiguity.

Curious where other people land on this, especially engineers who have worked with a PM doing it. Where did it help and where did it get in the way?

What a Social Science Degree Actually Taught Me About Building Products

Mariam Narimanidze — Mon, 14 Sep 2026 16:43:55 +0000

I studied sociology, philosophy, law, economics and a bit of digital literacy. I did not study computer science. I had never opened a terminal on purpose. My first week as a product management intern, someone asked me to "check if the endpoint returns a 401 before the retry," and I wrote it down phonetically so I could look up each word later.

A few years on, I run product and QA at an API documentation platform. Nothing about that path was planned. But looking back, the generalist degree I was slightly embarrassed about turned out to be the part that carried me.

This is what actually transferred, and what did not.

The degree that teaches you nothing specific

I went to the Free University of Tbilisi and studied Governance and Social Sciences. It is a generalist program by design: a semester of political philosophy next to a semester of microeconomics, legal reasoning next to research methods. You graduate without a trade. Everyone asks what job that prepares you for, and for a while I did not have an answer.

The honest answer is that it prepares you to walk into a room where people are arguing about something you do not fully understand yet, and figure out what the argument is actually about. In university that is a seminar. At work it is a sprint planning meeting where two engineers disagree about scope and neither of them is saying the real reason out loud.

What transferred, concretely

Research methods became user research. I was taught that how you ask a question determines the answer you get. Leading questions produce the data you wanted. The same thing happens in customer calls. When a client says "the search is broken," that is a claim, not a finding. My instinct from methods class is to go after the observation behind the claim: what did you type, what did you expect, what appeared. Half the tickets I write start as somebody's interpretation and end as somebody's actual behavior.

Philosophy became specification writing. Analytic philosophy is essentially professional pedantry about definitions, and product specs live or die on exactly that. What does "published" mean? Does an approved API contract count as published, or is approval a separate state? I spent one full week on a version of that question with our contract approval flow. Nobody in the room thought it was a philosophy problem. It was entirely a philosophy problem. Edge cases are just counterexamples, and I had four years of practice hunting counterexamples.

Law became precision under adversarial reading. Legal texts are written for someone who wants to interpret them badly. So are error messages, so are terms in an enterprise contract, and so are acceptance criteria that an engineer will read at 11pm. Writing so that one meaning survives a hostile reader is a learnable skill, and I learned it on statutes before I ever learned it on a Definition of Done.

Economics became prioritization. Opportunity cost is not a metaphor in this job. Every "yes" to a feature is a "no" to something invisible. Reading an economics problem set trains you to ask what the constraint actually is, and most roadmap fights are constraint fights disguised as taste fights.

Sociology became organizational sense. Processes are social objects. When I proposed changes to our QA process and release gates, the technical design was the easy half. The hard half was that a release gate reassigns authority, and people notice that even when nobody says it. I had read enough about institutions to expect it instead of taking it personally.

What absolutely did not transfer

I want to be honest, because "my humanities degree secretly made me great at tech" is a comforting story and only half true.

I had real gaps. I did not understand what an API was in any useful sense. I could not read a stack trace. I did not know why anyone would care about the difference between staging and production until I broke something. For the first months I was slow in a way that was visible to everyone, including me.

What helped was not pretending otherwise. I asked a lot of questions that were probably boring for the engineer answering them, and I kept a file of terms I did not know and worked through it on weekends. The generalist degree did not give me the knowledge. It gave me a fairly high tolerance for sitting in front of something I did not understand yet, which is a different thing, and it turns out to be the more durable one.

The intern-shaped middle part

The step people usually want to hear about is the jump from intern to owning product decisions, and I do not think there is a dramatic story there. It was mostly accumulation: I noticed things nobody had time to notice, wrote them down clearly, and did the unglamorous coordination work that makes releases go out on time. Being the person with the most complete picture of what is going on is not a title, and then eventually it becomes one.

Teaching helped too. I lectured at my old university while working, and explaining something to a room of people who will ask why is a very fast way to find out whether you understand it.

If you are in a similar place

A few things I would tell someone finishing a non-technical degree and looking at tech jobs:

Your degree is not a disadvantage you need to apologize for, but it is also not a credential anyone will read for you. You have to translate it into concrete things you can do.
Close the literacy gap deliberately. You do not need to become an engineer. You do need to stop being a person who has to be protected from technical conversations.
Get close to where the product is actually decided. QA, support, and documentation are all excellent vantage points and are all underrated on-ramps.
Write things down. In most teams, the person who writes the clearest document quietly ends up setting the direction.

I still think about my degree as generalist, but I no longer think of that as a gap. The specific knowledge was never the point. The point was learning how to enter an unfamiliar domain, find the real question, and stay there until it makes sense.

That is most of what product work is.