It's Marketing's Fault

William Imoh [0:00 - 0:50]: Are they building something at the moment? And they want to know how exactly they would use your product in what they are using. This is where tutorials come in, right? So they're following a practical, like, tutorial, building something, maybe a mini feature. And along the way, you're basically teaching them how to use your product in a hypothetical scenario. So it, you know, the goal of that is when they are done with the tutorial, they should be able to recreate it themselves. They should be able to start thinking, okay, what more can I do with this tool? So that's for tutorial. And then the last one is just. They're looking for short, sharp information. They know how it works, they know what they want to do. But maybe they've forgotten, like, syntax somewhere or they've forgotten, like some terminology or some API data or information, and they want that, so they just go straight to references. For instance. Get it? Head up.

Eric Rutherford [0:50 - 1:18]: Welcome to It's Marketing's Fault, the podcast where we discuss how to do marketing the right way. I'm your host, Eric Rutherford, and I am pumped because today I have with me William Emo. He is the founder and CEO of Hackmamba, which is a content agency that helps SaaS teams create original content and documentation which drives product growth and delivers a better developer experience. William, welcome to the show.

William Imoh [1:18 - 1:20]: Thank you so much, Eric. And thanks for having me on today.

Eric Rutherford [1:20 - 1:55]: Hey, it is my pleasure. I know last time we chatted on your show, it was a fun conversation. I wanted to get you on mine because what you guys are doing, man, that is so, so needed. So I just have to ask, because as I was flipping through the website, you know, I'm seeing about all this documentation and things like that. What was. How did you land on Hack Hackmamba? Like, what was. Were. What was the. What was the gap that you were seeing that you're like, we. I can fix that gap. I can. I can be there. So that you started Hackmamba?

William Imoh [1:55 - 3:20]: Yeah. So it's pretty. I would say it's pretty straightforward. So I used to be a technical writer, a freelance technical writer, while I was a software engineer and product manager. And because I combined these skills to create technical content, I could see things from the side of an external developer who will consume this content. And I could also see this as a marketing leader or a product leader that wants to create content that would benefit the product, that would help drive product growth and marketing growth. So I wrote great content, and I was getting a lot of requests to create even more content that I could take on. And not just that I was having my clients send me content from other freelancers and agencies, asking me to review their content and provide them feedback. And I would absolutely destroy the content. Like, I'll go, I'll go all in. I'll go all in on the content. So at some point I decided at that time I figured, oh, if I'm getting all this, you know, all these requests, maybe I'll turn this into a business. Because there's a gap for high quality technical content. Content that speaks to developers, that isn't selling. But is I something I like to say passively selling a product or a feature or a solution. So that's how I started Hackmamba on the side. And after two years I decided to go full time working on I love it.

Eric Rutherford [3:20 - 3:50]: And yeah, so technical content is really, it is very much a niche kind of, kind of content. But and I appreciate how that you mentioned that you were writing content that wasn't just overtly a sales pitch because so much of it is. Why is that? Is it because you think a lot of companies just don't know how to write it or. Yeah, I just love your thoughts.

William Imoh [3:50 - 5:11]: Yeah, it's for a plethora of reasons. Right. One obviously is a skill issue. They don't know how to write content that first teaches something. Right. And then aside, there's also pressure from marketing and leadership. Most marketing teams that I have worked with are pretty much selfish. They want to create content to drive conversion. They have all the attribution models set up. They just want someone to get. This is a demand gen initiative. So content creation for them is for demand gen. And they just want to see, they see it for what it is. Right. So you're either generating traffic through SEO or they just want anyone that comes in to convert probably through like a tutorial. So it's more bottom of funnel content. So when they have these outcomes without considering what a reader or a developer out there would get out of this content, there's this, there's always a mismatch and you get, what you get eventually is just content that sounds very salesy. Right. So it's, it's just heavy on. Here is, here's what we do, here's how to use what we do. Not to say that there isn't a place for such content, especially with sales enablement, but it shouldn't be in like general marketing, something you put on your blog to attract users.

Eric Rutherford [5:11 - 5:50]: Yeah, that's a good point. Is as far as the attract, it's like there's a place for it sort of on the funnel. But that shouldn't be the only content created like what you're doing. It sounds like then is very. It's informational, it's educational, it's showing the value of the product and service from a, from a technical viewpoint. So that you know others product managers, other engineers, other people using it really, and they get it. But it's not simply and buy it. Right?

William Imoh [5:51 - 5:54]: Yeah, obviously, because we need to keep creating more.

Eric Rutherford [5:54 - 5:54]: Right.

William Imoh [5:54 - 5:57]: The marketing team needs more budget from revenue.

Eric Rutherford [5:57 - 6:35]: So yeah, it is. And it's fascinating your background when you said you were your product manager, engineer and then content writer. Because I've seen especially, well, all kinds of different size companies, but I've been a part of companies where some of that information does fall on the product owner who is maybe responsible for some of the documentation and some of the content. It can fall in a lot of different places and I haven't seen it consistently land anywhere. And nobody seems to want that job in most companies. Because it's hard.

William Imoh [6:36 - 7:17]: Yeah, yeah, it's hard. It's difficult because you need really deep technical expertise, you need product context and then you need to be good at writing. Right. So if you're just good at writing and you belong in like the generic content marketing sphere, but with technical content, you need to be an engineer. At Hackmamba, we say all technical writers have to be engineers, either front end, back end, full stack, DevOps, AI and ML, but they have to be engineers. A lot of them have full time jobs as senior software engineers wherever, but they're just passionate about writing. So it's really tough to find such people on the team. But that's our requirement.

Eric Rutherford [7:17 - 7:42]: Wow. Yeah. Because if you can find that overlap with a writer and an engineer, they are able to speak the language in a way that is understandable and that's not just like a listing of features. Right. As sometimes like sales, sometimes is like, okay, well here's what it does and here's what it does and here's what it does and it's like, but that doesn't help me at all.

William Imoh [7:42 - 8:26]: Yeah, definitely it doesn't help. We say every content we create, we first write from experience, then we conduct some research and we write with research. So mostly from experience and research. And before we write, we ask why? Why should anyone care about this article? I'm going to write for every paragraph we ask the same question. Why should anyone care? Why should a reader care about this paragraph? So there's always that anchor placed on the problem that that piece of Content or the feature we're trying to communicate is, you know, solving. And then eventually we're teachers, so we're teaching, we're teaching whatever concept, whatever feature, whatever implementation or workflow we're writing about.

Eric Rutherford [8:27 - 8:51]: Do you find that in many, do you find that the goal sometimes is you want somebody to find and read the content and then be like engaged and then ready to jump to like the next blog article or the next, you know, article, white paper, whatever. Is it like you want, obviously you want them to keep coming back, not only to learn, but to build that trust is what it sounds like.

William Imoh [8:51 - 10:01]: Yeah. So typically this depends on the content strategy, the marketing team or the product marketing team they are going with. Sometimes folks come to us with the problem that hey, we built this cool thing. We want to, we want to build our top of funnel, right? So we want to build our pipeline. So we get people into either our sales pipeline or just our get the customer journey started. This means we're creating a lot of top of funnel articles to generate awareness. Right. So a lot of SEO articles, a lot of like transformation focused articles also go in here. And we're just literally addressing the broader problem that the product solves without really being very specific into here's a solution. It's just, here's a problem, here are potential solutions that can exist and here's how you could think of a solution, right? That's, that's one way to think about such content. And then there's, there are other forms of content that come in mid funnel and also bottom funnel content with different intents. So the content we create depends on what strategy. Whichever partner we're working with, they are, you know, they have at that time.

Eric Rutherford [10:02 - 10:32]: And that's, that's sometimes a tough piece of content to write when you're, when you're describing it and sort of being neutral in terms of who can provide the solution. You know, when you, when you start talking about, hey, this is a solution, that's where a lot of companies want to say, and I offer that you ought to check out my solution. That's, that's that moment of sales where sales can really jump too hard into it.

William Imoh [10:32 - 11:17]: Yeah, that's right. And it's pretty difficult as well to sort of passively weave in your product. It depends on again, what kind of article it is. If it's a listicle, then you're forced to put your product at the top. But you want to be very objective and specify why anyone should again, should care about this product. But you know, you're Pitting your product against maybe let's say six or seven other. Usually six, because you want the top seven, the top five, the top 11. So you want like the top seven. You're pitting your product against six other tools out there that are pretty similar. But you want your modes to shine through both at the start and at the end, when a reader is most likely going to make a decision to pick one.

Eric Rutherford [11:17 - 11:44]: I imagine that can be really challenging for an internal marketing team to write a piece like that because companies, I've been at it not always, but sometimes internally there can. Sometimes they hold their services up a little too high and maybe other companies a little too low. And so it seems like that would be some great things to have a third party actually create. So it's a little more objective.

William Imoh [11:44 - 12:32]: Yeah. So we typically say, obviously no one's baby is ugly, so everyone thinks their product is the best. Even if they're pitting against like competitors that have been around for decades, they're better always. So we come in, in that way to help them be very objective about. About what, you know, what they're communicating and also the features they have. Sometimes, especially when they're like Claire, underdogs, we have to find something, right? Something to say, hey, we address it early on and we know we are underdogs. We're just, you know, coming up. But then that's also our strength. Here are ways we are better. So sometimes you just have to come up front and be like, yeah, this company is better than this, but here's how we do it better. Here's why you should, you know, you should choose us.

Eric Rutherford [12:33 - 12:51]: Yeah, that is tough. But sometimes, yeah, sometimes you just have to call it out and that's okay. Especially in a content piece like that where you are pointing out the benefits of other companies as well. It's not. It doesn't come off salesy. I mean, it doesn't come off biased. It just honestly, it comes out just with some integrity too.

William Imoh [12:51 - 13:36]: True. Very objective. As objective as it gets. And the more depth you could put into it, the better the reader appreciates the time you've put and the effort you've taken to write this. A lot of teams do not have the time to test or try out 5, 7 products before they are able to write a listicle. They typically would just, yeah, go to the landing pages of these products, pick up some points there and write one. But for us, when we do write one, we ask that the author tries out each product. Right. Compares the features from usage and they can do so because they're engineers, so they can set up these tools, they can run local environments or virtual machines just to test and then they can write a very objective post from that.

Eric Rutherford [13:37 - 14:09]: Wow. Okay, let's kind of go into that because that is incredibly different from any marketing team I have ever heard about. Because you've got the engineering experience to be able to go and do just that. This is not second hand or third hand information. Like you as an engineer and your team as engineers are going in and basically going side by side and looking at all of it. Wow, that is a massive differentiator.

William Imoh [14:09 - 16:13]: Yeah, it is. And also in, not just in content creation, but also in reviews. Right. You have other engineers on your teams. Because we have a concept of teams. The authors work in teams so that we can retain product context. We don't just put in anyone to write any content just because we want to, you know, we want to help a partner create content. So the working teams and engineers in that team also review the content. And if it passes through like all the review stages, I sort of sanity check each content that goes out. So I'm looking through this. If it's a tutorial, I'm looking at the workflow, I'm looking at the code. And I've done this countless times for certain, like I would say workflows or developer experience considerations they had to make. I would also like question these. When we review, we ask questions. We rarely just go and correct something. Except maybe this is like a glaring typo. But if it's a change that's needed, we don't make the change. We ask a question like, so why did you do it this way? Why did you make this consideration? Why did you use maybe classes in Typescript instead of functions? Or why? I think a recent one, if I remember correctly, was latency in open source models. Right. So an author wrote AI models experience open source models. The challenge is they typically have high latency. And that was supposed to be far, but then I read it and I'm like, but closed source or hosted models also experience some form of latency. So you need to be specific, you need to actually state what the differentiator is here. What makes the open source ones have a higher latency? Probably is it because they are self hosted? You do not control the virtual environment where it's hosted. So a bit more into the technicalities. These are some things we can question. But a marketing person doesn't know what's going on. What's going on there?

Eric Rutherford [16:13 - 16:46]: No, no, that's. That is way outside the sphere of understanding and influence that most marketers have. And I'm raising my hand as like ye like those things. Those are just questions I don't, not only do I not know to ask, but I wouldn't even know what to do with the answer I get. Yeah, so that's, that's huge. So what do you work, is it small companies you work with? Do you work with large companies like, or just sort of the gamut? I didn't know who your customers were.

William Imoh [16:46 - 19:48]: Yeah, so our customers, we work with different kinds of customers and it comes to us for very various reasons. Right. So we have the large, I like to call them the mid market to upper mid market companies. And they typically come to us to augment their team and to get a variety of experts. Right. So at that stage when they're between anywhere from 50 to 150, 200 employees, they have a marketing team. But then they have like larger content throughput. They have content they need for demand gen, they need to create sales content, they need to generate top of funnel just for SEO. So we have some partners that put out anywhere from five to 10 blog posts each week. Yeah, yeah. So they put out five to 10 blog posts each week and they need to satisfy that demand. So they come to us to augment their team and just match that demand consistently. Also others come to us, especially the large teams as well. They come to us for a variety. They're unable to get or hire technical writers internally for Typescript, JavaScript, Python, Golang, Rust, the different programming languages out there, different technologies that exist. But they know if they come to us, we can always put together a very diverse team of very great technical writers and we can create content across different frameworks, languages and tools. So these are sort of like the larger, the larger clients we get, the smaller clients we get, basically they just want to do a couple of things. The first one typically is they want to offset content marketing. Right. They come to us to save cost. Right, that's, that's something because typically we are about between 25, 30% cheaper than our competitors. Right. So they come to us to save, to save cost. They come to us for consistency because when they work with freelancers, they have to manage multiple freelancers at once. They need to ensure consistency in the quality of the content they create. They also have to deal with editing the content, specifying graphics and design, making sure the content matches their strategy, and having to like make continuous reviews. So they don't have the capacity for that. They just want to build a great product and make it work. So they come to us for work that reason. And then there are some teams that come to us and say, hey, we've built this great thing, but our documentation is horrible. The developer experience is just poor. We need help with our documentation. In that case, we either have a documentation project or we augment their team with a full time technical writer that sits remotely in their product chores and just writes their documentation, creates content for them as part of like marketing effort. And yeah, we also help them with like strategy. We're brutally reviewing the documentation all the time, fixing gaps, that sort of thing. So typically our clients come from either small companies or large companies and they come to us for this, these reasons.

Eric Rutherford [19:48 - 20:28]: I love it. And you mentioned like some of that documentation and documentation always, well, always is a strong word but frequently is sometimes the last thing that people think about or the last thing that people get to just because of of time constraints, of resource constraints. How that seems like that would be a pretty valuable sales option for you guys, I can't imagine that. Let me back up. I would imagine that most companies are lacking in their technical documentation internally. Do you find that to be the case?

William Imoh [20:28 - 21:52]: Yeah, that's the case. And it typically depends from region to region. And this is something new I discovered in business for regions or business areas or countries that value a lot of like independence and they have a lot of SaaS, product led growth companies, they tend to have like great documentation. They put some effort into making sure the documentation is good because they know they're building something to scale, to scale to millions of users in first couple of months. So they always put like really good emphasis on dolls. But then when you come to other parts, like in Europe for instance where they sell to a handful of enterprise clients, they are sales led, they don't really care so much about documentation. They are the ones that still use something like Confluence. Like Confluence is like really bad for docs, but they still use like the older documentation tools. The documentation doesn't even have to be great. I've seen companies that have PDFs as their documentation and some send you a manual where email. They write you an email with here's how to install this, here's how to set it up, here's how to use it, here are the endpoints, here's what you need to send and that's it. That's as far as they go for documentation. So so far we've seen the need for documentation also vary from country to country and also from go to market motion from one to the, you know, to the other. Yeah, so, yeah.

Eric Rutherford [21:53 - 22:20]: So what do you from that aspect? Because it's a slightly different writing style than the content. What makes good technical documentation different than good technical content? And especially from a writing perspective, do you find writers or creators can do one better than the other or is it pretty much the same?

William Imoh [22:22 - 25:52]: Pretty much different. With technical content you are doing a couple of things. You're telling a story, right? So this is content for marketing. You're. You're telling a story, you're trying to be casual and a bit. It could be almost informal in some cases also because of the rise of like AI content. So we need to make sure the content we create feels as human as possible so folks can actually consume it. So the skill required to create content for marketing is totally like different. You're having to like weave in words, weaving like the product tactically. Whereas in product documentation, the reader knows what to expect. They know they are talking, you're talking about your product. So you can just go all in. You're not selling, you're just saying, hey, here's how my product works. It's almost like a manual. Some documentation creators or some companies add a little bit of flair to their documentation so it feels a bit like fun and it's comfortable to consume. Whereas some others just go like straight to the point because understand this is going to be consumed by developers. They don't have time to like mess around or read like a lot of text. They just want to get straight to it. So there is a lot of diagrams, they show a lot of code and then just few text in between. So that's the approach, the difference in the writing style with content for marketing and documentation, but also document with documentation, there are different parts to it, right? So something we do is we take an intent based approach to documentation. Right? We assume that, we assume a specific mental model of a developer, assuming it's a developer that would read the documentation we think about. Okay, so what mental state is this developer in? Are they just learning this concept? Generally that's one state. They just want to know how this thing works. Like how does authentication work in general? Are they building something at the moment and they want to know how exactly they would use your product in what they are using? That's one model. The third model is they are, they're learning, but they're not looking for general knowledge, they're looking for practical knowledge. Right. About how your product works. This is where tutorials come in, right? So they're following a practical like tutorial, building Something, maybe a mini feature. And along the way, you're basically teaching them how to use your product in a hypothetical scenario. In that case, the language could be a bit like, relaxed. You could, you could dump things down a little bit more. You want to state why, you want to state the reasons. You're making certain decisions there. So it, you know, the goal of that is when they're done with the tutorial, they should be able to recreate it themselves. They should be able to start thinking, okay, what more can I do with this tool? So that's for tutorial. And then the last one is just, they're looking for short, sharp information. They know how it works, they know what they want to do. But maybe they've forgotten like, syntax somewhere or they've forgotten like some terminology or some API data or information, and they want that. So they just go straight to references. For instance, get it, head out. So the, these parts of the documentation require like, different, also different writing style for them, but you're not afraid of like, you know, overselling or just talking about your product in each one. And that's the difference between that and content marketing.

Eric Rutherford [25:52 - 26:37]: And that's a, that's a big distinction because I think many times those two types of materials sort of get lumped under the same thing. And, you know, where it can almost be like, okay, so all of this is content? Well, no, not exactly. It can be very different. And even as you were talking about the documentation, like, that's. I hadn't thought about, like, they're very much different genres of even technical documentation that you're writing and that you're creating. Do these companies, is that something you'd kind of help, kind of flush out with them, or is that something they know ahead of time?

William Imoh [26:37 - 28:10]: So a lot of them, they know it ahead of time. Again, depends on the stage of the company, right? If we're working with companies with a product manager, for instance, that knows exactly what they want, they have these sections just to fill these gaps. That's pretty clear for some companies, especially when they're like, super early stage, you have absolutely no idea. And they come to us and they're like, hey, we've built this thing, we want to write documentation for it. Here's an open API spec for our API endpoints. And then we have a couple of SDKs, we have a couple of features on the platform, especially if it's developer focus and we want to document this. So a couple of things, right? We have to design a developer journey. So if a developer comes from a Website, how do we get them from zero to hey, I'm successful with this product, I have it installed, I understand how it works, I can make changes and I feel empowered enough to maybe even almost like contribute to it. Like I can suggest something that is off, understand what workflow is ideal and what recommended. So we look at these different workflows for developers and we develop that. That's usually the first, the first bit before we go into actually writing, structuring the docs first. So we have these flows and we determine, okay, so what kinds of documents do we want to have? What makes sense for us to have now and maybe later. Then we structure the documentation to follow that model, putting the most important first and the least last. We do that and then we get into actually writing the content.

Eric Rutherford [28:10 - 28:53]: I love that. So as you were talking, one question that popped into my head was, you know, I, I know that there are company leaders, execs who, they know it's important and it's good to have this kind of documentation for their products. But maybe they wrestle with, okay, how do I justify the spend for it? Like, yeah, it's almost like a nice to have but maybe not a need to have. How do you answer some of those questions? Because I know again, it's all about resources. It's trying to make things work properly. How would you respond to them?

William Imoh [28:53 - 30:41]: Yeah, so I mean a lot of times we hope it's easy that they see the value of what we are. We're selling, right? We're saying, hey, we're going to ship. You're going to have a better developer experience when they do. That's great. No convincing bug to your question. When they don't, then we actually have to sell. Typically what I do is I pull up Stripe. Stripe is the holy grail of documentation. I pull up Stripe's documentation, I put it side by side with theirs and I'm like, hey, look at this too. If you show a developer Stripe's documentation and you show them yours, they like throw yours out the window and they would go with Stripe. This is what good documentation looks like. So I show them what the transformation could look like right off the bat. Then I start to think about what are the other objections they have and how can I make it like risk free? How can I make it easier for them to start? We typically have like a one month non binding period where we work together. You see what output is if your outcomes are on the way to being met and also if our process makes sense for you, if we do, we continue Working quarterly, right? We do not lock them in into six month or one year contracts like a lot of our competitors would do because quarterly keeps us on our toes and it makes, you know, it makes sense for these companies. As a founder, it makes sense for me. I don't want to be locked into stuff for six months. So I extend, I extend the same, I would say I extend the same consideration to the founders and companies we work with, except they come to us and they say, hey, we love this. We want to keep this going for like long term. We want to lock it in for financial reasons. And yeah, we have a lot of such clients. I'm very happy, I'm excited to get that in.

Eric Rutherford [30:41 - 31:02]: But that's cool that if they come to you and ask for that, you do it. But that's not a push for you. You're really, not only are you an engineer, like you're a founder, you get the whole picture in terms of what they need and what you can provide. So that has to make it, that makes it better for everybody.

William Imoh [31:02 - 32:23]: Yeah, makes it better for everyone. I see the value they have for money. I understand what stage they are with their product. I've worked at startups, you know, my whole career so far. So when I talk to founder, I already know if it's a financial problem. I know like where they are at with finances, how much money they have to spare. And I'm suggesting something. So most of our offers are bespoke, right? They are, they are custom and they're made to feel. And a lot of times I go into these calls to disqualify whoever I'm speaking to and I say like, hey, shouldn't be doing this. I talked to founder recently and they do not have great documentation yet. But I told them, hey, you don't need our help. You don't need our help yet because you don't have volume, right? Your product isn't voluminous enough to create great documentation. What you have now, I think it's manageable by your team, product manager or even the engineers could dedicate some time to just document this stuff. When it's getting out of hand, then we can come in to clean things up a bit. And maybe we could leave like a technical writer behind that would just sit with your team and manage your dogs. So love these conversations. I'm also disqualifying founders because if I don't, it becomes a problem along the line. They feel like, yeah, they've paid for something, they're not getting any value and that's not what they sign up.

Eric Rutherford [32:23 - 32:55]: Yeah, I like how you, you talk about that. Both from trying to disqualify in terms of this isn't the right fit for you right now. But you also mentioned like some of the good technical writing that you do. Sometimes it's because they aren't at that level of scale. Like, is there a. What's that look like? What does that right level of scale look like? Where it's like, okay, you really need to make sure your documentations in order.

William Imoh [32:56 - 34:55]: Yeah. So if they are starting to go to market, they are building like a, like a sales pipeline or they're building up like a marketing funnel, basically their whole gtm. If they're doing that and they're going to be getting users. A common trap a lot of teams fall into is that they've built all these things, all these systems, put together a team to acquire users, but then they are unable to activate these users. I still talk to clients today that have like the marketing team, they're going like overboard. They're going all channels, they're doing events online, offline. But then these users come in, they sign up. So they acquired that metric. The acquisition metric is checked, but then they are not activated. They're not using the product. They churn faster than light. Really. They churn so fast. So the team, at this point, they're thinking about how can we develop our experience, how do we fix our own body, how do we make sure, like our documentation is great so folks actually understand what's going on, how to get started, how to derive value from this product. Right. So this is where we come in. And we come in when the engineers are unable to write documentation. The founders also unable to do that because they have higher priorities. Now the product managers are focused on product improvement, product development. Maybe they are, you know, seeking product market fitness. So the product manager doesn't have time to write like loads of documentation. Maybe they're going after a funding round. So they're just hard on product, hard on customer interviews, hard on customer acquisition, and they don't have time for documentation. This is where we come in. And we know hiring is also difficult. So we fill that gap where again, you need an engineer, but they're a good writer, they can communicate clearly to other developers. So this is where we provide technical writers. I just offset that load from these companies and we help them create their docs.

Eric Rutherford [34:55 - 35:49]: That helps me just in terms of like that demarcation line of when do you need that? And that's pretty straightforward. It's like when your Product managers can't handle the load of creating the documentation to bring you guys in. It sounds. And then it sounds like with go to market, you focus on the. And I've, as somebody who was in product marketing for a bunch of years, like, I know exactly what you're talking about. Like, I have seen the pain and the problems of acquisition and then you find the gap. So, and I'm guessing ideally when that gap becomes, when a company becomes aware of that gap, it's like, okay, I'm going to call Hack Mama and fix this. But it sounds then also like, if you don't have a high volume yet, it may not be the right time. Is that what I'm hearing?

William Imoh [35:50 - 37:32]: Yeah. So someone used a term, I was talking to someone yesterday, he used a term for this. I can't remember. But basically when we reach out to companies or founders or teams that do not need technical writers yet, they are not feeling the pain. They almost do not want at all. They're like, yeah, we don't need this right now. We're focused on product development. They haven't gotten to that tipping point yet. So for us, what I, at least what I try to do is just nurture them, build relationships, just stay in touch. I'm always happy to like provide services pro bono even, because I like to talk about this stuff. I can do it all day long. So I'm always happy to like audit their dog. So I just keep them, you know, keep them close, we chat, we become friends at some point. And then whenever they're ready, when they feel that pain, when developers are in their slack and their discord saying, I cannot find this thing, or I don't know how this works, or it's gotten so bad they're now on social media saying, this is a great product, but you absolutely cannot set it up. It's like spaghetti. You don't understand the documentation now that once that sort of message trickles into the company's slack, then they remember, okay, we need help, we need to hire someone, but we really cannot get the right fit to help. Maybe they have like a very niche product or they don't have a HR team. They don't have like hiring managers or people internally because that's usually like the last thing teams think about. They don't have that. Then they figure, okay, we need to talk to Hack Mama and see how we can get like a documentation project. At least we fill this gap and then we see what happens.

Eric Rutherford [37:32 - 37:53]: That's awesome because like you, it sounds like as you're Building these relationships, you know, it is likely they are going to call later on. They just, you just like, like there's no sales process for you because you just know there's going to be a day when they pick up the phone because that pain is going to become very real.

William Imoh [37:53 - 38:27]: Yep, a hundred percent so far. That's just what it's been. When we try to go outbound to reach out to them and say, hey, I see your documentation. I make loom videos, 5, 10 minute loom videos of like dissecting their docs. I'm like, hey, this person has a clear problem. They don't convert. They're like, we have other priorities now. We're not looking at this. The developers are not complaining yet. They are not complaining of being stressed and burned out from developing and writing content. So they're not feeling the pain. I just have to wait till that tipping point where it's like, okay, this is a lot. We cannot keep doing this.

Eric Rutherford [38:27 - 38:50]: Let's get help that makes sense. Now with. As you, as you start doing this work, do you also help with the organization of it? Because I know that in and of itself can be its own headache challenge. Like sometimes just finding the documentation that exists can be tough. Is that something that you also help with?

William Imoh [38:51 - 40:21]: Yeah. So that's typically second step of our documentation process is if it's, if it's a fresh, this is a greenfield project. So it's a fresh documentation. We structure it right. And we inform the team of like, hey, for subsequent documentation or content in the future, this is where it goes. You don't have to think about it twice. So just put it in here. This is where guide should be. And this is the mental model for anyone looking for that sort of document. And for documents where you're not sure where they go, we have like a special bucket. Just put them there. It's like R and D folder in the doc. So we also manage organization. Obviously it gets like really, I would say it gets really large. Like sometimes you get really large. So we work with like really enterprise clients have been around for decades, right? And they have like tons of content. How do we manage that? A number of times we also work with like partners, like documentation experts and like content managers. Right. And content designers that come in and say, okay, hey, here's how we're going to structure this. They just tackle the structure for that. They talk to like engineers, the interview folks talk to the team, see what the current workflow is like and then they work on the structure or they participate in like the overall documentation project. But they are specialists in just fixing like mountains of documentation that's in different parts.

Eric Rutherford [40:21 - 40:51]: Wow, those are my heroes right there. Because that to me feels like an insurmountable challenge is when all of that information and documentation is out there and it doesn't, it's a mess. Like that to me is. That gives me the cold sweats thinking about it. So like just. But knowing that you're able to put the right people into place and help them like that has to give a lot of comfort to those companies.

William Imoh [40:51 - 42:12]: Yeah, yeah, it does. Obviously it doesn't come without challenges. Right? Yeah. A lot of companies so far they're scared of like data and exposing like their IP and all the company's stuff to an agency. Then there's just the traditional agency bias. Folks are like, yeah, agencies just come in and make stuff worse. I think that's the most like the biggest problem I have sometimes. Like these guys, they just do not like the sound of agencies. They've probably been burned in the past by some really expensive agency that's just like didn't do stuff like just didn't do shit for them. So because of that they, they just do not trust agencies anymore. So I have to get past, past that. Right. And then there are also some companies that do not just want to work with external. They don't want external people in their system for seemingly cultural reasons. Even though the culture internally in the team might not be the best, like it's not good, but they just do not want someone external joining them. I'm like, what are you trying to save? What are you trying to save in the first place? There's nothing here. Why are you scared? Right. So that's, that's the challenge I have to deal with. So yeah, it's interesting.

Eric Rutherford [42:12 - 42:40]: It sounds like just though a lot of opportunities for companies to really get a handle on both their technical content, their technical documentation, without having to hire internally, without having to add headcount, without hiring managers. Really sounds like honestly a great option for a lot of companies just from taking the pain in the headache take of some of this away.

William Imoh [42:41 - 43:23]: Yeah, it does. It's a great option. I wish a lot of teams saw it that way. There are also teams that just want to have again, they want to have people internally, they want to add headcount, but then they want to add headcount their way. So you tell them, hey, this person is almost like adding headcount. You're going to have a full time senior technical writer that would just be sitting remotely they're just a contractor. You have, like, one more member of your team. They're like, no, they're still not in the company. We want someone that will go through, like, our hiring process and we'll, like, come into the company. Mike. Oh, man. Okay. I can't help you. You can't have it all. Go get a HR team together.

Eric Rutherford [43:23 - 43:28]: So before we wrap up, just one last takeaway that you'd like to leave the audience with.

William Imoh [43:28 - 44:03]: Yeah, I'd say write great content. Everyone should be creating. We're currently in the age where I feel like, and this is my personal opinion, I feel like original content would win. Right. And original content will become more valuable. At least that's a good way to put it. So I'd say, folks, create more, read more, write more, especially with technical content, build more. So be a better engineer and just, you know, write more. That's. That's what I'd leave to anyone listening to this.

Eric Rutherford [44:03 - 44:37]: I love that, and I would agree. And everybody listening, like, good content will always rise to the surface. Like, I don't. There's a whole bunch of content in the world, but there is a shortfall, I think, of good content that's helpful, especially from a technical aspect, because it. It takes a just the right touch and the right perspective to be able to create that. So that is a major differentiator that companies can create for themselves.

William Imoh [44:37 - 44:39]: Yeah, it is. It is. Totally.

Eric Rutherford [44:39 - 44:45]: So, William, if people want to know more about you, they want to know more about Hackmamba. Where do you want them to go?

William Imoh [44:45 - 45:14]: Yeah, so first, Hackmamba IO. I'm always happy to talk to anyone that needs help with either documentation or content marketing, or just chat and exchange ideas, or just share what works and what doesn't work. What I've seen so far, they can always reach me on LinkedIn. It's William, you emo, as well. Just find a guy with, like, pilot headphones on and that's. That's me on LinkedIn and send me a message. Send me a message anytime. I'm always happy to chat.

Eric Rutherford [45:15 - 46:02]: Awesome. Well, we're going to drop that link in the show notes as well as Hackmamba. If you're listening, reach out to William, engage with him, look at the content that they're creating, and definitely realize that this is an option that you don't have to handle internally. Your teams don't have to be buried. Like, this is not. It's not just another thing that they have to keep on their plate. This is a great opportunity to really build your company well and work with a great team at Hackmamba. The amount, just the sheer engineering experience that you provide and writing experience is just incredible to me. I think that's amazing.

William Imoh [46:02 - 46:03]: Yeah, thanks.

Eric Rutherford [46:04 - 46:12]: So, William, thanks for joining me today. This has been really fun and I have learned a lot. So I appreciate you joining me today.

William Imoh [46:12 - 46:17]: Yeah. Thank you so much for having me. Always happy to be on this. Always happy to just chat with you anytime.