The gap you're trying to close
There's a tension built into any technical product.
R&D and marketing are good at different things, and both are necessary. Engineering produces the product; marketing is how anyone finds out it exists and why they should care. But the two groups naturally operate from different instincts. Engineers reach for architecture, internals, and precision. Marketers reach for clarity, reach, and narrative.
Those instincts don't line up on their own. Deep technical explanations overwhelm most buyers. High-level pitches leave technical buyers suspicious. And in the middle is a gap between what the product is and how customers understand what it does for them.
Closing that gap is roughly what technical marketing is for. Your job is to translate technical depth into explanations of how the product solves a real customer problem, without oversimplifying to the point where an engineer in the room rolls their eyes.
The frame I find useful for doing that is what I call the Lego Level.
What I mean by the Lego Level
Think about how Lego sells their sets. The box doesn't show a pile of plastic bricks. It shows a race car, a spaceship, a castle. The pieces are present, but the thing you're being sold is what you can build with them.
That split is the part worth stealing.
A good Lego Level for a piece of content sits at the altitude where the reader can see what they're building and which pieces matter, without getting buried in how the pieces were manufactured. Too high and it's a marketing brochure. Too low and it's an architecture doc no buyer will finish.
Three things help me find the altitude.
Start from the outcome
Lego instructions are organized around the finished model, not around the properties of the individual bricks. Features alone don't mean anything to a buyer; they mean something when they're attached to a problem the buyer recognizes.
Before writing, pin down what "castle" you're showing. Pick a real scenario with a realistic environment and a clear before-and-after. Then work backwards from there. When you open with the outcome, everything you describe afterward has somewhere to land.
Skip the injection-molding details
When you sit down to build a Lego set, you don't want a lecture on the chemistry of ABS plastic or the calibration of the molding machines. Those details are true. They are also useless for the job at hand.
The same thing is true of products. Stability, reasonable performance, working auth, basic compatibility – these are table stakes. If they're present, users barely notice them. Where technical marketing tends to get stuck is explaining architecture, dependency choices, or internal complexity that matters enormously to the team building the product and not at all to the buyer using it.
My editing test for this: for every paragraph, ask whether the reader needs it to snap the next piece together. If not, cut it – or move it to a reference doc where someone who actually wants that detail can find it. Architecture posts are great; just don't disguise them as solution content.
Match the builder
Two kinds of buyers show up, and they want very different things.
Some are building the 9,000-piece Death Star. The product is big, the use case is complicated, and if you hand them a bag of parts and wish them luck they'll close the tab. These readers want a sequenced blueprint – the screens, commands, and config they need to get from box to finished build, without being re-taught the fundamentals they already know.
Others just want to play. They don't want a walkthrough. They want to know what pieces exist, how those pieces interconnect, and a handful of examples of what's possible. For them the Lego Level looks like a well-organized parts map: clean API docs, schemas, small recipes. Then you get out of their way.
Most products need both kinds of content. Problems start when you try to serve one reader with content built for the other.
Turning it into a habit
Nothing about this is a one-time exercise. A few things I try to do every time:
- Decide on the finished build before writing. A real problem, a realistic environment, a clear outcome. If I can't name those, I'm not ready to write yet.
- Use the customer's language for the pieces. Internal feature names and project codenames creep into drafts. Replace them with whatever a new user would call the thing.
- Show how pieces connect. Diagrams, short walkthroughs, and code samples that mirror a real workflow beat isolated feature descriptions almost every time.
- Move internals out of solution content. If a paragraph is really about how something is built rather than how to use it, it belongs in a reference or architecture post.
- Write for more than one altitude. Step-by-step guides for the first group; quickstart repos, API references, and diagrams for the second.
The short version: stop describing the bricks. Start showing what gets built with them.