4 ms·
Jon Yongfook has a brilliant approach - he writes code one week, then does only marketing another week. https://twitter.com/yongfook https://twitter.com/yongfoo
by metadata 5y ago
Jon Yongfook has a brilliant approach - he writes code one week, then does only marketing another week. https://twitter.com/yongfook https://twitter.com/yongfook
I plan to follow that as it completely eliminates the habit of "just have to fix a few things on the software side and then I'll get on with blogging/tweeting/...".
- mritchie712 5y agoThis is one of those bits of advice that you hear and say, "This is smart, I'm doing it... next week"
- unbanned 5y agoI am not clicking that link.
- mritchie712 5y agoTo Twitter?
- pawelwentpawel 5y agoI'd vote for Jon's method of one week code, one week marketing: - Limiting distractions. I won't get any work done if every five minutes I'm checking notifications that come in as a result of my marketing efforts. It gets me out of the zone immediately. - It forces a 50/50 split. It's too easy to stick to what you're good at. In my case it's coding and building the product - it's my comfort zone. It gives me a feeling for accomplishment and productivity. Feeling productive while neglecting the other side of the process is dangerous. - It's enough time to incorporate feedback from users quickly while staying sane without sacrificing the process itself. As per the release anxiety mentioned by the OP - that's a very common one, especially if you're the one that actually made the product. One way to tackle this is to view it as a continuous process of release, not a single event in the calendar. For me this means building confidence in increasing steps and doing a release often with a smaller audience first (maybe some small subreddit or a submission website?) and gradually increasing it as time goes on. This also allows you to spot any bugs or problems quicker.
- ChefboyOG 5y agoOne of the other benefits of this kind of approach is that it allows the two sides to inform each other without hindering each other. Each function gets the proper space to "breathe" in a sense. For example (and this draws entirely from my own anecdotal experience), I find that in the course of marketing, I often get the best feedback/inspiration from users/community members, and this is very helpful in deciding what to implement next. However, I find that this pseudo-research process is only effective if I take enough time to process the information in whole. In other words, if a user has an extremely compelling idea, it can be tempting to implement it right away. If I resist and take my time, considering the idea in the context of the dozen other points of feedback I've collected, I can often distill the jumble of ideas into a stronger, singular feature. If I jump in right away, I'll inevitably end up in a state of feature creep.
- datavirtue 5y agoYou have to be able to get into a marketing groove, though. It takes a lot of cajoling to get my brain to switch gears. I need someone who can live and breath marketing the way I live and breath software. I can get into a marketing groove but it going to detract from building. No way around that. Switching back and forth is going to burn me out.
- 255kb 5y agoSeveral months ago I decided to split my time 50/50, spend mornings on dev, and afternoons on marketing. it worked quite well so far. At least way better than the 99% dev and 1% marketing I-will-start-just-after-this-last-bugfix. I tried 1 week / 1 week before but during the marketing week I was overwhelmed by the wish to work on a new feature, or fix this damn bug :)