Tag: Design

Kathy Sierra on Making Users Awesome, Part 1

In the book, Badass: Making Users Awesome, Kathy Sierra analyzed and discussed the new ways of thinking about designing and sustaining successful products and services.

These are some of my takeaways from reading the book.

Imagine we are in a game with one objective: producing a bestselling product or service with no marketing budget and no PR stunts. The product or service also must be sustainably successful. In other words, it is not a short-term fad. Kathy believes this is achievable with skill and strategy.

The answer to the previous question does not live in the products or services themselves. Surprisingly, the answer lies in those, the users, who use those products or services. True, trusted recommendations are the beginning of answering the ultimate question.

We may be tempted to look for common attributes across awesome products and try to duplicate those attributes. What we should be doing is to look for common attributes across awesome users of those products. Another word, awesome product is mostly a by-product or side-effect of users who can produce awesome results from it.

When users get awesome results from our products, they become badass users. Badass users are more skillful and more powerful in getting awesome results that are personally meaningful.

When badass users evangelize our products to their friends, they do not do it because they like our products. They do it because they like their friends and want to share the great results with them.

It turned out that most companies compete on the quality of the product (product/service awesomeness), not the quality of the user’s results with the product (user awesomeness). Competing solely on product quality has little headroom, especially when everyone can practice six-sigma and other quality-assurance frameworks.

Competing on the user awesomeness scale gives much room to maneuver and to grow. There are many more varieties of user awesomeness playing field to work with. As a result, we can intentionally design our product/service to serve a tribe of users and reduce the competition.

Competing on the user awesomeness scale requires us to think carefully and hard about the question of “Badass at… what?”

  • What does our product/service enable?
  • What can people now do because of our product/service that they could not do without it?
  • What can people now do better because of our product/service?
  • What are people not doing now, but could if they took advantage of all that our product/service supports?

Kathy encourages us to think hard about the “Compelling Context.” People do not want to be badass at user the tool/utility we created. They want to be badass at producing better results with our tool/utility.

But what defines “better?” Better is like when we upgrade our TVs/monitors from standard resolution to higher resolution. Higher resolution means more details. More details enable higher expertise. Higher expertise notices and appreciates more details, so they support each other. In other words, badass means a deeper, richer experience for the users.

Higher resolution also results in higher-end products/services. When we do not just upgrade our product but also upgrade our users, chances are more of them will become badass users. Badass users talk, and they are our best source of authentic, unincentivized recommendations.

One last thing. World-class customer service does not always result in more badass users. Badass users only come from helping them grow their skills, resolution, and results. Don’t just make a better tool/widget, make a better user of tool/widget!

Math of Success, Part 2

Scott Adams introduced the notion of acquiring multiple skills to enhance our chance at succeed in something. In his book, How to Fail at Almost Everything and Still Win Big, Adams talked about the math of success.

Adams believes the best way to increase your odds of success is to systematically become good at the types of skills that work well together and are highly useful for just about any job.

He listed the following general skills, and I will write about what these skills mean to me personally.

Design (the basics)

I agree with the book that we are all designer of something. Design is no longer confined to just something visual. Anything that has a user interface aspect, whether for a product or a service, can benefit from thoughtful design.


Effective use of communication can make the other person feel good about the conversation, about you, and about themselves. Adams suggested a seven-step approach to conduct a conversation using stories. The book also recommends the composition of a good story and what aspects to avoid. Effective communication helps to build the connection between two people.

Overcoming shyness

Adams suggested that the single best tip for avoiding shyness involves harnessing the power of acting interested in other people. Acting interested in other people needs not to appear phony if done with genuinely honorable intention – not to mention it is still an authentic and civilized thing to do. Overcoming shyness is a learnable skill and worth the time doing it right.

Second language

The book discussed knowing a second language can be a competitive edge and opening more career or professional options – to which I agree. I think knowing a second language opens other possibilities such as cultural exposure and entertainment varieties. Picking up a second language is not a trivial effort. I believe learning a second language can be made more accessible by complementing the language with their hobbies or professional interests.

Change Management Process Design – Part 2


This post is part two of a series where we discuss the ITIL-based Change Management process and how to put one together. In the previous post, I presented some design considerations such as goal/purpose; the intended scope; and roles and responsibilities. In this follow-up post, I will discuss additional process governance and planning elements.

Categorization and Prioritization

Why do we categorize? Proper categorization can facilitate or drive certain governance decisions. Categorization can drive the lead time required for review and approval. Categorization can also determine what process workflow or approval authorities may be required to facilitate the change. ITIL recommends three types of change request: Standard, Emergency, and Normal. If ITIL’s definitions work for your organization, go ahead and adopt them. However, that categorization alone is probably not sufficient to describe the changes and how they affect the business operation. Finding a way to describe the risk and impact associated with a change is also important. Risk can be used to measure the level of the potential disruption of business operation associated with a change request. Impact can be used to measure how far-reaching a change can be. The key idea here is to find a way of properly assessing changes and managing risks.

When designing a categorization scheme for changes, I recommend examining your existing incident and problem categorization scheme and make an attempt to have a consistent categorization across the ITSM processes. I believe that a uniform categorization will make risk assessment more reliable than not having it. A consistent categorization could also make the design and analysis of the reports more meaningful. Some organizations choose to use separate categorization schemes for incidents, problems, and changes – a decision sometimes influenced by the organizational boundaries or the tools on-hand. Just keep in mind that a change management exercise is also a very much a risk management exercise.

Workflow and Documentation

Once you have the change requests categorized, you will need a workflow to process the change requests for review and approval with a well-defined lead time. These lead-times are necessary to provide the adequate time required to review and to approve the change request by the change manager and the stakeholders. Many organizations I was with have had either weekly or semi-weekly CAB review cycles. That means the approval and scheduling timing need to be well defined so CAB and change manager can review, discuss, approve, or even escalate the change with sufficient time. Also, different types of change or change risks/impacts will likely require different lead-times or maybe different work-flows to process them. Some organizations may be required to impose change freeze windows in order to support critical business systems or processes.

Just like other ITSM artifacts, change requests should be documented and, ideally, captured in a tool. The levels of detail needed to be capture will vary from one organization to another, but most organizations should capture the baseline of required data such as:

  • Change requester, owner, and implementer
  • Type, category, risk, impact, priority as defined in the process document
  • Configuration items (systems, applications, devices, etc.) affected by the change
  • Summarized and detailed description of the change
  • Business justification
  • Proposed schedule or implementation timing
  • Dependencies and required resources identified
  • Key approvers needed
  • Final report on the closure of the change

Once the changes are captured and processed, the process guide also needs to define the necessary communication and coordination mechanisms to support the change management activities.

Metrics and Measurements

Tracking and measurement are the key elements to the continual process improvement. Depending on the goal and purpose defined for the change management process, we can further define the critical success factors and the key performance indicators we will need to track in order to measure the effectiveness, efficiency, and the quality of the process. The process design should spell out the metrics requirements and make sure the tools can support the required metrics.

Process Integration

It will also be useful to define some potential connecting ITSM processes to CHM. Incidents, problem, change, configuration, and release management process all have activities that are closely tied to one another. Which processes will trigger the CHM process from an upstream workflow or will receive the CHM output downstream? If you have an incident identified and it requires changes implemented to restore the service, how will those changes be handled? If you practice problem management in your environment, how will CHM process be injected into the root-cause remediation or deficiency remediation activities? Will the incident tickets, problem records, configuration items, and requests for change be linked in some fashion? These are just some governance related questions that should be considered upfront as they will affect how you plan and design the CHM process.

In the last two posts, we just went over a number of governance and planning elements for the change management process. We talked about the scope and purpose of the process, how we categorize and prioritize changes, the essential roles for executing the process, the necessary categorization, workflow, metrics, and integration with other ITSM processes. On the next post, we will go over and example process flow and spell out more details for the change management activities.

Change Management Process Design – Part 1

http://www.dreamstime.com/-image25302740This is the first post of a series where we do the tutorial and some deep-dive of an ITIL-based change management (CHM) process design. In the next few posts, we will go over some of the process design considerations such as the goal/purpose; the intended scope; roles and responsibilities; RFC categorization and prioritization; scheduling; integration; and metrics and measurements. Towards the end, we will examine how all these planning considerations come to together as we design the example process flow.

Goal and Purpose of Change Management

When designing an ITSM process such as change management, one of the most fundamental questions to ask is why your organization needs a formalized process. By ITIL’s definition, the intention behind the change management process is to control the lifecycle of all changes. By exercising proper control over the changes, we put ourselves in a better position to benefit from the changes and to minimize any potential disruptions to our IT environment. Do most organizations need a formalized change management process for their IT environments? I believe so because changes are a part of our complex IT and business environments. There are a number of reasons and objectives for an organization to implement a well-organized change management process. Some of those reasons include

  • Accommodate changes but not at the expense of system or application availability
  • Identify and categorize changes that may have different approval workflow or implementation lead time
  • Determine a better approach of assessing the levels of risk and the potential impact
  • Ensure that request for change (RFC) is properly evaluated for technical merit and balanced with the business needs

Depending on your organization’s intent or requirement, it is important to determine your objectives and fully answer the question of “why.” For many organizations, having a well-thought-out and documented change management process can help reduce the risks brought on by poorly planned changes. That, in turn, can go far in strengthening the IT organization’s ability to deliver timely and useful technology services that meet the needs of business.

Scope and Policy Implications

In defining your change management process, it will be useful to define a few scope or policy related items upfront. Some of my thoughts are:

  • To what organizational boundaries will the CHM process be applicable? Who should initiate, review, and/or authorize the CHM activities? Like implementing most ITSM processes, the benefits will be more far-reaching and visible when everyone is adopting the unified approach and vocabulary. Consider just how connected many business systems are these days in order to support the business processes or services, it will be important to understand and determine scope boundaries of the CHM process beforehand.
  • What activities constitute changes and will all changes receive the CHM treatment? Fundamentally, I believe all alterations to the enterprise-wide computing environment should be treated as changes, and those changes should be handled, in some fashion, by the CHM process. Depending on the technical nature and business implication of the change, some organizations may require different levels of review or scrutiny for different categories of change. To have an effective CHM process, all changes should be identified, addressed, and documented by the process in some ways.

Roles & Responsibilities

A change management process can involve a number of participants. Here are some typical roles to be factored into the design.

  • Requester: Who can initiate a RFC? How will the requester participate in the overall CHM process?
  • Change Management Process Owner: The process owner makes sure that the process is defined, documented, maintained, and communicated at all levels within the organization. The process owner is not necessarily the one doing the actual work, but the process ownership comes with the accountability of ensuring a certain level of quality for the process execution. The process owner also drives the continuous improvement activities for the CHM process.
  • Change Manager: The change manager is the main actor in the CHM process and has the most visible role within the CHM process. The change manager ensures all RFCs receive the proper handling and review by chairing the Change Advisory Board (CAB). As an outcome of the CAB meeting, the change manager publishes and communicates schedule of changes. The change manager is also responsible for reporting the metrics to the process owner for quality assurance and continual improvement purposes.
  • Change Implementer: The change implementer role is often played by the subject matter experts who perform the implementation work. After the change is executed, the change implementer also reports the outcome of change to the change manager for documentation and further actions.
  • Stakeholder: There could be several different types of stakeholders involved in CHM process. The stakeholders should be identified as members of the CAB or for RFC approval purposes. Ideally, the CHM process could use at least one executive-level stakeholder who can act in a governing or mediation capacity when conflicts arise.

We will discuss additional topics such as RFC categorization and prioritization; scheduling; integration; and metrics and measurements on the subsequent posts. Stay tuned, and I welcome your feedback.