Webcast: Five Product Roadmap Traps (And How to Avoid Them)

2,257 views
2,167 views

Published on

Thanks everyone who participated in this webcast from The Association of International Product Marketing and Management (AIPMM).

This presentation discusses five all-too-common pitfalls that derail product roadmap presentations, diluting their message and leaving audiences bored and baffled. Understanding the role and purpose of the product roadmap document will empower you to leverage this valuable tool in promoting your agenda and fostering enthusiasm and gratitude from your colleagues and customers alike. Don’t miss another opportunity to make your product roadmap content, layout and messaging work for you.

Join John Curtis as he shares insights on one of the product manager’s most common – and most commonly misused – deliverables: the product roadmap. We’ll offer some concrete answers to help you get your product roadmap back “on track”.

Who Should Attend
Product Managers, Product Marketing Managers, Project Managers, Program Managers and anyone responsible for creating product roadmaps

About the Speaker
John Curtis is an AIPMM Certified Product Manager, Certified Agile Product Manager and Certified Product Marketing Manager. After receiving graduate degrees from both New England Conservatory of Music and The Boston Conservatory, John left classical music performance more than 20 years ago to pursue communications technology. Since that time, John has served as product manager in several data comm and telecom companies, from small high-tech startups to large multinational organizations. He is the coauthor of five telecom patents and several inventions, has extensive experience in network and application performance testing, and is also known among his colleagues as "the gadget guy" for his extensive and varied assortment of mobile communications devices, technologies and platforms.

About AIPMM
The AIPMM is the hub of all things product management. It is where product professionals go for answers. With members in over 65 countries, it is the worldwide certifying body of product team professionals.

It is the world's largest professional organization of product managers, brand managers, product marketing managers and other product team professionals who are responsible for guiding their organizations, or clients, through a constantly changing business landscape.

AIPMM's certification programs are internationally recognized because they allow product professionals to demonstrate their expertise and provide corporate members an assurance that their product management and marketing teams are operating at a high competency level.

Visit www.aipmm.com.

Upcoming Webinars: http://aipmm.com/aipmm_webinars/
Subscribe: http://www.aipmm.com/subscribe
LinkedIn: http://www.linkedin.com/company/aipmm
Membership: http://www.aipmm.com/join.php
Certification: http://aipmm.com/html/certification
Articles: http://www.aipmm.com/html/newsletter/article.php

Published in: Business, Education, Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,257
On SlideShare
0
From Embeds
0
Number of Embeds
187
Actions
Shares
0
Downloads
0
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide
  • The Certified Innovation Leader body of knowledge and credential is aligned with The Association of International Product Marketing and Management. AIPMM was founded in 1998. It provides professional development, training, and certification to those involved in product management, such as product managers and developers, marketing managers, brand managers, project managers, and many more. The certified innovation leader credential is one of four certifications provided by AIPMM. The others include: certified product manager, certified product marketing manager, and agile certified product manager.
  • So we’re going to talk about five “traps” today and it’s fair to say that most of them are the product of either misconceptions about what the product roadmap should be or miscommunication between stakeholders. This first “trap” is the product of a legacy, outdated perception of product management is. It’s also often born out of misguided executive control over someone else’s job (i.e., the product manager’s job).So we’re all too familiar with the “traditional” perception that a product manager “manages” (whatever that means) the product and prioritizes which features will be delivered in which releases and when. OK, before we go one, just one disclaimer. (See, I’m a product manager. I’m putting disclaimers in already.) If your superior tells you to do this, by all means do it. Your job is important. However, CONSIDER, if the opportunity allows, engaging with him or her to discuss whether this is the best use of time, resources, people, etc.Let’s investigate further in a bit more detail what we’re often asked to do and what value it has.
  • Most of the roadmaps that I’ve seen – and, I’m embarrassed to say, most of those I’ve authored – show the “yesterday-today-tomorrow” perspective. Here is what we just sold you YESTERDAY. Here is what we’re selling to you TODAY that makes what you bought YESTERDAY completely obsolete. Here is what we GOING to release TOMORROW that will make whatever you buy TODAY obsolete.”PASTWe often show dates on the roadmap for past releases. Why?- Show a cadence  Does the roadmap convey and support this intent?- Encourage users to upgrade to new versions  Is this the right venue for that?- Convey responsiveness to internal stakeholders  All but one will be unhappy!- Congratulate Engineering – Careful about audience’s global participation in efforts.In short, past events don’t offer much. It’s OK to include them, but understand their limited value.FUTUREWe like to show all the cool things in the future, covered by a disclaimer that we can change any and all without notice at any time. So…Question: What is the value of committing WHAT without committing to WHEN?So the audience might take some action based upon the information.Customer might not buy, or might not churn.Engineering might feel encouraged or disheartened.
  • I’m not saying that you should never have a date on a road map. However, think back for a moment to a roadmap that you observed in the past. That is, you were in the audience watching someone else present the road map. Ask yourself this question: Looking back on the experience, do you feel that the person who created or delivered the road map really understood your challenges, your job, what you needed to know, what was most important to you?Remember that. Now think about a product road map that you are currently using or are creating. If you have to compress everything on that entire road map into one or AT MOST two sentences, could you do it? You should be able to do so. Just as you need to convey your product as an “elevator pitch” – at most 30 seconds to describe the pain, the vision and the solution – you should be able to do that for the road map.The product elevator pitch doesn’t list all of the features by release. It discusses the realization of a business goal. That is what the road map should be. Think about the next release. What are the one to three global business challenges that it addresses. Let’s call them “Themes”. For instance: “New features that bring you closer to the people, places, and things you care about. Simple refinements to make your phone a delight to use every day. And safeguards to help keep your data secure and your mind at ease.” (1) Closer. (2) Fun to use. (3) Security.Approach the road map by either discovering or, better, defining, the two or three general trends for the product. You should be able to summarize them in 2-3 sentences. Then, what you show and how you show it and how you position it should fit into those themes. If not, either (a) your themes are wrong or (b) you shouldn’t be bothering with that feature.
  • If the customer has a specific need, s/he should ask about that one thing.Underlying the traditional roadmap feature list is the idea that there is “A” roadmap that is the optimum vehicle for communicating information to your audiences. That’s like saying that a flight from Boston to Dallas is the optimum travel arrangement for all passengers. So let’s begin with a quick summary of what is commonly known as the Abilene Paradox. If you’re familiar with it, please bear with me for one minute because it’s important that we are all familiar with this.[ABILENE STORY]So, who asked for the roadmap? Why? Did the person who asked for it KNOW what his/her intended audience needs? Or did he/she think that “we ought to present our roadmap” and, then, “can you, product manager, do that?” It’s like saying that we should have a meeting, then trying to create a presentation for the meeting; it’s BACKWARDS.
  • Eliminate wrong reasons. They may not be real, but if you don’t know, then you don’t know enough about the real need behind the request.Column fodder: Perhaps our features and schedule are providing a point of comparison for a customer to justify another product from another vendor. If so, we’re wasting our time and helping a competitor.Worse still, perhaps the customer is engaging with us to provide price pressure on a competitor. Of course, this presumes that we also have a broken sales machine, and that’s another issue entirely but the roadmap request could be an early indicator that something is happening that isn’t completely in our favor. In any case, this is the worst possible situation because, while it might seem that we want to deprive a competitor of revenue, what we’re really doing is driving the market value of our product set down and still losing a customer to a competitor.I’ve been in such roadmap meetings where we discovered later that the customer wanted to understand our product futures so that the customer could build a competitive product without the cost and delay of researching what the market needed.Finally, perhaps a bit less harmful but still annoying is using the roadmap as a reason for the customer to meet the vendor. Sometimes asking things of the vendor is a way of individuals within the customer’s organization of showing procurement and planning activity.NONE of these warrants your time. You are TOO VALUABLE to waste time for any of these.What about internal roadmap requests? Ask why? (It’s a friendly customer, in a way.) What is the expected outcome. Often, especially at Sales meetings, there is the general belief that “we’ve always had a roadmap update from product management.” Everyone thinks that someone else wants it – but NOBODY does. So ASK!
  • If you don’t have a C2A, then you should NOT be giving the presentation.Here are some GOOD reasons for a roadmap review, but it will be up to YOU to suggest these reasons, to make them a reality, to ensure that they are clear up front. For instance, in the case of the PoC, explain to the customer, “We’ll do this roadmap presentation with the expectation that you’ll have someone at the meeting who can schedule a PoC. Is that fair? Who will that person be?”Tell the SEs that you EXPECT feedback; you value their insights; you want to be sure that you have their views. And that you’ll take their silence as a sign of full approval.In the case of R&D and QA, it should be the group-wide agreement of what you have all agreed in private.So let’s follow this line of thinking about the possible different goals that we might have for different audiences.Poll Question #2We’ll be investigating this in some detail momentarily. However, one of the traps that we often find in product management is that often this dichotomy is the ONLY distinction that the company makes. That is, if there IS a distinction among the road map audiences and stakeholders, that distinction is never developed more granularly than simply categorizing the audience as internal or external. For instance, in such cases, the external road map is simply the internal one with some confidential items removed. That’s like saying that you build a car by first building a jet and then removing the wings; what you get makes a terrible car and it can’t fly. And instead of cup holders on the dashboard, you get a tray table that returns to the upright and locked position whenever you depress the brake.
  • In my many years of presenting products and roadmaps to a variety of audiences, I really can’t remember the last time that I saw someone create different versions of a road map for different audiences. OK, it’s true that sometime we remove confidential items from internal presentations when we present outside our company, but usually that’s the extent of it. In fact, the request that *I* usually get is for the “latest” roadmap or the “most recent” roadmap or the “current” roadmap. However, I’m almost NEVER asked for the “business partner roadmap” or the “integrated systems vendor” road map or the “service provider” roadmap or the “Engineering” road map or the “Sales” road map.So the first thing we need to ask is, “Who is the target audience?” If you are a sales person, then the audience is nearly ALWAYS the customer and, in some very small, niche markets, all customers might fit exactly the same profile. HOWEVER, my experience has been that you have to present to more than one type of customer – e.g., network equipment manufacturers, integrated system vendors, end users, consultants, project managers, et. al. MOREOVER, as a product manager, you’ll be presenting to INTERNAL customers, too – and, like your external customers, they have very different interests.
  • Since we have a specific call-to-action, then our roadmap should be uniquely designed to empower the audience to take that action. It should clarify what we expect from the audience and it should provide what our audience needs to take that action.For instance, if we’re talking about pre-sales – e.g., account manager, sales director, sales engineer, pre-sales support – then the road map is a vehicle to ENCOURAGE sales of what you have now and NOT a vehicle to DELAY purchase waiting for what you are GOING to have tomorrow. Example: I intend to buy a VZW Nokia Lumia 822. I find out VZW will offer 928 later in April or May. I defer my purchase. I find out AT&T has 920 now. Guess what?For the Engineering groups – R&D, QA, product documentation, system integration, system test – the road map is really a tool for acknowledging and praising them. Here’s why:- They know what they just worked on. Your job is to tell them who benefited and why it was important.- They know what they’re working on now. Your job is to tell them who WILL benefit and why.- The engineer doesn’t really care what another engineer is doing. He or she DOES care about the value of what he or she is doing.Finally, please forgive me for reiterating, but a customer should only be audience to a roadmap discussion if there is a VERY CLEAR understanding of the call-to-action.
  • It’s easy to say: Do more work. However, the real message here is: Deliver non-zero value. You don’t need to do it all at once. There doesn’t need to be an official “library” of roadmaps, all of which get updated simultaneously with each change. In fact, the expectation of such a massive project is the reason that many companies have reverted to a “single master” roadmap.So, here’s a secret: It’s *OK* to have a master table or slide or diagram or outline or database or something that documents and tracks all of the feature and releases. For instance, in an agile scrum organization, it’s often ideal to use the agile planning software to capture and track requirements in this way. However, this is not a road map.Remember when we discussed earlier the need for defining between 1 and 3 general themes? If you have a mastery of these themes, then simply pull out the themes for the audience and populate the document with supporting data, eliminating distracting or unhelpful data. Example:Customer was a NEM, very sensitive to speed of issue resolution. We even had specific SLOs for workaround v. correction. In response to this customer’s requests, we implemented better internal diagnostics. NORMALLY, that would not have been a customer-facing feature since only OUR company was able to access it. HOWEVER, in this case, it was in direct support of our customer relations so it DEFINITELY warranted a place on the road map in support of our theme of “SLO-compliant diagnostics and resolution”.
  • It’s common – perhaps not desirable, but common nevertheless – to be working on presentations the night before the meeting – or on the way to the meeting – or during the meeting. We want the information to be fresh. The mentality is that we can make changes right up until it’s time to present them.You’re the product manager. You own the product. The road map is under your authority. So you get to decide what and when, right? Your job – so says conventional wisdom – is to finalize the road map before you have to present it. So the idea is that you can pretty much change the answers to the test right up until it’s time to turn in your paper.So let’s go back to our discussion about the call-to-action. If you intend to use the road map to tell others what they are going to be doing, then (a) it’s a TERRIBLE way to communicate, (b) you’re VERY likely to meet with passionate hostility and (c) you will create barriers of mistrust that will take months or years to remove.In fact, the EXACT opposite is true. Everything that you say in a road map should be common knowledge to everyone who cares. What does that really mean?
  • First, as a product manager, you have all the responsibility and none of the authority. If that sounds like a complaint, it’s not. At the risk of getting off topic, I might recommend “The 360-degree leader by John C. Maxwell; leading those over whom you have no direct authority is an INCREDIBLY powerful and one that differentiates product managers from most other professions. In light of this, you’ll want to negotiate with your stakeholders beforehand. That means that you’ll need to “horse trade” features v. dates v. performance etc. so that you’re not asking for something and not offering something in return.Second, consensus is NOT a sign of weakness. It means explaining why you want to do something a certain way and LISTENING to reasons why it’s a bad idea (from others). It doesn’t mean PROVING that your way is better, but it does mean that you commit to foregoing your decision (presuming that it’s yours) until you’ve carefully considered all of the other persons’s points. If, after thorough consideration, you decide that you approach is better, forewarn your detractors. “I’ve carefully considered you points that [itemize them and their advantages] but still feel compelled to do [the opposite].” Expect to get resistance during the final delivery.Two tricks to use to get through this VERY difficult process. I have found both to be priceless.1. From my PDM mentor: “Here, Diane, show us how it works.” Usually, I do it by handing the erasable market to Diane. First, it’s much easier for her to point out weaknesses in your plan than it is for her to create a better one. Second, if the crowd is hostile, give them a chance to vent their hostility toward one of your detractors. Third, Diane will realize that, in the eyes of her peers, her ideas are subject to more criticism than yours. When she sits down, a sympathetic comment like, “This is REALLY difficult” will help her to save face. The goal is to show that it’s not as simple as it looks. The big risk in “yielding the floor” is losing control of the meeting in general but I find it worth the risk given the HIGH likelihood of gaining consensus.2. Show interest in others’ ideas. Go back to ask one of your detractors for clarification. Get ALL the information. DON’T interrupt. DON’T presume that you understand. Repeat in your own words. Ask MANY questions. First, you must be an EXPERT on any opposing views with which you disagree or you will lose credibility. Don’t discover that you misunderstood your detractor’s point when it’s time to present the roadmap. Second, when you choose to disagree, your detractor will feel that you have done so in light of his or her very compelling and convincing arguments so you’re NOT ignoring them but making a clear decision to take a particular course of action – one that cannot please EVERYONE but seems to be the best approach.Show respect. Be humble. Wait your turn. Don’t interrupt. Compliement others. Play second fiddle – or third or fourth.Poll Question #3So here’s our third and final poll question for today. Hector, I’m going to predict that nearly all respondents will select the first option based upon my experience at many different companies, though it’s always been a treat when I’ve been fortunate enough to be in the second or third categories. It’s wonderful to be in a position of having autonomy over the road map and, as we’ll see in just a moment, it’s not unreasonable to ask for it if you DON’T have it. Regarding the third option, it’s a nice situation not to be responsible for the roadmap but it implies that you’re in a job other than product management, per se, e.g., corporate marketing, public relations, project management, etc.; that’s fine, and those are highly commendable positions – just be prepared that a move into product management will put an abrupt end to this vacation or sabbatical away from roadmaps.
  • The final trap is one that is more dangerous to our careers than to our product. Most organizations have a “road map” already and we’re asked to update it periodically. The problem is that the road map layout is often chosen by the same individual or team that creates the data sheets, corporate branding, logos, color palette, etc. At first blush, that makes sense. Wouldn’t’ we prefer a road map that complements the branding rather than one that distracts from it?Just as an example, consider Dunkin’ Donuts. When it changed its slogan from “Time to make the donuts” to “America runs on Dunkin”, it wasn’t just one person deciding to use a new slogan but the entire franchise chain was effectively forced to embrace the new messaging. Yes, it’s that important. But let’s put it into context for a minute: The marketing team decides on the logo and the layout for the data sheet, but usually doesn’t choose how to portray specifications or compliance or features. The product manager decides which features or specs warrant inclusion in the data sheet. Why is this important?Because the Marketing team SHOULD define the colors for the road map, the logos, the disclaimers, etc. – but the product manager should decide what to show and in what dimensions. If the goal is to show trends, direction, strategy, then the product manager SHOULD have the flexibility to decide whether to show a Gantt chart, or a flow chart, or a time line, or bullets, or pictures, or an animated GIF, etc.
  • If we understand the different audiences to which our road maps are targeted, and if we can artculate the call-to-action, then we will have a very good idea about what information to portray. So we need to ask some important questions internally within our organizations so that we can respond sensitively to those who may have made personal investments or sacrifices in creating the road maps that we have today.Who: Is that person still here? If so, what was his or her intentions? If not, let’s make an educated guess based upon company and product history.Purpose: It the roadmap layout, content, format, etc. conducive to achieving that purpose? If not, what changes would make it serve the purpose better? For instance, I find that the default road map template that many companies use would be ideal if the goal were simply to track features. However, it conflicts with any sense of long-term product evolution and strategic direction. Validity: Is the reason for the road map’s format even relevant any more? If the market has evolved, if the customer profile has changed, if the company’s strategy is different, if mergers and acquisitions have changed the personality of the portfolio – then the road map layout might be highly ineffective at representing the current portfolio.Universal: Just as we want to optimize road map content for each audience, we may want to optimize the layout and format for each audience, too. If we need to converge on a single format, we should at least first recognize all of the potential customers and audiences for whom the document is intended and choose a format that best addresses that target market.
  • When changing – or proposing to change – the road map template, it will be easy for others to see you as a troublemaker, an iconoclast, ignorant of corporate branding, etc. This is another case where interpersonal diplomacy is paramount.First, let others think it’s THEIR idea. Either “Jim once suggested….” Even if Jim NEVER suggested it, he’ll be tempted to believe he did because you think it’s such a good idea. Jim will be on board with it.Second, ask questions that allow others to discover the solution (the one that you already discovered). Let them bask in the glory of their ingenuity. Let them take credit. Those who feel proud of the idea will be your strongest evangelists.Third, if you are working with a team who has near-zero creativity or who is not likely to think of the solution on their own, jot down a few ideas (including the one you want) and ask them if they think any of them are worth discussing.
  • I’m anAIPMM Certified Product Manager, Agile Product Manager and Product Marketing Manager. After receiving graduate degrees from both New England Conservatory of Music and The Boston Conservatory, I left classical music performance more than 20 years ago to pursue communications technology. Since that time, I’ve served as product manager in several data comm and telecom companies, from small high-tech startups to large multinational organizations. I’ve coauthored five telecom patents, I have extensive experience in network and application performance testing, and I’m also known as "the gadget guy" for my somewhat extensive and varied assortment of mobile communications devices, technologies and platforms.
  • Webcast: Five Product Roadmap Traps (And How to Avoid Them)

    1. 1. © AIPMM 2013 www.aipmm.comAIPMM Webinar Serieswww.aipmm.com
    2. 2. © AIPMM 2013 www.aipmm.com
    3. 3. © AIPMM 2013 www.aipmm.comFounded 1998World’s largest professional association for productmanagement, product marketing and brand managementProvides professional development and certification• Certified Product Manager• Certified Product Marketing Manager• Agile Certified Product Manager• Certified Innovation Leader
    4. 4. © AIPMM 2013 www.aipmm.comAIPMM CertificationsAIPMM offers globally recognized certifications:• Certified Product Manager (CPM®)• Certified Product Marketing Manager (CPMM®)• Agile Certified Product Manager (ACPM®)• Certified Innovation Leader (CIL®)• Certified Brand Manager (CBM®)
    5. 5. © AIPMM 2013 www.aipmm.com• 12-month AIPMM premium membership($175 value)Participate and Win!
    6. 6. © AIPMM 2013 www.aipmm.comHector: @hmdelcastilloAIPMM: @AIPMMJohn: @BlackFalconsultTweet!
    7. 7. © AIPMM 2013 www.aipmm.comToday’s SpeakerModerator:Hector Del Castillo, CPM, CPMM, PMPPresenter:John C. Curtis, CPM, CPMM, ACPMBlack Falcon ConsultingJohnCurtis@BlackFalconConsulting.com@BlackFalconsult
    8. 8. © AIPMM 2013 www.aipmm.comFEATURED PRESENTATION
    9. 9. © AIPMM 2013 www.aipmm.comJohn C Curtis, CPM, ACPM, CPMMJohnCurtis@BlackFalconConsulting.com
    10. 10. © AIPMM 2013 www.aipmm.comTrap #1: Dates & FeaturesConventional Wisdom: Roadmap should show…• Dates• Features• Product Releases
    11. 11. © AIPMM 2013 www.aipmm.comPast, Present & Future: QuestionsPast• Does it really matter when?Future• Why would I reveal it?What SHOULD it show?• Strategy, vision, direction, stability, innovation,conformance, convergencePAST FUTUREPRESENT
    12. 12. © AIPMM 2013 www.aipmm.comDo this: SUMMARIZE• Trick: Elevator pitch• Identify themes• Summarize in 2-3 sentences
    13. 13. © AIPMM 2013 www.aipmm.comTrap #2: Roadmap to AbileneConventional Wisdom: The goal of the productroadmap is to “provide information”……for WHOM?Abilene53 miles
    14. 14. © AIPMM 2013 www.aipmm.comWho asked for it?External• Column fodder• Justify delay, pricing• In-house product• Meeting justificationInternal• Ask! Don’t presume.SERIOUSLY!• DifferentreasonsColemanAbilene
    15. 15. © AIPMM 2013 www.aipmm.comDo this: HAVE A CALL-TO-ACTION• Tip: Identify what YOU wantto happen nextExamples:• Customer requests PoC• SEs provide feedback• R&D, QA et. al. agree to plan
    16. 16. © AIPMM 2013 www.aipmm.comTrap #3: One Roadmap• Conventional wisdom: There is ONE roadmap.• Question: Is there only ONE…– Discount schedule?– Proof-of-concept model?– Meeting format?– Business model?– Negotiating strategy?– Audience agenda?
    17. 17. © AIPMM 2013 www.aipmm.comKnow Your Audience• … or at least IDENTIFY them!• Sales, Sales Engineers:In case someone asks• R&D, QA: Whyare we doing this?• Customers – STOP!Ask the tough questions!
    18. 18. © AIPMM 2013 www.aipmm.comDo this: MAKE MORE ROADMAPS• Roadmap per audience type• Similar to product presentation• Tip: Create/update superset
    19. 19. © AIPMM 2013 www.aipmm.comTrap #4: Updates & News• Conventional wisdom:The product roadmap is a goodvehicle for communicatingwith stakeholders.
    20. 20. © AIPMM 2013 www.aipmm.comDo this: AVOID SURPRISES• Negotiate beforehand• Obtain consensus• Listen even if you don’t agree(know your enemy)• At the very least, forewarn✍ Tip: Yield the floor.✍ Tip: Ask for clarification.
    21. 21. © AIPMM 2013 www.aipmm.comTrap #5: The “Official” Template• Conventional wisdom:Deviating from the“official” templatewill dillute the brand.• Consider an example…
    22. 22. © AIPMM 2013 www.aipmm.comThe Emperor’s Clothes Syndrome• Who created the template?• What did s/he envision the roadmap to be?• Does the road map still fulfill that purpose?• Is the purpose still valid?• Is it the BEST formatfor ALL situations?
    23. 23. © AIPMM 2013 www.aipmm.comDo this: MIND THE END GOAL• Give others credit• Tip: Lead others to the answerby asking leading questions.Example• Was our intent to use the sameroadmap for all audiences?• Have our products/strategies/messages changed since we made this?
    24. 24. © AIPMM 2013 www.aipmm.comRemember S-C-A-R-F1. Summarize trends2. Know your Call-to-action3. Make it Audience-specific4. Review with stakeholders5. Optimize the Format
    25. 25. © AIPMM 2013 www.aipmm.comQ&AModerator:Hector Del Castillo, CPM, CPMM, PMPPresenter:John C. Curtis, CPM, CPMM, ACPMBlack Falcon ConsultingJohnCurtis@BlackFalconConsulting.com@BlackFalconsult
    26. 26. © AIPMM 2013 www.aipmm.comKey Takeaways: S-C-A-R-F .• Summarize trends & strategies1• Know your Call-to-Action2• Make it Audience-specific3• Review with stakeholders4• Optimize the Format5
    27. 27. © AIPMM 2013 www.aipmm.comSpeaker BioJohn Curtis, Black Falcon Consulting• Strategy, vision and guidancefor technology markets• 20+ years hands-on technologyproduct management• AIPMM CPM®, ACPM® and CPMM®• Several communications patentsand patents pending27
    28. 28. © AIPMM 2013 www.aipmm.comUpcoming CoursesCourse & Location Dates Days TimeACPM® Certification Prep Course & ExamTeqcorner, McLean, VA July 22, 2013 M 8:30 am – 5 pmCPM® Certification Prep Course & ExamTeqcorner, McLean, VA July 23-24, 2013 T, W 8:30 am – 5 pmCPMM® Certification Prep Course & ExamTeqcorner, McLean, VA July 25-26, 2013 Th, F 8:30 am – 5 pmContact Cynthia Petti, cynthia@280group.com for more information. Additionalcertification prep courses are available in Austin, San Jose, Seattle, and London.
    29. 29. © AIPMM 2013 www.aipmm.comUpcoming CoursesCourse & Location Dates TimeCIL® Certification Prep Course & ExamKuala Lumpur, Malaysia Jun 5-6, 2013 9 am – 6 pmCPM® Certification Prep Course & ExamDubai, UAESingaporeKuala Lumpur, MalaysiaAmman, JordanMay 19-23, 2013May 27-29, 2013Jun 3-4, 2013Jun 17-18, 20138 am – 5pm8 am – 5 pm9 am – 6 pm8 am – 5 pmCPMM® Certification Prep Course & ExamDubai, UAESingaporeAmman, JordanMay 26-30, 2013May 30-Jun 1, 2013Jun 19-20, 20138 am – 5 pm8 am – 5 pm8 am – 5 pmFollow the links provided to get more information regarding these courses.
    30. 30. © AIPMM 2013 www.aipmm.comFor More Information About• AIPMM membership benefits• Certification courses near you• How to prepare to take a certification examHector Del Castillo, CPM, CPMMSenior Product Innovation Consultanthmdelcastillo@aipmm.comlinkd.in/hdelcastillo
    31. 31. © AIPMM 2013 www.aipmm.comPlease Join Us Again!AIPMM Webinar Series:http://aipmm.com/aipmm_webinars/Global Product Management Talk:http://www.blogtalkradio.com/prodmgmttalkStay Informed!Newsletter: http://www.aipmm.com/subscribeLinkedIn: http://www.linkedin.com/company/aipmmMembership: http://www.aipmm.com/join.phpCertification: http://aipmm.com/html/certification/

    ×