[metadata]

Jon Yongfook has a brilliant approach - he writes code one week, then does only marketing another week. 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/...".

[pawelwentpawel]

I'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.

[mritchie712]

This is one of those bits of advice that you hear and say, "This is smart, I'm doing it... next week"

[ChefboyOG]

One 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.

[255kb]

Several 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 :)

[datavirtue]

You 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.

[unbanned]

I am not clicking that link.

[mritchie712]

To Twitter?