Tag Archives: product
This is the final installment in our blog series “what does it take to launch a product?” If you are interested in the previous posts, we covered Product Definition, Pricing, Sales Enablement and Making Hard Choices. This blog will highlight the communication plan that is required with a product launch. Like many elements of Product Management, it requires more thought and care than might initially be expected.
Here are some tips and tricks regarding communication:
If you have a Marketing department that is separate from Product Management, include them in a discussion about launch communication. We all have our skill sets and you want the best players in the right positions. Many product managers are excellent marketers and writers, but they may not have the depth of expertise and relationships that your Marketing team does. This is an opportunity for close collaboration.
Identify your audiences
You may have several “masters” to serve and they may need to be communicated to very differently. Internally, you have to think about your sales force, executive team, customer service representatives and other company employees. Externally, you have to consider existing customers, prospects, the media, Analyst firms and possibly investors or shareholders. Each audience may need a slightly different message so it is prudent to think through this ahead of time so you aren’t left scrambling right before launch. Also, some audiences can promote your message so you want to get to them early in the process.
Determine appropriate amount of communication
How much is too much or not enough? Communication can be tricky because you don’t want to over-message something that is small, thus diluting your Marketing credibility. Nor do you want to under-message something big and miss a potential opportunity.
We solved this, like many other companies by creating Launch Levels. An “A” launch is a big deal – Press Release, videos, micro-site, sales training, etc. In order to qualify as an “A” launch, it has to be a brand new product or a significant enhancement that will drive revenue. Depending on your innovation cycle, you may only have one or two “A” launches per year.
A “B” launch is less impactful; it might be only available to existing customers, or it might be an inexpensive add-on that won’t drive significant revenue, or it might be a version 1 product that you are testing on a smaller target market before making a big splash. “B” launches will have fewer marketing assets and activities than an “A” launch but still require thoughtful consideration of content, audience and timing.
“C” launches are more like product enhancements. You definitely want to get the word out but it isn’t worthy of an Analyst Briefing or new website.
The way we manage the different launch levels is to have a Launch checklist and whether a task is required, optional or ‘as needed’ varies by the launch level. For example, in our company, a social media campaign plan is required for an “A” launch, ‘as needed’ for a “B” launch and not applicable for a “C” launch.
Have a plan
Even if your organization isn’t mature enough or big enough to have a Marketing department or need the sophistication of launches levels, take the time to craft a communication plan. It is important to let the world – or at least your sales people and prospects – know about this great new offering. If you aren’t purposeful about it, or you slap something together at the last minute, it can devalue the product and no one benefits from that!
Launching a product is a highly orchestrated effort that requires thought, planning and follow-through to be successful, but when it is successful, it is a great feeling to see your “baby” hit the market and start generating sales. There is such a sense of pride and accomplishment that comes from it. I hope every reader gets to experience that feeling. Happy launching!
Originally posted on a now defunct site on 4/16/13
Image source: http://www.powerelectronicsworld.net/article/0/79963-gigoptix-producing-gaas-e-band-pa-chipsets-in-volume.html
This is the fourth in a series called “What does it takes to launch a Product?” and this entry focuses on the hard choices that need to be made between Product Management (Product Owner) and other stakeholders. There is never enough time, resources or money to deliver everything that is desired in a product. But in order to actually launch something – to get the product out the door – difficult choices need to be made. Here are three rules to help with the process:
Don’t build for the 1% (or 10% or maybe 20%)
This is one of the most difficult rules to adopt and live by because it is in our human nature to solve problems. But in order to get the product out of the design phase and into the marketplace, you have to be willing to say “yes, that might happen, but the odds are low so we will handle them manually or not at all.” Here is an example – what if a customer places an order for a product they already have. Will we issue an immediate refund? Will we notify them via e-mail? Will we convert them to another product? Before you build a complex, automated solution consider how often this will happen. If it is an ‘edge case’ or something that will not be a common occurrence, put a manual process in place and move on. Some in your company will probably fight you on this saying that it will be it harder for operations or customer service and that is true. The trade-off should be worth it because new products should equal new revenue and revenue solves most problems. Honestly, if a manual work-around really becomes cumbersome, it can always be automated post-launch. (Lean Product Development calls this the Minimum Viable Product or MVP.)
This is the second in a series on “What does it take to launch a product?” This blog is about pricing which is a critical exercise in the process of launching a product. The observations shared here are focused solely on B-to-B sales (business to business, not business to consumer which has many different nuances.)
Golden Rule #1: Sales cannot set standard pricing
Every once in a while, I will hear from someone that their executive team wants sales to set the pricing because they are most aware of the marketplace and the competitive pressure. And while I agree that Sales should have a tremendous amount of input in the pricing process, they shouldn’t have the final say in setting *standard* pricing. It is a bit like having the fox watch the henhouse. Anyone with a quota has different incentives with regards to pricing than someone who is objectively trying to express the business value of a product. Once Standard pricing is set by Product Management (PM), then Sales will have an active role in deals-based pricing or ICB pricing. But Standard pricing must be owned by an organization without a quota.
Golden Rule #2: PM (or Finance) should define both Published Pricing and the floor
In the b-to-b world, like most other markets, pricing is negotiated. It is often the case that you want to publish your standard pricing which is the price that you would love to get, but you understand that there needs to be some wiggle room for the Sales force to negotiate. Our experience has been that when PM sets the standard and the floor, Sales has clear boundaries that they can move within. Some skeptics will say that Sales will always go straight to the floor and that may be true but it depends on a number of factors – namely their comp plan. If good salespeople will make more money by pricing closer to the standard/published pricing, then they will. Less experienced sales people or folks who are compensated on volume and not margin will likely go straight to floor pricing. But if PM defines it, the company should still be confident that adequate margins are maintained, even at floor pricing.
Today starts a series of blogs on launching a product. If you have heard me speak or been around me for 10 minutes, then you have heard me say that we recently launched 6 products in less than 3 years. I talk about it so much because I am so proud of this organization for accomplishing such an awesome feat. What does it take to launch a product? You have to define it. That sounds pretty basic, huh? Who would have a product that they couldn’t define? But the devil is in the details and there are several ways that products need to be defined. Let’s look at the nuances to better understand why this is harder than it looks.
Define for IT (Engineering)
You have to articulate each feature in detail so IT (Engineering) knows what to build. This could be a prioritized list of 10-15 things or perhaps 100 small features. The point is that Product and IT need to be on the same page as to the critical features, and what are the nice additions to be added, time and resources permitting. But for product management, the product definition doesn’t end there.
Having moved from Austin, TX to Des Moines, IA to San Diego, CA, I have had to learn a few things about hiring product managers. In Austin, Product Management is a well-known profession and many talented people who are either natural product managers or trained ones are available for hire. Des Moines, like many areas in the country, is not a product management town. It is full of wonderful, hard working people but with industries centered around insurance and agriculture, there has not be high demand for product management, as a discipline. This is changing, both with the enthusiasm around Agile as a software development methodology and the increasing number of start-ups in the “Silicon Prairie.” The need for product managers is, therefore, on the rise. If you are tasked with hiring Product Managers, here are three tips to help.
Comfortable withOUT a job description
For nearly every job that I have had, I have lacked a job description. Not only am I comfortable with that, I actually prefer it. And I think most natural Product Managers feel the same. Of course, we all want to know the rough boundaries around our job but we tend to be very comfortable with ambiguity. A product manager’s job may range from strategic product visioning to market research to customer interviews to tactical prioritization to sales training to process documentation and much more. What you intend to get done when you arrive at the office may differ completely from your accomplishments at the end of the day. As one of my colleagues so eloquently stated, “A product manager is the CEO of that product” and just like company CEOs, you have to roll with the punches and respond to the needs that are presented that day.
Many of the complaints that I hear often about Agile implementations concern the product owner. Either the business is not engaged appropriately, or the product owner is indecisive or unavailable, or the quality of the requirements/user stories is poor. Whatever the situation, the product owner is often “at fault.”
Instead of lamenting why we do not have good product owners, I would like to shift our thinking to: How can we build a Product Owner? These are challenging jobs and often the people put in them have little background on what is expected of them. This is the first in a series of three blogs to help us build better product owners, which will lead to better products. First, let’s examine a new product offering. Where would a new product owner start?
For this effort, I recommend a three step process and I have to give credit to David Hussman who provided some of the inspiration for this topic.
1. Create personas
Who is going to use this new product? Who is your buyer? Will you have power users and casual users? Do you need to consider administrative users?
Personas first came into the conversation with Alan Cooper’s book “The Inmates are Running the Asylum” in 1999. Personas are fictitious people who are going to use the system so the Product Owner can think about user interactions and how best to optimize the experience. Let’s map out a few personas.
It may sound odd that you need to consider pricing when sunsetting a product or platform but you do – at least in some form. This is the final installment in a series on decommissioning or sunsetting a product. First you must get data to know exactly what the situation is; second, you must craft your communication plan, and finally, you need to consider the financial implications.
If you are truly turning a service off, or ‘going dark’, you may have to consider whether refunds will be required for your existing customers. If your business model is one of pre-payment, then you need to look into contractual obligations, notice periods and financial true-ups. The potential impact of refunds may even dictate your sunsetting strategy, so you can minimize pay outs.
Let’s consider an example. The company charges annually for the following year. For example, on November 1st, you are charged for November 1st to October 31st of the following year. The company will need to research the month with the highest number of renewals and you might base your decommissioning date based on that information to minimize the refunds. If sunsetting this product is a large and complex effort, you might consider a rolling project where customers are moved off of the product or platform as their services expire contractually. This approach can take up to a year to complete, but that might be ideal in certain circumstances.
As a Product Manager, one of the efforts that we are often asked to consider is the decommissioning or sunsetting of a product or platform. It is not always a fun task, but it is very important to the business. This blog series is dedicated to the steps that a strong Product Manager needs to consider when researching this kind of issue. The first and most important thing to do is to get data.
If ever there was a project that should NOT be executed based on gut feel, this is it. You need data to make sure you make the most prudent decision possible. There is no way to sunset a product without upsetting some aspects of your business, so this is not something that should be taken lightly. What kind of data do you need?
You need solid data from the financial and CRM systems of the company to answer the following questions:
- How many customers are impacted?
- How important are those customers?
- What other services have they purchased?
- What prices are they paying?
- What is their lifetime value?
Product Management roles are challenging and fun and I am a self-professed Product Management geek. One of the critical responsibilities for a product manager is to successfully launch new products that are built in concert with the IT and Operations teams. In my experience, there are several key steps in the launch process that must be considered. Here are five posts that walk through these steps.
What does it take to launch a product?
Making Hard Choices
Developing a Communication Plan
I hope you find this information helpful and interesting. If there is anything that was missed, please let me know. Happy Launching!