Entries from January 2009 ↓

A business strategy is a set of guiding principles that, when communicated and adopted in the organization, generates a desired pattern of decision making. A strategy is therefore about how people throughout the organization should make decisions and allocate resources in order accomplish key objectives. A good strategy provides a clear roadmap, consisting of a set of guiding principles or rules, that defines the actions people in the business should take (and not take) and the things they should prioritize (and not prioritize) to achieve desired goals.

The only question that falls out of this for me is, does the roadmap come after the strategy or out of the strategy? I am wondering if the roadmap is the communication vehicle for the strategy. I believe your roadmap communicates your strategy and therefore is your strategy.

The article then goes on to tie, through alignment, the mission statement (what will be achieved), vision statement (why people in the organization should feel motivated), value network (with whom value will be created and captured) and strategy (how resources should be allocated) together through alignment. This strikes me as the core of what product management is.

As a product management type who is likely bound by the strategy in place for your organization, do you think it is sufficiently defined for you to be successful or help the company be successful?

There are many comments attached to the article, you should read it.

Image source: Harvard Business Publishing

I found this interesting line reading the December issue of Product Bytes from Rich Mironov the author of Art of Product Management.

Our goal for scenario planning is not to predict the future, but instead to prepare for it: have well-thought-out answers for a handful of possibilities, and practice reacting strategically to outside events.

This is an important point, very important. Change is going to happen and how you prepare for it is going to separate you from the followers. I would suggest that you begin allocating an hour every week to review your roadmap to ensure the strategies and assumptions are still accurate. (Tell me you don’t want one hour every week to think strategy, and I know we can eliminate something from your schedule to find an hour.)

Every week you ask, what could possibly change every week? Consider the following possibilities: a) a new mega customer with a contractual commitment for certain features, b) a senior developer has left the company, c) a natural disaster, d) a competitor launched a preemptive feature into the market ahead of you, and e) a financial market meltdown. I would bet a pretty safe wager that three or more of these happened to you last year. True some of these may be major and some unlikely, but bugs are an ever-present disruption among other daily events that derail your plans.

What can you do to plan for alternate outcomes? We discussed the usage of success statements in a previous post which will define a happy path to success. As I was reminded by someone, planning for success does not guarantee success. Running a simple scenario planning technique on each of your succes statements will help you plan for potential alternate outcomes. The technique states that for each statement to ask yourself the following three questions: 1) what is a possible alternate outcome, 2) what is your recommended course of action and 3) what course of action would you avoid.

This simple technique will provide some comfort that you have run your options through some possible outcomes and show the readers of your plan that success is not guaranteed but you are ready for change. Remember a ‘fail to plan’ is a ‘plan to fail’.

EVERYONE claiming they are strategic. Will NO ONE ever acknowledge that their job or abilities are primarily tactical?  

To an extent this is false. Every task requires a strategy to complete it. If I start my day with an activity to execute a set of test cases, I will need a plan to execute the test cases and this makes me strategic. However, I suspect in the context above she was referring to being strategic in the grander sense of the strategy (i.e. the corporate strategy) and in this case she is right. Meet me on the fence!

Most employees are executing a corporate strategy or more likely something that has filtered down into the product strategy and therefore these employees are considered tactical and there is nothing wrong with this. Remember, without people the strategy does not exist, therefore your tactical roles are just as important. (I am not trying appease either side here or imply there are sides, we are all on the same team, but I sense “being strategic” is state of being important. My observation could be wrong.)

The people who are strategic are the people who are defining a strategy. We know from an earlier post that a strategy is a long term plan which means a Product Manager, who defines the roadmap, is by definition a strategic role. However the problems I see with most roadmaps are they are very tactical-based (putting a feature in your Q3 release is not a strategy) and do not articulate what success means or the plan to achieve success.

In a previous post, I discussed the need to consider primary activities and whether you have sufficient content in your roadmap to build on these activities to create additional value and minimize costs. Your roadmap will not end there, you also need to consider defining various strategies (e.g. competitive, operational, marketing, sales, technology, did I miss any?). These strategies will make up your product strategy and according to Michael Porter, must formulate a strategy that leads towards differentiation, cost leadership, or focus in order to achieve a sustainable competitive advantage.

In future posts I will dig into how product management can influence the strategy behind each one of the components of your product strategy.

Building a roadmap is starting to sound like a lot of work isn’t? It should, done right it is the most important document you can develop. Your product (and career) depends on it.

Product Strategy for High Technology Companies by Michael E. McGrath

One of the key determinants of success for today’s high-technology companies is product strategy–and this guide continues to be the only book on product strategy written specifically for the 21st century high-tech industry. More than 250 examples from technological leaders including IBM, Compaq, and Apple–plus a new focus on growth strategies and on Internet businesses–define how high-tech companies can use product strategy and product platform strategy for competitiveness, profitability, and growth in the Internet age.

I find most roadmaps, which are in a sense a strategic plan, tend to be very development focused. By that I mean it is generally a list of features (with some jazz) plotted out in a time period of 3 to 5 years. This is great but is the delivery of features going guide you to achieve success?

A strategy would be incomplete without mention of the activities that are required for your product to even exist. Value chain analysis, a concept described by Michael Porter in his 1985 best-seller, Competitive Advantage: Creating and Sustaining Superior Performance describes the primary and support activities of a firm or in this case your product.

The value chain categorizes the generic value-adding activities of an organization. The “primary activities” include: inbound logistics, operations (production), outbound logistics, marketing and sales (demand), and services (maintenance). The “support activities” include: administrative infrastructure management, human resource management, information technology and procurement. The costs and value drivers are identified for each value activity.
- Value chain (http://en.wikipedia.org/wiki/Value_chain)

The goals of value chain analysis are to maximize value creation and minimize costs. Sounds very product management like doesn’t it?

As you build your next roadmap ask yourself these 5 questions:

1. Have I considered what the needs of the organization are to build product?
2. Have I considered the processes of the team to build product?
3. Have I considered the operations and distribution needs and processes?
4. Have I identified the buyer problems and equipped the sales and marketing teams to address those with value?
5. Have I considered what changes are required for the professional services (including support, training, etc.) to achieve success?

Remember, the only way to answer these questions is to understand (and document) what success is.

Here is a simple definition of win/loss analysis from Graff Group:

A Win/Loss Analysis is a business-to-business research tool that gives you the highest quality information fast and cost-effectively. We tactfully find out, from the mouths of your current and prospective clients, why you did or did not make a sale.

You have been tasked with creating or updating a roadmap, you have done your diligence to understand the business drivers and you have some semblance as to what it means to be successful. What changes do you need to make to your product to help you achieve the success that you strive for? I suppose you could talk to some customers or root through your inbox for all your feature requests. Just keep building what they ask for, right? Maybe, see assumption below. A big part of being successful is to refine what is working today and make it better. Not so much from a “make faster horses” perspective, but maybe you can extend the reach to a new market or better enable the sales team to win some of the losses with stronger positioning.

It is well documented that your largest market out there is not a bigger slice of the market currently with a solution but the market prospects who seek a solution. How can you possibly engage them without changes that directly enable you to engage them or without solutions that benefit them? Generally the feature gaps or process deficiencies that are identified from your loss analysis can have the largest positive effect on your product. They are also easier to quantify for ROI and are easier to get support for.

The key take away from the win/loss method is to understand: 1) who the prospective buyers are; 2) what they looking for; and 3) what criteria and methods are used in their buying process.

The big assumption in all of this is that your business driver and success statement push you towards new customers and new revenue. If it is customer satisfaction and retention you seek, then maybe you better start looking at those feature requests.

Last two notes on win/loss analysis: 1) it is WIN/loss analysis and not just LOSS analysis; and 2) to understand why you are doing win/loss analysis.

The Product Success Statement is a method to help you define the desired outcome (or outcomes) of your plan. If you recall in my previous post, Success First, Roadmap Second, I stated that for you to effectively document a roadmap (i.e. your plan / strategy) you needed to understand what it means to be successful.

I have based the Product Success Statement concept on the Customer Success Statement concept found here: “The Customer Success Statement” by Bennu Group. The core idea behind this concept is to start with the output of the chain – the successful customer outcome. The Customer Success Statement method will be a great addition to your user scenarios methods. The Bennu Group outlines five directives when defining a customer success statement:

1. Use action statements when describing the customer success statement
2. Clearly define the beginning and the end of the experience from the customer point of view
3. Include a statement for ALL points where the customer touches the business
4. Make sure to consider time
5. Also consider the number of customer actions

To craft your Product Success Statement, you can start by replacing the word customer in the five directives with product to help you structure your statements. Simple enough. Let’s work through a very simple example. To start, we need to identify the primary driver for our product. Fortunately, our newly minted company, Tunes Inc. is guided by the following business driver: registering new users. Using this, we can start to apply the directives to our new Product Success Statement for our fake product, Mytune.

Mytune Product Success Statement

On March 30th, Mytune has 145 registered users, of which 132 have been active within the last 15 days.  Over the next 365 days, following the corporate business driver of registering new users, Mytune will grow to 25,000 registered users with 22,000 of them active within the previous 15 days.

This statement has an action statement – grow, defines the beginning and end, highlights how the product is going to improve the business, considers a timeframe and in this example only has one action. Additionally, I think it is important that you have done sufficient research to support your statement. Perhaps this example is too simple, but it helps with deciding which features are on the roadmap and when.

In closing, you will likely have many success statements to support many initiatives and your strategy can and will change over time, but remember that if it changes your definition of success may also change.

The simplest definition of strategy is that it is a long-term plan for success.  So as a stategic product manager you define a roadmap. Does that qualify you as being strategic?  Maybe not, according to our definition.  The roadmap needs to articulate a long-term plan for success.  If your roadmap does not articulate what success is, you are not strategic. Perhaps we have identified the first step to being strategic. So what does success mean? The funny thing is that the definition of success is the achievement of a something planned.  I think Excel calls this a circular reference.  Ugh.

Despite that, we press forward with defining success for our roadmap. Fortunately, for the product manager our success is usually defined by the Executives in the form of either a corporate strategy or business driver.  Usually they take the shape of statements like grow revenue, reduce costs, increase efficiencies. We now know these are more drivers than strategies.  Are the drivers listed in the previous sentence sufficient enough for for you to achieve success?  These drivers are excellent at kicking off our exercise to define success but are they SMART (specific, measurable, attainable, realistic, timely)? For you to achieve success your definition will need to pass these 5 attributes.  Once you have defined your success statement, you are ready to define your roadmap and well on your road to being strategic.

Last thought, can your success statement change?  Absolutely.  We’ll discuss that later.  We’ll also come back to the structure of a success statement and have more content on strategy later… for now you can begin to define what success is for your product.