When you are rolling out major changes to product, there’s a ton of people that have to take notice. And, of course, this changes based on whether you are managing a B2B product or a B2C product. I thought I would dive in to both, as I’ve made some mistakes along the way, learned some things, and I’m sure I’ll make them again.
B2B
B2B product rollouts, to me, have always been easier than B2C. The reason for this is simple – they are finite. In my mind, there are less variables. For example, in a B2B rollout / uograde you have (typically) the following things to do:
- Train sales
- Write documentation
- Work with dev to ensure code is deployed
- Ensure critical defects are fixed
- Notify clients
- Work with clients on changes in the release
- Work with MarCom to update collateral
Really, there is a lot of communication. I’ve used a check list in the past that covers all of these components – and it can really help to make sure that you, and your team, don’t miss any crucial points. Otherwise, you are going to have angry sales people yelling at you for not telling them about feature 1, 2, or 3. Or quickly out-of-date marketing collateral.
There really isn’t an option of doing these things – whereas with consumer products, you may or may not have a sales team to train or MarCom pieces to update. However, with enterprise products, you really can’t get away with not doing those things; they are critical to the success of the release.
For this reason, I’d recommend having a release checklist that helps you keep track of all of the activities you have to remember to execute on. Without it, it’s too easy to overlook something and then remember it later, in a moment of panic at 3am.
B2C
When it comes to B2C releases, things are a bit different, but similar. Of course, this depends on the methods used to distribute your product (supply chain, Web, download, etc…). In a Web environment, you are not going to notify all of your users for every single minor / patch release. Only for the exciting things. Whereas in a B2B environment, those customers want to know about the patches and fixes, since they usually pertain to one (if not more) to them.
This will also depend on if you have a sales force out there selling to consumers directly, or if you have a free product. So really, you have to use common sense where it’s applicable to ensure you are hitting the right people with the right level, and type, of communication.
When it comes to the internal side of things, it all pretty well stays the same. Of course, like B2B, the extent to which you communicate and create materials will depend on the size of the team. If there is 1 sales guy, no marketing people, for example chances are you just need to have a 30-60 minute meeting going over things. I had actually copied and pasted the list I used above for B2B and realized something – the activities are the exact same.
The way in which you execute on them will vary depending on the scenario, of course.
It All Comes Down to Communication
Really, this is the key. However you go about it. Certain groups need to know certain things. The level at which they know about them is at our discretion. But remember, it’s your responsibility. If you aren’t telling sales the latest and greatest – and you’re not making sure MarCom is updating things, then it’s your fault when things don’t sell, or things that are selling are out-of-date and wrong.
You have to keep on top of this stuff – especially more so as your team and product grows. When you are small, there is less need for formal procedures. People still need to be shown how to do certain things, but you don’t need a scheduled 1/2 block for official training with a pop quiz at the end of it.
I have the philosophy that you do what you think is best for the scenario – and if you find that after a few releases people aren’t getting what they need, then you can change accordingly. Of course, even 1 or 2 years in to a single product, you will find the execution needs to adapt. Companies change, things change, and you have to roll with the punches.
{ 10 comments… read them below or add one }
Over the years I too have had to use a “checklist” approach in making sure that all the relevant and interested parties that should be included in the communication, are in fact included.
However, I think you also need to consider that before you do ANY communication, not only do you need to consider what you are communicating and to whom, but HOW. It is not as simple as checklist. You need to make sure that you are using the medium and method to which that the market segment/audience will respond.
Failure to remember the HOW with the WHO and WHAT will still result in failure.
Over the years I too have had to use a “checklist” approach in making sure that all the relevant and interested parties that should be included in the communication, are in fact included.
However, I think you also need to consider that before you do ANY communication, not only do you need to consider what you are communicating and to whom, but HOW. It is not as simple as checklist. You need to make sure that you are using the medium and method to which that the market segment/audience will respond.
Failure to remember the HOW with the WHO and WHAT will still result in failure.
Totally agreed, Jennifer – great point.
Totally agreed, Jennifer – great point.
Adam, do you think that the list of people with whom you have to communicate is better defined in B2B or B2C?
Adam, do you think that the list of people with whom you have to communicate is better defined in B2B or B2C?
In my experience, B2B. However, they both tend to evolve over time and are
different depending on the company. Early stage b2b will tend to adopt the
process they need more rapidly due to their client base.
For example, if you are working with a Disney or a GE or other
enterprise-level client, you need to be somewhat more fastidious when it
comes to releases than you would for a consumer-based web app. That's their
expectation. Wheres with consumers, you can sometimes be a little bit more
flex; especially when it comes to free web apps.
The importance of the communication doesn't change, though. Just the nature
by which it evolves over time – and the level of detail / extensiveness
that's required for the audience of the business.
In my experience, B2B. However, they both tend to evolve over time and are
different depending on the company. Early stage b2b will tend to adopt the
process they need more rapidly due to their client base.
For example, if you are working with a Disney or a GE or other
enterprise-level client, you need to be somewhat more fastidious when it
comes to releases than you would for a consumer-based web app. That's their
expectation. Wheres with consumers, you can sometimes be a little bit more
flex; especially when it comes to free web apps.
The importance of the communication doesn't change, though. Just the nature
by which it evolves over time – and the level of detail / extensiveness
that's required for the audience of the business.
Adam, do you think that the list of people with whom you have to communicate is better defined in B2B or B2C?
In my experience, B2B. However, they both tend to evolve over time and are
different depending on the company. Early stage b2b will tend to adopt the
process they need more rapidly due to their client base.
For example, if you are working with a Disney or a GE or other
enterprise-level client, you need to be somewhat more fastidious when it
comes to releases than you would for a consumer-based web app. That's their
expectation. Wheres with consumers, you can sometimes be a little bit more
flex; especially when it comes to free web apps.
The importance of the communication doesn't change, though. Just the nature
by which it evolves over time – and the level of detail / extensiveness
that's required for the audience of the business.