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.

Agile Development And Co-innovation Across Three Countries. Hits And Misses

The Career OnDemand team works out of  three countries. Germany, Hungary and USA. The development team does 4 week sprints. The user experience team does weekly updates to the entire team on their progress. Their work almost feels like a weekly sprint to me. Both the teams record the presentation and conversation using Adobe Connect and share it with those who could not make it. Since the teams works out of Germany, Hungary and California, the recordings are very important assets to share, review and discuss. All conversations, both intelligent and not so intelligent are recorded and preserved for everyone to listen to. It is sometimes shared with people outside the team.

Prototyping 
Use experience teams create html prototypes in a tool called ForeUI to convey the detailed design and flow of the various product stories. The product owners who work with co-innovation customers build prototypes using a tool called Axure so that they can convey concepts as tangible experiences. They update the prototypes at least twice a month and share the concepts and flow of the story via video with other product owners, user experience designers and development architects.

Storytelling
Concepts are directly built into html prototypes and conveyed in person or via video. Very little is captured in PowerPoint. No market requirements document was written. The concepts are conveyed via story telling, in person, via web conferencing or via video. For example, the employee stories was repeated more than 175 times to customers over 12 months to refine the story and prototype.

Radical Transparency within the team and for customers
Almost every week, team members and customers get to see the current concept and latest screen designs. Every month everyone in the team gets to see an update of the functioning product. There are some use cases and spec documents. But mostly teams rely on what they see. Not what they read. There is one exception. There is a wiki page where decisions are captured.

The design specification is not a contract between product owners and developers
The good thing is that there is no design specification that is treated like a contract. A poor idea, even if it is written down, is not implemented if product owners are not convinced. Almost every feature can be tracked back to a customer conversation. No feature gets developed before a customer has a chance to review the screens and flow of the story. This is very different from how SAP traditionally develops software. There are some problems here and there. It sure requires a high level of trust and personal accountability. Sometimes it feels like no one is in control. But, so far so good.

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.

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.

Tell a Story Rather Than Write Minutes Of A User Interview

I have spoken to tens of end users in the past few months about their workplace aspirations, challenges and problems. Some times I speak to them in person and some times over the phone. I always do this along with another colleague. One of us takes the lead on asking the questions and the other one writes down what he hears.

Rather than write my notes in a note book, I learned from @MChewD to write my notes with a thick pen, such as a Sharpie, on rectangular Post It notes while I am interviewing the person. When ever I identify a topic under which I can group the notes, I write the topic down on a Post It note with a thick Whiteboard marker.

If I am meeting the person face to face, I invite the person to walk over and see my Post Its and check If I captured their thoughts correctly.

After the interview, I collect the Post Its and go to our project room or my desk and paste the Post Its on the wall while sharing the story of the person we interviewed with my colleagues. If another colleague has taken down their notes on a Post It, they will post their notes on the wall as well.

This process almost always induces a conversation, about the person we interviewed, the main themes that emerged and the big takeaways from the interview. The beauty is that all this happens right after the interview without a formal meeting set up. In fact, we do this sometimes within a few minutes, in the time it takes to set up a meeting on Outlook.

Give it a try. Keep your note book and fine point pens away and use Post Its and Sharpies to capture your interview notes.

I follow different research principles, when I visit customers and talk to a group of people.

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.

Storing Data In The Google Cloud With Google App Inventor

Two product management colleagues from the US and a product manager friend from India reached out to me and said that they are very curious about Google App Inventor. One of my colleagues who is from the SAP Mobile Product Management team wanted to know how user preference data can be stored on the cloud and retrieved when a person uses another app.

For example, a person can say that he prefers a green background when he is using one app and another app can pick up that preference and set the background of the second app green. This feature lets multiple apps or multiple people access the same data stored in the cloud. This is a very powerful feature. Data is stored in the Google cloud.

This is very straight forward to do in Google App Inventor. I created an app where the user choose the background color for the app. The app stores the data in the Google cloud. When the user restarts the app, it retrieves the data from the cloud and uses that information to set the background color.

Here is a video demonstrating the concept using two mobile apps.


Here is the complete code for the mobile application, i built to explore this feature.

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.

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.

Simple Prototypes Lead To Complex Intelligent Conversation, Complex Ones Lead To Simple, Stupid Conversation

For the past several months, I have been showing prototypes of people management software to hundreds of colleagues, customers and research partners. When the prototype I showed was simple, clear and uncluttered, it led to complex, intelligent and meaningful conversations.

When I showed a cluttered prototype with too many ideas packed in a screen, it consistently led to simple, shallow, stupid and meaningless discussions.

This might be another reason you may want to think mobile first.

Google App Inventor - A Simple Twitter Client

Google App Inventor is a visual tool to develop simple mobile apps without writing any code.

Today I wrote a very rudimentary twitter client for the Android phone using Google App Inventor. My app enables anyone with a twitter account to authenticate themselves and tweet. It was an interesting exercise to register the app with Twitter first, get the necessary Consumer Key and Consumer Secret codes and connect to twitter from the mobile app.

This may not sound like a big deal for my development colleagues. But it is a big deal for me, because I am not a mobile developer and have never written code for a living. I am a product manager with a product design background, who makes prototypes to understand the market and people.

You may be hesitating to start making mobile apps of your own, thinking that you are a product manager or product marketer with an MBA and limited technical skills. I assure you. You can do it even if you have an MBA. I have one and I was able to do it.

I am convinced that Google App Inventor can be a useful tool for product managers and product designers who like making things. To convince you that it is easy to write app inventor applications, I have posted the logic of the twitter client I wrote here.

All the logic you need for a simple twitter client

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.