# Going from blog posts to full launches

DevFeed: [Going from blog posts to full launches](<https://devfeed.tech/articles/going-from-blog-posts-to-full-launches-41183.md>)

Original publisher: [Read original article](<https://www.craigkerstiens.com/2015/12/26/Going-from-blog-posts-to-full-launches/>)

Author: Map

Published: 2015-12-26T20:55:56Z

Content type: opinion

Language: en

Sources: [Craig Kerstiens](<https://devfeed.tech/sources/craig-kerstiens.md>)

Topics: [Development](<https://devfeed.tech/topics/development.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Learning](<https://devfeed.tech/topics/learning.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [development](<https://devfeed.tech/tags/development.md>), [marketing](<https://devfeed.tech/tags/marketing.md>), [startup](<https://devfeed.tech/tags/startup.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

The article explains how teams can evolve from publishing individual feature blog posts to running coordinated product launches. It recommends having the product ready and validated with alpha or private-beta users, allowing schedule padding, preparing demonstrations, and using launches to test and refine the core product message.

## Source excerpt

I recall extremely early stage where you'd build a feature, realize it was awesome, then the next day write a blog post for it. At some point you start to move from that to more coordinated launches. A larger coordinated launch allows you to reach a bigger audience, can lead to bigger deals, and help expand your overall market. But perhaps more importantly by the time you hit full launch you've message tested and ensured it's going to resonate in the way you expect. The process itself will both help amplify and validate/refine your message This is often a more gradual process than a sudden single change, you'll introduce new parts of this in time. And for many what an entire launch process looks like comes by trial an error, to help shorten that learning curve here's key areas I pay attention for a launch and process followed by a rough timeline. Product first Making sure the product is in the right shape is key to any big launch. You don't get a second shot and if the product isn't in shape customers often won't take a second look at it later. For this reason I strongly prefer to have your product locked and loaded before you even start talking launch times, or at least be in the bug clean up phase. This means you've built a feature, validated with alpha users or private beta, and are ready to open it up to the world. If you have to set a launch date without the product or feature being already done allow padding. Sometimes it's good for the team to know the padding, sometimes it isn't. When you have extra time it's not uncommon for your development to magically consume exactly that amount of time and still result in a small scramble towards the end. A good driver I've found is needing to have it fully like to demo a few weeks out from the launch itself, such as during analyst pre-briefings. Crafting your message Every launch is an opportunity to tell your core message and value prop. If you miss this opportunity for focusing on a single narrow feature you've misse