Punch with the intent to hit, otherwise you will never hit.
If you aren’t ruthlessly focused on success in your career, quit – do something else.
If you don’t wholly believe in your product – find another.
Applications for marketing? For one, pursue a solid segmentation strategy. If you are a small company and are late to the game, you aren’t going to win in the general market – you do not have complete intent. Sharpen your segmentation strategy, focus on the markets where you can win and pursue that strategy ruthlessly.
Competitive research is a critical part of a product manager’s job. There’s a right way to do it and a wrong way to do it. The Apple v. Samsung case has done a great job of illustrating both.
Let’s say you find yourself, as Samsung did, suddenly well behind a competitor in some important aspect of your product. Customers are telling you this, analysts are telling you this, your kids are telling you this. You have an obligation to understand the problem and to articulate it in nauseating detail to your development team. It’s your job to not only close the gap, but to leap ahead of your competitors. Time for some serious competitive analysis. Samsung did the work here – check out this exhibit from the trial.
The Good: Samsung did a very detailed analysis of the gaps between their product and the iPhone. You need to get to this level of analysis in order to understand the problem.
The Bad: They went beyond analysis and actually used screen shots from the competitive product to describe what needed to be done in their products. Presumably this was given to developers. They are basically saying “make ours looks just like theirs”. Yea, that’s illegal.
If the next version of your product comes out and looks and feels exactly like the competitive product that you used to perform your analysis, you have made a serious mistake. The Samsung product manager should have thrown a flag at this point. Going to market with a straight-up rip-off of your competitors product is not only extremely uncool, but as Samsung just learned, illegal and expensive.
There is some interesting banter on Twitter between @crankypm and @rcauvin concerning the role of product management in product design. Design is a topic near & dear to my heart, so my thoughts on the subject could not be contained by Twitter’s 140 character limit.
The point of contention in the debate is whether Product Mangers should be using tools like Balsamiq (of which I am also a big fan) to produce mock-ups. Cranky and Roger have gone back and forth on this and I think they are talking past one another. I’m guessing that they actually share a great deal of common ground on the subject, so am going to do my best Mother Teresa and attempt to demonstrate that common ground here.
Roger’s spot-on that too many companies don’t appreciate the value that an interaction designer can provide, and as stated in his Feb ’08 blog post that critical role is all too often filled with someone with the best of intentions, but the wrong skill set.
Cranky, too, is correct in her assertion that there’s nothing wrong with a Product Manager picking-up a design tool in order to communicate a product concept with a mock-up – a picture being worth a thousand words and all that.
It seems to me that the critical issue here is the intent of the mock-up. I use mock-ups frequently myself, because I am a visual person and so communicate more easily and effectively with a picture than a wordy document (never know if from this blog would you). I know that I’m not an interaction designer and don’t want anyone mistaking my attempt to communicate a concept as an attempt to specify a design. So, I am very careful to include the following disclaimer on every mock-up I produce: “…the UI is intentionally low-fidelity and serves only as a narrative – this is not a UI design artifact”. I also call my mock-ups storyboards and accompany them with a little textual narrative as this helps to drive-home the point.
The open-ended discussion that mock-ups stimulate are critical in the very early stages of product design. Just as important, however, is the need for professional interaction design; there are few things more important to a successful software product than nailing the user experience and an interaction designer is key to achieving that goal.
I hope I’ve helped to move the conversation forward, because it’s an important one.
I’ve been asked more than once if it is within Product Management’s purview to prescribe a product development or project management methodology. Experience has taught me that Scrum works, and I believe that it is within my authority to prescribe a process through which I believe success to be possible, and perhaps more importantly to veto a process that I know to be doomed for failure.
I was recently asked to make this case in writing and was pleasantly surprised at the results. I feel like I’ve stated the case for Scrum – or something quite close – with legitimate business reasons. Following is an excerpt from a product charter document on the subject of project management:
This project will be executed under a somewhat unique set of circumstances. Selection of a project management process that supports these circumstances is critical to the success of the project. It is the responsibility of The Team (Executive, Product, and Development) to select a project management process that will be used for the lifetime of the project. Following is a discussion of the circumstances of the project along with indications for the project management process.
This project is not being fulfilled for a single customer. We are building to where we believe the market will be in one year’s time – our perception of where exactly that is will very likely change over the next 12 months. For this reason we must follow a project management process that allows for continuous adaptation of the project deliverables.
The company has a rather small team of highly qualified and experienced software developers who have worked together for many years. Such a team will not be helped by a heavyweight process, but more likely hindered by it; clearly this is not desirable. Therefore a second requirement on the project management process is that it be “lightweight”. In other words the artifacts of the process must be few and straightforward, requiring minimal documentation and creating little process overhead.
Accountability for product strategy lies with the SVP Product & Strategy. In practice, however, the responsibility for defining product strategy is shared across multiple organizational disciplines including Executive, Development, and Sales. An additional requirement on the project management process then, is that it must provide transparency to in-flight development in order to facilitate shared responsibility for product strategy.
Finally, we anticipate a great deal of interest in this project from existing customers, prospects, board members, prospective investors, and press. To maintain credibility, we cannot afford to have discrepancies between reports on project status. We must speak to all external stakeholders with a single accurate voice. A final requirement on the project management process is that it must allow for measurement of progress towards goals and milestones.
I’m curious how the selection of methodology/process is decided at your shop. Does PM prescribe it, do they even have a voice? Also curious what you think of my argument above.
Carl Knibbs on his aptly named “carl’s product management blog” has a post discussing considerations for getting the green light on development of a new product. I agree on all Carl’s points and would add:
Market/opportunity size will typically be the number one concern for a new venture. A new product should make it the same. Find a way to quantify the opportunity and present it in a way that makes sense to someone not familiar with the market.
Carl covered “why me” – I’d like to see some statement that explains why your company is poised to succeed at this new venture.
- Do you have favorable relations with the buyers?
- Do you own technology or other IP that you can leverage to exploit the opportunity?
- Do you have a partnership network that puts you in a unique position?
- Are you able to leverage a unique geographical presence?
- Is your brand readily transferred to the space?
Whatever the reason, spell it out. Why is your company uniquely positioned to succeed in this endeavor?
Who else is likely to attack the opportunity. While the opportunity size defines the size of the pie, the answer to this question helps to define the size of your slice (given the answer to “why us” above). Under most circumstances, a small slice of a small pie is not an interesting proposition regardless of the answers to the other questions.
If you’ve ever been involved with a start-up, you know just how important timing can be. Some might say that it is the most important consideration – though it’s nearly impossible to predict “perfect” timing”. It’s important to explain why this is the right time to solve the problem for your target market. What makes today an important time for the market?
Like any good start-up, a new product should have an exit strategy. What’s the long-term vision. Do you integrate with other parts of your portfolio? Does this establish the beginning of a new portfolio? Does the product get spun-off as a new business or acquired by a competitor. This isn’t a “burn the ships at the shore” statement of strategy, but it’s important to have some idea of the potential outcomes as they will drive long-term strategy.
Nice list Carl, thanks for carrying the conversation forward.
Charlie O’Donnell‘s post on “Why Product Management is More Like Baking than Cooking” has some great points. In the post Charlie is lamenting the fact that when it comes to product management, the leadership of startup companies seem to want to wing-it (like a cook) as opposed to execute on a proven process (like a baker).
Having more than a little cooking experience, quite a bit of product management experience, and much less baking experience; I’d rephrase the title to say that being a product manager is more like being a Sous Chef than being an Executive Chef. If you haven’t worked in the F&B industry before the difference may escape you – follow me here, I think it’s worth the effort.
Executive Chefs provide vision. They start with a general direction, an idea of the dish they want to serve and a knowledge of the ingredients on-hand. They turn themselves over to the creative process, relying heavily on past experience and gut feel, and voila! they turn-out a plate. The success or failure of the effort will depend upon the skill of the chef, the quality of ingredients, and also rely a good bit on fortune. Many a chef has ruined a dish while learning something that later helps him to prepare a real gem of a meal. This is the software equivalent to R&D.
Sous Chefs, on the other hand, are professional managers. Their primary job is to productize a creation dreamed-up by the Executive Chef. While the Executive Chef has only to create the one dish, one time, and take as much time as she requires to finish it; the Sous Chef must crank out that dish a hundred times a night, with limited resources, while maintaining consistent quality. To be successful it’s got to be more science than art at this stage.
Which brings me back to the point of Charlie’s post. When you are cooking with someone else’s money, it’s time to hire a Sous Chef. Someone who can bring transparency, predictability, and repeatability to the process of taking new products to market.
Note that this does not mean, as some of the comments to Charlie’s post have implied, that the creative process ends when a professional Product Manager takes the reins. Nor does it mean that you are now following a waterfall process where the product goes into the oven and you are stuck with what comes out. As Charlie rightly points out, measurement tools are a critical component to the long-term success of the product. Going back to the analogy, the Sous Chef will monitor key performance metrics such as the amount of time it takes to prepare and serve a dish, what the temperature of the dish is when it leaves the kitchen, the number of dishes ordered per restaurant guest, and overall guest satisfaction. By monitoring these important indicators, the chef can course correct if things start to go awry. The same is obviously true for the product manager.
If your product is ready to leave the test kitchen and get out into the real world, take a big step towards repeatable, predictable success and hire an experienced, professional Product Manager.
I was just looking at a video of Lizzie O’Leary (Bloomberg) on Alltop.com discussing how to effectively tell a story with numbers. What an important skill for product managers. As the leader of your product it’s not only critical that you have data to back-up your decisions regarding product futures, but that you can effectively tell a story with that data.
If you are a product manager, you’ve likely internalized the tenets embodied by Steve Johnson‘s quote, “your opinion, while interesting, is irrelevant.” The best product managers say “no” to every new feature request and to keep saying “no” until the case for the feature is made. The case for the feature is made by data. But the product manager’s job is not done when the feature is added to the backlog and prioritized. It’s important to communicate the need to stakeholders inside and outside the organization. Use data; turn it in to a story; indicate the trend and the opportunity. Explain to all stakeholders why you want to do something – not just what you want to do.
David Radzialowski and Joshua Steffan of B2B Product Makers have posted a great piece titled “So You Got the Product Manager Position – Should you take it?” It got me reflecting on the same question, so I’ve added some to their excellent list of issues to consider before you say “yes”.
Budget. David & Joshua mention this, but I want to call more attention to the subject. As a new PM you will want to travel. Well, you may not want to, but you’ll need to. You need to hit the road with the sales team, listen to existing customers and prospects, attend trade shows, and get a feel for the market. Depending on the product you may want to visit production or service delivery locations. You’ll often have the need to purchase tools. You may need to fill in gaps by outsourcing important functions like win/loss analysis if no one is doing it today. All of these activities are critical to your success and you’re being set-up for failure if you aren’t going to be able to get the necessary budget.
Product Development. This may seem like a silly question to ask, but it’s an important one. Does the company make their own products or do they resell? Your job as PM for a VAR will be about portfolio management, service delivery, and partner relations. Is this your thing? If it’s not, then you’ll want to get with a company that is developing their own products.
Innovation. David & Joshua talk about idea generation, but I’d like to focus on a slightly different aspect – is the company committed to innovation? Lots of companies aren’t and it’s not a requirement for financial success. But it might be a requirement for your happiness. If it’s important to you – ask the question.
People vs. Process. This could be a sub-header under “culture”. Does executive management put its faith in people or process? It’s not a fair question, as the answer is likely both, but where is the emphasis. If you are a Six Sigma-type, you might be fine with an organization that believes in process over people. If you are the highly creative, color-outside-the-lines-type, maybe not so much. Fortunately salary is a pretty good indicator of the value a company places on talent. If they are paying below market they probably don’t feel like they need the cream of the crop to be successful.
After fielding several comments on my last post regarding product naming (“What’s in Name?“), I realized that I had over simplified the problem some. I’m going to add some necessary follow-up thoughts here.
I was previously considering the product naming exercise from the point of view of a start-up. A catchy name works for a start-up because start-ups are building a brand around the product. The game changes considerably for larger companies. Imagine a company the size of IBM with 5,000 products in its portfolio, all with cutesy names like Wizzi. Discussing the portfolio with customers would go from comical to ridiculous in a hurry.
Companies with large product portfolios and well established brands will want to leverage the brand and provide descriptive, functional names for new products. Recall that in our example, the product detected marketing-speak in presentations. Let’s add to the example the fact that the product is marketed by a large, well-known software company – ByteCo. Rather than use a catchy name, ByteCo would be better served to name the product “ByteCo Presentation Cleanser”, “ByteCo Gobbledygook Cleanser”, or something of the sort. Doing so would allow the company to leverage their brand and would allow the product to describe itself to potential buyers browsing the existing product portfolio.
A similar approach is to develop a brand around a suite of products (in addition to the company brand). Microsoft has done this well with the Office suite of products. Having the Office brand applied to a product immediately tells consumers much about the product: it’s for desktop use, productivity related, integrated with Outlook, Word, etc. IBM has been similarly successful with the WebSphere name.
Note the examples above also indicate that descriptive names aren’t necessarily verbose. These kinds of semi-descriptive names are another great option for start-ups. NetFlix, for example, is both catchy and descriptive at the same time.
The subject of product naming came up today on the Pragmatic Marketing LinkedIn discussion board. Naming is one of those creative subject areas that in practice are a pain – but in theory are lots of fun. So what better place to discuss than my blog where I can air my opinion free of political concerns.
I’m a fan of names that have no semantics attached (Kleenex), very generic meaning (Apple), or very esoteric semantics (Google). I also go for names that are easily remembered and easily pronounced in all major languages.
For different flavors of products I like to take two tacks:
- generic packages with generic (standard & advanced) or non-sensical (XE, ES) names
- solution-based names aimed at a particular use case / segment.
So let’s assume we have a cool new product that will scan your powerpoint presentations for the detection of marketing-speak; inspired by David Meerman Scott’s “Gobbledygook Manifesto“. We decide to call it Wizzi. There will be a free version called Wizzi Basic that will only scan 10 slides a day. The full version will be Wizzi Pro. There is a package aimed at medical marketing companies which adds common phrases determined to be bullshit in this industry (the medical marketing add-on), we’ll call it Wizzi Pro – Medical Marketing Version.
Seems so easy in the abstract. Why is it so hard in practice?