Road-mapping User Journeys Is Better Than Road-mapping Features

Heads of product will face this problem in most software product companies. During every planning period, every product team comes with a long list of features they want to build. Most features will have cryptic names that few people understand and investments are made without even a clear idea about what is being built let along the return on investments. All well-meaning product teams clammer to get their features in without realizing how they fit into the overall objectives of the company. They build the features. The features don't fit well together. Even if they are good, they never get promoted to the right users at the right time. Even in the event the products are used, the reporting teams don't have an idea that the features are getting used because they did not built the tracking instrumentation. Product marketing teams or aggressive sales teams make up their own stories about what the product can do with little input from the teams that built the product. Once the product is made available, disgruntled customers complain bitterly and refuse to renew their contract. The sales team comes to the product team and requests for features. The product team build features with no purpose other than to keep the contract from getting cancelled. Everybody loses including the customer.

Such behavior of product teams might be overlooked for a while in a large company with a very successful product that is already a market leader and makes huge profits. However if you are a company trying to build a product for a new market or if you are a small company working hard to keep your customers, this sort of behavior could kill your company or at the very least your product managers our of work in a couple of years. Slowly but steadily, product managers who build features without knowledge of user journeys and without tracking usage will slowly lose investment and their value to the organization and eventually their job. In other words if one wants to succeed as a product manager of product leader in the long run, user focused and data driven roadmap planning is probably the only way to go.

Changing behavior of product teams is very hard. But there is a framework that might work. In my early experiments with a user journey driven framework for roadmap planning, I see acceptance from various teams and acknowledgment of value from product managers. This is the framework. Ask your product teams, including product managers who build features, product managers who are custodians of existing features, user marketing teams that promote your products and analytics teams that instrument your product for tracking and reporting to think about all their features, assignments and campaigns in the context of a user's journey. Here is an example of a user journey [1] where multiple teams contribute.

 

Ask them to build a collection of the top 5 users journeys that their features form a part of and estimate the impact of those user journeys on product objectives. To do this first, they have to think about the user. Second, they have to think about the other product managers and teams that they need to rely on and collaborate with. Third they need to focus on how much engagement does their feature bring today. Fourth, they need to collaborate with the analytics teams to estimate the potential impact of the user journey on product objectives. Fifth, they need to identify instrumentation gaps in their features and think about building just the right instrumentation for reporting purposes.

During this process product teams will realize that a feature cannot become successful on its own. It required some one such as a user marketing teams and other upstream features such as home page or mobile channel to promote it. User marketing teams will realize that there are good features that bring value for customers not being promoted. Product managers will recognize that their feature usage is not being tracked by the reporting teams. This will help them convince the reporting instrumentation teams to build just the necessary instrumentation. Product teams can communicate a collection of user stories to product leaders, product marketing and sales so that they sell what has been built. Not what they cooked up. Customer success teams will be happy because they will get accurate reporting on user journeys that matter without having to wrestle with the analytics team to dig up data every time they have to report progress to a customer.

I am not saying this is easy. However it has worked in the past for me and my new experiments are showing signs of more promise.  If done right, this approach could be the difference between your small software company staying in business or going out of business.

If you don't have a framework for evaluating features, product teams will use phrases such as 'customer commits',  'table stakes' or 'strategic project' to justify the investment. While customer specific features are part of every product team's work, when you hear such phrases from more than 25% of your product managers, as a head of product, you should be very concerned because you will end up with a hodgepodge of features that bring no value for your users. If you are a CEO, and you hear phrases like these from your product team very often, you should be very concerned because your investment is being squandered by a team that is inexperienced and has no framework for execution towards your business goals.

[1] The user journey discussed above  is for a business to business to consumer (B2B2C) product company. Many enterprise software companies fall into this category. I am making the assumption here that you are a cloud product company and your customers pay you if and only if you can prove to them that their employees are using your product to either stay compliant, save money or help you make money.

The main ingredient in design thinking, customer development and agile programming is people

I enjoy cooking South Indian food at home. The secret of any cooking, I learnt from the cook books I read, is fresh and appropriate ingredients. Even the best of recipes is useless when the right ingredients are not in place. So I always have fresh ginger at home. Since it is hard to keep fresh curry leaves, I have a plant in my backyard, which I take a lot of pain to keep alive.

@enricgili and I were talking about similar things today afternoon. The main ingredient in design thinking, customer development and agile programming is people. No amount of process definition is going to ensure success unless the right talent is assembled. Yet, relatively less attention is paid to finding and assembling the right talent. A lot of energy is spent on defining the process. The process, like a recipe for cooking, is important. However, the right people, like right ingredients for a dish, is always the place to start.

Thinking Mobile First Helped Us Improve Web Experience

While designing Career OnDemand, we started by thinking mobile first for most of the use cases. This forced us to think about the most important information to be presented on a screen and the most important action to be performed on a screen. We did this even thought we had no firm plans of releasing mobile apps for all use cases in the first wave.

However, identifying the most important action on every screen helped us highlight the buttons or user interface elements in the web interface with bright orange color. This was received very well by people who experienced our interface design.

This is not a Career OnDemand screen

We Think A Lot About Where Not To Focus

The Career OnDemand product designers and product managers spend as much time thinking about where not to focus on as much as they think about where to focus on. 

I find the iPad Value Curve, which I found in UXPlanner.com very useful, while determining product strategy at the early stages. We used this approach to determine the features we need to focus on.

Focus on a few things. Don't try to solve all the problems.

Knowledge Flows Vs Knowledge Stores

The book, The Power of Pull by John Hagel and John Seely Brown, influenced our thoughts significantly while designing the informal learning framework in Career OnDemand. We did not place much emphasis on storing knowledge. Instead we focused on how to quickly connect people with passion and generosity with curious people who have an open mind. We focused more on moving ideas quickly from person to person rather than organizing the knowledge in a neatly formatted way in a huge knowledge store.

In fact knowledge is so quickly accessible and perishable today, that we consider the effort of building knowledge stores almost a waste of time. Even when we attempted to store some knowledge, we just used it as an excuse for generous and curious people to start a conversation that leads to new ideas and creative friction.

We put the foundation in place to track these relationships and recognize the contributors and the consumers. If you are in the people management business, I highly recommend the book and the video below.



If you want to discuss this topic, talk to my colleague @burningcrow. He is very passionate about this topic. If you are interested in getting an early peak into Career OnDemand, please let me know. I'll show you what we have done so far. There might be some paper work. Don't worry. I'll deal with it.

Mobile First by Luke Wroblewski

I attended a session by Luke Wroblewski on Mobile First today in the offices of Ning in Palo Alto. Since we have been thinking mobile first for the design of Career OnDemand with good success, I went to this meetup to see what's new. There are a lot of new things. Here is his current presentation. http://www.lukew.com/resources/articles/MobileFirst_LukeW.pdf  I highly recommend it. Please visit www.lukew.com for his upcoming talks. He has a book in the making named Mobile First.

In Career OnDemand, we designed every use case Mobile First. We painstakingly created prototypes for every sea level use case for the employee view and manager view. It helped us focus on the most important things, clarified the purpose of a use case and made the use experience significantly better.

When we transferred the mobile first design to the web, the main button that showed up on the mobile screen was displayed in bright orange color in the web page to indicate the most probable action to the user. It was received very well by users. I'll keep you posted.

Not Everyone Is A Visual Designer

While designing the profile pages of Career OnDemand my colleague @enricgili brought up an important point. Not everyone is a visual designer. Not everyone wants to be a visual designer. Not everyone has the skills to be a visual designer. So we decided to request users to provide and content and prescribe a look and feel for them rather than give them greater control over the branding of their page.

At the same time we decided to let them provide access to websites that help them promote their brand and expertise from their profile page. This product design guideline helped simplify many of our conversations and decisions.

If you are an About.me fan you might like the approach we are taking.

Sales OnDemand User Experience Was Built By UX Designers And Product Owners

The role of a user experience designer and product owner are changing drastically now-a-days. Design has become very important and yet companies do not hire sufficient number of designers to cover the work. I was curious how the Sales OnDemand team handled this situation. I posed this question to Prerna, one of the UX design colleagues. She said that User Experience designers provided the basic screens to the product owners and explained the broad framework within which product owners needs to operate. Product Owners did a significant portion of the user experience design themselves.

This makes a lot of sense. Design is how things work. It is not just how things look. So the product owners who have a deep understanding of the needs of customers should be able to think through how the product will work and represent the flow in some form.

Such product owners will be successful in the future. Those who don't run the risk of failure.

The Book That Inspires And Motivates Me To Pay Attention To Experiences

A while back I was collaborating with my colleagues to design the home page of Career OnDemand. Since the home page is an entry point for the application, I decided to go and look up the book, Pattern Language by Christopher Alexander. I am big fan of this book and the way it describes experiences of everything from entering a home from your car to meeting friends in your neighborhood.

My colleagues and I are putting people first and paying close attention to the experience of a person at every stage of his or her interaction with Career OnDemand. We are prototyping the user experience and testing the same with people even before we write code. We are working hard to ensure that the application works the way people normally do their work.

Here is the experience of walking from your car to the house and kitchen described in the book, Pattern Language".

The snap shot above is copyrighted material. I have shared it to promote the book. If you like it, please buy the book. This is a bible for anyone who cares about design, patterns and building meaningful experiences.

The Purpose Of Multiple InBoxes

I used to wonder about the purpose of multiple emails inboxes in multiple systems. For example your online back account has its own inbox. Your hospital's online account has one. I thought all we needed was just one universal personal email inbox provided by providers such as Google or Yahoo.

A message from my bank today gave me some insight into why my bank wants me to have a separate inbox, which has a higher level of online security. When there is a sensitive message to be shared, my bank posts the message to the inbox maintained by the bank, and only sends a notification to my personal email account. I am forced to go online into the more secure inbox to check my sensitive message. I think my hospital might do the same thing. Now I understand the purpose behind multiple inboxes.

People Centric, Collaboration In Context and Mobile First

I am working with several brilliant colleagues on the next generation of people management applications at SAP. After talking to hundreds of people, and tens of thought leaders and customers we have distilled out principles for the next generation of people managements apps to three things.

• People Centric
• Networking and Collaboration in context
• Insight Everywhere
• Mobile First

People centric thinking puts the person first and process next. We realized that, but for some special cases, meeting the needs of a person and providing instant value for a person is more important than ensuring the integrity of a process. While we will strive to ensure the integrity of all processes, we will address the needs of the person first and make our tools useful for the person and make it work the way they work, when they want it and where they want it.

Collaboration In Context brings collaboration to the context of the person rather than ask the person to take the context to a separate collaboration space. We decided to bring the most appropriate collaboration tools to the context of the work as and when required.

Mobile first: As part of our research we learned than it is matter of a couple of years before majority of access to business software will be from mobile devices. So we start our design process now-a-days by thinking mobile first. 

If you like our thinking and would like to join us in Palo Alto, please let us know. We are looking for people like you. Let's build disruptive people management tools for the idea driven economy.

Drawing And telling Stories During a Compressed Workshop

This week, several colleagues and I had a three day workshop to start the design process for a new product. Nothing new. We do that all the time. However, this time we were on a compressed time schedule where we had limited time to capture our ideas and turn them into stories.

On day three of the workshop we split into multiple teams to create a high level story within 45 minutes. Normally we take the time to draw detailed stories to communicate the story, the principles and the ideas. Such detailed stories may look like the image below.

Since we had no time to draw stories in the comic strip format using tools in an electronic document, we just started drawing the comic strips on the white board. It helped us formulated the story of a person who needed to get something done.

We had a challenge. How do we take this story, in the form of a comic strip drawn on the white board, quickly to the workshop room? We decided to take a picture of the white board and email the picture to a colleague. We then showed then projected the picture on the wall to explain the story. It was received well by  all participants.

Later we could print the photos and add them to PowerPoint slides for presentation and storage purposes. It took a bit of image processing to ensure that the prints were clear.

It does not matter even if you have limited drawing skills. Drawing liberates the thinking of the team creating the drawing and the opens up the minds of people who see the drawing. Give it a try. It works well even for heavily compressed workshops.

A Camera App Using Google App Inventor

I built a Camera app using Google App Inventor today. In the video below I demo the app and explain how it was built step by step. I have also posted the entire App Inventor code required to build this camera app below.

Mobile Usage Of Your Products May Change Your Product Strategy

I met a friend who works at eBay, the auction site, yesterday. She shared an interesting story with me. eBay, she said, was slowly moving away from being an auction site to a fixed price online store such as Amazon. Then something interesting happened. eBay product designers and engineers created a mobile version of eBay.

People who use the mobile version of eBay started participating in auctions more than fixed price purchases. This behavior may influence eBay's product strategy, she said.

I find this remarkable. But I am not surprised. eBay auctions mobile brought the adrenaline rush of competition and gaming to you no matter where you are. Users were willing spend more time and pay more money for the experience of competing against each other to get what they want and were willing to pay more for the experience.

I firmly believe that mobile delivery will significantly alter the expectations and behavior of your users.

For designers of enterprise software, particularly human capital management software, this is a great opportunity. This is an opportunity to think mobile first, rethink your software as a tool that helps to connect people and move ideas from person to person rather than move documents from desktop to desktop.

I am cautiously optimistic about the possibility of enterprise software that people would actually enjoy using, may be even look forward to using.

Design your Software Use cases for OnDemand Products like Romanesco Broccoli

Design your Software use cases for OnDemand products like how nature designed Romanesco broccoli. Start with a few core use cases. Add use cases in such a way that even a few of them will make a whole product. Keep option open to add or remove use cases where appropriate.



If the development team runs into feasibility issues or time constraints they will still have the opportunity to build a product that is useful, consumable and looks like a small version of the whole.

Constraints, Ironically, Help Produce More Ideas

In the book Made to Stick, the authors ask the readers to go through a mind exercise. They ask readers to write down all the white things they can think of in 15 seconds. Then they ask readers to write down all the white things inside their refrigerator. The authors say that people produce a longer list of white things when they start thinking about things inside a refrigerator.

I tried this at work last year. In my experience of designing several software products using tens of prototypes, I found that I was able to produce more and better ideas when I started thinking mobile first.

The Architecture Of Your Product Needs To Enable The Movement Of Ideas, Not The Movement Of Documents

When I work with my colleagues in Walldorf, Germany, I work from Building 18, which is called the star building, because of its shape. The building is relatively new. Its star shaped architecture enables many chance encounters and micro discussions, which is where many meaningful decisions are taken at SAP.

The bathrooms, coffee, water, discussion tables, smoking room and meeting rooms are all in the middle of the star. So those who need to use the bathroom, drink coffee or water, need a table to chat or smoke must walk to the center of the star. When we we do this we invariably run into a few colleagues with whom we need to talk. There are many tables and chairs nearby to facilitate a quick conversation where ideas are exchanged and decisions are taken.

This change in office architecture has happened in recognition of the fact that most products today are an assembly of individual ideas. The more the interactions, the better the ideas get. The goal of most workplaces in the developed world today is not to move material from one workstation to another workstation as quickly as possible. Instead the goal is to move ideas from one person to another as efficiently as possible.

Designers of enterprise software need to recognize this change in the nature of work. Let us design enterprise software that is a virtual version of the star building at SAP and enable chance encounters of people as many times as possible in a day. Let's build collaboration into the core architecture of the products we design. Let us move ideas from person to person rather than documents from server to server.

Rely On Design Principles Rather Than Slave Over Useless Accuracy

When a product team wants to create a product, there are two approaches. The first approach is for a product manager to slave for months to write elaborate and detailed specs and hand over these uselessly accurate specs to the product development team and hope that they will appreciate the intent, understand the requirements, read the details and develop the product. From experience, we know that this approach fails more often than not. Product managers and developers end up quarreling with each other, bargain with each other and grudgingly accept realities and slowly but steadily become skeptical of each other.

The second approach is to establish a common schema for the team and then write compact stories or simple prototypes that convey the core requirements to designers and developers. The development team members who receive a compact set of stories will rely on a commonly understood schema, which is a set of design principles, to elaborate the compact stories into full fledged requirements and then turn them into products. The important thing to note here is that the people who make the product are given the responsibility to come up with ideas to realize the product.

In large organizations, a design thinking team outside of the regular product teams can take the key responsibility of creating and evangelizing this schema with all the product teams.

At my work place, we have a product design team lead by @MChewD. His team of design thinkers and practitioners have constructed a common schema with core design principles. They evangelize the schema via workshops to my design and development colleagues.

This makes my job as a product designer and product manager a delightful one. I get to focus on the core requirements, convey compact yet clear needs to my colleagues and rely on the brilliance of my design and development colleagues to pour their creativity to turn my requirements into tangible products. Along the way they enrich my intent with hundreds of their ideas and surprise me with things that I never imagined. I get to avoid useless accuracy and focus on the things that create incredible value for my customers.

This is possible because we rely on a commonly understood schema rather than useless accuracy.
Try this approach. I am sure  you will find it useful.

My Answer To The Question - How to become a product manager?

I answered the question "How to become a product manager" in Quora. Here it what I wrote. Let me know what you think.

The primary responsibility of a product manager is to be the voice of the market. This requires experience in a domain, curiosity, empathy for people and their problems, skill to conduct market research, the ability articulate a product to the people who build it and the ability to articulate the meaning of the product to the people who buy it.

Engineers who have worked in a domain for a long time become product managers. They take the experience route. User Interaction designers or product designers who work with other product managers gain domain experience and go on to become product managers. Product designers, typically with interaction design or industrial design background can bring important skills such as user centric design and similar research methodologies to the table. Engineers and MBAs are not trained in such methodologies in college.

Companies hire MBAs right out of college to manage a product because of their quantitative market research skills. Such MBA's normally, though not always, tend to take the product to the market first and then slowly and steadily gain domain knowledge, gain ability to conduct customer research and, sometimes, the ability to appreciate good design. 

When I first interviewed for a product manager job, I got the interview because I had an MBA. MBA will open doors for you. But an MBA may not get you the job. I was hired because I had more than 15 years of domain knowledge in the field of human capital management.

The two day course "Practical Product Management" conducted by Pragmatic Marketing is a good course to attend to bolster your chances before applying for product management jobs. The course will give both engineers and product designers the edge they need.

The ideal way to step into product management is to find a product manager who is willing to mentor you, preferably on the job.

There is a school of thought now-a-days that says that the ability to design and the ability to make things with your hand are far more important than the ability to analyze, prioritize and manage. I believe thinkers need makers and vice versa. If you can think and make then you are in the Mark Zuckerberg, Bill Gates category.

What If Enterprise Applications Were Like Wooden Furniture

One of the real world  examples enterprise application designers could look at is wood furniture. The more you use it, the more character it gets and the more desirable and more valuable it becomes.

Enterprise software application designers should strive to build a framework that enables users to add their inputs to the tools they use. These inputs could be content, and at more advanced levels, functionality. It is possible. At least, this should be one of the design principles to strive for.

Software that gets better with time and usage is a delightful thing.