Monday, September 13, 2010

Platform Product Management

One of the most important Product Management roles is that of Platform Product Management - being responsible for the key foundation of the product(s). Often this role is not broken out separately but may be encompassed in your role as head of Product Management for one or more products. This role is critical as it exposes one of the primary challenges of product management - the trade off between foundational elements (architecture) versus customer facing features. Engineering wants to know how much resource to contribute to next generation architecture, versus sales people who are screaming to just add a certain feature so they can close $$$$ this quarter.
This challenge is prevalent in enterprise technology companies today, as many products were built on platforms that are 10+ years old, and fundamental limitations are now becoming obvious. A good example is the many products built on a 32 bit custom operating systems that are approaching scalability and performance limits and need to move to a new generation operating system/environment - but after 10+ years of features in the 32 bit OS, a wholesale move is almost impossible.  What to do?
Firstly, Product Management must ensure that the organization is aligned behind a common vision.  If the organization cannot with confidence and consistency state where it will be in 2-3 years, then you will suffer from incrementalism, and a schizophrenic product, plus at some point miss out on a strategic shift.  I am a huge believer in the visual product vision as outlined in the post Do you have a visual vision? If an organization, including sales, engineering, marketing, management, does not have a clear product vision 2-3 years out, then Product Management is failing.

What is happening in the industry and the customer installed base is a critical element of the vision - obviously we are in a multi-dimensional transition - from in-house data centers to hybrid and then outsourced virtual data centers, from in-house services to XaaS, from Windows desktops to a heterogeneous device landscape, and from a hardened DMZ approach to security, to 3/4G connected devices talking to multiple application sources. Attending infrastructure events like VMWorld is critical to understand where enterprises are heading.

The next step is to analyze the current business and understand the strengths, weaknesses, opportunities and threats (SWOT).  While this is the start of a longer business plan for each product or the product line, you should be able to identity areas of opportunity for revenue. Even a fully mature product always has opportunities to penetrate new markets - often called a Product Line Extension (PLE). And of course if your vision calls for movement to a new platform/architecture then the vision and roadmaps are going to need to explain how this transition will occur.

A good example of a Product Line Extension is Citrix adding the Secure Gateway as a feature to XenApp (then called MetaFrame). Secure Gateway allowed XenApp to be used securely across the internet for remote/travelling workers, partners etc - the feature was so successful it transitioned in the Access Gateway SSL VPN, and has become a key capability to drive revenue across multiple Citrix products. Another example is Novell's Netware - a legacy product that has been declining for many years, but still generates hundreds of millions of dollars of revenue - so Novell is obviously still delivering value to specific segments - whether geographic, industry, size etc -success is likely measured in terms of reducing the decline.

A good way to understand what people are using in the current product is through a "dial-home" type of service, such as Microsoft has implemented in Windows.  Of course this needs to be an opt-in service, but if you explain to users it can we used to make better products, no confidential data is transferred, and many will participate.  Imagine being able to know exactly what features, configurations, performance, user counts etc about your product in the field.  Imagine how this can help you prioritize capabilities of a new platform.

Obviously the current quarterly and annual goals affect product trade-off decisions - there is nothing wrong with sacrificing long term for short term revenue if the company needs immediate revenue.  There is no use having the best next-generation architecture if you run out of money in the meantime. The takeaway here is to accurately label why you are doing every item in a release/sprint e.g.  use codes in the backlog/PRD/MRD:

S - Strategic - moves us towards vision
T - tactical - doesn't move us towards vision
R - Revenue - immediate revenue generating feature
E - Extension - moves the product into a new space/segment.
B - Bug fix

A single feature may have a combination of codes and the main point is to get united in a common understanding why something is being added to the solution. Your biggest challenge (as always) is going to be saying no to sales people who see revenue in a space that just isn't strategic or big enough for the company, and ends up a distraction.  This is where the vision comes in, and you must help sales understand that by focusing on the vision they will end up better off by having an easier to sell solution/product, albeit over a longer term.

One area that needs to be specifically called out is the transition to a new platform/architecture.  The time to start a transition is not when the main product goes into decline, but while still growing.  A new architecture/platform can be tested or validated in smaller/different market segments without jeopardizing mainstream revenue.  Citrix purchased their Online Division while traditional products were still increasing in revenue (as they still are), and it provided a services based delivery mechanism to address new market segments and is now one of the top ten SaaS businesses in the world - and at the same time they were able to move from a 32 bit to 64 bit platform, increasing scalability and performance.

If your long term vision does call for a complete cut over in architecture, for example from deployed software to service, one of the best paths forward is to acquire a smaller company that has implemented the new architecture, and give them the resources to succeed.  Your customers will be much more tolerant of an acquired service not having all of your capabilities in the initial release, and will look to an integration roadmap.  If you can successfully develop a new architectural offering internally, proper positioning is critical so customers don't expect all the capabilities of the main offering.  Intuit has done a great job here by positioning Quickbooks Online as a very clear sub-set of capabilities of the main Quickbooks offering.

The Platform/Feature trade off is like a teeter-totter (called a seesaw in the Commonwealth) - but without a vision, clear data on the product business, and an understanding of the current business objectives, you can't effectively make tradeoffs. Otherwise you're just blindly moving to one side to the other.