Google Docs

This guide gets you from "I open a blank doc and start typing" to running Google Docs as a real operating surface for a growth business: a place where briefs, specs, proposals, and SOPs live, get written collaboratively, and stay findable a year later. It is for founders and operators who already use Google Docs casually and want to treat it like infrastructure rather than a typewriter in the cloud.

Getting set up

The first decision that matters is not about the document, it is about where documents live. Google Docs files sit in Google Drive, so before you write anything seriously, settle your Drive structure. If you work with anyone else (clients, contractors, an AI agent fleet), use Shared Drives rather than your personal "My Drive", because a Shared Drive owns its files at the team level: when a person leaves or a contractor's access ends, the documents stay, they do not vanish with the account that happened to create them. For a solo operator this matters less today, but it costs nothing to start clean and it saves a painful migration later.

The second decision is naming and folders. Pick a convention and hold it. A simple pattern that survives scale is a short prefix plus a clear subject, for example "BRIEF , Q3 paid search" or "SOP , client onboarding", so a glance at a search result tells you what kind of document it is. Folders should map to how you actually work (per client, per function, per venture), not to an idealised filing cabinet you will never maintain.

The third decision is sharing defaults. Decide up front whether a doc is private, shared with named people, or link-shared, and lean towards named-people sharing for anything sensitive. Link sharing is convenient and it is also how confidential proposals end up indexed somewhere you did not intend. Set the default to restricted and open it deliberately.

Get the basics configured once: enable offline access if you draft on the move, turn on the spelling and grammar suggestions you want (and turn off the autocorrect ones that fight you), and set your default text style so every new doc starts in your house format instead of the generic blank.

How to actually use it

The core workflow is write, structure, review, finalise, in that order, and the mistake most people make is collapsing them into one pass.

Start by writing badly and fast. Get the argument down before you touch formatting. Then structure it: apply real heading styles (Heading 1, Heading 2, and so on) rather than just making text big and bold. This is the single highest-leverage habit in Google Docs, because the document outline, the navigation pane, the eventual export, and any automated processing all read those heading styles. A doc styled with proper headings is a doc you can navigate, collapse, and reuse; a doc of manually bolded lines is a wall.

Once it is structured, bring people in for review. Use Suggesting mode (not direct edits) when someone is reviewing your work or you are reviewing theirs, so every change is visible, attributable, and reversible. Use comments for discussion and questions, and resolve them as they are dealt with so the margin stays a live to-do list rather than a graveyard. Assign a comment to a specific person when you need them, not the room, to act on it.

Finalise by accepting or rejecting the suggestions, clearing resolved comments, and checking the document outline reads cleanly top to bottom. If the doc is going to a client, that final outline pass is your quality gate.

Power moves

Use the navigation outline as a working tool, not a side effect. Collapse headings to move whole sections around, and treat the outline pane as your table of contents while you draft.

Lean on version history. Every Google Doc keeps a full timeline of who changed what and when, and you can name specific versions (for example "sent to client v1") so you can jump back to a known-good state instead of scrolling a soup of autosaves. This is your undo button for entire weeks of work.

Master a few keyboard moves: paste-without-formatting to stop foreign styles polluting your doc, and the "@" menu to drop in people, dates, files, and building blocks inline. The "@" building blocks (meeting notes, checklists, dropdowns, tables) turn a doc from prose into a light structured workspace without leaving the page.

Build templates for the documents you write repeatedly: the proposal, the brief, the SOP, the weekly update. A good template encodes your structure and your standard sections so you start from 60 percent done. Store them in one obvious place and copy from them rather than rewriting from memory.

Finally, learn the export paths. Google Docs exports cleanly to PDF for sending and to Markdown for anything that feeds code, a CMS, or an AI workflow, and that Markdown export is exactly why proper heading styles matter so much.

Where it fits your stack

Google Docs is the connective tissue of a Google Workspace setup: it sits next to Sheets (data and dashboards), Slides (decks), and Gmail and Calendar (where docs get shared and scheduled). Drive is the shared backbone underneath all of it.

For a growth and ops toolset, the high-value connections are: linking docs into a project tool (Notion, Asana, or similar) as the canonical brief rather than copying text around; pulling meeting transcripts or notes into a doc as the working record; and exporting finished specs and SOPs to wherever your team or your agents actually read them. Because Docs handles real-time collaboration and comment threads natively, it is usually the right home for the writing and reviewing, with the managing and tracking living in your project tool. Resist the urge to make Google Docs your task manager; it is a writing surface, and it is excellent at that one job.

Pitfalls to avoid

The biggest pitfall is fake structure: bolding and resizing text instead of using heading styles. It looks the same and it breaks everything downstream. Use real styles from the start.

The second is link-sharing by reflex. Convenient today, a leaked proposal tomorrow. Keep the default restricted.

The third is letting comments rot. Unresolved threads from three weeks ago make a doc feel abandoned; resolve as you go.

The fourth is treating one giant doc as a database. When a doc grows past a clear single purpose, split it. Long monoliths are slow to load, hard to navigate, and impossible to reuse in parts.

And the fifth is ignoring version history until you need it. Name your important versions as you ship them, so "go back to what we sent the client" is one click, not an archaeology dig.

INTERVIEW EWOUD: How is your Drive actually organised for Solid Growth and your client work, and what is your real naming convention for briefs, specs, and SOPs?

INTERVIEW EWOUD: What is the one Google Docs workflow you rely on most (templates, the agent handoff, the Markdown export into the repo), and how is it set up?

INTERVIEW EWOUD: What is your hard-won tip with Google Docs, the thing you do that most people miss?

Google Docs is Google's browser-based word processor, part of the wider Google Workspace suite alongside Sheets, Slides and Drive. It lets you write, format and structure documents that live in the cloud, with multiple people editing the same file at once, leaving comments, suggesting edits and seeing a full revision history. Everything saves automatically and opens from any browser, so the document is the same whether you reach it from a laptop, a phone or a shared link.

Where it fits

The core use case is collaborative writing where more than one person touches the same text: proposals, briefs, meeting notes, shared SOPs, contracts in draft, anything that needs comments and tracked suggestions before it is final. It is genuinely strong for small teams and solo operators who want zero setup, instant sharing by link, and a clean comment-and-resolve workflow. It also pairs naturally with the rest of Workspace, so if you already live in Gmail and Drive it is the path of least resistance.

It is a weaker fit when you need heavy desktop-grade layout (long manuscripts, complex print typesetting, dense academic formatting), structured knowledge bases with databases and relations, or strict offline-first working. Teams that want a single connected workspace of pages, tasks and databases tend to reach for a dedicated tool instead, and design-led documents usually move elsewhere.

The honest take

The real strength is collaboration done right: real-time co-editing is reliable, comments and suggestions are intuitive, and the revision history means you can always recover an earlier version or see who changed what. Sharing is frictionless, the learning curve is near zero, and it runs anywhere with a browser. For getting words on a page with other people, it is hard to beat.

The trade-offs are real too. Formatting control is limited compared with a desktop processor, and long or image-heavy documents can feel sluggish. It assumes you are comfortable keeping work in Google's cloud, which is a governance and privacy decision some businesses cannot make lightly. Offline use exists but is clunky, and as documents accumulate, organising them across Drive becomes its own chore. It is a writing surface, not a structured knowledge system, so do not expect it to be your wiki or your project tracker.

Google Docs has a free tier for personal accounts, with paid Workspace plans for businesses.

INTERVIEW EWOUD: What is your personal verdict on Google Docs, and your star rating out of five?

INTERVIEW EWOUD: Is Google Docs in your own stack today, and if so what do you actually use it for (and what have you moved off it)?

INTERVIEW EWOUD: What is the one line you would tell a peer who is deciding whether to use it?

Teams and founders who want shared, real-time document editing in the browser

Google Docs is a browser-based word processor in Google Workspace for writing, editing, and sharing documents that are stored in Google Drive. Multiple people can edit the same document at once, with comments, suggestions, and version history built in. It is free for personal Google accounts and available to teams through paid Google Workspace plans.