I know there's no de
[2023-02-10 12:16:05 PM] : I know there's no definitive answer for this issue, but I'd love to get some feedback and thoughts on it.
I've got knowledge and experience that can help my audience (Django Developers), but I know that the solutions I provide could also be easily adapted and used by others in a broader audience (Developers). The pain points are universal across all forms of developers.
I'm concerned that by focusing on just the narrow audience, I'm losing out on the larger audience that could easily benefit from the same things. But I also know that writing to a generic audience dilutes the effectiveness of your content (for authority building as well as feeling applicable to the individual reader). I'm not quite so concerned about losing out on potential sales as I am simply not helping the most number of people possible.
All that to say, I'm torn between focusing on the narrow audience or instead broadening the scope of my target audience.
(There's also slight concerns about "Django developers" as an audience and finding more than one major pain point, but that's probably just lack of enough Safari yet.)
1 Reply
[2023-02-10 01:12:41 PM] : I wondered about the ways my audience relates to neighboring disciplines, too. The safari process revealed that my audience (technical writers) believes that they are :sparkles: special :sparkles: and will happily ignore useful resources that aren't specifically for them. I don't know if that's true for your audience, but in my case, safari taught me that generalizing would mean forgoing the significant advantage of working with the audience I was already most familiar with. Which is to say, bigger isn't necessarily better and it might not be apparent without doing the research first.
[2023-02-10 02:38:46 PM] : 100% correct.
[2023-02-10 02:39:08 PM] : Every audience wants to believe they are special even when they aren’t.
[2023-02-10 02:39:30 PM] : I’ve never seen anybody lose by going too specific, but plenty of people lose because they were too vague.
[2023-02-10 02:42:06 PM] : Too specific is technically possible but I’ve only ever seen one person do it. In this context, too specific wouldn’t be “python” or even “Django” but it might be “one specific function or feature in Django”
[2023-02-10 02:45:14 PM] : And even within that, if the function or feature is expensively painful for a lot of people, you might still have something! Probably not an audience but at minimum some ebombs and likely product(s).
[2023-02-10 03:11:04 PM] : a lot of developer pains are definitely universal :smile: but imagine reading a headline like “The complete guide to architecture for software developers! Buy now. It works for every language” vs “The complete guide to software architecture for Django developers! Buy now”
[2023-02-10 09:36:39 PM] : Thanks to all of you for your thoughts on this.
[2023-02-11 03:45:08 AM] : I’ve also struggled with that issue. And I found trying to help all developer vs a specific subgroup makes writing ebombs very hard.
It starts with in which language do you write code samples. Narrowing it down onto one language makes it so much simpler.
[2023-02-11 03:58:34 PM] : what’s your newsletter or social media i can follow? i use Django at work
[2023-02-11 04:04:58 PM] : Daily info snippets on the Bird App: https://twitter.com/Solo_DevOps
Newsletter signup at the bottom of the page: https://www.solo-devops.com/
[2023-02-11 04:05:54 PM] : you got this broken link not sure if you’re aware [File hidden by Slack limit]
[2023-02-11 04:06:00 PM] : All the current content has been pretty focused on the general audience instead of the specific Django audience, but it's all still heavily applicable.
[2023-02-11 04:06:43 PM] : Yeesh. I keep forgetting to kill that link until I have a some of those. Thanks for the reminder.
[2023-02-16 09:51:30 AM] : Just to chip in Chris V point about not having a clear idea of who you are writing for can burn a lot of time and energy - I find myself still refining this and trying to get more and more specific.
[2023-02-16 10:28:05 PM] : In my case, which is probably an outlier, I benefited from being more generic. Ruby is used for all kinds of projects, but "Ruby on Mac" isn't advertised as only for Rails for example. From talking to people who used the free version before it became Ruby on Mac, I knew that the most popular tools people needed Ruby for were Rails, Jekyll, and Cocoapods, so I mentioned all 3, and I have e-bombs for all 3.
And then with more research (thanks to F5Bot) and more conversations with customers, I discovered people were having issues running Flutter and React Native as well, so I started posting in those subreddits, and added those terms to the Ruby on Mac site.
However, the specific part I'm focusing on is Mac. Perhaps some day I might expand to Linux and Windows, but for now Mac keeps me plenty busy.