I’m not just a marketer, I can code too. Working for ISVs for my whole career has given me the opportunity to see the world both from my development teams point of view, and mine, the guy who has to get people interested in his product. Part of getting people interested however is continually updating features in the product. They way development teams architect their release process is a critical consideration for how well that product does.
Most developers couldn’t care less about go-to-market strategy. In fact, I’ve heard from a few developer buddies their total frustration with their marketing department, “always asking for random things” and “they always slow down my work”. It is true that marketing’s relationship with development is rocky, but more and more as web applications tightly integrate with marketing tools, the two teams have to work together. Besides analytics and drip campaigns, there is another area where what the development team does, directly impacts the ability of ISVs to market. However I’ve never seen marketing teams or dev teams acknowledge it, and that’s the impact of release cycles on go-to-market strategy and marketing campaigns.
While this post is good for both marketers and developers, it’s really targeted at you. The developer who is pounding his/her desk because of a feud with their marketing department. I am fortunate to have the point of view of being both a marketer and, what I would call a “duct tape developer”. I spend brain cycles on understanding how technology products are created, but also how to get them in the hands of users. The point where the development team releases new features, and the marketing team talks about those features, has a big impact on the products market. Yet we do not often think about what this relationship means to our users and marketing strategy.
In the increasingly user demanding world, where they expect new things on a frequent basis. And the advancements in DevOps processes that have allowed ISVs to release new versions of their product much sooner – every three weeks, every two weeks, every week, even every day means that the dev/product teams need to work together on the releases. Development needs to make the marketing team aware of not just what is new, but how it benefits the user, and the marketing department needs to be ready to talk about what’s new in a way their users understand.
This is not easy. Especially if the ISV has not identified a strategy around it. From my experience, some of the things you should consider are:
1.) Which new features are announcement-worthy?
At CloudShare we have several ways to announce features – in the product, and on the blog. These announcements are usually related to a specific feature and its function and benefit. Obviously, every single release we do, we are making big changes to our platform, things which users don’t necessarily see, or may not even experience. So what we talk about is usually customer-facing functionality. Our release cycle is every two weeks, so it’s very easy to know when we will talk about something and what it is. The conversation about what is going to be announced happens the week before a release when we know for sure features are going to show up.
2.) Tie several features to a single value proposition
So sometimes it’s not an individual feature, I actually believe that most of the time you should be talking about the benefits of a solution rather than its individual components. So when a new feature impacts significantly one of the ISVs top value propositions, you should consider a broader announcement. Such as a press release or talking with analysts and press. This is much harder than the first point. Because not only do you need to know a month in advance the feature(s) are coming, you need to be certain they will show up. We all know that in development cycles there are sometimes features that do not end up being released because they do not pass QA. The best solution here is to know in advance the large announcement, and have a regular sync with Product, Marketing, and Development to make sure all dependencies are moving nicely.
3.) What does marketing need to understand?
Not all marketing teams in ISVs are technical. Some would argue, especially when not selling to technical audiences, that they should not be. So there are times when the value proposition is not clear to the marketing team. When your software product is related to high-tech, like at CloudShare selling to developers, how the platform works is very important to our users. But for other products that sell B2C, not so much. However it may not be clear to a marketing team for example that enhancements to a back-end increase performance, or reduces clicks. So development teams must work to get marketing to understand one thing or another makes the users lives better. Usually it’s product management that helps here, and it should be. But the challenge compounds when development teams and marketing teams are in separate offices, often separate countries.
4.) Keeping users engaged is critical
Most importantly for dev teams, despite how annoying marketing might be, they must understand how critical it is to have a drumbeat of activity with users. This should impact the planning of functionality. For example long periods of time without a customer-facing benefit, especially in the mobile and web work, can be very bad. During release cycles things get very busy, so a standard practice to consider having at least x number of customer-facing features released every release or every other release.
As a developer I would not in my wildest dreams think that the regular release process dev teams adopt would directly impact the success or failure of a product in a market. But after a product has been shared with the world, it’s the regular updates and enhancements to the product that keep customers and entice new ones.