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