Prioritization of Requirements - Right product that delivers maximum value


Prioritization of Requirements - Right product that delivers maximum value

This is one of the most important decision a product manager has to make in order to define the release and develop a roadmap.  Even though this is a key decision...very few  PMs spend time on this process .

The most common way to prioritize requirements is by adding a suffix with every requirement that states it’s a must have, should have and nice to have. So, what's wrong with us method of prioritization.  Must have in PM's definition implies that we wont ship the product, should have if we have time in the release and nice to have is essentially relying on some unknown factors influenced by super natural powers to get the requirement into a release.  Natural reaction on the first look at this list is for the engineering teams to eliminate should haves and nice to haves. Why do teams do that? If you recall in my previous blog on what's wrong with PRDs I highlighted that engineering cannot cost the release by reading a few lines/paragraphs. So, the natural reaction is reduce the risk by eliminating what' s not really important to the Product Managers to begin with.  Should have's and nice to have's are gone in the very first discussion or prior to that. Then what remains are the must haves and the "dance" starts.  Engineering is asked to provide scoping analysis of the high items  and the process of elimination starts.  An engineering lead I'm friends with started a presentation with a nursery rhyme as part of his discussion with the product managers:

  • You put your right foot in,
  • You put your right foot out,
  • You put your right foot in.
  • And you shake it all about.
  • You do the Hokey-Pokey,
  • And you turn yourself around.
  • That's what it's all about!

After all this is...what remains is a set of requirements that for legacy Enterprise products are usually the "me too" or "customer escalation" or " a specific customer request" or a "catch up" or "close gap" or a "tactical feature" to deliver the release. At times, innovative requirements/features do get it but this is based on perception of the PM and no hard data and thus starts the costly gamble for the product team/business.  You may or may not get lucky with these innovative requirements.  Similar issues, exists with all the other forms of prioritization - p1, p2 p3/ 1,2,3/ voting etc.

So, what's the alternative…

Let's revisit the core responsibility of a product manager again . Product Managers have to define a right product that provides maximum value to the customers while reducing the complexity and meeting the time to market needs of the business and customers.   With this key definition firmed up...lets look at the prioritization process from this perspective in the diagram below. Always, keep this definition in sight ...


  1. Business Strategy - What is the strategic direction of your business?
  1. Product Strategy - > How will you support the business strategy?
  1. Business Opp. Assessment -> What Problems?, For Who? Competitive/Substitutes/Threats?, Why us?,  Why now?, Market size?,  Risks? & Critical Marquee Themes ?
  1. Customer Validation (Ideas or themes)/ Internal customer facing teams validation
  1. Brainstorming (three key stakeholders - Product Management -> market needs/problems , Product Designer -> Understand the persona & required user interaction , Architect-> Determines the feasibility)
  2. Iterate through steps 4-5-6 UNTIL you define a right "minimal" product which has a blend of form (UI) & requirements and that provides maximum value to the customers while reducing the complexity and meeting the your business and time to market needs.



Scoping analysis does help prioritize the requirements.  But, this could be done via a gut level feasibility analysis and not the formal scoping effort.   There are a few big issues with the scoping analysis method where engineering teams are asked to go into vacuum and come back with estimates.
 1 - You waste time and valuable engineering cycles
2 - You are asking for validation of the features from the engineering team which is not what engineers are supposed to do.  PMs have to put the right set of requirements from a customers / market and industry perspective.
3 - Create unnecessary stress between development and the PM team. No one likes the dance we do ...why do it if you can avoid it in the first place.

The steps outlined above are meant to gather the right data for you to help define the product. Some product managers like to go one level deep with this analysis and actually come up with some mathematical model to use.  There is no harm in doing this as long as you stick to the fundamentals outlined above. So, how do you go about adding  more granularity to this process. Well, add one more step

  1. Assign weights based on key factors (weight/factor).  Use a very simple formula  that works for you and you can justify.  But, this is after you go through the 6 step funnel process to identify the right product that customers want to use. 

Product Managers - Need to lead with radical ideas


Product Managers - Need to lead with radical ideas



Innovation is one of the most commonly used term. The word, which derives from the Latin noun innovatus, meaning renewal or change is a part of our day to day corporate vocabulary .  A WSJ article indicates how often this word is used:

  • Some form of the word "innovation" occurred 33,528 times in 2011, which was a 64% increase from five years before that
  • More than 250 books with "innovation" in the title have been published in the CYQ1'2012 . Just three months…

However, a few companies actually pursue or deliver "radical innovation" .  Product managers hardly get a chance to work on innovative ideas in large enterprises since these vendors  don’t provide an environment for individuals to work on game changing ideas. Instead, small incremental improvements are labeled as "innovative" deliverables  .  I always try to get back to the basics and then see how we can leverage these fundamental concepts in our day to day business world.  So, lets start with the basics first….

Innovation - What does it mean ?

Lets look at three definitions from three leading researchers in this field and identify the commonalities :

Theory 1 :  Leading the Revolution by Gary Hamel

Gary Hamel in his book defines innovation as a "Radical Product – Has the power to change customer expectations and redefine the basis for completive advantage". Companies do focus on incremental product innovations which are focused on existing products/services/ markets but in an increasingly nonlinear world, only nonlinear ideas are likely to create new wealth.  An article for INC by Gary Hamel further describes this in detail:

  • A radical idea has the power to change customer expectations : Not long ago, the PC was the ugliest thing in your home. Then Apple hired Jonathan Ive, a young British designer who turned that monstrosity into the first iMac -- a jazzy, fresh work of art that changed customer expectations. That's radical innovation at the product level.

  • A radical idea changes the basis for competition: In a world of increasing income bifurcation, conventional wisdom in retailing said that shoppers would go either to a Wal-Mart and that it would get ever tougher for companies in the middle to make money. Then Kohl's proved that conventional wisdom wrong. The company has half the number of stores as Sears and one-third the number of stores as J.C. Penney, and yet its market value is greater than that of either of its two century-old competitors.

  • A radical idea is one that has the power to change industry economics: By adopting a point-to-point routing system, Southwest Airlines keeps its jets in the air for two or three hours longer than most of the other airlines (which use the hub-and-spoke model), thereby using its capital more efficiently.

Executives and including product managers goals should not be to forecast "what might happen in the future but imagine what you can make happen".  A few other examples cited in his book shed additional light on "how" companies continue to drive innovation.

UPS : Getting outside the truck
  • Experimentation and rapid Learning approach to new business development
  • Bringing in new talents to fuel innovation.
Charles Schwab: Bricks and Clicks
  • Open and rapid experimentation allowing prototyping and testing of new ideas

Theory 2 - Fooled by Randomness & Black Swan by Nassim Nicholas Taleb

In his two books , Taleb regards almost all major scientific discoveries, historical events, and artistic accomplishments as "black swans"—undirected and unpredicted.  What we call here a Black Swan is an event with the following three attributes.

  • Its an outlier, as it lies outside the realm of regular expectations
  • It carries an extreme impact
  • In spite of its outlier status, human nature makes us concoct explanations for its occurrence after the fact, making it explainable and predictable

Google, Microsoft office are examples of black swan products that have fundamentally changed the way we search and forecasts our business.

Theory 3 - Blue Ocean Strategy by W. Chan Kim & Renee Mauborgne

Authors describe the concept of value innovation.  Value innovation is created in the region where a company’s actions favorably affect both its cost structure and its value proposition to buyers.  Cost savings are made by eliminating and reducing the factors an industry competes on.  Buyer value is lifted by raising and creating elements the industry has never offered.  Over time, costs are reduced further as scale economies kick in due to the high sales volumes that superior value generates. This leads to what the authors introduced as a vital concepts. Red Ocean vs Blue Ocean.

  • In the red ocean, differentiation costs because firms compete with the same best-practice principle.  Here, the strategic choices for firms are to pursue either differentiation or low cost. 
  • In the reconstructionist world, however, the strategic aim is to create new best-practice rules by breaking the existing value-cost trade-off and thereby creating blue ocean.

Red Ocean Strategy
Blue Ocean Strategy
Compete in existing market space
Create uncontested market space
Beat the competition
Make the competition irrelevant
Exploit existing demand
Create and capture new demand
Make the value-cost trade-off
Break the value-cost trade-off
Align the whole system of a firm’s activities with its strategic choice of differentiation or low cost
Align the whole system of a firm’s activities in pursuit of differentiation and low cost


Where do innovative ideas come from ?

This is an interesting question and something that we all wonder about.  What's the genesis of innovative ideas.  I'd recommend reading  " Where Good Ideas Come From: The Natural History of Innovation by Steven Johnson". His book provides insights into what leads to innovative ideas.  Economist article provides an excellent summary of his key concepts :

"The first of the patterns is “the adjacent possible”: the innovations that build logically on previous breakthroughs. In technology, this results in the common phenomenon of several people inventing the same thing at the same time, because it seemed the obvious next step. Similarly, life itself emerged as a cascade of increasing complexity, and the forking paths of evolution allow one innovation to lead to another, such as the semi-lunate carpal bone that made velociraptors more dexterous predators, but subsequently led to the evolution of winged, flying birds. Cultural and social life is also an exploration of the adjacent possible, as one unexpected door opens and then leads to others."
" In a similar vein Mr Johnson explores the “liquid networks” that foster innovation, whether online, in coffeehouses or in ecosystems, and the “slow hunch” whereby an idea develops slowly and often wrongly, before suddenly becoming the right answer to something. He also examines the benefits of serendipity and error, which can each lead to beneficial insights; the notion of “exaptation”, in which an innovation in one field unexpectedly upends another (Gutenberg’s press combined ink, paper, movable type and, crucially, the machinery of the wine-press); and “platforms”, from operating systems to coral reefs, which provide fertile environments for new developments."
How do you foster innovation ?

Lets review how Google's fuels its innovative engine.  Interview with Eric Schmidt in 2012 provides good insight into how companies create the right ecosystem which includes a mix of smart individuals, culture  that promotes experiments and rewards success/failure to build an ecosystem of ideas.

"Early on, “we put in a system of mechanisms,” for innovating, Schmidt said, citing the  so-called “70/20/10 system.” This was a principle that everyone should spend 70% of their time on their core job, 20% as part of another team, and 10% on something blue sky. It was often honored in name more than the event, I’ve heard from insiders – if you’ve got a critical job and a tight deadline, you don’t give it up at that 70% mark. It was however, a good way for people to see projects all around Google, and test them against their own ideas". At Google, “We don’t have a two year plan. We have a next week and a next quarter plan. Most of our successful products were built by small teams reacting quickly.”

Why do companies fail to innovate ?

When we look for innovation, we expect it to come from startups . Large companies struggle to drive innovative projects/foster innovative ideas or create an environment that helps with experimentation.   Well, there are reasons why. One of the leading HBR article summarizes the key challenges.

"The classic traps" by Rosabeth Moss Kanter summarizes the key reasons why company's fail to innovate

Strategy Mistakes
  • Rejecting opportunities that at first glance appear too small
  • Assuming that only new product counts - not new services and improved processes
  • Launching too many minor product extensions that confuse the customer and increase internal complexity
Process Mistakes
  • Strangling innovation with the same tight , budgeting, planning and reviews as existing business
  • Rewarding managers to what they are committed to do and discouraging them from making changes as circumstances warrant
Structure mistakes
  • Isolating fledging and established enterprises in separate silos
  • Creating two classes of citizens - those who have the fun (innovators) and those who make the money (mainstream businesses)

Learning's for Product Managers- Think like a startup

With the background in place lets look at how does this impact the product managers.  As a PM, its your key "responsibility to bring the future into the present".  As a PM it is your responsibility to create the blue oceans or the black swans or define radical ideas that have the power to change the competitive  & industry dynamics and above all fundamentally change your customer expectations.

So, where do these ideas come from.  There is no one source of ideas. But, I truly believe that the right environment with individuals who are motivated and are a part of a culture that promotes experimentation and rewards success and failures can lead to innovative ideas. This kind of an environment is usually there in a startup.   Startups have no legacies, they are in search of blue oceans, do not have existing customers to guide them or lead them to solutions or existing processes that limit their thoughts. They are outside the box and thus can lead to breakthrough innovations.  Irrespective of the environments PMs may find themselves in they need to think "outside the box" and focus on open and rapid experimentation allowing prototyping and testing of new ideas with their product teams.  Develop these fluid informal networks that helps you develop pipeline of ideas .  Many product managers rely on customers for these ideas. They talk to customers, validate the concepts and ideas etc.  Talking to customers is an important step in this process but as PMs you have to identify the "difference between the customers perceived wants and the real problem". Usually, Product Managers focus on the customers perceived wants only and thus ignoring the larger picture.  You need to strike the right balance between the top down driven innovation (lead by folks who feel the force) and bottoms up approach (customer driven )validation.  Blended approach  to innovation would be the right model as highlighted in this NY times article by John Kao  at the World Economic Forum in Davos , 2012. 



Product Managers should focus on developing the ecosystem of these promising ideas. A few are near term , a few are medium term and a few are long term plans which are in their initial stages.  Develop this pyramid, present it to management, ask for building an innovation team within your team, or build an innovation team by balancing your own product budget and connect the dots with all the innovators within your team and outside your team. It's the network of all these connections lead by you that will help build the ecosystem. Scoot Cook founder and CEO of Intuit in his speech at the world innovation forum in NY highlighted the need for experimentation  -  "Don’t be afraid to constantly be experimenting, and don’t be afraid to fail at most of those experiments".  To achieve game-changing innovation, Cook says, be willing to constantly run small-scale experiments, to develop a “culture of fast cycle experiments.”

Simple User Experience : Simplicity is the ultimate sophistication


In my previous blog on product requirements documents I had highlighted the need for  developing prototypes along with other artifacts like use cases/user stories etc for driving product management activities.  I highlighted the reason why ...since requirements and user experience are intertwined . They need to be looked at from one eye to define a usable product that provides value to the end users.  Lets review this topic in detail by looking at a famous quote that is often used in our industry today. I included a non IT definition to illustrate the important of simple user experience.

  • "Simplicity is the ultimate sophistication" - Steve Jobs
  • The ability to simplify means to eliminate the unnecessary so that the necessary may speak - Hans Hofmann (abstract impressionist painter)

Here are the core principles for delivering a great user experience that product managers must follow and stick to it at any cost. 

  • Focus on the end user and only the end user. End users interaction with the software is what should guide your requirements/design / development. Focus on a few features that would make your product usable.  Make it simple for end users to use .
  • Say NO to everything that compromises the user experience. This most importantly applies to your requirements , to the features you prioritize to the downstream development code that gets into the product. This implies that you would say NO to a lot of good ideas, a lot of customer requests, feedback from the internal teams, analysts etc. But, stick to this principle...this would help you eliminate complexity in the product and adapt the 80/20 rule. 20% key features that provide 80% value.
  • Provide a direct path to get the task done….a straight path is what you need.
  • Don’t pile features . More features would make the product complex and unusable. Focus on a few features that are usable.  Mathew May , author of In Pursuit of Excellence ,says the best ideas have something missing and what's missing leads to a more elegant solution .  Hint : iphone, ipad ?
  • Don’t just focus on how things look. Get to the next level and focus on how things actually work. A good UI does not necessarily translates into a simple user experience for the user .
  • Ship with minimal documentation.  A product that is usable does not require pages and pages of manuals.  You hit the mark if you pass this test.

How can you start to implement these principles ?

I'm not straightforward to implement these principles especially with existing products with legacy customer base . But you got to start somewhere and the further you delay these decisions the more complex your product becomes. Here is a quick recommendation to help you get some discipline around it :

  • Review the value proposition of your product?
  • Identify why your customers buy the product?
  • Understand how they use they use the product ?
  • Create your customers profile (buyer, user)?  List all the tasks they do?
  • Keep this profile on your desk or as the background image on your laptop/desktop?
  • Keep the core principles in sight ? Always
  • Review every features, request, additions to the product from this lens

Product Strategy: What does it mean? Need to understand these concepts to develop the strategy




Product Strategy: What does it mean? Need to understand these concepts to develop the strategy   

Strategy, business model, strategy planning...buzz words are commonly used terms by the product managers. However, a few selected product managers that too with a strategic planning experience actually understand the entire strategic planning/development process in detail. Sharing the basic concepts along with the process product managers need to follow to develop product strategy. 

What is Strategy?
We don’t need to reinvent the wheel on this. Let’s look at two definitions:

  • Harvard professor Michael Porter defines strategy as "a broad formula for how a business is going to compete."   It's the creation of a unique and valuable position, involving a different set of activities.
  • Bruce Henderson, founder of The Boston Consulting Group, defined it as, "a deliberate search for a plan of action that will develop a business's competitive advantage and compound it"..."competitive advantage is founded in differences."


Strategy is focused on what is needed to create sustainable competitive advantage & deliver customer value.

There is a wide spectrum of paradigms that have emerged over the years to help companies develop strategies. Here is a snippet of how the strategic world looks like from strategy-business.com in their issue 61 (Winter 2010).



What is a business model?

Business model describes how the organization will implement the "Strategy". Business model is focused on the how the organization will create and deliver substantive value to customers.   Product Managers often confuse strategy with the business model.

What is a Strategic Planning?

Strategic planning is the process of conducting research, defining strategies, identifying and developing the business models to achieve the core vision company has outlined.  Simply, put this is the systematic process company follows to answer three basic questions:



  • What's the current situation?
    • External - Market, Industry, Competitive, Environment …
    • Internal - Financial, Current SWOT
  • Where do we want to go?
    • Select the key strategic focus areas
    • Identify strategic options/ alternatives
    • Identify the strategy
  • How can we go there?
    • Execution plan

Product Strategy
So what does it mean for product managers?  This diagram illustrates how the PMs should go about developing the strategy which then leads to product roadmaps.





What’s wrong with the Product Requirement Documents (PRDs)?


PRD is the most commonly used mechanism for product managers to describe product requirements for a release. PRDs forms the basis of requirements for both Waterfall and now even with Agile software development processes. However, there are some fundamental challenges with the PRD model and I’m sure if you take a step back and analyze the pros and cons of the PRDs...you will find commonality between your thoughts and what I have shared below.  Not sure who invented PRDs but I’m sure this person/organization didn’t have just the word document as the fundamental way to define products.  So, lets start with the challenges first :

Take Time to Write
Product Managers spend considerable amount time on the document.  During this time your product teams are in waiting mode and management is anxious to figure out what’s next. So, cycles are wasted and engineering management cannot plan for what’s next from a staffing, budget , platform perspectives until this document is firmed up.

User Experience is an after thought
This is the biggest challenge with the PRD. They are a bulleted list of requirements ...very verbose but cannot describe the user experience. User experience is the most important element of a requirement...experience does not only imply the UI. It's every touch point the user has with the product. 

Static in nature
PRDs are static documents. However, development is a dynamic process...in fact, agile development is used today to help give structure to this dynamic nature of software development. On the other hand , the most crucial document that is used for software development is static.
 
Error prone scoping Analysis
Engineer cannot actually provide the scope of the work until he really understands the requirements, gets a chance of putting a high level prototype or design document . However, we hardly give this "must needed"  time and force the engineering team to come up with the estimates to help identify the next spot on the roadmap . Thus, what you get usually are high level estimates with a significant error margin in them and off course very conservative.  PMs are still not done.  Then, the next round of discussions start around the negotiations. Give and Take...

What you ask for is not what you get ?
We all have lived through this. What is specified in the word form in the document is different then what you get? Why is this? Because requirements are subject to interpretations ...PRDs cannot capture the entire context of the requirement.

Cycles after cycles are wasted
The ping pong game between engineering and product management on requirements is a waste of time and crucial product release cycles are wasted. It causes frustration, results in lack of trust, results in throw away work. PRDs usually start with the complete wish list from a PM and ends up with what should have been there from day one prioritized as the right feature set for the release. This is a significant waste.

Cross functional teams have no clue what’s in the release
Even though PRDs exist but honestly the only teams that read it are usually the engineering staff. As a result, cross functional teams are in dark and they all wait for the final PRD and some kind of a dev milestone to understand what is in this release. So, they are in dark and cannot plan for future deliverables.

Too long to read and it changes...
Hardly a few engineers read the entire PRD which takes time and by the time you read it usually changes . Infact, the change is constant since you are going and forth from a market perspective but also adjusting based on all the discussions.

Management is left in dark
Executive team usually gets a few bullets on a power point to help illustrate what the next release would look like. These bullets form the basis of budget approvals, decisions and pretty much the “Go/No Go” decisions for the project.

Do not describe the requirements but end up describing the solutions
In order to be precise and to make sure what you ask for is what you get product managers end up identifying the solutions to the team instead of the requirements. PRDs suffer from this common problem.

Cannot be validated

There is no way to validate the PRD and the assumptions associated with the requirements. It’s not something you can put in front of the customer ans ask for feedback or lead them to discover new requirements.

This list can go on and on...but I’m sure you will find a connection between your process and these data points . On the positive front...PRDs in its true form are a useful document when you know the exact set of requirements and can clearly / very clearly articulate it and expect little to NO changes to it as you move through the release. Usually, this is true with waterfall development models or shorter releases.  This is hardly the case in the software world we live in these days. 

So, what’s the solution...

Solution lies with the startups and entrepreneurs who have built companies from scratch. This will be a topic for my next blog...but here is the hint. What do startups do differently? What do Entrepreneurs focus on initially when they have limited availability of everything ...money, cycles, resources etc?

Eat your own dog food


Product Managers are always busy.  They work on multiple things  over the course of a normal day and the same pattern stays intact for the lifecycle of the project .  During a project release PMs get a chance to see a lot of demos but hardly get an opportunity to actually install and use their product.   It's important for product managers to not only understand the market/technical dynamics, industry , customer profile, competitive landscape etc but also understand the "DNA" of their own product. Superficial knowledge results decisions that are not based on facts.  Eat your own dog food is important for you/your team to understand what customers have to go through (good and bad) to use your products.  Take time out from your daily grind and spent time with the pre sales guy , do a quick POC  , come back with findings and you will see a remarkable difference in your approach to all the decisions you take and would help define products from an end users perspective. 

Product Managers - Core Responsibility


Product Manager is a very interesting role. PMs are responsible for managing the entire product line. As a result, they focus on everything that touches the product.   This pretty much involves the entire cross functional teams such as engineering, QA, docs, support, sales, product marketing, product analysts, compliance team, project management, operations, process etc.  Management and interaction with this entire spectrum is important but you should not forget the basics.

Product Managers are responsible for "defining and launching"  products that meets the following criterion:

Customers

  • Simple User Experience - DEFINE products that the end users can use and would continue to use
  • Meets Customers Needs - DEFINE products that customers want to use
  • Minimize Complexity - DELIVER products that customers can actually use

Organization

  • Time to Market - MINIMIZE time to market
  • Business & Product Objectives - MEET the KPIs you outline in the business case

Always maintain the focus on the basics. You have to deliver value to the  end users and maniacal focus on "core product management basics" is very important

Qualities of a Product Manager






This question comes up every time during the product management interview process….potential employee and the hiring manager both are looking for common qualities that defines the product manager.  It's not possible to cover a large spectrum of capabilities that a product manager should have in this blog.  Being said, I have highlighted a quick summary of key qualities that product manager should have :

Technology & Product Passion -  You should love technology and the products.  You live, eat, breath the products and the underlying technology. This passion is what drives you and is contagious which helps rally the team behind you.  Check out Steve Job's commencement speech on passion at the Stanford University in 2005.

Strong Work Ethic - This is a demanding job.  There are no working hours or holidays or vacations .  The job is not meant for someone who is afraid of hard work.  It's no different then running your own company ...you put everything you have for the success of the product line .

Intelligent-  This is a key  role.  A lot depends on the PM and the decisions you take.  PM must have a very strong  technical and business skill set.  There is no substitute to this.

Influence -You should have the ability to influence others. Cross functional team doesn’t report to you nor do you have any control over the team.   You must rally the team behind the common vision, roadmap and the overall product strategy and the key to this is trust and respect. You need to work hard at building these relationships over time and garner support from not just the technical team but also all the field teams and customers.

Core Values - This may sound a bit strange. But, this in my opinion is key.  Companies not only entrusts the product managers with the product but also the core values of the company and the cross functional team looks up to you . As I said earlier...passion is contagious and it is this passion that translates into garnering respect/support from the team and thus your belief in the company's core values should be reflected in your thoughts and actions.

Focus / Discipline -  Product Managers spend significant time on prioritizing things.   Focus on what you want to do , where you want to take the product, managing  your time, prioritization of the work, meetings etc is very important. Disciplined  and systematic approach is important else you end up focusing on all the things that really don’t translate into discovering and defining products that matter.

Communication - Need very strong communication skills . Both writing, speaking skills are essential for this job.

Additionally, there are other qualities that are important for the product manager to succeed.

  • Self Confident
  • Great Listener
  • Ability to make hard and quick decisions
  • Strong customer focus
  • Relentless focus on improving execution

One can get into the depth of each of these qualities . My hope this quick summary will help identify the key traits and what you need to focus on.  Check out the YouTubex  videos on what product managers focus on at Google : Chris, Aseem, Charles

Platform as a Service for product demos & beta programs

Developing product demos or helping pre sales/services team put the demos together is a common task performed by product managers  Many enterprises use a private cloud for hosting product demos. They have dedicated teams that performs this function with help from product managers. However, these clouds are geared for internal audience and thus limits product managers from testing new ideas/concepts with their core focus groups/user communities. Exposing new functionality (beta program, technical previews etc ) via internal demo infrastructure is complicated and usually is a bureaucratic process (multiple IT approvals) in large organizations.


Src:http://aws.amazon.com/ec2/
 
Public Cloud offerings can simplify this entire process. Cloud infrastructure can be used for demo, beta programs, end user studies etc. Vendors that offer "platform as a service" could be used to install, configure and showcase the products. There are quite a few vendors who offer these cloud services. Amazon Simple Storage (S3), Simple DB, EC2  would be a good starting point. Amazon EC2 provides a virtualized computing environment. It offers the pre packaged virtual appliances (DB, OS, App Servers etc) bundled in a native format (Amazon Machine Image format) which could be commissioned on as needed basis and configured with your applications. The "pay as you use” model makes it easy to justify the investment for your product portfolio. Try your beta / release candidate/ sneak previews with Amazon EC2.

Software as an appliance - What is it?

Software vendors are slowly moving away from the traditional delivery models for shipping software.  The pains involved in certifying products on multiple platforms, complex upgrade processes, maturity of virtualization technology, use of open source software,  simpler licensing and pricing models,  application isolation, greater hardware elasticity,
quicker sales cycle, plug and play software and lower TCO are some of the key factors fuelling the adoption of  "software as an appliance" delivery model.   Product managers should evaluate this concept as a key component of their strategy.  Here  is a simple definition of a software appliance.
 

  • Software appliance = Just enough operating system + S/W application that is ready to be consumed. This is it. Packaging could be in either on a virtual machine or a physical machine or CD etc 
  • Virtual appliance = S/W appliance supported by a Virtualization platform. Check out the VMWare marketing place to see a few examples

Do product managers need a special skill set for SaaS offerings?

I have been struggling with this question for a while. Thought, I’ll take a shot at providing insights on facts and myths about product management responsibilities in a SaaS environment. High level themes (planning, strategy, GTM plans etc) remain the same. However, the differences arise in the way each theme is handled in an on premise Vs SaaS environment. The bullets below provide a high level overview of the differences:

Theme : Product Development
Off course, development cycles are shorter. Iterative/ Agile development is must have for a SaaS environment. This also means that as a product manager you have to be quick in translating requirements into use cases and prioritization of use cases with engineering groups. Brainstorming sessions tend to be quicker, verbal discussions will be more, documentation tasks would be less. Focus should be on quick iterations and greater customer response.

Theme: Requirement Analysis
SaaS environments cannot be customized easily. Thus, clear understanding of the customer’s problem & how your feature will add value is vital.

Theme: Customer feedback
Prepare to receive, interpret feedback from multiple direct sources. Blogs, Wikis, community portals etc. Product should have built in mechanism to provide feedback to the core groups. Product managers shouldn’t cut down on the direct communication with the customer. You also need to make sure that customer input should not be tailored in manner that fits predefined customer buckets.

Theme: Usability
This is obvious. However, in a SaaS environment you have to more vigilant/informed about the user’s needs, their tasks, their aspirations for the product, user scenarios, industry and user characteristics. You have to make your customers stick to the product. The cost of moving away is nothing. In addition, strong understanding of the web based technologies is essential. Easy, simple UI that gets the tasks is important. Clear crisp use cases hold the key.

Theme: No Training
Design and develop your product with a “no training” goal.

Theme: Communities
Focus on creating and leveraging communities.

Theme: Quality
Quality is important for on – premise and SaaS products. However, with a SaaS product you don’t have the luxury to exclude your sev3/sev4 bugs also. Every user would hit the issue in the SaaS model. Besides, you cannot control what the environment on the users machine and thus the chances of running into edgy issues is very high.

Theme: Innovation
“Me too” features is a recipe for disaster.

New Product Development: Product Managers play a key role in evaluating & launching new products

Managing existing product portfolios is relatively easy than launching new products. However, as a product manager it’s vital to focus on future along with managing the current expectations. Normally, product managers are under pressure to ship the products on time meet the current customer demands/expectations and thus cannot devote time and energy on new ideas. Innovative ideas are muddled by what occurs in the present.

Strategic investments and not incremental innovations lead to great products. Gary Hamel’s landmark book highlights the importance of innovation not as a buzzword but a philosophy that every company needs to follow to create a niche market for their products. Absolute must read for Product Managers. The blog highlights how product manager contribute to the NPD process. Have highlighted the high level process below.

Step 1: Define your vision
Step 2: Define product strategy
Step 3: Ideation
Step 4: Define your business case
Step5: Define the project operating plan
Step 6: Product launch

One could easily write detailed chapters on every phase of the NPD. I have focused on the Ideation phase since this is where product managers spend most of their time.

Ideation phase is essentially a phase where product managers collect ideas from multiple sources. There is no scientific procedure to collect this data. However, one could use a disciplined approach to generate and prioritize the data points to make a compelling business case and a product that works for your market segment.

Here is the framework that one could use to collect ideas:

One could easily write detailed chapters on every phase of the NPD. I have focused on the Ideation phase since this is where product managers spend most of their time.

Ideation phase is essentially a phase where product managers collect ideas from multiple sources. There is no scientific procedure to collect this data. However, one could use a disciplined approach to generate and prioritize the data points to make a compelling business case and a product that works for your market segment.

Here is the framework that one could use to collect ideas:

Customer Visits (Most Important)/Lead User studies: Coordinate customer visits to gather ideas from your lead users and not the representative users. Lead users are smart, are aware of the business, products, industry & technical trends and have ideas. It’s important to work with smart people inside and outside the company if you have to focus on creating innovative solutions.

Talk to your sales: Relationship with folks who sell the product is important. They are closest to your customers.

Brainstorming sessions with R&D and cross functional groups: As stated above…its important to work with smart people. Assemble a team with cross functional group participation and setup a whiteboard discussion. Don’t forget to include your support team. Unfortunately, many IT companies do not involve support in the product development process. During the session highlight the high level use cases, analogies, metaphors…anything that gets the discussion going and helps generate ideas. At times, this functional group could be from a different product unit. Cross – pollination from one product to another can lead to new products/newer selling channels.

Competitive studies: It’s easy to learn about third party products. There are quite a few forums to gather this data.

Past success: Established products have this luxury. Learn from your past

Market Research : Technical forums, social networking groups, focus groups, seminars etc: I’d categorize everything else that you read/explore as a vital step that is essential