Sunday, May 11, 2014

Moving Blog to LinkedIn Influencer

Given the incredible power we're all experiencing from the Linkedin Influencer program, I've decided to move this blog to that platform but will keep this site running until the transition is complete.

So head over to my Linkedin page to find the newest blog posts - www.linkedin.com/in/philmontgomery/

Monday, September 30, 2013

Product Managers – What Do They Do?

A big challenge for any Products or R&D organization is deciding which markets to enter, what product features and capabilities to add, and when. We can’t do everything customers want, and they don’t always know what they want, or what is possible. As Henry Ford famously said, “If I'd asked customers what they wanted, they would have said ‘a faster horse’."

Product Management evolved as it became obvious that coordinating the process to decide what needed to be built (and in what order) was a full time job.  Every organization has a slightly different perspective on how Product Management is defined (Microsoft uses the term Program Managers). One of the unique (and some would say crazy) aspects of Product Management is that it’s not a degreed program at any college – go figure! While Product Management terminology can vary by organization, the basic best practice for this profession is consistent in all technology companies. In this article I’ll cover my own observations from a lifetime of Product Management.

Product Management is essentially a business alignment function between market requirements and development resources. This is often expressed as delivering the right product to market, but in reality what Product Management does is align the R&D side of the business with market requirements - it's that simple.


Product Managers ensure that products have the features and capabilities to meet business objectives. Those objectives are usually revenue targets, but can include other measurements like market share, number of users, downloads, etc. Product Managers primarily achieve their defined goals by influencing other parts of the organization, such as Marketing, Sales, and Engineering, although Product Managers typically have no authority over these parts of the organization.

A commonly used definition of Product Management, the "product CEO", is completely inaccurate.  The term "CEO" implies direct control of resources and people, but Product Managers do their job strictly by influencing the other groups in the organization engaged in product development and delivery to market, especially R&D.  One of my past colleagues said it well:

“The ‘product management is the CEO of his/her product line’ statement is not correct. Being able to achieve your means by influencing others is the most important skill for a product manager in a large, multi-product organization. My current company offers hundreds of different products, so I find myself spending more time influencing my company’s executives (as to why my business needs more investment and incremental funding) and sales leadership (as to why their sales teams should be selling my product and making loads of money rather than selling something else) more than I spend influencing my engineering team why they should build something. “

If I were a member of R&D, what should I expect from Product Management?

The most visible aspect of Product Management is defining the product roadmap and prioritizing features - using a deep understanding of many factors including the marketplace, competitors, core competencies, customer needs, partners, and so on.  

However, a roadmap and feature prioritization is useless to R&D (or any corporate department) without understanding how a release fits into the overall product business plan and what’s needed to achieve market success. Product Managers must establish a product vision and strategy that fits into the overall company vision, and be able to clearly articulate that vision to everyone they work with.  They must be able to explain where their product/feature is heading and how it helps the company win — and be able to distill these complex concepts down to a single slide and a simple elevator pitch.  Product Managers also need to ensure that every feature and capability they request fits into the product vision and strategy.

Once the overall product strategy is in place, Product Managers bring to R&D a deep understanding of the market’s requirements due to the close relationships they’ve established with Sales, SEs, partners, and customers.  They gather hard data (not just opinions) from sources such as detailed analyses of historical sales data, analysts and market surveys.  Instead of saying "the customer needs this," they say, "Customers need this, ABC Corp is a perfect example, and here is a list of their needs from my interview," or, "the data shows that x% of customers need this." Nothing in the market is absolute, but there are plenty of useful data points. My own personal favorite is blind win/loss analysis to truly understand what drives the purchasing decision and to identify product gaps.

The picture below is not exhaustive, but lists the main sources of data to discover potential features:


In this process, Project Managers must prioritize features based on which best support the product strategy and enable the product to win more market share. The criteria they use to make this evaluation can vary depending upon the market, competitors and product maturity.  As an example, product performance is often a key differentiator, especially in the early days of a product lifecycle.  However, over time, competitors often improve their solutions until they become “good enough,” and the market then differentiates in other ways. For example, in the mainstream motor vehicle market, all offerings give good enough “performance” in terms of top-end speed. However, miles-per-gallon is rapidly becoming the key differentiator due to the shift in the market created by the high price of gasoline.

Product Managers need to be top of changes in the marketplace and buying criteria due to this dynamic environment.  The key is to identify patterns that support the business case and product strategy, not to simply react to a single data point. Additional factors to consider when evaluating feature candidates include:



Unfortunately, there are often multiple possible paths to product success, and it can be almost impossible to prove which path is right — or wrong. If there were always one clear answer, there would be no such thing as a failed product by any company in any market.  Product Managers create a hypothesis based on the best possible information. When there are multiple answers, they pick the one that has the most likelihood of success and align everyone around that path. They need to be able to explain their hypothesis as clearly as they can to articulate their product vision and strategy.

Members of R&D, hold your Product Managers accountable for their rationale for feature prioritization. An easy way to represent prioritization rationale is to use single letter codes in the prioritized list, for example:

·         D – Differentiated Capability
·         C – Competitive Blocker Removal
·         R – Cost reducer

As mentioned above, Product Managers must also lead product strategy by aligning the non-R&D parts of the organization, such as Marketing, PSO, SEs, and Sales, so that every member of every group can communicate the great capabilities of the product with customers, partners, resellers, analysts, etc.  A key communication technique is holding a weekly one-hour meeting (known as the Product Action Team, or PAT), which includes key non-R&D personnel. Without consistent communication to maintain alignment, product-related activity can become disjointed or siloed, damping down success.

Product Managers must be inventive problem-solvers to get their product to market and build market share.  If R&D is blocked on development because they need a server, additional headcount, or any other business-critical asset, the Product Manager is the one that’s going to be heads-down to remove the roadblock.  In some cases a Product Manager must take the ‘ask forgiveness, not permission’ approach, using his best judgment and possibly a corporate credit card, for example, to eliminate an otherwise immovable roadblock. 


The key to success as a Product Manager is a close and supportive relationship with R&D, but part of any successful relationship is a healthy measure of creative friction and tension.  R&D, don’t be afraid to push a Product Manager for the market data you need or to challenge their assumptions. Effective collaboration between R&D and Product Management will always yield better results and a more successful product.

Sunday, December 30, 2012

Multi-Product Portfolio Planning


One question I hear often is "How does product planning change in a multi-product environment?". While all of the key tenets of Product Management and Product Marketing continue to apply to ensure that you are building the right individual products, and taking them to market effectively, there are fundamental differences.

When faced with multiple products, the first factor to consider is that they all fit within the corporate vision and strategy. If products don't fit into the established strategy, you need to ask some very hard questions - while these businesses bring in revenue, they may prevent achieving the established goals and vision by distraction, consuming resources, and confusing customers.

When considering a portfolio, I often like to ask everyone "Should we build Ferraris?" - and the answer is a universal "NO - building Ferraris does not fit into our established strategy".  But this question and answer establishs that there is a line of what the organization should and should not be building (and that there is a strategy) - and you can zero in closer to establish where the line actually exists.

Assuming all products fit into the established strategy, the next big task is to allocated resources (R&D, marketing, go-to-market) based on product/market potential, and not on current revenues. One of the most erroneous statements ever made by a Product Manager is "my product is profitable so I am untouchable". Companies need not just profitable products, but products with high growth potential.

All companies have limited resources to invest and too many fall into the trap of allocating based upon product revenue or relative profitability e.g, let's take a look at a XYZ Corps revenue for a diverse product portfolio.




The above chart would lead many companies to make similar resource allocations - as we know, P&L is the common management mechanism in large companies and headcount is allocated based upon the product revenue and forecast growth.  However, resource allocation should be based on overall market opportunity and product managers often fail to make difficult decisions to prioritize investments effectively across multiple products.

There are numerous tools to help make these prioritization decisions, but they all acknowledge that  there are many factors that need to be considered, such as annual growth, market share, competitive landscape, route to markets, core competency, product maturity, etc.  One of the commonly used tools is the BCG Matrix, applying a scatter graph to rank the products on the basis of their relative market shares and growth rates, with sales revenue shown by the size of the bubble e.g: XYZ Corp product portfolio yields the following results:




Using this analysis we can start to pose some very interesting questions?


  • Should be investing more in Product 3? We have a great market share and high growth potential.
  • Is Product 2 viable?  Can we do better here? 
  • How much investment should we make in Product 1? We already have a great market share with lots of revenue.
  • Should we exit Product 4?

The BCG uses four terms to describe each of the quadrants:

  1. Stars are products with high market share in rapidly growing markets.  These businesses are often going to need additional resources to capitalize on their early success and are not yet profitable.
  2. Cash Cows have high market share in slow growing markets.  Look very closely at investment levels here and only do what is needed to maintain the business.  Over-investment in Cash-Cows is a huge problem that Product Managers must address, but this can be a very difficult and emotional process.
  3. Dogs have low market share in slow growing markets, and often break even, but should likely be sold off. Again, this can be a difficult and emotional process.
  4. Question Marks typically have low market share in markets growing rapidly.  They have the potential to become stars and ultimately Cash Cows.

One of the points made with BCG planning is that any successful company has a combination of Stars, Cash Cows, and Question Marks - you probably have some Dogs too, and they should be sold off if possible.  But the point is that not every product can be a Star, and all products go through different quadrants as they mature through the product lifecycle i.e. they start out Question Marks, become Stars, and then end up Cash Cows.

How to calculate product market share in another interesting topic, and many companies use PPH or PPPH analysis, where:
  • P = Product Line Coverage - what % of  market does the product target?
  • P = Presence - what % of the time do we get to propose our product?
  • P = Preference - what is the % share of market within our own channel partners?
  • H = Hit Rate - how often do we win the sale (%)?

P x P x P x H = MS

Multiplying PxPxPxH gives us a "market share" factor that can be used to evaluate the effect of different market strategies on the market share.

The BCG Matrix is just a tool, and like any tool, has positive and negative points. You can use many different methods the point is that you consider all the relevant factors when making portfolio decisions, and move investments to maximize overall returns.

The final dimension here is that successful portfolio planning relies heavily on effective relationships across product groups and a healthy dose of pragmatism. Here is where the organization with the best relationships between products teams is going to win - and the organization with the most silo-ed approach will likely fail. Nobody likes their product to be called a cash cow or a question mark - everyone wants to be the star - but we need to be realistic and look beyond our own products and work together to do what is best for the complete portfolio and entire company.

Sunday, July 1, 2012

Post-PC - Companies that don't evolve will be gone over the next 10 years.


The term " Post-PC" is everywhere and nobody is doubting that we've entered the next phase of computing.  But do we really understand the effect that this is having on our industry today, and how it will shape the future?  I think not.

Post-PC is really an incorrect term - the PC (Intel/Microsoft) is not going anywhere and will continue to be a valid and viable choice for many industries and consumers (I'm writing this blog on a Windows 7 PC).  The real change is that the PC will no longer dominate - the future does not belong to any single device - rather it will be a heterogeneous mix of PCs, Macs, Tablets, Smartphones, Chromebooks, Android, iOS, Intel, AMD, and devices that have yet to be invented.

The velocity of device innovation is accelerating, and trends such as BYOD (Bring Your Own Device) have forever changed the face of enterprise computing. Surprisingly, even regulated industries such as Healthcare, Finance and Government see the rise of BYOD as inevitable.  Even if these organizations try to (mostly) standardize on a single device, they admit that BYOD in just one organizational pocket dramatically increases complexity. The enterprise application and data delivery landscape is going to be multi-device and multi-platform.When CIOs ask what will be "the new PC", they are (falsely) applying thinking that has developed over the last 30 years and deduce that there will be single device that dominates - that just isn't the case. 

The face of Enterprise computing is forever changing and there is no going back to the 'simplicity' of a single device - the Wintel PC.  Just as 30 years ago there was no going back to the minicomputer.  The minicomputer was born in the 60's and ruled until the mid 80's, when PCs started to trickle into the workplace.  The PC emerged from the new low cost microprocessor, and succeeded in business due to factors such as the lower cost, Local Area Networking delivered sharing, and freeing users from relatively inflexible IT departments.

Ironically, many of the issues leading to the demise of the minicomputer are also drivers to the Post-PC Era - IT departments are seen as not being flexible or rapid enough to provide users what they want/need, and the new devices are much cheaper.  The same core drivers around cost and flexibility continue to affect change. None of the minicomputer vendors survive today, and there was not a technology problem, as PCs were much easier to build and sell than minicomputers.  These companies were unable to shift their business models from one era to another, and the only exceptions were those who broke the rules.  IBM created a PC in under a year using off the shelf CPU and parts (even the operating system). From http://www.economist.com/node/7226000:

The IBM Personal Computer running DOS 1.0 In many ways, the PC triumphed due to the very un-IBM way in which it was developed. When IBM's previous attempts at a PC failed to sell, being too expensive, a “skunk works” team of engineers was convened in Boca Raton, Florida. The team did not report through IBM's stifling bureaucracy, but directly to the top of the company. It was given a year to devise a low-cost machine. 


“The people doing that work weren't talking about it, there weren't any business cases done, there wasn't any annual budget review,” explains Lewis Branscomb, IBM's chief scientist from 1972 to 1986. “IBM did a lot of radical things—and that proved to be very successful.”


To meet its ambitious goals, the team bucked two IBM traditions. First, instead of using only IBM parts, the team chose off-the-shelf components. Second, rather than keep the design a secret, the team made the specifications open, so that independent software developers could flourish. When the PC finally launched, IBM expected to sell 250,000 units in five years. In the event, it had sold nearly 1m by 1985.


Anyone working at a company delivering enterprise products today must deeply understand the change to the Post-PC Era. Analyze reasons for the ultimate demise of the minicomputer market - the same lesson has played out in hundreds of industries and there are plenty of great examples. Help your organizations understand that a huge change has started and product/technology is just part of the solution. Once your colleagues understand the ramifications of this shift, they'll be more likely to evolve to meet this new environment.  Companies that don't evolve will be gone over the next 10 years.

Monday, April 9, 2012

Does your Product have Safety Guards?


One important aspect of Product Design is ensuring that your product includes what I call "safety guards".  Safety Guards prevent any product from being used in a way that causes damage to the operator - and exist commonly in shop machinery.  Safety Guards prevent the operator from either deliberately or accidentally doing something that can cause them damage, without reducing or limiting functionality.

Software products are no different - expect that instead of causing physical damage to the operator we need to guard against doing damage to the technology environment - such as data center, network, end device, and so on.


Many products forget this part of design and testing, and we end up with solutions that accidentally or through deliberate misuse create havoc with our customers or business.  Customers may try to use your solution in a way that it was not designed, and then demand support and product modifications to fit their unsupported use case. 


While startups and early stage products may seek every viable use case in a search for a viable product and market, mature products need to guard against being pulled into fringe markets where there is not sufficient available market to sustain the product, or being pulled in a planned direction too  early. Don't arbitrarily install safety guards either - look for active situations you want/need to avoid, rather that grossly limit the product - you don't want to restrict customers from finding genuine use cases that had never been considered.


The easiest way to resolve this potential problem is to consider ways that the product could be misused, and design the interface to gracefully prevent these situations. Monitor sales and support calls and look for patterns where you are being pulled into directions that don't make sense. Design the safety guards just like those of machinery - don't limit the functionality, be simple, and just guard against things where the operator may cause damage to themselves.

Saturday, December 31, 2011

Aligning Strategy

Without a doubt the most stressful in any organization is  "Strategy Time" - the annual strategy process that culminates in a key presentation to the CEO and/or board of directors. The idea is to define the overall organizational strategy for the next year - where to place the bets, what markers to go after, etc.

There are many reasons why this process is so stressful, but primarily the goals of the process are misunderstood;  too many people focus on unveiling the smartest/best/most clever strategy.  The mistake here is that strategy must be presented with organizational alignment to be successful, and stakeholders must be brought along on the journey.

Good strategists understand that they must bring the organization along on the strategy journey and determine all the stakeholders needed - they go into the final meeting with everyone in alignment, ready to move to the execution phase.  In many cases you'll need to be an amateur psychologist as you 'herd the cats'.  As an example, you'll need to include elements of competing strategies to align certain stakeholders - good strategists are pragmatic and know which elements matter, and which to let go.

Although I hate to use the term, this can be mapped to "politics" and also to our basic human needs to interact at a social level. For politics, remember that there are good and bad politics (although the definition may change at the hands of who wields the influence), and they are a part of every organization.  I like the Wikipedia definition:

Politics (from Greek πολιτικός, "of, for, or relating to citizens") is a process by which groups of people make collective decisions. The term is generally applied to the art or science of running governmental or state affairs, including behavior within civil governments, but also applies to institutions, fields, and special interest groups such as the corporateacademic, and religious segments of society. It consists of "social relations involving authority or power"[1] and refers to the regulation of public affairs within a political unit,[2] and to the methods and tactics used to formulate and applypolicy.[3]

When the CEO receives the presentation they'll monitor the body language of the other attendees and immediately know the degree of alignment.  Disagreements and arguments in the presentation will lead the CEO to see the strategy as "half-baked", or the presenter as lacking preparation or leadership.  Behind the scenes the CEO will also reach out to key stakeholders behind the scenes and ask for their opinions  e.g. key technical staff often have a say in many software companies. And in many cases the CEO keeps their observations and conclusions private.

If you read this, roll your eyes, and think that this is a bureaucratic process only needed in large organizations - you'd be wrong.  All organizations, big or small, agile or waterfall, have to be aligned to move forward towards a goal.  Failure to align leads to implementation failures and missteps.

Similarly, when organizations are dictated a top-down strategy they often reject it if certain elements don't make sense or feel a lack of disempowerment.  So an tops-down strategy goes through a similar (inverted) process of alignment or eventual rejection. In Steve Job's  recent biography the claim is made that his reports often ignored his directions if they felt it didn't make sense.  I call this the "passive/agressive" organization where everyone nods in agreement, but as soon as the meeting ends they ignore the strategy and follow their own directions.

The worst outcome is an organization without alignment - nothing is more poisonous or counter productive.  I've seen the outcome here in both startups and big companies, and it's always ugly - you end up back at step one trying to find a strategy  where alignment can be achieved.

The bottom line is that any technology company is a social organization and successful organizations are aligned and work together on a single, well understood strategy.  The process to get to this point is often difficult and time consuming, but the outcome is well worthwhile.

Never present something important (like organizational strategy) unless you've put in the hard work to align the stakeholders and know the outcome.

Saturday, October 8, 2011

Management Styles and SciFi Movies

(Note:  This post may not make sense unless you have seen the movies "Independence Day" and "Battle: LA").

A recent alien invasion movie, Battle:LA, is quite different to traditional alien invasion movies such as Independence Day.  While the overall theme of invasion stays the same, the difference is how the problem is approached and how the day is saved.  These movies draw a great analogy to contrast how large companies operate.

Independence Day is the traditional "top down" movie, where the president himself decides the strategy, along with an elite top scientist, and work out a plan to stop the aliens.  The people at the top also join the fight, and the president even jumps in an F18 fighter to join the final attack on the alien mother-ship.  The movie very much focuses that that the day was saved by the people at the top doing almost everything themselves, from the strategy to the execution.

Battle:LA offers a totally different perspective, where the story is told completely from the perspective of a marine platoon on the ground.  The platoon is made up of a diverse group of individuals who are very flawed in many ways - the main character is trying to leave the marine corps as the movie starts as his body is starting to slow down with age (which I can relate to :-)).  There are no generals or politicians in the movie, and the focus is on the platoon going about the mission they have been given.  However, as circumstances unfold, the platoon sees an opportunity to defeat the enemy, and without being told, they take the opportunity.  The platoon shows intense teamwork - everyone knows their role, and they come together to surmount incredible odds.

These two movies provide a contrast in how companies operate:

Independence Day companies:

  • Define the strategy at the top
  • Hire star players at the highest level
  • Operate the company from the top down
  • Lower level teams constantly ask permission and are monitored closely
  • Execs step in and define tactics plus get involved in execution


Battle: LA companies

  • Define the strategy at the top
  • Hire star players at all levels of the company, from the bottom up
  • Focus on building great teams at the execution level
  • Operate the company from the bottom up
  • Execs keep away from tactical execution and let the lower level teams win.

Without a doubt Battle:LA offers a more realistic way to operate a large company - company executives  define the overall strategy and then get out of the way and let lower level teams win.  We are living in an extremely dynamic and turbulent time, and no single person at the top can understand all the factors affecting outcomes.

When lower level teams are giving the freedom and space to execute they can achieve truly amazing results. Many of my most productive and successful times at large companies have been when I was working on products that lacked executive visibility.  We knew the overall company mission, and were able to execute with small teams - the lack of interference gave us the ability to focus and deliver.

If you haven't seen Battle:LA then sit through the movie and consider how much the platoon achieves and how this applies to your company. Great companies enable their lower level teams to go out and win.