Wednesday, April 29, 2009

Best book I've ever read for Product Management and Marketing


Lateral Thinking is undeniably the best book I've ever read on product management and marketing. 

It addresses three of the biggest challenges for today's Product professionals. 
  1. what do we build? 
  2. how do we build and market the product?
  3. knowing what we know how do we get further down the product "todo/feature/wish" list with the scarce and competing resource demands in the organization. 

While Lateral Thinking techniques bring value to #1 and #2 it brings phenomenal value to #3 where most organizations struggle even after figuring out #1&#2. 

Lateral Thinking Techniques

  1. Alternatives: Use concepts to breed new ideas
  2. Focus: Sharpen or change your focus to improve your creative efforts
  3. Challenge: Break free from the limits of accepted ways of operating
  4. Random Entry: Use unconnected input to open new lines of thinking
  5. Provocation: Move from a provocative statement to useful ideas
  6. Harvesting: Select the best of early ideas and shape them into useable approaches
  7. Treatment of Ideas: Develop ideas and shape them to fit an organization or situation

Try it out, always yields amazing results for me :-)

Monday, April 27, 2009

Models - Not the ones your're thinking about


As product managers and marketers have you ever been in situations where you're starting to draw graphs or tables, using analogies, trying to visualize something that cannot be directly seen, trying to infer patterns from data? Well chances are if you dug a little deeper on Google for what you were discussing there's most likely someone who's done a study around it and come up with a model for it. So why reinvent the wheel?

There are obviously some caveats to this,

  • There should be a good enough usable model around what you're looking for not a model someone just threw together one night in a highly caffeinated state (well then again maybe you do)
  • In general they are from reputed sources, vetted and widely accepted (this ones not necessary though)
  • That they are extensible without rendering them useless
  • Also need to watch out that it really applies to the problem space or statement that you're trying to make, and it does not overly complicate things.
Here's examples of ones I've used in the past;

Now a lot of these can be used readily and presented on in meetings while others are more for hashing out your own thoughts or getting a convincing case going where you see a pattern and are looking to guess the outcome. Models or frameworks fit right in that sweet spot, where someone's spent serious time and effort (sometimes their entire life) researching and building that model. So the next time you get the urge to create your own model to describe something check online there might be a model out there ready to use and extend.

Newbie PM hint, models help you become more informed. So you dont walk into meetings and throw out ideas like wouldn't it be cool if we identify our customers by market share and market growth. Wonder if anyone else is doing that ... well ever heard of the BCG Matrix :-)

Needs to be complemented with .. Brainstorming alternatives .. Experience and learning .. but you can rarely beat a good proven model.

Monday, April 20, 2009

The Product Management Manifesto


Recently got forwarded this link to a product management manifesto that has been drafted by Brain Lawley, CEO & Founder of the 280 Group LLC. 

Now I havent heard much about manifestos in the software or product world, so pardon my ignorance the only other manifesto's I'd heard of were the ones we were taught in History classes around political movements.

and more recently the "GNU Manifesto" and very recently the "Agile Manifesto". Though I actually think that the agile manifesto is a pretty crisp presentation of agile principles and beliefs (if I may call them that) and in many ways powerful enough to alter your way of thinking around creating and delivering products to the market.

Started reading and the thought crossed my mind, is there really a need to  define product management through a manifesto though. 

Maybe its a brief research study worth having to see how many job roles have been defined through manifestos. Need to do my Google search on this pretty soon.

First off I think the manifesto has captured the essence of S/W Product Management really well. The reason I prefix the manifesto with the term "Software" is because time and again I keep reminding myself that product managers also exist in other industries like CG's, FMCG's, Pharma etc. They've been around in those industries way longer than there have been PM's in software. So us S/W PM's trying to define the manifesto for all of PM land sounds a little too far fetched.

After reading through the manifesto here are the 3 extracted points that I think would be part of my PM Manifesto if I were to draft one. Since I found them in there, this manifesto has my vote. 
  • Im dedicated to bringing great products to market. Products that delight my customers. Products that are massively profitable for my company. Products that help change the way people work and live.
  • I have a strong vision for my products and develop winning strategies that align with my companys goals and ensure that our investments of time, money and energy are well-spent.
  • Iam the voice of my customers and represent them in every critical decision that is made.

Having given it my vote, I'd also like to highlight that the last three points in the manifesto seem to be in there more for effects. You could apply them to other roles as well. But hey that's just my opinion.
  • I refuse to settle for mediocrity ...
  • I believe that Product Management is one of the toughest, yet most rewarding jobs ...
  • Though I have all of the responsibility ...

All in all I think its a good manifesto for a SW PM to identify with their role and help the organization understand this key role better. 

Monday, April 13, 2009

A healthy living breathing Product Roadmap


Having recently gone through a major Product Roadmap definition exercise I thought it would be cool to share some thoughts on product roadmaps and get feedback. While there are tons of great posts out there on how to create product roadmaps it's unbelievable how many Product Managers are developing products with no roadmaps!!

Product roadmap documents do not have to be fancy slides with great graphics. In fact good roadmaps are so crisp and clear that they can be captured in one slide or page of your favorite document creation tool. Dont be fooled by the simplicity.

Agile products and teams need roadmaps too. Just cause you're developing in iterations does not mean you become a backlog factory and lose sight of the big picture.

Mature products with very little new feature velocity need roadmaps as well. Little velocity means you have only so many resources and shots to fire in each release, imagine spending those on activities that are not aligned with your long term product roadmap.

Knowing our stack ranked list of 300 product enhancements does not mean you know your roadmap. A stack ranked list of Enh. is a very good place to start, but a roadmap is so much more than that and should be more strategic. It should be able to tell you how you will be navigating the course towards your product vision.

Use roadmaps to build consensus and get key stakeholder buyin. It's useless complaining that half-way through a release my roadmap always gets over ridden by one of the Execs. What that tells me is that your roadmap is not aligned with the overall corporate or business strategy and was not bought into by the stakeholders.

Ensure that you continously validate items you place on the roadmap with your long term product vision. Reality is that you'll have to deviate from the roadmap every now and then, however the constant validation will help ensure that you either tie it back or ensure that the deviation is not a huge sidetrack from the original vision. 

(special case of point just made above) Avoid letting the next big sales deal define your product roadmap. Yeah right, easier said than done. This one's the toughest one to combat, contain, accept ... use your favorite term here. However be prepared for the ultimate reality that revenue is a key engine in a for-profit organization and will often trump other items on the roadmap. I think the key here is being open to such mega deals and then not letting them completely dominate the scene, but rather harnessing them in the right fashion to achieve your longer term vision. Remember with mega deals come resources to get things done. Thats good news for most resource strapped product teams.

Never get into the "We know what we're building here, so we dont need a roadmap" syndrome. Its the first sign of an internally focused product creation cycle that ultimately will drive the product aground.

For larger more complex product lines, ensure that frequent cross-product roadmap validations take place. This ensures that functional overlap areas, commonly shared areas like platform, cross-team impact areas like internationalization are clearly defined and rationalized as part of the roadmap.

A product roadmap to me is a high level document that lays out the product plan for a given timeline (near-term or long-term) with clearly defined milestones (releases) of how we'll be able to navigate from where we're today towards achieving the vision.

3 Key Takeaways for Product Roadmaps

- Always create product roadmaps and ensure that they are living breathing documents that are revisited atleast twice a year.
- Get key stakeholder buyin for your roadmap items. Ultimately roadmaps have to be aligned with corporate and business strategy and exec buyin is a large part of that.
- For every item placed on the roadmap ask the question, how does this help us achieve the long term product vision