ProductCamp Vancouver 2011 Retrospective

On Feb 12, I had the pleasure of attending ProductCamp in Vancouver. (www.productcampvancouver.org) PCV11 was my second product camp – also having joined ProductCamp Seattle back in October 2010.

This was an extremely well attended event, particularly given it was the first such event in Vancouver. Attendance was a diverse mix of new and experienced product managers, aspiring product managers (students) as well as folks from other related functions such as development, management and sales. A wide variety of types of companies employ the attendees: from independent consultants, to startups to giant national or mega-national companies.

Here are some of my notes on PCV11, and the product camp experience in general:

• Networking & meeting your colleagues is what I find most valuable in Product Camps – bring your business cards! I talked with several great folks that I am unsure how to find them again.
• The content and quality of the sessions can  vary – and what is ‘good’ or relevant to me could be completely different for you. I found at least one gem of information in every session I attended.
• Move on if you don’t like the session & create your own if there’s a topic you want to see covered.
• Bring lots of energy – product camp can be a long day!
• Get involved! I helped a little on the day-of & it was a great way to meet people.
• Even though we all have personal commitments, ProductCamps are well worth giving up a Saturday for.

There will definitely be more product camps in my future & I recommend that you find one too

Thanks again to the team of dedicated volunteers who pulled the whole event together & the generous sponsors who helped keep the event free for all attendees.

Did you attend Product Camp Vancouver? What was your experience?

Improving Product Profitability

Revenue minus expenses equals profit. It’s a simple equation, but not always simple to influence.

As a role that is closely related (and frequently within) the marketing team, Product Managers & Product Marketers can get caught up in focussing on efforts to drive more revenue: supporting customer meetings for new business development, training the sales team, developing collateral, selecting the best feature that will make us the most money etc.

Spending some time focussing on the other side of that equation can also create a direct boost to the business cases of the products we manage. As a hardware product manager, the products that I work with have an actual cost of components, plus other overhead/indirect expenses which are allocated against the product. Expenses also of course come in the form of funding the development team to create the product as well.

Over the past few months, I have been systematically identifying the largest cost contributions to my products and ensuring they are reviewed/justified by the internal team responsible for that line item.

Through this scrutiny, I was recently able to achieve a meaningful improvement in the profitability of the whole product. That of course meant gently persuading internal stakeholders to reassess their assumptions or improve the costs being charged to my product line.

A similar effect can also be achieved by ensuring that development expenses are only being spent on feature developments that meet a market need. Not recommending that you try to push your developers to do more with less – although that may save some $$, it will aggravate your best ally!

The beauty of improving the cost basis on the expense side of the equation is that is provides an immediate boost to the product profitability (including revenue from existing customers). Improvements in this regard flow directly to the bottom line.

How have you improved your product profitability?

also see: Influencing without Authority by Jennifer Doctor http://outsideinview.com/2011/01/26/11-ways-to-influence-without-authority/

When a shortcut, isn’t

Continuing from last week’s theme of trying to ensure that product launches are successful from the beginning, this week’s theme is about taking shortcuts in your products — and when those shortcuts backfire.

This is an experience I have lived through over and over again as a product manager. Imagine the scenario: a key launch date or customer milestone is approaching with the deliverables incomplete, and the team needs to make the choice between communicating a slip (or missing the milestone), or deciding whatever is available is ‘good enough’ and getting it out the door.

Many times, in my experience, taking such a shortcut backfires and causes more work and damaged relationships in the long run than sticking to the original plan.

For example, if a customer is hungry for a software release and they are sent a build which “should” be okay but isn’t completely validated. When the customer inevitably stumbles across a bug which should have been found, everyone is unhappy and has to go into scramble mode.

In another example, skimming through checklists and other control points during factory setup of a new product can be tempting, especially if many similar products have been released previously. Fixing a factory issue during mass production could be downright catastrophic.

That is not to say it is always easy to decide when a ‘shortcut’ is okay and when it is not okay – nor is there always a ‘right’ decision. 

 Helping the team to decide when a shortcut poses an acceptable risk (vs whatever demand is pushing for the shortcut) is part of the “Art” of Product Management. Here are some of the questions I ask when faced with such a decision:

• What will go wrong if this shortcut backfires? (upset customers, re-doing steps)
• What will go wrong if we postpone  the deliverable so we have enough time to ‘do it right’? (missed revenue, customer relationship)
• What is there to gain by insisting that no shortcuts are taken? (better customer relationships, if nothing – maybe a process can be streamlined)

Have you taken a shortcut in your products which has been wildly successful? Or do you find that shortcuts are a shortcircuit to ensuring you need a do-over?

Getting it right the first time

 With a manufactured product, there are hard costs associated with building the product and you don’t usually get a second chance at launching a product; nor can you easily ‘patch’ a manufactured product after launch.  With a hardware product, fixing an issue could add hundreds of thousands of dollars in new tooling costs. I’ve even worked on some projects (cutting edge IC’s), where the rule of thumb to release a design to manufacturing was $1M. Marketing launch costs are over and above that.

It would be simple to say that software products are ‘easier’ in this regard, as they can be taken through a beta period or receive critical update patches after launch. (Just how many Windows Updates will I receive?)  However, just like a hardware product, if a software product is lacking in some way, it’s likely to not be as successful in the market as it should have been.

Regardless of the type of product we manage, our goal should be to ensure that our products ‘get it right the first time’. While on the surface, this seems like a pretty obvious statement, in my experience, many products don’t actually ‘get it right the first time’.

In order to get it right the first time, we need to ensure that we have:

• Clearly understood the requirements of the market we are targeting
• Developed a product which meets those market requirements
• Not released a product into the market before it is ready (bug-free, missing features)
• Set sales & customer expectations about what the product does

What are the ways you ensure that your products are the most successful?

Are your products always a “Rev A” or “Release 1″ success?

** This post is expanding on an idea spawned by reading Pranav Desai’s recent post on the differences between hardware and software product management.

http://hardwarepm.wordpress.com/2010/12/05/hardwarepmdiff/

A little about me….

I am an experienced product manager, looking to share some of my thoughts with the rest of the product management world & get some good discussions going.

Unlike many product managers, I’m focussed on hardware products – but there are many similarities regardless of they type of products we manage.