Month: August 2010
So here it is, looong overdue, the continuation of this series of articles. I published Part 1 and Part 2 late last year. I also had part 2a back in May, related to an audio seminar I participated in with Tom Grant of Forrester Research.
I’m not sure why it’s taken me so long to get to part 3, but here it is.
The story thus far
Unlike departments such as Sales or Marketing, measuring the value and contribution of a Product Management team or department is difficult.
Product Management doesn’t directly build, market or sell product, but clearly contributes significantly to the success in all those areas.
The focus of Product Management is product success, but that changes depending on the product strategy and the stage in the lifecycle of a given product.
Given the broad scope of the work, the dynamics of different products, and the cross-functional nature of the role, how can Product Management measure it’s success.
A different view of the Product Lifecycle
A traditional Product Lifecycle diagram (for a successful product!) looks something like this:
This is clearly a simplified diagram for illustrative purposes.
For any actual product, the stages such as Develop, Launch etc. would have different lengths of time, with the Maturity, and Decline stages being much longer than they are shown. The curve itself would also vary somewhat in shape and wouldn’t be a simple bell curve.
Each of these stages is fairly self explanatory, but if we look at the same diagram and replace the stage names with the main objective of each stage, the diagram becomes:
Described this way, it becomes much easier to identify the key Product Management goals and focus for each stage.
The focus is on developing the first version of a product or solution that addresses a market need for an identifiable set of target customers. This is typically an iterative process, starting with an initial hypothesis or seed of an idea and then working with a small set of early (pioneer) customers, learning from them as they are exposed to the product and incorporating that input back into the offering.
Once the product is launched, Product Management focuses on gaining an even deeper understanding of use cases, product limitations, positioning and messaging issues, sales barriers, pricing issues and other blocking factors that would prevent rapid adoption of the product in the target market. Education is a factor here, both within the company as well as externally. Thus working with press, analysts, key partners and other influencers is very important.
Once Product Management has “nailed it”, (maybe with version 1.2 of the product along with changes to the marketing, pricing etc. of the product), focus shifts to helping other parts of the company scale efforts and results. This can be tied into working with marketing, education, finance, sales channels etc. Additionally, changing market conditions, customer and partner feedback, and competitive issues will be used to drive the product development cycle.
In my opinion, this is a very interesting phase of the product lifecycle, because there are many ways to extend a product beyond the original problem space and target market segment. But it takes a lot of discipline to properly decide how to proceed and many companies fail miserably at this stage. Some methods of extension include:
- technology– e.g. adding new platform support such as a port from Windows to Mac or Linux
- geography — e.g. international expansion or foreign language support
- market segments — e.g. a small business edition or other vertical market specific offering
- adjacent problems — e.g. like adding more blades to a Swiss Army knife
- channels – e.g. working with resellers, VARs, distributors, OEMs or other parties
At a certain point, either due to market or technology changes, the return on investment in extending the product is not justifyable. And assuming the market for the product has not commoditized — i.e. with free or very cheap equivalent alternatives — a product can enter a “cash cow” phase where the company can “milk” it, by collecting revenues but with minimal investments.
At this point Product Management’s focus is on maximizing the (declining) revenue stream, minimizing expenditures, and defending against low cost alternatives or other threats. Traditionally software products in this stage have benefited from a large customer base, strong recurring maintenance revenue and low demand for product changes or investment.
At some point, based on declining revenue, increased maintenance costs, related technology obsolecence or complete lack of demand, a decision is made to end-of-life (EOL) a product. For any established product, this can take a period many quarters or years depending on the product and market segment.
There is not a lot for Product Management to do in this phase except perform the business analysis for EOLing a product and have it approved by management. Once that is done, assuming an EOL process is defined, a number of tactical activities, usually undertaken by other teams, are performed to ensure a smooth transition for customers.
In the next part — and I promise it is NOT months away — I’ll dig further into each of these stages and focus on specific activities and metrics for Product Management.
Over the weekend, unexpectedly, the blog was not available for approximately 12 hours.
The reason was a problem in the blog database.
Thankfully it happened over the weekend and not during the week so the impact on readers was reduced.
The database issue has been addressed and the blog is up and running again.
If you have any other problems in the future accessing the blog, please let us know.
Our email is onproductmanagement (at) gmail (dot) com.
NOTE: The following is a guest post from Ilya Bagrak. If you want to submit your own guest post, click here for more information.
When I take a look at agile programming from far enough away, I am astounded by the powerful ideas it brings to software engineering. I am not going to regurgitate all the benefits and detractions of agile, but I will restate it in simpler terms or as I tend to understand it from my product management perch.
- Agile takes a medium-term engineering goal, decomposes the delta between the current state of affairs and the objective into bite-size chunks, and then chews through one chunk at a time, learning as it goes along.
- It increases the opportunity for self-correction by structuring the learning such that the team can apply the things that it learned in one iteration to the one that follows.
- If self-correction happens often enough, we arrive either at an engineering success or at a well-supported argument why a goal cannot be reached.
Arguably, you can’t do much better at optimizing engineering resources regardless of whether you call it agile, waterfall or something else entirely. And this brings me to the original reason for raising the agile specter:
Can the above principles be applied to product management?
Agility in Product Management
I believe that some agile principles can be applied to product management, but we need to take note of a couple of terms listed above and how they are different for Product Management. These terms are “team” and “iteration”.
Agile methods place a lot of focus on intra-team communications. It’s all about making sure that engineers get to bounce ideas off one another other, sanity-check their estimates with each other and work on the problems collaboratively as opposed to in complete isolation. Naturally, a lot of agile engineering deals with prescribing specific agile roles and the responsibilities that go along with them.
Contrast this with Product Management, which is often a “lone ranger” role. You do it all, with few team members, but usually in collaboration with various external stakeholders. For better or worse, these external stakeholders are all embedded in their own distinct workflows (sales, marketing, senior management), so they cannot be easily compelled to play by a uniform set of rules (as required in agile development).
To work with these stakeholders, it’s easier to think in terms of inputs you need from them and the outputs you must provide to them to move forward in the most efficient way possible. So in the end it’s all about communication as well (isn’t everything?).
How can this way of thinking be translated into action? It helps to sit down with different stakeholders and write down and agree with them about what they expect from you and what you expect from them. Trust me, I’ve done this exercise and it helps a lot in streamlining communications. You’ll also find that people are strongly motivated to sit down with you because there is clear value in this exercise for them as well.
This is the other term to consider. Earlier I referred to iterations and the medium-term goals that engineering focuses on. To an especially cynical product manager it may seem natural to partition software development into sprints because all engineering activity is homogeneous, whereas product management activity is heterogeneous. The argument may be that it’s harder to march in lockstep since in product management you advance on many fronts at once.
But, there is nothing natural about splitting engineering work into bite-size chunks because work items often exceed the length of iteration and/or don’t start at the start of iteration. In my experience this is a tremendous source of agile headache. So in the end it’s not done because it’s a natural thing to do, it’s done because the benefits outweigh the downsides. The same holds true for product management.
If you have many concurrent and heterogeneous activities in various states of completion, nothing should be stopping you from checkpointing yourself every so often. To deflect the obvious criticism, let me say that I am not talking about scheduled reporting to your boss.
Instead I am talking about self-correction and squaring your progress against your own plans. The hope is that by increasing your opportunity for self-correction you also increase your chances of reaching your goals. The reason this is difficult for product managers is that it’s hard to pause just to have a conversation with yourself.
How long should agile product management iterations be? Think in terms of raw percentage of time spent planning and updating plans. This in my view should not exceed 10% of all work you do. If it takes you 1 day to plan for the next three weeks, that’s 1/15 or 6.7%, which looks just about right to me.
Putting Everything Together
If you’ve worked closely with engineering, you know that engineering gets a lot of flak for missing deadlines and providing inaccurate estimates of work to be done. And these are precisely the problem that agile programming practices try to address.
However, I often see Product Management get less criticism than engineering for the same missteps. We are more easily forgiven for messing up the little stuff or steering off course temporarily as long as the overall direction and trend is acceptable. On the other extreme, when product managers fail, they fail spectacularly and with much more serious repercussions for the person at fault.
Why is this the case? I think the main issue is that our success as product managers is more amorphous and difficult to define than engineering success, and any agreement on how to evaluate product managers has proven elusive. It’s really a function of the multiple hats we wear, the lack of opportunity for repetitive course correction along the way, and the fact that complete and utter product failure just takes more time so it occurs less frequently, which in turn creates the perception of greater leniency.
What I like about agile programming is the commitment to improving the metrics by which engineering is ultimately judged. As a consequence of inherent differences between product management and product engineering, not everything that is agile can be applied to product management. Still I do believe that a combination of:
- more structured product management communications,
- iterative planning and self-evaluation,
- finer grain (as opposed to all or nothing) performance metrics
can all lead to better product managers and better products.
Ilya Bagrak (@ibagrak) is a product manager and a budding internet entrepreneur who shares his time between Moscow, Russia and Silicon Valley, California. He also blogs about product management, entrepreneurship, and technology at codercofounder.wordpress.com.
Usually service engagements start off as custom pieces of work. Creating a statement of work defines what will be done and an estimate of the labour required is provided along with an hourly rate. After a few service engagements with customers you likely notice common activities in the work. When you see these, you have an opportunity to productize your service.
What does it mean to productize a service?
It means to define an offering with a set of repeatable activities and deliverables that address a common business problem of your customers.
Why would you productize your services?
- It is easier to sell a defined offering that contains specific activities and deliverables rather than custom statements of work
- Standardized delivery means it is easier to train your staff
- Delivery is more efficient since the framework is already defined
- Each time the offering is delivered it gets better through learnings
- It strengthens the credibility of your organization as experts in your field
The company I work for has a specialty in implementing Microsoft Project Server. Virtually every client needs dashboards and reports that show project delivery and resource status. We have implemented many of these over the years and found that the key metrics for delivering projects are similar between companies. Based on our implementation experience and industry standards we have defined and now consistently deliver a standard, repeatable service to define and deliver Project Dashboards for organizations.
Other productization opportunities
Although this example is specific to a specific business function (Project Management), there are common themes of offerings that exist across business functions. Some common offering themes that you can consider for your company include:
- Maturity assessment – Based on your understanding of your industry, investigate and compare your customer along different business functions.
- Business case preparation – Uncover the inefficiencies in an organization that could be addressed with a solution.
- Roadmap – Define a multi-year timeline with key benefits and milestones along a business line or functional area.
Remember these rules
Once you have a general idea of the service you want to productize, consider the following tips when working out the details:
- Fix price the offering. When someone buys a product, they need to know the exact price up front. Even if you are intending to have the offering as a free value-add to a larger purchase – putting a price on it demonstrates the value the customer is getting.
- Constrain the timeline. With a fixed price you want to constrain the timeline so your costs don’t blow up. Be crystal clear which activities occur during the engagement. Identify key milestones and deliverables.
- Base it on previous experience. If you don’t yet have customer experience delivering the service you want to productize, do a trial run with your internal organization or a trusted partner.
- Be clear about the benefits to the customer. Document the value proposition of the offering directed at helping customers understand the
- Specify what you expect from the customer. Indicate who will participate in the offering, how much time is required from them and the types of activities.
- Build supporting documentation. Items such as delivery guides and samples reports help the customer see that you have real intellectual property baked into the offering rather than using them as a guinea pig.
As you productize your service, keep your objective in mind. Will the service be a revenue generator or will it be tool to open doors with customers with the intention of a larger follow-on sale? Depending on the goal, you may market it differently.
Have a look at the types of services you are delivering to your customers today. Pick the most common one to start and apply these rules to productize it.
Craig McQueen leads the Business Intelligence practice for Agora Consulting Partners. He is involved with all aspects of the practice including sales, marketing and delivery. Through his consulting career, he has worked with enterprise customers including TD Bank, Royal Bank, BMO, Rogers Communications and Bell Canada. You can reach Craig at the following email – cmcqueen (at) agorainc dot com.
Last year, as I was creating content for my Devil’s Dictionary for High Tech – I tweeted the following:
You can see the original Tweet here.
Now this was clearly a satirical definition, but it is based on my experience with the topic of thought leadership. I’ve been in more than a few meetings where someone stated that one of the marketing goals was to be seen as a thought leader in our space in the coming year.
No one, myself included, asked what it actually meant to be a thought leader, or how we’d know that we’d achieved our goal, or even what the benefits were if we did become one. The goal of being seen as a “thought leader” was in itself a phrase whose meaning seemed self-evident.
But, clearly that isn’t the case. As mentioned in a previous post, Tom Grant at Forrester is conducting research on thought leadership and is looking for community input.
Having said that, I thought I’d get some direct input from you folks about this topic. And while Tom is focusing on thought leadership in the enterprise software and services space — using Salesforce.com and Wipro as case studies — I see this topic having direct relevance to Product Management.
What is a thought leader?
Before going further, let me try to put a box around the phrase “thought leader”. I say “try”, because I think the phrase will mean different things to different people and there is no single definition that can cover all viewpoints. Here’s one view:
A thought leader is someone who consistently communicates credible and unbiased information and insight in a particular domain AND whose insights are used by others to take action or make decisions about issues in that domain.
OK, so that won’t fit into a single tweet, and it probably could use improvement (your thoughts are welcome), but it does contain several important points.
1. Thought leaders are people.
Yes, sometimes an organization can be viewed as a thought leader, but it’s the people who make up the organization, and in particular those who speak for it, and represent it that can be viewed as thought leaders.
2. Thought leadership is an active task.
People must communicate in an ongoing manner. A brilliant person who cannot communicate his/her insights to a wide audience cannot be a leader. Communication is one of the 4 Cs of Leadership.
3. Credibility and trust are a must
Virtually anyone can speak on any topic, and with web technologies, they have a virtual megaphone to get their message across. But that fact alone doesn’t make someone a leader. Thought leadership, like any type of leadership requires the trust of those who follow. The leader must be believable and not be seen as a self-promoter or a shill for some organization.
4. Other people/parties must find the leaders insight relevant and actionable
Leadership must be tied into action or progress for those who follow, and not simply the number of those who will listen.
For example, Kanye West joined Twitter on July 28/2010. He had about 200,000 followers the next day and currently has almost 500,000 (roughly 1 week later). Does that make him a thought leader? Not in my opinion, at least not on Twitter. Between musings on life, or Twitpics of things he wants to buy, it’s hard to see how any of this minutae about his life can be considered useful insight. In fact, Kanye seems like a perfect example of the Devil’s Dictionary definition I gave at the beginning of this post.
Product Managers are thought leaders
Looking at the 4 points above, they can clearly be applied to the role of Product Management. Product Managers must lead through influence, must convince others of their perspectives and views, must have credibility and trust, and must communicate information in ways that others find useful and relevant. This applies to both internal teams and with external audiences.
Product managers may not see themselves explicitly as thought leaders, but they often are viewed that way by others. Keep this in mind as you work through your next research project or product release.
How would you define thought leadership?
Do you see yourself as a thought leader in your company?