Before coming to blockchain, I used to work in web2 dealing a lot with DeepTech communications: how to tell the story of the product, how to pitch to investors, enterprise, and governments, how to talk about your technology in a way that people understand it, feel it, and want it. I worked with different projects from BCI and NanoTech to SpaceTech and BioTech. The last three years I am doing the same in blockchain. In this article, some of my thoughts on how we can do it better and why for our industry it’s a big deal.

Blockchain as it is today is pretty much DeepTech. It’s an extremely non-trivial task to explain to someone from outside what an infra blockchain does. Not even talking about why it matters. Just the basic principle of how it works.

At the same time, while we are fascinated by beautiful tech stack, we are still (mostly) working for companies that are expected to generate revenue i.e. whatever we’ve built we need to sell it.

So, technical writing is the spine of sales, BD, marketing, and growth. I am telling you this not because i am doing technical writing and want to claim that my role is the central one to serve the ego, but because technical writing in DeepTech serves as a bridge from product production to product consumption.

Let’s take L2 as an example. The usual pitch of L2 is scaling Ethereum. Which L2 will the web3 dev choose to build on? The one who organized the most lucrative event and provided the best food. Which L2 will the web2 developer choose?

Imagine you are an L2 developer, you want to build a dapp and you are suggested 50 L2s all of those are scaling Ethereum. wtf

The reality is L2s are different: except for having zk and optimistic rollups, there are still sharding (someone is poking it), PoS, and what’s not. They have different block building time, different DA, different finalization time, might have different block building mechanisms, MEV handling mechanism, reorgs handling mechanism, etc.

That’s in fact way more than ‘scaling Ethereum’ and a bunch of work for technical writers.

If we want to sell the infra we are building (for example, zk outside of blockchain) the very first thing we need to be able to explain what our product is and how it can be of any help. For DeepTech products, that’s quite a technical job i.e. non-technical people can’t do it as they will abstract technical details and technical details are the essence of what we do (at least at the current stage of the industry).

The takeaway from this section: every sales and marketing group in DeepTech startups should be equipped with a technical writer.

Technical writing can mean different things. In this article, I want to talk about blog posts and other types of content (i.e. not docs or specs). For this purpose, technical writing can’t be boring. The reader or potential user should be entertained all the way long. However, it shouldn’t be a clown show too. But it can’t be boring.

Technical writing should have storytelling and be directed as a theater play. Meaning we should consciously foresee how we expect the reader to comprehend the information, where they should laugh, where they should feel serious, at what point will the feeling of belonging be born, etc etc etc. There is no objective truth even when it comes to technology. People will adopt it if it feels secure not if it is objectively secure because people paying money are not security researchers (even though they are consulted by security researchers).

Selling technology should be wrapped into selling a dream. It’s very banal but we do not do it at blockchain!

We also usually work with just a few mediums: blog and irl/online talks. Both of those are very vertical: i am talking, you are listening (and admire my genius technology). While usually DeepTech sales engage way more interactive mediums (interactive not researchers with researchers but technical people with potential users).

We have personal blogs (different from company blog), TikToks and instagrams, forums and publishing platforms, communities, calls, etc. We should go for more formats and talk to our audience. If we don’t know who is our audience (common thing in emerging markets) we should talk to all audiences who could be our audience. And engage, engage, and engage. How they feel about our technology, what did they understand, what they didn’t, what is scary, what initiates affection.

People don’t want 30-page whitepapers or abstract pitches of the best L2 on Ethereum. However, they do want a particular technicality level. Talking to them in a manner ‘hey you stupid customer buy my genius tech’ doesn’t work out.

The takeaway from this section: be creative, tell stories.

We should be very thoughtful while writing about technology. At the current stage of our industry, we need to sell more than potential users need to buy. If it was the opposite, we’d already have wide adoption.

• We need to understand what we want to say, the core takeaway people should have after reading/listening.

• We should outline the minimal sufficient level of technicality: which details must be provided to deliver the essence and which can be omitted at the current stage.

• We need to be very precise about who are we talking to and what is their mindset. Writing for general developers, enterprise, governments, and indie hackers will be three absolutely different pieces: different storylines, style, length, depth level, etc.

In fact, technical writing in DeepTech has quite a product approach. We should say what the potential customer expects to hear and not what we’d love to say. In the same manner, in product development, features should meet users’ pains and not product managers worldview.

The takeaway from this section: stick in a very pragmatic manner in what you want to say and whom you want to say. It will pay back.

Product stories are born from what should be said. It’s not fiction written in a free flow. It shouldn’t be beautiful. It should be clear, concise, and talk to the reader. Don’t rely on intuition or simply how it goes. Define what you want to say, split into sections, define key messages for each section, write as few words as possible.

Drawbacks and mistakes are easier to catch from outside rather than you’ve been working on a piece for quite a while. Ask for reviews, be open to feedback and making corrections. However, do some sanity check for all the feedback you get. Sometimes it doesn’t make any sense or people are reviewing topics they have no clue about (idk why they do it). If you know what you are writing about – trust yourself more than anyone else. At the end of the day you are responsible for the write up.

If you are not native use a good professional copy editor. These guys are expensive ($200/hour) but it’s worth it. There is a special category of people who freaks out from a single absent coma. It’s a silly reason to lose a connection to the reader/potential client just because of the comma. In DeepTech there are many such people (typical of geeks, nerds, introverts, etc.)

It’s just bad for writing. It can save tons of time but the quality is poor. It’s not catchy, not joyful to read, it lacks natural spontaneity, and taste. Write on your own. The world is flooded with AI generated content. The world appreciates authenticity.

Managers hate it but it’s very hard to measure the real impact of technical writing on product sales or distribution. One can define metrics like time on the page or number of readers. However, when it comes to DeepTech, each reader matters and it’s quality over quantity. You don’t know who is on another side of the laptop reading your write up right now, which thoughts come to his mind and which actions they will trigger. That is to say… if you are a technical writing, don’t expect much credit for your work even if you are really good in what you are doing =) The credits will be taken by marketers, BDs, and sales.

• If you have a DeepTech company but don’t have a technical writer – you should have one as long as you care if your product will have any customers ever.

• If you are an active web3 technical writer – hit my DMs and join tech. writers community to nurture and polish your art of technical writing and help others do the same.

• If you have any questions about the matter, doubts, thoughts, or suggestions – send me a message I am always happy to talk about the topic because I care a lot.

Thank you for reading =)

Contacts:

Twitter: https://x.com/cryptobuilder_ | tg: @l_girll | email: lisaakselrod@gmail.com