A few years earlier, I worked for another international company. We were using tools produced by teams in the US. I still remember the launch of a new version of one of their tools under the code name NorthStar. I was used to very codified version numbers, x.y.z, where each letter had a particular meaning.
And then I realized that everyone was talking about the NorthStar project. There was a whole storytelling about why it was being done, what it was going to do. It was actually a great promotional operation, and it was working, beyond the technical teams.
In the past I've had trouble with promoting a project, selling it. I considered that the result spoke for itself. The quality, the usefulness of a tool or an application could be seen, it didn't need to be sold. On the contrary, doing too much made the speech suspect.
Individually, many techs have this way of thinking, don't like to put themselves forward and consider that their results speak for themselves. The Dev population is by nature skeptical and trusts logical facts and data more than nice slides and speeches.
And yet, far from falling into the category of misleading advertising, knowing how to sell your work is also a way to bring clarity to your objectives. To whom it is addressed, what is the expected value. You can't blame people for not understanding your work if you haven't made the effort to talk about it.
At this point in my career I'd say it's not a topic I feel I'm very good at yet and I'll probably rework this article in the future. But I had to make a chapter here, because tech marketing is a strong lever to create impact in an organization.
From startup to scaleup
On Malt, as a co-founder, I experienced the growth from 3 to 700 people.
On a small team, it was pretty obvious to see the value of the product and understand it. The Product works or not, users sign up and use it, or not. We don't measure the availability or quality of the software. If the app is not available, everyone sees it.
Anyway, when we were a startup, I didn't promote the product because it worked well.
But on a more complex product, it became a real issue, because as the business of engineering grew, it became blurred.
The blur
It is a very difficult exercise to age a product, much more than to create it. Every decision has consequences. Each new feature brings complexity. The constraints are increasingly strong with growth, on security, robustness, efficiency. Saying that an application is available no longer means anything. Does the payment work? Does the recommendation engine work?
To deal with all this, to make an ever more successful product, you need large teams, but this comes with a cost in terms of communication and coordination.
Why does it take so long to build this "small" feature?
Why do we need so many people on the X team, security, ops etc?
I just saw that we built feature Y, what is it for? Are we really working on the right priorities?
What is the use of all the feedback we get? Who's working on it?
You may have recognized some of these phrases. With growth comes a certain amount of vagueness.
This vagueness is detrimental to the trust you have in your product team. Trust also means investment. Investment in the product is made if you understand what you are going to gain, or what you might lose.
It is necessary for the company to explain how it spends its money, how it invests and with what result. Again, in a product company, it is obvious that you need a product team. But what is the right level of investment? Why not 50% less for example?
And I'll let you imagine what the recent example of Twitter, which let go of almost 80% of its staff, could have done. "If they did it, it's because it works".
Clarity
Our role as tech leaders is to remove that blur, and bring clarity. I like to call it "extracting the signal-to-noise ratio".
Let's take some examples:
- Of all the possible tasks, you chose to work on tasks A and B. Why? How do they relate to the company's strategy? It's a matter of implementing a data-driven culture.
- Once a choice has been made, how do you get the right people together and make sure that everyone understands this priority? This is, among other things, a question of leadership.
- Once you've done the work, how do you make sure it has impact, that it's used? There is a distribution issue.
To orchestrate all this, I like to look at marketing, and in particular product marketing, which can be roughly summarized in two major steps: Discovery, Distribution.
- Discovery is the exploration phase to determine what to build.
- Distribution is the methods to bring your product to the users.
This is exactly what we can use internally, within the product team, as well as externally, through other teams in the company, and even beyond.
Market Research
The parallel between technical discovery and market research is quite obvious and I like to take inspiration from these techniques to identify "user" needs.
For example, Market Research consists of studying the market via surveys, interviews, shadowing (user observation) or Data. These are very good tools to reuse on the tech side.
These tools also have the internal advantage of preparing "Storytelling", another marketing technique to promote attachment and adhesion.
Story Telling and Press Release
Storytelling requires simplification and vulgarization.
Not everyone understands tech, and even within a large team, the issues can be complex to explain. You have to simplify. I was talking about bringing clarity, it is impossible to bring clarity if the projects cannot be explained simply to people who do not work on them. Tech needs to get out of the specialist posture and instead be approachable.
I insist on this, major tech initiatives must be explained to anyone in the company.
One tool Product Marketing uses to make sure everyone understands the objective is the "press release". A "press release" consists of writing a short text at the beginning of the project, or even a tweet as it would be written at the end of the project. It must be short, understandable, impactful. This tweet will set the ambition and the expected impact for the next x months.
Project Singapore
In 2022, we launched a project that aims to completely simplify our frontend architecture from 6 technologies to only 1. The goal is to improve our speed and solve a technical debt that was handicapping us more and more. This technical debt was about to explode to the point of making any new development very complex.
We studied the market, and in particular the experience of other companies at almost the same stage as us. Several of them had had to freeze code for several months to deal with technical debt. Our metrics confirmed a loss of speed and significant development complexity.
The storytelling around this project resulted in two blog posts:
This name, these blog posts, and the internal communication contributed to aligning the product teams on the issues. It became a major objective for the year and it allowed us to communicate beyond the product team.
Product Knowledge and distribution
If Market Research and Storytelling prepare the distribution phase, the work is far from done. We have all known projects that were very well done, but not used, not understood, not found. Distribution is all the actions intended to promote your product, to bring it to the users. It's not "just" Product Tours.
Good distribution methods are what made Teams win the battle against Slack.
In short, a good distribution is the difference between an "okissh" project and a great product.
Related to Engineering this includes all the mechanisms needed to make people know and understand how to use your product. This includes: technical documentation, development portals, training, newsletters, demos.
For example, for the Singapore project presented above, we have completely overhauled our internal documentation portal and introduced many "Getting started" guides. The project is ongoing, but every week we organize a one-hour session to present new features (or difficulties) and improve the documentation portal. The people of the Singapore project are in constant support of the teams that need it.
Outcome, not output
Lastly, Tech Marketing is knowing how to communicate on these successes, knowing how to celebrate what has worked and what it has brought.
But it is important in this communication to insist on the impacts, the results, not only the achievements. We need to talk in terms of gains: cycle time, financial income, availability rates, etc. The trust that we are trying to build in an engineering team is based on these gains, not on the means. The means must of course be explained, especially in order to be adopted. The output of project X is necessarily important. But what creates confidence over time are the gains of project X, not the fact that project X has been completed.
Questions
Do you communicate about architecture changes, technological evolutions of your product?
Would you say that tech is understood within the company?
When was the last time a technology project was mentioned in a communication within your company?
Resources
TIP
This blog post is part of the book Impactful Software Engineering. Feel free to read the other chapters.
