The Product Life Cycle (PLC) is a fundamental concept in Marketing that defines specific characteristics of products and markets at various points in their evolution.   Less common is the discussion of the company evolution and characteristics at different stages, also known as the Organizational Life Cycle (OLC).   This article discusses the stages of the OLC and specifically how it relates to high tech product development and delivery organizations, from start-up through mature companies.

Software-as-a-Service (SaaS) is quickly gaining credibility and market share against traditional packaged software.  This presents new opportunities for product groups and also new challenges to teams used to developing packaged software.    This article provides an overview of SaaS, how it differs from packaged software and specific new areas of focus from an end-to-end product perspective required to ensure a successful service.

Deciding what features to do in your next product release and beyond can be a difficult process.  There are always more requests than can be done, different priorities from various stakeholders, and even vastly different types of features that are competing for attention.   This paper discusses a framework and tools for assessing how to attack the problem and can be used in both traditional and Agile projects.

Painting a Picture of User Interactions

The typical product requirements process starts with a list of features or tasks intended for a specific release and then dives into defining Use Cases or User Stories for the user functionality. This can result in a disjointed solution being developed due to lack of an overall picture of what the user expects to be able to do, and context as to what they are trying to achieve. This article discusses a means of identifying the user need and conceptual functional solution in a high level narrative format called a Usage Scenario before diving into more formal detailed requirements methods. Usage Scenarios can significantly improve your requirements process independent of your development methodology (e.g. Waterfall vs. Agile).

The Executive Viewpoint

There have been plenty of discussions about how to measure and demonstrate the value of Product Management within companies.    From posts on other sites:

• VP of Engineering has a mandate. You need one too.
• Product Management Metrics (part 1)
• Proiduct Management Metrics (part 2)

and from a recent roundtable at the October Seattle ProductCamp, there’s an obvious challenge for the profession.

I decided to follow the prescribed Product Management protocol – I went out and talked to my customers. Here’s the feedback from some senior executives running technology companies to the following questions:

I admit it.  I’m an online shopaholic.  My addiction started over a decade ago when Amazon delivered my first book right to my doorstep, painlessly and effortlessly.   From there I progressed to flowers, gift baskets, electronics, shoes, travel and practically everything else.   The major reason I got hooked was due to my overall positive customer experience.    The web has come a long way since then and my expectations on the level of service delivered to me have increased, largely due to some innovative companies raising the bar.   This discussion is about paying attention to your customer’s full lifecycle experience, not just product features, to develop true loyalty.

3 Popular Theory Viewpoints

In previous articles, I’ve spent a lot of time looking at the MP3 player market, and especially the success of the iPod.  (See Innovation Lessons from Apple – Parts 1-3)  An article recently came out from the Wharton School of Business titled “Pushing Zune: Is Microsoft Pushing an Uphill Battle?”.   Is it making progress; does it have a chance; should Microsoft continue investing?   This was too intriguing to pass up, so this article looks at the Zune strategy from 3 popular marketing theories to see how these questions might be answered.

5 Activities for Successful Product Conceptualization

The early stages of product planning earned the nickname The Fuzzy Front End due to the unpredictable nature of initiating new product ideas and concepts within most companies.   The process, the timing, and the outcome are all often quite nebulous and mysterious.   This is in apparent stark contrast to the next phase, Product Development, which has clearly defined processes and deliverables.     This article dives into the murky waters of this front end phase and discusses five activities to help demystify the process.

A Productization Capability Self-Assessment

When was the last time you really assessed your products and your organization’s ability to create and deliver them to the marketplace? If it’s been a while (maybe never?), here are 12 quick questions and scoring criteria to help you determine how well you’re doing and to identify potential areas of improvement.

Part 3 of 3

With the release of the first iPod, Apple had an immediate hit on its hands. They repeated this with iPhone. What activities did they engage in on each of these products to ensure continued success? The primary method was to compete with themselves, and before their competitors did. Two key activities were continuous improvements and line extensions. This article continues the discussion from Part 2 - Innovation Lessons from Apple – Obsessing on Customer Experience.

Part 2 of 3

Apple is the undisputed leader among technology companies for creating products that border on art. They create products that are not only a delight to use but also provide a strong visual and emotional attraction. How do they do this? By making the customer experience a top priority. This article continues the discussion from Part 1 - Innovation Lessons from Apple – Finding Market Gaps.

Part 1 of 3

Apple has been hitting home runs since the 2001 release of the iPod, then iTunes Store, then iPhone, then the App Store. How do they do it? One place to look is in their level of investment in R&D… are they outspending others? As it turns out, Apple’s R&D expense as a ratio of gross profit is only 10%, compared to 12% for HP, 15% for Oracle, 17% for Microsoft, and 21% for Google. So… HOW DO THEY DO IT?! This article is the 1^st of 3 parts to discuss three key activities Apple does well to create innovative products.

A Discussion of Roadmap Planning

In a recent survey of product managers, the biggest challenge they faced was that of “Roadmap planning and commitment”. Figuring out where your products should be headed, in what timeframe and getting corporate support to commit resources to the plan can be daunting and frustrating. This article explores methods for improving the process of developing your plan and in getting organizational support. For reference, also see the article Your Product Management Poll Results.

An online poll was conducted in early May 2009 asking Product Managers to select their biggest challenges from a list or providing their own selections. The poll ran for just over a week and a total of 24 Product Managers responded and provided 63 different selections. The aggregated results are provided in this article.

Part 3 of the Product Requirements in a Nutshell Series

Parts 1 & 2 discuss the Requirements Process from traditional (waterfall) point of view and which focuses on documenting the features and functionality of the system to be built in advance of building the solution. The artifacts for this are the requirements docs and specs. At the complete other end of the requirements spectrum is the software development methodology of Agile/Scrum. The main thrust of this method is to AVOID the creation of the formal requirements documents and to use the actual product as the spec. This article explores the methodology and compares whether the common problems identified in Part 2 for traditional techniques are overcome by Agile.

For more background, see Part 1 – A Tour of Requirements Documents, and Part 2 – 4 Common Requirements Issues.

Part 2 of Product Requirements in a Nutshell Series

The main purpose of the Requirements process is to communicate to the technology team about a problem to solve and the envisioned features and functionality required to provide a solution. While on the surface this seems simple enough, the reality is there are several wrong steps to make along the way that can significantly reduce the value proposition that gets delivered to the marketplace in the form of the product.

This article is the second in the “Product Requirements in a Nutshell” Series and discusses four common issues that can arise in the development of Requirements and the potential outcomes that can result. For more background on typical Requirements documents, see Part 1 – A Tour of Requirements Documents.

Part 1 of the Product Requirements in a Nutshell Series

Despite all of the hoopla around new Agile software development methodologies, the vast majority of high tech companies (web-based software, packaged software, hardware/software systems) still use the traditional development methods that have been around for decades. In this traditional development world, there are usually the Requirements docs and Specification (Spec) docs. Depending on your industry and company, these two terms may mean the same thing and are interchangeable, or they may refer to entirely different pieces of the process.

This article is the first in the “Product Requirements in a Nutshell” Series and discusses some of the common variations in the documents names and purposes. For additional reading, see Part 2 – 4 Common Requirements Issues.

By Understanding Where Things Go Wrong

Developing a new product is risky business and a big part of the problem lies in planning and delivering the right product. In the book New Products Management[i], Crawford & Di Benedetto give 3 primary reasons for why new products fail:

1. Customers had no compelling reason to buy
2. The product did not meet customer expectations
3. Customers did not get the product message

This short article focuses on the early pre-launch activities (items 1 & 2 above) and where things can go astray.

One of the main drivers of post-V1 Development activities are Feature Requests, both external and internal to the company. The process of managing these requests is far from standardized, resulting in many products with a weak pipeline of ideas or a roadmap comprised of less-than-compelling functionality. This article discusses ways to optimize the process to acquire and select the best options for your customers and your company. In addition, we also look at a few leading companies using social networks to improve their results.

Assessment & Ideas for Improvement

As a product manager, do you know how you impact the bottom line or major objectives of your company or division? Do you even know how your activities are tied to objectives? As an executive, do you feel your product managers are delivering high value to the organization? Do you even know what they are doing?

Product Management has such a broad definition and set of responsibilities within a company that it can be difficult to assess which activities are truly delivering value. It can also be difficult to determine how to measure product management since their actions may not directly affect the core business metrics of revenue, costs and profits. This article presents a high level means of assessing whether your product management team is delivering all of the value it could, some reasons why it may not be, and some suggested steps to take towards maximizing your team’s contribution.