Marketing Plan » History » Version 6
aplanas, 2013-08-07 09:05
| 1 | 6 | Project description |
|
|---|---|---|---|
| 2 | =================== |
||
| 3 | |||
| 4 | Communication and Marketing plan |
||
| 5 | ================================ |
||
| 6 | |||
| 7 | *High level communication/marketing/engagement plan* |
||
| 8 | **Marketing actions** |
||
| 9 | |||
| 10 | * Kickoff meeting & article |
||
| 11 | * Explain project, goals and time line, ask for input |
||
| 12 | * Usual social media promotion |
||
| 13 | * Make sure to have a pretty logo, a site to link to and at least a basic thingy to download/look at/demo. |
||
| 14 | * in case of ‘big deal’ project pre-seed press with information |
||
| 15 | * Provide updates |
||
| 16 | * Short (bi)weekly update mail to devel@ and project@ |
||
| 17 | * in case of ‘big deal’ project |
||
| 18 | * Status updates for news.o.o |
||
| 19 | * Interviews/articles during milestones |
||
| 20 | * Final/concluding meeting & article |
||
| 21 | * Celebrate success and contribution (if any) |
||
| 22 | * Usual social media promotion |
||
| 23 | * in case of ‘big deal’ project |
||
| 24 | * pre-seed press with information on final release and possibly initial announcement |
||
| 25 | * create countdown to 1.0 release |
||
| 26 | * attempt to get articles on other websites |
||
| 27 | |||
| 28 | *Note*: the vast majority of the writing above needs to start with the developers. They have to provide either a draft or have a conf call with someone who can write and then be available for review. |
||
| 29 | |||
| 30 | *community engagement actions* |
||
| 31 | |||
| 32 | * Write article about how to get the hands dirty |
||
| 33 | * how-to, tips & tricks, walk-through... |
||
| 34 | * create (recorded) hangout explaining how to do X, Y, Z |
||
| 35 | * 2 min intro of project, goals and timeline |
||
| 36 | * 2-4 min intro of current state & how to use it |
||
| 37 | * 2 min where to start hacking |
||
| 38 | * Q&A |
||
| 39 | * Keep first one short!<>! If there is demand, do more in-depth hangouts later. |
||
| 40 | * Give conference workshop(s)/talks |
||
| 41 | * Hands-on with the resulting project. Only if ready for end users |
||
| 42 | * hacking session. Only if a community around the project exists\ |
||
| 43 | * short talk on progress/plans\ |
||
| 44 | * quickly present project, goals, timeline. If project is small, maybe just a lightning session. |
||
| 45 | |||
| 46 | *Note:* only engage people if this is an intrinsic part of the project or you risk just creating disappointment and failure. You can’t do engagement just by talking or writing: you need to make it part of the development process. Have meetings in the open , make sure the software is VERY easy to deploy and easy to use , be there for questions, have a FAQ on the website etc. And yes, this ALSO goes for technical people. Being a ‘technical’ person merely means you happen to be good at something. It does not mean you’re willing to fight a build system, work through a terrible UI or read terse documentation. *‘engaging technical people only’ is an excuse for not admitting that you don’t want to put effort in.* |
||
| 47 | |||
| 48 | If you want engagement: |
||
| 49 | |||
| 50 | * Be honest. Put effort in, otherwise, don’t promise stuff you won’t do. |
||
| 51 | * Make clear what channels developers will be available and when. |
||
| 52 | * Make sure external documentation is up to snuff |
||
| 53 | * Have usability/ease of use as high priority during development |