Thinking Beyond Features

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.  

The Next Wave

The mobile space is innovating at breakneck speeds and it’s easy to fall behind on all the activities and trends.   Here’s a roundup of some of the major thrusts going into 2011.   If your non-mobile business is not yet thinking about mobile offerings, it’s probably time to get it on the roadmap.   If you’re already in mobile, well, you’re probably just trying to keep up.  

Requirements in Pictures

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.

These can be simple modifications to existing product screens or a complete wireframe sequence for new capabilities.   In addition, it’s becoming increasingly important to begin testing both your product concept and possible solutions with real users before you write one line of code, even in Agile. 

Establishing Credibility & Building Relationships

The PM roles (Product Manager, Program Manager, and Project Manager) all need to lead cross-functional product efforts without having direct control of resources.   A common phrase heard is “I have all the responsibility but no authority”.   Last month at the Seattle ProductCamp, brainstormed in a session titled “Responsibility without Authority” to get ideas on how to establish credibility and influence your organization.   Here’s a quick discussion of those notes generated from about 25 attendees.   It includes identifying the major stakeholders, the roadblocks to influence, and suggestions for gaining credibility and the ability to influence. 

The Importance of Organizational Environment

In a previous guest post at OnProductManagement, we interviewed executives about product management and asked whether product managers met executive’s expectations. We got a resounding SOMETIMES.    Executives expected product managers to deliver against current business objectives but also acknowledged that the environment has a great deal to do with product manager success.   We’ll explore this environmental issue in more depth, specifically what do execs and product managers need to be doing to make the role successful. This discussion applies equally to other “PM” roles, including project and program managers.

Bridging Concept to Solution

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 role of Program Manager in many industries acts in the capacity of super-project-manager - coordinating multiple interrelated projects towards a common goal and often from a business manager perspective.     In high tech, the Program Manager role has evolved along very different lines, especially in software development.   This article explores this product development role, how it differs from other Product Manager roles, the value it brings to the development process and where things can also go wrong.

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.

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, 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.

4 Perspectives to Help You Shape Your Solution

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.

Portfolio Management, Opportunity Assessment, & Release Planning

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?

Have You Considered Asking for LESS?

As a product leader, your success is dependant not only on your ability to drive the right products into the pipeline but also on the rest of the organization to be able to build and support them. Sometimes (or perhaps often in your case) no matter how hard you push, nothing seems to happen due to bottlenecks in your organization. This can be a high source of frustration for the product management team (and other executives) and the cause of much conflict in your organization (this I know personally). So what can you do about it?

And Are You Delegating Your Company's Future?

Where do you find most product management teams organizationally within companies or divisions? The two most likely scenarios are within the Development organization reporting to the CTO or VP of Development, or in the Marketing organization reporting to the CMO or VP of Marketing.

The question is: Is this the right place in your company for this function?

Prioritizing Strategic and Tactical Activities

A major challenge for many companies is realizing the full value of Product Management within the organization. The reason this is challenging is due to product management not being a clearly defined role with specific activities and responsibilities across the industry. This makes it very easy to have product managers performing the wrong or incomplete set of activities, limiting your product's potential.

An Overview of Product Management Roles

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.