Two worlds of documentation: A conversation with Pocus’ Alexander Rose
Alexander Rose from Pocus explains how to balance marketing and technical docs, reduce self-disqualification, and turn documentation into a growth lever
Alexander Rose, Customer Engineer at Pocus, has worked in both support and growth engineering — giving him a fairly unique insight into the varied roles documentation can play.
We sat down to discuss those roles, the challenges of keeping docs current in fast-moving startups, and why documentation is becoming a bridge between teams.
Tell me about your background and how you came to work with documentation.
I’ve been at Pocus now almost three years, primarily on the support side, and was previously at Airtable — also for support. I’ve been working at Pocus for a while and had the opportunity to move into the growth sector. I have a strong relationship with docs — I’ve written docs, edited docs, requested new docs, basically everything.
Coming from the support side and going to the growth side, I’ve noticed that there are kind of two worlds of docs, and they’re very different breeds of docs for different purposes, but they are both documentation for the same product.
Can you explain those two different kinds of documentation?
The big split is: what are you showing to people that are not yet sold on you, that are kind of interested or looking for a particular solution, versus what are you showing to people that you’re having a conversation with about their use case, they’re doing a POC, or they’re an early customer that wants a quick ROI, or they’re fully bought in and just need help with something.
For prospective buyers, we have our very upfront documentation that you’re going to hit first when you look for our company or a solution like ours. That’s what we do search engine optimization for. Those focused documents — such as a PDF saying “this is the state of product-led sales,” — that’s going to be in the upfront documentation, and that’s where we’re going to track that click.
Then we have our real technical docs that are more useful for somebody that’s already in the product — the personas accessing these are different. So maybe we’re doing a POC where somebody’s already bought it, and we need a data engineer to help set up an integration. They’re going to go to the technical documentation, which a prospective buyer — maybe a Head of Sales — would not find useful, and may even lead to self-disqualification.
To some degree, you kind of want to hide the technical documentation. You shouldn’t make it difficult to find necessarily — but you don’t want that to be front and center, because self-disqualification is a big issue.
Interesting. But do you consider that first category — the front-facing content — to even be documentation?
I would, because it’s almost like an abstraction of the product documentation. It’s the big picture — what problem do we solve for?
Think of it like a sausage: it’s meeting your hunger needs, but I’m not going to show you how I make it quite yet, because then maybe you’ll say, “I don’t like sausage.”
Once you need to know — and you’re sure you want the product — then we say “okay, this is how we do it.” That just comes later in the pipeline.
So how do you distinguish between that front-facing documentation and your marketing site?
That’s a hard question. I think that’s going to be on a case-by-case basis depending on what your marketing is, what your product is, and how technical it is. There’s a lot of opportunity — that’s a sliding scale that can be very light or very detailed depending on the situation.
Where we are right now at Pocus, there’s a pretty tight coupling between what marketing is doing and what the problems we’re solving are, and how we approach it. So something as simple as showing our UI and walking through what a salesperson would do on our product in a day — I think that’s documentation.
Okay, so you see the two working closely together. Is there also a hybrid approach for post-sales customers?
For sure. In the post-sales side, there’s a bit of marketing-technical documentation hybrid, which comes into play in expansion and enablement for customers that are already bought in. Especially in a B2B context — if a manager has bought it for a whole department, you might have some people that aren’t sold on it.
We can see their product usage — we use our product for ourselves — and then do targeted marketing that’s actually product enablement. We know what the exact use case is for their company, we know why their team bought it… but we can see they’re still not using it. So we can send a targeted email saying, “Hey, saw you sign on, your team is seeing this interaction with the product — this is how you build a list, or this is how you do one particular thing.”
That’s a melding of those two worlds — it’s targeted outreach to somebody that’s already sold, but we’re trying to drive enablement or drive expansion.
Okay, so you have a few different kinds of documentation, each aimed at different parts of the customer journey. How do you measure success across them all?
For the marketing-documentation world, that’s where we do all of our insight gathering of engagement. So metrics like pages viewed, how they move into pricing pages. For growth reasons, you really want to look at that.
We’re not tracking anything in our technical documentation right now. But ideally, I’d want to track page views generally, time spent on pages, where people are spending the most time — because that shows they have real engagement with that feature.
Another one is terms searched. And also: what are people visiting the documentation jumping into right away? A big issue with a lot of documentation is creating a logical flow or subject nesting. At Airtable, there was so much information that you really just had to use the search bar. There wasn’t an intuitive way to know where to find the answer to the problem you had from the left-hand navigation.
Getting terms searched would be super useful to understand what people are trying to do and running up against right away. Long term, that becomes product feedback. A lot of people don’t submit product feedback — they’re just frustrated, or they stop using it, or they find a solution from the documentation. That should be built into the product immediately.
Who writes your documentation today?
A good chunk of it is written by me and other people on the go-to-market engineering team, although it’s a bit ad hoc. Our support team handles the more technical side, and then our marketing team updates the very front-end marketing documentation as products and features change.
If you go to our technical docs right now, we even have a product overview that’s done by our CTO. And some of the high-level stuff that’s on the more technical side is going to be handled by marketing, to paint a higher-level picture.
So we get input from everyone really — but that comes with being in a very small company. Airtable had a dedicated team of four people, and that’s all they did.
What’s your biggest pain point with documentation?
I think it’s keeping it updated when we’re shipping changes very rapidly. Our UI just changed entirely — so we need to replace all the GIFs, the screenshots, everything. And then the nuances of what we name our features and things like that.
So updates are the biggest pain point. It’s kind of fun — even though it’s the dirty work — to put something new out. You feel like you’ve moved something forward.
Going back and cleaning stuff up? Nobody thanks you for that, but it needs to be done. There’s nothing worse than when people look at your product, go to your documentation to find out how a feature works, and it just looks wrong.
It happens to everybody. I’ve seen it with Snowflake, seen it with ClickHouse, which is a massive, super technical database. People are just like, “Oh, this page isn’t even finished.”
I hear that a lot! I think updates are a problem for everyone maintaining documentation. I’m also interested to hear what you see as the future of documentation?
I think the ideal state that everybody wants is a chatbot that we can use as support, which has all the context, and that knows the actions people are taking. That’s the end goal everybody wants, because support is essential, but it’s very difficult to get ROI on. How much money are we spending on people in support? How much revenue is that actually generating?
If you have extremely robust documentation, there’s a world in which a support person is just the bridge — they have almost a lexicon knowledge of robust support documentation. Or a question comes up about a new product and they know what we need to update in the documentation.
I think having something that is good enough that you can at least consolidate your support team — that’s the dream that AI may make real. The difficulty is how upfront do you have to be in investing in your documentation to get that AI agent to be that smart?
It’s a really hard question, and a big gamble because people don’t like making documentation. Every company I’ve worked at, it’s kind of a dirty job that no one wants to do — and everybody definitely needs done. I think especially smaller companies aren’t going to invest, upfront, the amount of detailed documentation they would need for that to be effective. It would be a huge time sink.
It almost becomes a chicken and egg problem. To solve that, you almost need another agent that can help you write documentation more effectively.
Absolutely, but it’s a great vision for the future. And are there any other applications you see for AI in documentation?
A more effective way to navigate documentation would be super helpful. There are some people who come to docs and they know what they’re looking for. But there are some who are browsing, or trying to understand a product better. How do you guide somebody along that journey when you don’t necessarily even know what they’re looking for? They might not even know what they’re looking for.
Better integration between docs and product is something people want, because docs are really just supposed to be another view into the product — it’s just another representation of the product.
And I think there’s even a world where you use that product-documentation parity almost like version control. This is what has changed since the last update, your docs reflect that, and then marketing is able to say, “This is the latest update in our product. Let’s do a blast to existing customers.”
If you had an agent do even a really crappy job at updating your docs when a new product or feature is released, it would still be helpful. Just alone, so that there is a top-level insight that somebody on marketing team who’s not technical could be like, “Oh, this is a new thing that was just added because we just added it in the codebase, it got published, it’s in production.”
So ultimately it comes down to AI helping to keep docs updated alongside the product, that in term helping internal teams in sync?
Totally. Using it to keep engineering and marketing in sync. I would rather have a poorly complete page than an incomplete page every time.
This interview was published on 21 August 2025, and conducted as part of research for the 2025 State of Docs report.