My pal David Daniels is moving his Launch Clinic blog. Join his discussions and learn techniques for better product launches. If you're already a subscriber (as I am), check your RSS feeds.
My pal David Daniels is moving his Launch Clinic blog. Join his discussions and learn techniques for better product launches. If you're already a subscriber (as I am), check your RSS feeds.
Well, golly, this doesn't look good. Last year, Scott Sehlhorst at Tyner Blain concluded that experience overcame gender bias in compensation but his 2009 analysis of Gender Bias belies that conclusion. Read more in Analysis of Gender Bias in 2008 Salary Survey, part of our continuing series of posts on product management and marketing compensation and roles.
Each year, Pragmatic Marketing conducts a survey of product managers and marketing professionals in technology companies. The results provide interesting insight into a typical "day-in-the-life" for those tasked with defining and launching technology products in today's competitive market. Read more in 2008 Annual Product Management and Marketing Survey.
I was interviewed for Michael Ray Hopkin's Product Management Pulse podcast.
Michael writes, Product managers are the messengers of the market for their companies. In this episode of the Product Management Pulse podcast Michael talks with the strategic product manager himself, Steve Johnson. Through his years of experience as a software developer, SE, sales rep and then product manager, Steve has gained a deep understanding of technology products, from idea to release to success. Steve shares his experience in his typically humorous and instructive manner.
We've experimented with different formats for the Pragmatic Marketer magazine: print, PDF, and individual articles in HTML. Our crack marketing team has found a clever tool for reading the magazine online that I think you'll really like. It looks and feels like... a magazine!
Come check out Volume 7 Issue 1 of the Pragmatic Marketer, now available in FlexiPage ebook format, PDF, and Kindle. In this issue, my article on Pragmatic Marketing's 2008 Annual Product Management and Marketing Survey, part 4 of Practical Rules for Product Management: Some Rules Just Aren't Meant to be Broken and more.
My friend and colleague Stacey shared this with me. She writes,
Whenever I travel outside the U.S., I am struck by the number of people who speak multiple languages fluently. On one particular trip, I was in the Brussels airport. The ticket counter agent was speaking at least 4 languages – and she knew them so well that she could quickly switch between them. She’d get someone checked in using French, then turn around and answer a quick question in German. She spoke to me in near perfect English, and as I was walking away I heard her speaking Spanish (or perhaps Portuguese) to another passenger.
For awhile, I would kind of beat myself up over this -- my Spanish is pretty rusty, and I would definitely not say I’m fluent. I often wish I knew at least one other language – it’s so much more personal to greet people in their native tongue, rather than expecting the whole world to speak English.
Upon further consideration, I decided I was being too hard on myself. After all, don’t we Product Managers translate constantly for our organizations? I may not know French, German, Chinese, Flemish, or Hindi – but I do understand Sales-speak, Development-dialect, Promotions-patois, and Operations-oracy.
We do translations all the time. The agile product manager is skilled at understanding each member of the team, so they can translate for others.
When Sales says “If I could only get this feature in the release, I’d close this deal,” they actually mean, “I feel like I’m losing here, and surely it cannot be my fault.” The Product Manager’s job is to help the team understand, and to keep them focused on their current work. If a Sales person makes a statement like that directly to development, without any translation, the team might believe the rhetoric, and quickly switch to satisfying one sales person. The Product Manager needs to help everyone see the market clearly and objectively.
When Development says “we’re delivering a new architectural layer that will dynamically expose all data elements”, the Product Manager needs to intercept, and ensure that the Promotions team understands the benefits of the release, rather than the technological miracle that happens under the covers.
The biggest battle in doing this translation is to give ourselves a moment to think. Where did the statement come from, and who else needs to understand it? Think about the Development explanation from above – they are speaking from their very technical viewpoint. Promotions, however, needs to understand the benefit to the buyer and/or user.
Early on in my career, I did a lot of this translation on the fly. Later, I learned that much of this translation can be ‘canned’, by anticipating the needs of each department and communicating to them so that their primary concerns are placed front and center. In the case of Promotions, positioning is the preferred method of translation – we use positioning to move us away from the technical, into laser-focus on the market’s problems and our solutions to those problems. We can do that translation up front, so the Promotions team can continue to focus on the benefit, without getting distracted by Development details. The secondary benefit is that we don’t have to spend quite as much time being personally involved in reviewing early versions of the Promotional artifacts. In fact, with a good positioning statement, MarCom is free to operate independently – creating high impact promotions with minimal daily involvement by the Product Manager.
We translate for our teams every day. When we focus on that necessity, we can do some of the work up front, and ensure that each member has what they need to be really good at their job. In turn, we can continue to create, market, and sell current products effectively…while we return to the market, analyzing its problems and prioritizing requirements for the next big thing.
Product managers need to intimately understand their markets in order to be effective. They must know the customer better than they know themselves. Yet meetings and administrivia fill their schedules. What's needed is a challenge for product managers to visit customers with specific tasks and tips to get started.
Now that you've attended a Pragmatic Marketing seminar, you know the value of having market knowledge. What are you waiting for? Barb Nelson and I wrote an ebook, Effective Product Managers Know Their Market, to help you get started in your visits to the market. Download it now.
Saeed writes, would you mind asking your readers to hop over to our blog and leave a comment or fill in the survey about what problems they see in Technology Product Management?
My friend Stacey shared this:
Companies are like machines. Each department plays their part, and together the thing somehow works. People within one department don’t always have to understand the entire operation – Sales people, for instance, are not required to understand how coding actually happens.
Certain organizational changes happen, and force the departments to understand a bit more about the machine. For instance – if Sales people are asked to begin selling a product that is delivered as an API, they’re probably going to have to learn something about coding (even if it’s just enough to explain the benefits of their solution).
Usually, Development can make adjustments to their process without needing the support or understanding of other departments. They change the process for controlling source code – but no one else has to deal with that, so it’s an isolated change within their department. Or, they go from manual testing to automation. Again, no one else needs to understand that change (as long as quality is positively impacted).
In most companies, changing to agile is not isolated. When the process for receiving requirements and estimating work changes, lots of areas in the company are impacted and must be brought on board. Basically, this change can cause stress in other parts of the company. If Product Management was having a hard time keeping up before, the change to agile will highlight that weakness, and sometimes stretch our process so far that it actually breaks.
If your development team is thinking of going agile, you have to stop and examine your requirements process. Are you ready to live in an agile world?
How are you preparing requirements? Do you constantly update the prioritized list of market requirements? Or, do you get to a point where you realize you have to deliver requirements, and quickly scramble your schedule so you have time to write stuff down before the team wants to review?
If I asked you to give me your top two requirements tomorrow morning, could you do it?
This is what Product Managers have to be prepared for! When your team goes agile, you have to constantly maintain the prioritized requirements, so you can give development more work at any time.
An agile team is going to ask for requirements more frequently, since they’re organizing their work into short sprints rather than a long waterfall release cycle. If you are constantly seeking market input, and organizing that input into a prioritized list of market requirements, you should be able to handle the transition fairly easily.
If your developers are transitioning to agile, take a look at your machine. Oil as needed, so that your team is enabled to succeed in an agile world.
However beautiful the strategy, you should occasionally look at the results.--Winston Churchill
Kristin Zhivago asks,
What is more important than your plan? The work your people do, and their daily interaction with your customers.
In Are you a blind CEO? Zhivago explains that a typical CEO, living in an environment far removed from customers and employees, is unlikely to understand what's really happening in the company. It's easy enough to see: many CEOs are too busy with planning and strategy to focus on daily operations. They're too involved with other senior execs to talk with the rank-and-file.
One company president systematically interviews her employees... over dinner. Once a quarter, she invites a few employees to dinner at a local restaurant and discusses what is and isn't working at the company. What recent decisions do they question? What do they think of recent changes? What do they think about the company's plan and its future? Of course, to be effective, the employees have to know that they won't be penalized later for speaking their minds. (You can see this done badly in many companies but nowhere worse than The Office episode "Performance Review.")
Does your company have a method for hearing the good and bad from the folks who do the work?
Sales people are often very good about telling you the pulse of the market--at least what they're hearing from their customers.
Product managers are in a unique position to know the pulse of the company. Product managers work with development, marketing, sales, support, finance, distribution... every department in some form or another. What can product managers tell us about the way the company is working internally? And if product managers are doing their jobs, they'll have data on how the company is perceived in the market. After all, a good product manager is making a dozen calls per quarter to the market.
Product managers' knowledge of the health of the company and products makes them ideal as the president's representative at the product level. That's why I am pleased when I see the product management group reporting directly to the CEO.
Wanna know what's going on? Ask a product manager.
CNN reports that emergency officials are responding to a downed US Airways plane in New York's Hudson River. (update: Happily everyone survived.)
Call your mother. She doesn't know where you are.
Back in the early 80s, I worked for a great guy, Rob Porter, who was truly one of the best managers I ever had. He had a rule: if there's ever a problem in the news, particularly if it's travel-related, always call your family to let them know that you're safe.
Rob called me into his office one day to complain about my expenses. I was terribly anxious because I had been very careful with expenses, watching every penny. "You don't call your wife often enough," he complained. "You need to call her once a day at least. After all, she is raising two kids without you whenever you're traveling. And what is your mom's phone number?" he asked. I told him and he was truly annoyed. "You haven't called your mother in a month? What the heck is wrong with you?" In his view, the corporate phone plan--(before cell phones of course)--was as much for personal reasons, to make sure everything was okay at home, as well as for business. Part of the job is traveling; sure it is. But that means that a spouse, a parent, or a child is wondering where you are and if you're safe.
Our families know that we travel. And today, particularly with cell phones, it's doubtful that they have any idea where we are. Always call home after a travel-related disaster.
There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. --Machiavelli
I've often wondered about creating a product management manifesto or treatise or statement of direction or personal oath. I have participated in discussions with Graham, Saeed, Alan, and others. I was truly inspired by the call to arms known as The Agile Manifesto because I completely agree: we do spend too much time writing about writing code and not writing code; we do seem to blindly follow a plan rather than adapt to changes. So hat's off to Kent Beck et al for rejecting conventional wisdom and refocusing development on the things that really matter.
As for product management, Alan Bullied may have the right idea; he has this to say. Brian Lawley took a shot at it with his Product Management Manifesto but Tom Grant at Forrester had a fairly strong reaction to it.
I find, in the end, that I keep coming back to Peter Drucker's definition:
The aim of marketing is to know and understand the customer so well that the product or service fits him and sells itself.
Call it marketing or call it product management, that's my product management manifesto. And for me, the articulation of it for technology businesses continues to be the Pragmatic Marketing Framework.
I was laughing over the 2009 Bad Usability Calendar when I realized that it was a one-page ebook. 12 usability mistakes illustrated on a single page with over 2000 downloads in under a week. David Meerman Scott has convinced me; I am a big believer in ebooks.
Nobody likes a hard-sell! How could you get your customers and non-customers to spread your message? Write an ebook! Explain the three or four (or 40 or 50!) things that you and your company know that others do not.
How can you harness the power of the web to get customers to tell your message to their friends? (and she told two friends, and she told two friends, and so on and so on...)
"She analyzes synergies, or synergizes analogies... or some such thing."--Father Brian Finn (Edward Norton) in "Keeping the Faith"
Peter the CEO just returned from a corporate funfest with a new partnership. "This puts us in the sweet spot of the market by leveraging our mutual synergies in a going-forward approach." Now he wants Robin to work out the details. "Just put out a FAQ, brief the sales force, and start inviting the new team to your product planning meetings."
Nothing seems difficult for the people who don't have to do the work!
Poor Robin. As a product manager, Robin already has plenty on her plate and now this! What to do? A good partnership solves a problem for a market segment. First, find a problem, determine the optimal solution, and then explore partnership opportunities. Before doing anything public, Robin needs to understand the reason for the partnership--visualize the results of the partnership from the customer's point of view.
Is this a technology partnership? Is this about creating a new or improved product? If so, Robin should plan a few "getting to know you" meetings and get clarity on exactly what the output will be and who will be responsible for what. Ideally, the team should produce some work product before announcing the partnership. What if Robin can't work with the team? What if their architecture is incompatible with hers? What if the team cares more about quick-and-dirty and Robin cares more about elegant usability? Are the partners compatible?
Is this a marketing partnership? If so, Robin needs to discuss promotional opportunities with the partner company and then align them with her own marketing plan. The partner hosts a significant user conference; is speaking at events a key element of Robin's marketing plan? If so, sign on up. If not, why support the partner conference?
Is this a sales partnership? Here's one way to know: a successful sales partnership presents one sales person, not two, to the customer. I know I know. It sounds great--internally--to say "our two sales people will go to the customer arm-in-arm to present a single solution." Alas, that always seems to fail in the real world. One solution = one sales rep. Actually, sales partnerships are rather fun. Since Robin knows the partner sales people don't know her products, she won't assume that they do and will create better sales tools and training as a result. [Hey! Maybe you should assume your own sales people don't know the market or the products. Wouldn't you create different sales tools and training?]
Partnerships are a great way to expand your expertise, your product set, your exposure to the market, and your sales reach. Both partners should benefit from the relationship. And your mutual customers should get a better single solution than the parts created by the two of you individually. But you better label your stuff. The average partnership in technology business lasts about four years. Be clear what is owned by whom for when the inevitable separation occurs.
Don't announce a partnership until you're clear on team roles and deliverables. The best partnership creates better experiences for your customers.
The news from Cupertino was fairly boring last Tuesday so the Onion revealed the MacBook Wheel.
"For many executives, an obsession with ROI is just a convenient excuse to shy away from something new and untested. Yet that's exactly what the best ideas for creating a World Wide Rave are--new and untested. If you're obsessed with ROI measurements that worked in an offline world, then you're just making an excuse. If you worry about losing control of your message, then you're making an excuse."
David has just posted his new ebook called Lose Control of your Marketing! David's ebooks are always a treat for me so I'm gonna put everything else aside so I can start reading this!
How do you read www.productmarketing.com?
Looks like Google Reader wins the contest for RSS Readers by a wide margin--at least for the readers of www.productmarketing.com.
And what do you do as a product manager when your competition has the market-leading position AND is free? I dunno. I think it means you need to look elsewhere for revenue. Instead of competing head-to-head with a dominant (and in this case, free) product, look for personas that are not well-served by the generic solution; find a niche that needs tailoring for their special needs.
If you haven't heard about it, Scrum is the most widely adopted development planning method in use today. (Well, actually, "hybrid" is the most commonly used method; that is, a hybrid of XP, Scrum, waterfall, and others.) Usually about half of the people attending our Requirements That Work seminar are adopting Scrum. Requirements That Work focuses primarily on requirements and the artifacts of planning, product managers are also interested in the mechanics of agile development.
If you want to know more about Scrum, there are many books and websites available with information--often too much information for what a product manager needs to know. This video does a very good job of introducing Scrum in a very short ten minutes.
Take a few minute to learn more. You may find that these techniques can be used in your product planning regardless of whether your company has adopted Scrum or not.
I made a font of my handwriting. I don't know whether to be thrilled at this cool font or just depressed that my printing looks like I flunked penmanship (or is it penpersonship?). And you know what's really depressing? I never learned to touch-type either. My kids just laugh and laugh at how many times I have to type and retype the same sentence. So I never learned to write well or type well. Yeesh! Good thing that I'm funny. (At least that's what I tell myself when I'm alone.)