Month: August 2007
I wish I had a funny link to something on YouTube showing a moron being a product manager, but I guess there are some things too obscure even for YouTube. Over at LinkedIn, however, Santosh Maharshi asks about how to be a great product manager. Many fantastic answers ensue.
Well this is a nice surprise for us. Our blog is being translated into Portuguese! If imitation is the highest form of flattery, translation is right up there.
You will notice that I added a comment to the first article because the translation is being done without attribution, and the translator / author did not contact us first. But … aside from that, we take it as a big compliment to be picked up this way. And whoever the author is, please do contact us!
PS: Some information on the Portuguese language can be found here.
PPS: I’ve always believed that our blog is best read while listening to some Jobim. Preferably some stuff with Getz and Gilberto backing him up. Hard to believe I hadn’t mentioned that earlier.
Over the last few years I’ve written several articles that have been published by the folks at ProductMarketing.com.
I discussed one such article, Product Management Axioms, in another blog post.
The remaining articles cover different topics related to product management, from beta programs to prioritizing customer feedback to a discussion on how many product managers are really enough in an organization.
I’d love to hear your feedback on any of them.
Building a Better Beta
Detailed description of the key elements of beta programs and ways to make them effective across teams in a software company
A Model for Metrics Driven Feature Prioritization
Describes a method for including large numbers of customers in a closed-loop dialog on product direction
You Can Never Have Too Many Product Managers
Defining the value of Product Management in a software company is difficult but critical. Companies must ensure the Product Management role does not bottleneck other parts of the company.
A House with no Front Door
Creating great software products requires diligence and forethought. Efforts that put development efficiencies ahead of user needs simply increase complexity and cost for the vendor over time.
Every product manager has to do a SWOT analysis at some point in his or her career. The only trouble is that they’re often so few and far between that no one ever really gets very good at doing them. This is generally not a big deal, as a SWOT analysis is pretty easy to do, but doing a few simple things will make your SWOT documents a lot more effective.
First, on the SWOT elements: strengths and weaknesses should reflect internal characteristics. Opportunities and threats are external or environmental.
So, for example, a lack of customers is not a weakness, unless there are no customers buying any product like yours. “Lack of market” is a threat, “lack of market penetration” is a weakness. Try to focus on issues that are clearly internal or external in origin. Choosing “it’s nobody’s fault” types of issues doesn’t make for a compelling SWOT.
Once you have identified a few clear issues in each category you can begin the really important part of the SWOT analysis. Early in my career I just made a list in each category and left it at that. No conclusions, no recommendations. Not surprisingly, I didn’t see SWOT as having a lot of value. After doing numerous SWOT analyses in school I started to see the value of a more thorough job.
The real value comes when you make a matrix and compare your strengths and weaknesses against opportunities and threats:
So see how you can use your strengths to exploit opportunities and offset strengths. Look for areas to avoid by seeing where threats attack your weaknesses and see where you need to improve weaknesses to take advantage of opportunities.
It’s this second level of analysis that really brings out useful recommendations and an action plan from SWOT analysis.
I recently completed a six part series of articles entitled:
How to be a GREAT Product Manager
I started writing the series as an analogue to Ken Norton’s posting on his blog: How to hire a product manager.
Ken lays out six major points on how to hire a PM. Each part of my series focused on the flip side of his points and focused on how to be a great PM. The following table shows the two side by side:
Hiring a great PM
Being a great PM
|1||Hire all the smart people|| Don’t just sound smart, act smart and be smart
|2||Have a strong technical background||Be technical without becoming a technologist
|3||“Spidey-sense” product instincts and creativity|| “Spidey-sense” instincts are good, hard data is way better
|4||Leadership that’s earned||Follow the 4 Cs of Leadership
|5||Ability to channel multiple points of view||Be an integrator, translator and communicator|
|6||Give me someone who’s shipped something||Own the product from conception to completion and beyond|
There’s probably a lot more to write on both hiring and being a great product manager. When hiring you only have a limited amount of time to assess the person, ask key questions, see some of their previous work if possible, check references etc.
Most of the time, the hiring decision comes down to a mix of the person’s performance in the interviews and a gut call made by the hiring manager. Some people interview well but perform poorly. Others don’t interview as well but deliver results. Finding good talent is always tough, and this is especially true in the case of PMs.
Being a great product manager is not easy either. Aside from rising to the challenge on your own, there can be organizational, political or business hurdles hindering your path to success. The role of a product manager in a larger company is likely very different from the same role in a startup.
It can be very hard to make a big imprint in a larger company where strategy and major product direction decisions are oft-times made at the senior management level, with product managers being tasked to execute on those decisions. In a startup, I’ll bet you’re likely understaffed with more to do than time to do it.
In either case, you can still rise above the noise and be effective. Focus on the key objectives you need to deliver and ensure those get done in a timely manner. Don’t be a “just-in-time” product manager. It leaves you no wiggle room if you meet unexpected delays and makes people depending on your rather nervous.
Beyond the key objectives, keep watch for places where you can help improve how the organizations builds, markets, sells and supports your products. If you notice that the evaluation process for your software is cumbersome and this is impacting sales, help identify and define the solution.
If you see that sales consultants aren’t adequately trained then work to get them the help they need. If you notice that customers are getting frustrated with the quality of support (despite what the results of the 3rd party customer satisfaction survey says), raise it with Support management or other executives. The point here is that beyond the product(s) you manage, identify ways to make the company better and be part of the solution team.
Be wary of internal power structures and political circles. It is far too easy to get encumbered by company politics or suppressed by hostile power structures. This is more often the case in larger companies, particularly those who’ve grown quickly and where many of the original or early employees have risen to management positions.
Dealing with and navigating internal power structures could be the subject of a series of blog postings (hmmmm), but all I will say for now is tread carefully and knowingly when in enemy territory.
In the end, there is no magic recipe to ensure you are a successful product manager. It takes a lot of effort, insight and thinking. But if you keep those 6 rules in mind and try to apply them wherever possible, you’ll certainly increase your chances of success.