Ask an Expert
Looking for help? Click on a topic below for some great advice from our instructor team.
In our consulting and training, we focus on best practices but we also focus on practical ones—things that product managers can realistically do. Best practices would include extensive budget money for market research and travel but since we rarely have this, there are other ways to identify and quantify the market needs.
In terms of business planning in particular, anybody doing a business case should be calling out, “Here’s the market segment that has a clearly understood problem; we understand the buyer and user persona; and furthermore, no one is focusing on the segment so we have a chance to be a dominant player.”
Instead, many vendors say, “Wow, there are a lot of people in ERP right now, so maybe we should build an ERP product because it would be really fun to work on.” The problem is, there are already dominant players in that space. With PeopleSoft, SAP, Oracle, and any number of other vendors already there, can you possibly be one of the dominant vendors? The answer is “no.” So instead, maybe we can focus on a market segment like doctors, or hospitals, or insurance reimbursement for small body shops, and the more focused we get with a market segment the more we can find a group of people that have not had their problems solved by a generic solution.
In terms of best practices in a business case, we want to be able to say, “Here’s a market segment where we can leverage our distinctive competence and dominance is an option.” Typically, we also need to know how to communicate through the business case to our executive team. They are less interested in geek-speak and more interested in financials so show executives where they can get 30% market share in a reasonable time frame and that profit is ultimately going to be the result. Fundamentally, focus on a market segment while leveraging your distinctive competence and dominance is an option.
Who would start a development project without a clear idea of what the market wanted to buy? Oh wait! We do that all the time! But does the product become successful?
Requirements are merely a list of problems or features that are driven by the needs of the market. The negativity around requirements generally originates from two problems: 1) poor product management, and 2) a misguided view of innovation.
In the technology industry, innovation is the name assigned to “creativity” while requirements equates to “dull.” Missing from both typical innovation and from formal requirements is context: What is the problem? Why does it occur? Who is having it? How do they deal with it now?
IDEO, a brilliant design firm, uses a method of innovation that begins with a clear statement of the problem and then field observation of it. Sounds like requirements to me.
Innovation is not about creating cool stuff in the isolation of a development lab. Innovation is not just adding more features. The real challenge of innovative projects is knowing what features to omit. The more we understand the persona and her use of the product, the more we will know what features are mandatory and which can be safely removed.
Railing against requirements is often another way of railing against poor product management. Too often, product managers are trying to document their opinions of a successful product. Students of Pragmatic Marketing® have learned that product managers are messengers for the market. They know that “your opinion, although interesting, is irrelevant.” Product managers should bring market facts to the planning session instead of their opinions. And most of all, they should put those facts into context with problems, using scenarios and personas.
The relationship between product manager and development manager is like a partnership, a marriage. Each brings something to the relationship: The product manager brings market information; the development manager brings technical prowess. One handles the business decisions while the other handles the creative ones. And when conflict occurs—and it will—the answer can be found in market data rather than opinion.
One more point about market facts: We’re not interested in what features customers say they want as much as an articulation of problems they have. Henry Ford reminds us that if he had asked the market what they wanted, they would have asked for a faster horse. Customers will ask for more of the same while continuing to struggle with problems. Product managers need to identify those problems, not ask for the customers’ wish list of features.
Great product managers observe the problems and report them to Development—in the form of requirements.
We have several well established product lines with roughly once per year major release for each product. Product version numbers are primarily internal tracking numbers used by technical support, development, and QA. I’ve spent many hours on technical support calls and surely one of the first questions one asks is “what version are you running?” Perhaps the easiest call to take is one where the problem occurring in version 1.1 is solved in version 1.2. The support rep just says, “Yes, that bug was corrected in version 1.2. Please upgrade.”
Product version numbers typically consist of three fields: the major version, the minor version, and the update version.
X: major release with identifiable new features Y: minor release with existing feature improvements Z: update release (distributed) containing bug fixes but no new functionality.
There is often a fourth number associated to the code build. Not all builds are distributed but this number generally represents a count of builds from the beginning of the development project.
So 188.8.131.5221 means
9: Major release of functionality 0: no minor releases yet 1: bug fix released to public 3821: development build
These program version numbers need not necessarily correspond to the numbers used in our marketing, as we see with Microsoft products. Word 2000 (communicated to the public) is really Word 184.108.40.20621 (internal to the product team). Product marketing owns the name that's distributed; Development owns versioning and the project code name.
Numbering schemes are largely irrelevant to customers; versioning is only for keeping track of what is shipping to the customer. There are many software developers who think that numbering schemes are a not-important marketing aspect of the product. Marketing people and customers generally do not (or should not) care about version numbers.
What Should You Tell the Public?
In most cases, a change in the Major version justifies a product launch with a press release or some communication in the market. Some companies use the major number to require companies to pay for the upgrade rather than getting it free as part of the maintenance or subscription.
Minor upgrades are proactively communicated only to the customer base but not to the general public. They don't justify a formal launch beyond getting the company ready to support it.
Updates are communicated on the website and from tech support. Power users will encounter the update information on the product support area of the website and download it. The majority of customers need not know about it unless they encounter a problem fixed by the update.
Builds are never communicated outside the product team (development, QA, product management, and usually tech support).
Project Code Names
Project code names are often assigned to a new project; these are also internal to the product team. Frankly, we recommend that project code names be silly or somewhat offensive. Use foods, diseases, or cartoon characters as the basis for code names. I doubt people will talk publicly about the “Deputy Dawg” release or “Taco” or “Ear Wax.” Otherwise, some names seem so clever that we start using them outside the team, and pretty soon the channel knows and then the customers knows. Before long we start getting calls about the status of the “Nile” release. And when we decide the actual product name, everyone has already gotten used to calling it “Picasso” and it’s much harder to get the real name accepted.
Using Versioning with Goals
In Requirements That Work,™ we teach a technique for using goals to define sets of functionality for release. Goals help us achieve a ship date with a product release that offers a complete using experience. Versioning can help here as well, with one modification. Since we group the product requirements by user goals, we can use the version number to define target sets of functionality. We’ll use the “bug fix” for release candidate.
Let’s say we’re doing a new major upgrade, planned to be v2.0. The new release has a new data model and other architectural design changes. When these changes are complete, we can extend our 3-D modeling capabilities in four functionality areas. If we can complete it by the end of the year, we’d also like to offer a new set of statistical functions specifically designed for business planning that allow the customer to calculate time value of money as well as NPV (net present value) and EVA (economic value add). Using goals with versioning we can plan:
V2.0.0 = architectural changes V2.0.1 = 3D modeling V2.0.2 = business planning suite
After completing version v2.0.0 we can begin the functionality for v2.0.1. After that goal is complete we can begin v.2.0.2. What if we realize we need to ship before v2.0.2 is ready? Just release v2.0.1—the last set of completed customer functionality—as 2.0 and then continue developing v2.0.2. When completed, we can release this functionality as an update, as Microsoft often does with service packs, or as release 2.1. In this case, the “bug fix” node is serving double duty: as release candidate on prerelease product, and then as bug fix for released products.
Version control is a required element of mature product planning, largely an internal method of tracking. Version numbers catalog which features and fixes are available in different distributed versions of the product. Versioning can also be used to accommodate goal-oriented product planning, as taught in Requirements That Work. Project names are merely shorthand for specific development projects and should always be kept internal to the company. The nomenclature doesn’t really matter as much as an understanding of what version numbers and project names mean to your product team and its customers.
I have seen four themes for naming releases:
name (or model number without any version numbers) (salesforce, Linksys WRT54GL) name + year (Office 2007, iLife 08) name + version number (iTunes 7.3) name + release theme (remember OS/2 Warp?)
Hosted services tend to have no visible version number although there is always a version number somewhere for tech support purposes. Obviously, Microsoft has gone with the year method and there’s something great about that: You know that you’re really out of date if you’re running Office 2000. The negative is if the vendor hasn’t delivered anything since 2000.
In the end, I think the naming standard depends on what you’re trying to accomplish. A major release usually means that you charge the customer for it. I actually am annoyed when I’m charged for a minor release. I just upgraded from a product’s 7.1 to 7.3 and had to pay $75. I’d be more willing to pay to go from 7.x to 8.x-—which is the most common situation. But at version 12 and 13, this starts to get a little ridiculous. Version numbers become less relevant as the product reaches maturity. I suspect that your customers do not care except as the name or version relates to billing.
With all the mergers and acquisitions that occur, this is a relatively common problem.
I don’t know of any article or research that states one approach being better than another.
“It depends”… In fact, you can probably find examples to support either approach as having been successful in a given company. Statistically, I don’t know of a study that asks companies to evaluate the success of one approach over another in a way that evenly weighs all factors. Eventually, if you’ve been in business long enough, you always face the issue of upgrading technology/architecture/platform to acquire new customers even if your old customers are content to stay put.
Rather than focus on the external secondary research supporting one or the other, continue the discussions. Have each camp make the real business case for one over the other. It may end up being a combo effort (invest some resources in the platform for the future while looking at possibly retiring or at least reducing investments on products that are highly redundant or that don’t deliver real value to the company and the market). Encourage each camp to look for a third alternative, not just to focus on their bias. What are your growth objectives (growing by new customer acquisition, selling more products and services to the existing customer base, looking for new markets to serve)?
Look at the 4P’s we talk about in our Practical Product Management course:
Is there a market problem you’re solving by building a new platform? (How many customers have multiple systems that look and feel different? If they do, what pain is it for them or is it OK?)
Can you create a competitive advantage by solving problems in a unique, sustainable way by having a new architecture?
In quantifying the problems to solve, is there really a cost-savings to re-do the platform (once you’re done, assuming you pick the right platform, right architecture, right set of tools)? Can you then bring new products to market quicker?
- Which products solve the most compelling of the problems? If you don’t have enough resources to support and enhance all products, which ones should you retire? What’s the business case for doing that and what impact will it have on customer loyalty and customer retention?
Do you have the skills to build a new platform? How can you avoid it becoming a science project? (Clue: it also needs product management)
Are there some technologies within existing products you can leverage into becoming architectural elements or is it better to start with a clean sheet of paper? (Re-use is less sexy; “inventing” new stuff is more fun. Are you over-engineering the architecture over the value it will deliver to you and to your customers?)
Can you time-phase delivery of the architectural components while adding functionality (or new products) that will allow you to sell into new accounts? How should you split your development resources so you don’t completely go dark in new products or new functionality while the underlying platform and architectural development takes place?
If the sales team is having difficulty selling, is it because there isn’t clarity about which products solve which problems for which segments? In the short term, can you start by positioning each offering as it is today and then figure out how you want to position each one to target different parts of the market tomorrow?
Until all of this is sorted out from a development perspective, how can you help Sales beyond positioning the products better? Where are they confused or where are they struggling in the sales process? Provide good positioning to map problems to products with interview questions to help them figure out which product is best suited to solve the problem.
Do you use the same sales channel for all products? Maybe the sales channels need to be segmented according to product lines and market segments until (or if) you get to “one platform.”
In summary, bring facts to the table, not just opinions. Insist on the same for proponents of each side of the argument. Your dilemma is not an easy one to solve, but make sure you all provide thoughtful considerations of what the impacts will be not only to your company, but to the market.
Win/loss provides insights into the buyers, process and criteria used to make a decision. As such, it can often improve velocity by allowing you to better support the buying process through the following:
Where gaps in tools and content exist, it often introduces delays in follow up. Custom tools must be created. Even if the team isn’t creating one-off pieces, the reactive nature slows the process down. Win/loss helps you identify and prioritize sales tools so you can proactively arm your customers and salespeople.
Win/loss identifies points in the buying process where internal processes and sales steps are inconsistent with buyer expectations. For example, perhaps the conflict is seen as arduous or the time to receive a quote seems too long. Some of these items may not be the domain of marketing, but having market knowledge empowers other teams to prioritize initiatives that can improve sales timelines.
Win/loss not only helps move deals faster, it also provides guidance on when a deal may not be the right one. Knowing early whether to run from a bad deal increases channel productivity, because it allows individual reps to stay focused on deals they can win.
Lead scoring is a collaborative, iterative sales exercise that identifies the actions taken by individual evaluators and defines a score or value for each action completed. Once evaluators reach a certain score, they are classified as a qualified lead, meaning they have the correct characteristics for sales engagement.
Win/loss calls are invaluable for defining the steps evaluators take and the value of each. Plus, once a lead scoring program is deployed and a baseline established, additional win/loss efforts can help fine-tune the definition of “qualified,” making it increasingly accurate.
Using win/loss to better understand the buying process, identify gaps and focus your salespeople can improve speed to close, another reason it is one of the most powerful tools for any marketing department.
I encounter those organizations all the time: revenue or technology driven organizations who don’t value product management. These are often the very organizations we see in the news—in bankruptcy. Most companies only really understand product management when the company starts to fail. But getting senior management support for product management is often a huge challenge—with only one answer: Use market facts to make all product decisions. Alas, it’s easier said than done.
There is a huge pretension on the part of engineers (and often the founder of your company, who was an engineer), who say, “I am brilliant. I have come up with a technology product and everybody will want it. All we need to do now is find customers.”
These companies quickly reach some level of success and they can’t push past it. They’ve been at $10 million for a decade, and they’ve had a bunch of new products and none of them have done well, and finally they think that maybe product management is the answer. It’s just too hard to build and maintain a company on technology alone. Product management gets involved in saving the company when the other avenues have failed.
There are organizations where you watch their stock fall and if you interview any of their employees, they say “Wow, we thought the sales people were the customer and now our stock has tumbled to $2 and we don’t know how it happened.” But the failure was easy to predict: sales people are not the customer and the more we listen to them the more likely it is we will bankrupt the company. Salespeople are focused on the three deals they’re working—which is exactly what we want from them. But we don’t want to rely on these short-term focused employees for long-term product strategy. In fairness to sales people, their VP has encouraged this behavior. The VP of sales doesn’t believe in all that tedious planning and ivory tower thinking that product management is doing; a “deal a day” is his success formula. It’s just the way sales people are wired and that’s why growth companies look elsewhere for strategy. Revenue driven companies focus on the quarter to the detriment of next year.
The solution is for product management to be representatives of markets and not deals. Find a problem in a market segment and ensure that the segment is big enough to generate a profit. Deliver this information to the senior executive team in a business case that combines personal customer experience with quantified market research. Sell the value of the long-term view.
Once a path is determined, keep up the communication. Don’t cover over the problems and hope you won’t miss the dates because you surely will. When the company accepts a deal that pulls developers from your project, make sure the senior executive team understands that they have delayed the delivery of your project. When a developer adds a “neat” feature while refusing to work one that we’ve agreed to, tell management. In effect, tell them that the company is deviating from their plan and make sure they’re happy about it. But they should be furious when either sales people or developers derail agreed-upon plans.
Assuming that we want market information—and I’m convinced that most companies do—we have to explore the options for market research.Traditional B2C companies do market research all the time but B2B technology companies don’t. The chief reason B2B avoids research is that it’s perceived to be both time-consuming and expensive, but it doesn’t have to be.
My friend Bob Martin uses the concept of listening posts to reveal the many research tools between gut instinct (low cost and fast) and comprehensive market research studies (high cost and slow). Many of these “listening posts” are already available; we just have to analyze the information they’re telling us.
In the short run, the listening posts you can tap are right inside your company: Sales, SE’s, executives, technical and customer support—anyone having customer contact. An extremely valuable listening post is on-going feedback from visionary customers; those who are perceived thought leaders. Imagine an inner-circle of customers and prospects that you can reach when you need some quick feedback on an idea. If you haven’t established these relationships, start building them now. The collective intelligence of all these touch-points must be collected, analyzed and acted upon.
And the answers we get are powerful and direct: instant product feedback, competitor feedback, business issues our customers need to have addressed—literally a cornucopia of intelligence which gives you a competitive advantage. More than anything, listening posts are relatively inexpensive means to quickly gather information —which will help you make better business decisions.
A great way to better understand the buying and using criteria around your current solutions is to talk with new customers. You can ask them questions like:
- What first led you to buy our product?
- What other products were considered in your evaluation?
- What problems does our product solve for you?
- What do you like most about our product?
- What do you like least about our product?
- How can we improve our product?
But you can also broaden your focus to try and find new opportunities—whether it’s new products, incremental offerings or solution bundles—with questions like:
- How did your organization prioritize solving this problem over other problems in your business? The responses will help you better understand buying drivers, the budget process, total elapsed timelines and buyer personas.
- What do you think about our company? The answers will help you identify the positive perceptions that exist—which you may want to amplify—and unearth less positive sentiments, which you may need to address.
- What are some of the best products you’ve seen lately? These answers will help you identify emerging competitors, potential acquisition options and potential partners.
- As you think about the company as a whole—not just our current offering—what additional problems can we solve for you? This question helps move the discussion beyond the constraints of current implementations or services to identify potential products you could develop or extend in your current portfolio.
In my experience, once you start getting feedback, more questions easily pop up. Here’s hoping these questions will encourage other ideas and new areas to explore.
According to our survey, it does.
In the 2011 Annual Product Management Salary Survey, we compared product management experience against college versus advanced degrees. In each experience group, the higher degree results in a higher salary.
I remember my father complaining about people with MBAs years ago. He felt that they treated people and projects like numbers on a spreadsheet. And I think we've all seen examples that prove the fiction of 'a good manager can manage anything.' However, MBA programs teach how to run the business aspects of a product, something technical people tend to avoid.
Product managers garner credibility from a deep understanding of the product combined with broad customer experience. Nonetheless, adding a masters degree to your resume seems to result in adding to your family's bottom line.
You should always start with market problems. You wouldn't get in a car and start driving without knowing where you're trying to get to. And it's the same thing for anyone starting a new product role.
It's very easy, no matter what your title is, to get caught up in executing activities and tasks and not thinking strategically. There's always somebody standing in your doorway, saying: When can you get this roadmap done? Can you help with this sales call? Or can you go to this event? The people who get into product jobs are can-do people. They never say no, they just go and respond.
But when it really comes down to it, no matter what task you want to pursue, you have to start with Market Problems. First and foremost, you must understand what problem you're trying to solve, and then use that context for all other activities. If you do that, you're golden.
To get to those market problems, one of our favorite sayings around Pragmatic Marketing is: "Your opinion, although interesting, is irrelevant." It means that you have to leave the building and listen to the market, rather than just dreaming stuff up. You discover those problems in the market by interviewing your customers and potential customers. Then, you dig deeper to find out how common those problems are in the market.
All of the activities we include in our Pragmatic Marketing Framework, from strategy through execution, are important. But in our courses, we drive people to think about what problems they are trying to solve first. Then the rest of it is more powerful, and the pieces will tie together more cleanly. And your execution will be smoother, because you stopped and thought about it before getting on the road.
Product management is often hard to break into. Potential employers want to hire someone who already knows their products and their markets, and they don’t want to re-deploy an existing employee. The result, no one fits their impossible requirements. My best hire was a sales engineer (SE) who had some domain knowledge and the ability to learn our products and markets. He was stuck in his career; he couldn’t get promoted internally because he was the company’s best SE. This would be my advice to a hiring manager: to look for product managers within the company’s SE ranks.
Most product managers come to the job via a technical job from within the company, usually sales engineering, professional services, development, sometimes tech support or documentation. Leveraging your technical skills, you could possibly get into the right company via the SE ranks or via professional services—or you might also be able to get into a company through user interface design or QA and then move into product management.
Don’t kid yourself: product management in a technology company is a technical job. We have to be able to understand the choices that Development gives us and know when their designs are under- or over-engineered. Of course, we also have to understand the domain and the company’s target markets.
As for the next ladder, the “straight path” for product managers is to move into a product line management or director position over Product Management, then to VP of marketing with Product Management and Marketing Communications. The ultimate destination is COO. Product management gives one incredible experience across all organizations in the company. In fact, one statistic reported that almost half of the CEO/COOs in technology are former product managers.
There are some alternate career paths that we see. A move into:
- Sales, selling the products that we know so well
- Product marketing, taking existing products to market
- Development management, often in the role of product architect, designing user interaction and leading development teams.
- Project management, defining standard procedures and templates for use on all products—creating a “playbook” for product managers so that new people don’t have to create their own set of tools. Pragmatic Marketing® offers a base set of templates in our classes to assist in this effort.
The Pragmatic Marketing Framework identifies the activities that we see product managers doing. Using this framework for self-assessment, identify which activities you think you can do well and that you would enjoy doing. How well does your skill set fit the activities in the framework?
Chuck Yeager, the famous test pilot, admitted that he didn’t really have a career plan; instead, he just took on jobs that he thought would be interesting and fun. Likewise in technology—as you move though the organization, see what types of work you really enjoy (and which ones you don’t). And when you’ve found a job you love, keep doing it. If you love what you’re doing, you’ll never work a day in your life.
The measurement of product management results can be seen in both “leading” and “lagging” indicators. Lagging indicators are the more classic business metrics, such as revenue growth, increased customer satisfaction, or even product level profitability. But those metrics involve many more people than the product manager, and take time before they are evident.
So as a VP, I prefer to look at leading indicators of product management success. Metrics such as number/frequency of face-to-face visits with the market, followed by the creation of buyer and user personas, drafts of problem statements, and eventually statistically valid market evidence that describes those problem statements by their pervasiveness and urgency. All that input (personas with problems that have market evidence) goes into the creation of artifacts. Business cases, positioning documents, requirements documents —you get the idea.
So, how do I know when a product manager is doing well? First and foremost, I can see that they are outside the building interacting with real members of the market. What they learn gets cranked into documents which in turn empower other groups within the company, like development, sales and marketing communications. And that is how we get to greater revenue, higher customer satisfaction and product level profit.
Best of luck in your job search.
- Jim Foxworthy, president of Pragmatic Marketing
Cross Functional Teams (CFTs) can be an effective tool to expedite a launch. But if not managed correctly, they can be your worst nightmare. CFTs have two purposes. The first is to combine the widest possible range of expertise so that, hopefully, every detail is surfaced, documented and addressed. The second is to improve time to market. These may seem at odds, but CFTs accomplish both when effectively organized and managed. Here are some tips for building and managing strong CFTs
An effective CFT has one representative from each functional area who has the ability to make commitments on behalf of that area. If the representative can’t make commitments, it’s a waste of everyone’s time. Team members who sense their time is being wasted will stop coming to meetings. Picking the right representative for each functional area is key. Do your homework and identify the best available resources.
Avoid ambiguity by clearly defining CFT goals and expectations so the team knows what is expected of them. Even if you have experienced members from previous CFT teams, it’s still critical to set expectations, including consequences if expectations aren’t met. Also, make sure management understands the importance of the CFT to your organization and that their support of the team is fundamental to its success.
Keep CFT meetings brief. One hour is usually enough. Distribute an agenda several days before each meeting so that team members have sufficient time to prepare. It’s also a good idea to increase meeting frequency as the launch nears. For example, in the planning phase you may want to meet every two weeks. In the readiness phase you may want to shift to weekly meetings, and then to daily meetings as the launch phase approaches.
It’s not necessary to invite every member to every meeting, but be sure to indicate who is required to attend and who is optional. Include someone to track time and document action items, issues and decisions. This frees the leader to focus on driving the meeting. When an action item is raised, document it, assign it and set a date for completion. When an issue is identified, document it and assign it. Likewise, when a decision is made, document it.
It’s your responsibility to communicate progress—good and bad. How you communicate may depend on the audience. A summary email may be all you need for communicating with the management team. But it may be helpful to call team members who aren’t under your direct supervision to remind them that CFT commitments are a top priority.
By selecting the best available people for your team, setting clearly defined expectations and getting management buy-in, you’ll be well on your way to creating an effective team that will expedite your launch.
Everybody wants to deliver good products. That statement sounds simple, but it's important to remember when choosing a launch date. It isn't just about getting your company's product out the door—and then having plans to "fix it" later. It's about setting realistic expectations for delivering those good products.
In teaching our Product Launch Essentials course, I am frequently asked how best to establish launch dates. And while I have seen many successful product launches throughout my career, I've also seen many product-launch train wrecks. Here are a few considerations:
Launch at the beginning of the quarter.
This can perhaps be one of the biggest keys to success if your company reports quarterly. The team could run into a technical glitch, lose a skilled team member, decide to include additional features that weren't budgeted for or experience any number of other delays. If you had scheduled your launch date for the end of the quarter, a development delay would push it into the next quarter. While that may not seem like a big deal on the surface, the number of early adopters anticipated and the sales momentum could be significantly impaired.
While I’m not a proponent of allowing the sales team (or channel partners) to sell what isn’t shipping, preselling can be effective in building sales momentum for products with complex, long sales cycles. Having to move launches to the next quarter means sales has lost time and credibility with early adopters and has got quota to make up for. (I can assure you if the launch slips, the sales team’s quota isn't reduced.) Delays can have a devastating effect on the sales channel. And it can mean a huge loss of your own credibility with sales.
If you announce that you are launching in a particular quarter and set your launch for the beginning of that quarter, you still have time to recover lost momentum and regain mind share with both sales and early adopters.
Consider sales cycles.
What if you overcome technical hurdles, and the product becomes available in the end of the second quarter—but there's a 9-to-12-month sales cycle? Sales will likely say: "If a sale falls in my lap, I will pay attention to it. But if you expect me to spend the next 6 months to get revenue for something that takes 12 months to sell, that's not a good decision for me personally, because I've got a quota to hit."
That might not be as big a concern for a 3-month cycle, but you should still think about how sales cycles can be affected as you plan your launch dates. The longer the sales cycle, the earlier in the year you might want to schedule your launch.
Do your research. You shouldn't launch a product in July or August in Europe, with many Europeans on holiday. Be aware of any dark periods, major holidays or any other such global nuances if you're seeking to launch outside of the country.
Prepare for vendor delays.
So you've got your launch date, but sometimes delays just can't be helped. But I've still had situations where we've encountered problems with an off-the-shelf piece of technology. It's outside of my control, and I can yell and scream, jump up and down and hold my breath, but the vendor is going to move at the pace that they're going to move to solve that problem. You should coordinate with your major vendors around any of their major launches or development cycles that could keep them from assisting with your launch as needed.
Manage executive expectations.
As you're applying pressure on your vendor, your CEO is applying pressure on you, because there could be expectations from the board of directors, major investors or other entities that aren't visible to you.
On one hand, the CEO is not happy about the delay. On the other, he or she knows that you can't deliver a less-than-satisfactory product to the market, because that would be worse. As I said before, "Everybody wants to deliver good products." A bad product could damage the reputation of the company of the CEO and all those involved. Until you have a higher degree of confidence that things are getting back on track, don't over commit.
Let's face it: We're running businesses here, not laboratories. We're trying to get those "good products" out into the market so that we can make money and grow and satisfy stakeholders—which will give us the opportunity to build more stuff and make more money and grow more. But we have to get that launch right for any of that to happen.
- Dave Daniels, Pragmatic Marketing Instructor
We are dedicated to helping our alumni succeed in
their companies and their careers.
If you have a product management or marketing question for our instructors, simply fill out this form.