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.

 

http://www.livetime.com/wp-content/uploads/2009/07/Picture-4.png

• 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