Our Whitepapers
These are longer articles in whitepaper format
A major driver of where you should go with your product strategy is the overall industry category in which your product resides. A product category also has a lifecycle with distinct stages that can dictate the product strategy options. This article discusses these stages and provides some general guidelines to help you frame your thoughts around updating your own product strategy.
Managing the lifecycle of a product isn’t a clear cut or an easy task. Managing the lifecycle of multiple products or product lines can be daunting. How do you decide where to invest and where to hold? How do you decide the best use of your valuable resources? This is the activity of Product Portfolio Management and the discussion for this article.
In recent years, we've seen a number of technology companies create or completely transform entire industries. Some examples include Amazon Kindle, Apple iPhone, Google Android, Mint, and NetFlix. In every case, their success was not the result of a new or disruptive technology advancement, but rather a unique technology application based on a business model innovation that was disruptive in some way. This article provides a primer on business model innovation.
If you’re involved with creating product requirements, especially for software, you may need to provide some form of visual representation of the features you’re working on. While it is possible to define the functionality in terms of Use Cases and supplementary flow diagrams, comprehension is going to be significantly enhanced with some pictures illustrating a form of user interface.
A recent search on Monster.com for similar job title openings nationwide yielded about 800 Product Managers, 150 Product Marketing Managers, 1,000 Project Managers and 1,000 Program Managers. What’s a Program Manager?
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.
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).
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.
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.
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.
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.
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 1st of 3 parts to discuss three key activities Apple does well to create innovative products.
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.
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.
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.
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.
Assessing new opportunities for a product or service is one of the top strategic activities that a Product Manager can do within a company. These opportunities can be in the form of entirely new products, or more likely, enhancements to existing products. They can come from external feature requests, internal stakeholders, or from “out of the blue”. Since the product manager is the “business owner” of the product, there are multiple perspectives he/she needs to assume to be able to make the best decisions for the market and the company regarding these opportunities.
As technology companies move from the startup phase into more mature states with multiple customers and multiple releases of at least one product, a normal queue of requested functionality or ideas begins to form for what to do next. Customer requests, competitive responses, new opportunities, internal operational issues and defects all begin to pile up and compete for attention. Someone needs to deal with all of this and the question then becomes WHO & HOW? How do we organize, understand, prioritize and decide what to do with this stuff? More importantly, which of these items, IF ANY, will actually contribute to the long term success of the product and company?
What do your product managers do? Are you aware of all the things they could be doing?
This paper gives a brief overview of the typical activities that product managers get involved in and some potential issues that can crop up. The goal is to provide awareness of the possibilities to product leaders and product managers for assessment of your situation and opportunities.