Image Source: kcet.org

Many times I come across quotes, phrases, small nuggets of information that seem profound yet do not require an entire blog post. Henceforth, I will post such pieces as “microblogs”. No fluff, no detail, just the condensed version.

UX vs UI

Lipstick on Pig

Image Source: lipstick-pictures.blogspot.com.au

Oh, the confusion! Saying UX when you meant to say UI and vice versa? Believe me, I have been there. I have watched designers and UX experts cringe when I mixed up the words. I think I understand them better now. And not because I got myself a certification in either. It’s because I am a foodie! So, I will explain you the same way I understood it.

How many times have you dug your teeth into a pie (or a burger for that matter) that looked tantalising only to realise that it didn’t taste as good. All those pretty pictures of food in advertisements (I call it food porn) that left you salivating and yet had you taken a bite of it, you would have probably ended up in the hospital. That’s all fake. But I don’t want this post to turn into a rant on how advertisers mess with our senses so I will stay on course.

How the food looks is its UI (User Interface). What you feel when you eat it is its UX (User Experience). If it looks good and tastes good, you are a winner (and so is the chef!). However if it looks good but doesn’t taste so, then you might not visit that eatery again (don’t go there on a date). If it doesn’t look great but tastes awesome, then you might want to go there repeatedly (it might be a tad difficult for the eatery to get customers in the first time though). Now let’s see how does this analogy work with digital screens (websites, mobile apps, etc.).

When you look at a website or a mobile app that looks really slick but is a nightmare to work with because of convoluted workflows, you have a great UI but bad UX. The opposite is when you have an average or poor looking screen but it does what it says and doesn’t tax your brain in the process. That is when you have a poor UI but good UX though such scenarios are rare. A winning website or app not just looks awesome but also lets the user cruise through it leaving him with a sense of satisfaction and accomplishment.

Sometimes the experience with food goes beyond eating and involves digestion or even longer term affects. You had a great meal but it made you feel bloated and you ended up farting all night much to the chagrin of your partner. Or it gave you a sore throat and you had to go to the doctor to find some relief from incessant coughing. Disclaimer: As someone who loves to try new food from different eateries, I have fallen victim to both the above scenarios. Similarly, it’s possible that the user experience with a website led you to believe that you had set everything properly only to realise later that it wasn’t so and you had to go through a lot of trouble fixing it. That qualifies as poor (if not terrible) UX too.

Summing up, don’t just put lipstick on a pig. Before you make the website or app pretty, make sure it works well too. If you really want your burger to give an orgasmic satisfaction to its eater, make sure its done well and looks good too. Now all this talk about food has made me hungry. I will go and eat something.

Theory of Constraints

Theory of Constraints

Image Source: chuansong.me

I recently attended a meet-up where one of the presenters spoke about Theory of Constraints. While a lot of us use this term, only a few truly understand it and can put it to good use. Luckily for me, the presenter was one such person and did a great job at explaining it to the audience. As he went along explaining the paradigm to us, I couldn’t help but notice how nicely it fit with the Agile and Lean philosophies. This blog post is about that connection.

But before we go any further, let’s first understand what ToC is. The website for Theory of Constraints Institute describes ToC as a way of identifying and managing bottlenecks that restrict the entire system’s output. It is a set of management tools devised by Dr. Eli Goldratt and introduced in his book “The Goal”.

ToC says that, at any point of time, there is a single constraint throttling the system. Eliminating/ easing this constraint improves the output. You then have to evaluate the entire system again to find out the next constraint. Rinse and repeat.

The above has an interesting corollary. An hour lost on the constraint is an hour lost by the entire system. However, an hour lost on a non-constraint is no loss for the system overall. So when we continue to improve something and still wonder why there is no improvement with the system at large, possibly we are trying to optimise something that is not the constraint choking the bigger system. Yes, we might still end up improving a sub-system but local optimisations do not help the larger scheme of things.

Eli structured the following 5-step process for ongoing improvement:

Theory of Constraints

Image Source: Theory of Constraints Institute

When we get bowled over by methodologies like Agile, Lean, Six-Sigma, etc., we forget that these methodologies primarily help to Elevate the Constraint (Step 4). Some of them might also contribute towards other steps but we still need to perform them.

I am an Agile Coach


I don't always

If you throw a stone at a congregation of software people, chances are you will hit an Agile Coach. Being an Agile Coach is almost becoming a fashion these days. “I am an Agile Coach”. I get to hear this quite a lot these days. It’s like ScrumMasters of yesteryears have now graduated to become Agile Coaches.

Not to condescend all Agile Coaches out there (well, I am one of them), I see lot of asses in lions’ skins (ass means donkey here, not what you think!). Yes, some of these Agile Coaches have truly risen from the ranks, worked their way through the trenches, and have earned their stripes (I come from a family with a long tradition of serving in defence forces). Such coaches have reached the Ri stage of Shuhari paradigm. They really know their stuff and are making significant impact with the teams/ organisations they are working with. However, there are others who picked up a ScrumMaster certification after two-days of training and became Agile Coaches overnight. Some of them even flaunt certifications across methodologies – Six-Sigma whatever belt, PMP (seriously?), etc.

Being an Agile Coach is not very different from being a sports coach. To begin with, you can’t be one just by passing a theoretical exam and having worked very little in the field. You need to have years of experience in the field and should have mastered some aspect of it. Like a sports coach, you should know that not all methods apply the same way everywhere – different teams have different training needs because of their own strength/weakness combinations. There is no one-size-fits-all approach. Yes, the basic principles remain the same but you still need to customise the treatment for each team.

And to make matters worse, such Agile Coaches are being hired by organisations (as employees on payrolls or as consultants) eager to get on the Agile bandwagon. And when their methods don’t work in such organisations, Agile gets bad name. People think, “maybe Agile is not for me”. Well, that could be true with some teams/ organisations but a bad implementation of Agile by a worse “Agile Coach” should not be considered a representation of what Agile truly has to offer.

I would just end this rant hoping that professional astuteness would trump fancy titles.



Image source: Wikipedia

Innovation and claiming to be innovative is becoming a fashion as product development markets become more and more competitive. However, while some product companies are innovating truly and are at the bleeding edge of their space, others are paying only a lip service to it. It is expected for companies in the tech space to be innovating because technology, by its very nature, not just allows but even encourages innovation. However, it is really impressive to see a retail organisation innovating and consequently faring better than its competitors in the wake of a slow market.

I recently had the opportunity to listen to Michael Fagan, GM – Store Renewal at Kmart Australia. It was interesting to learn how Kmart was fostering a culture of innovation and some of the indirect benefits it had reaped as a result of the same. 5 years ago, Kmart was close to bankruptcy and making virtually no profit. It’s an entirely different picture today. First quarter results for 2015 showed a 12.5% increase in sales for Kmart that helped it breach the billion dollar mark to hit $1.1 billion. While its competitors Myers and David Jones struggled to grow, Kmart recorded an impressive growth to increase its lead over them. Here’s a quick summary of points as mentioned by Michael that are helping Kmart thrive in this heavily competitive space:

  • When innovating, you have to do things differently from others. Get off the trend line.
  • Have high tolerance for ambiguity, risk, failure.
  • Fail faster, fail often. If you aren’t failing, you aren’t trying things differently.
  • Act fast, fail fast, learn fast.
  • Flat structures ensure bad news travels fast.
  • Don’t smack people down when they fail, especially in a high pressure environment.
  • Don’t be afraid to cannibalise yourself. It’s better to be cannibalised by yourself rather than someone else.

As I continued to hear Michael talk about how the culture at Kmart was transformed, I couldn’t help but realise that new principles fostering innovation were the basic tenets of Agile. When Agile came into being, or should I say “was formalised into a methodology”, the basic principle was to get real – accept that changes would happen, early and fast failures are preferred over the illusion of success, people need to be trusted so they can work at the their maximum potential – be more agile than more prepared.

While all of the above sounds like common sense, it still requires diligence and courage to implement it at an organisation with over 200 stores and 31000 employees. Kmart pulled it off. And not only did it help itself, it also helped its customers and vendors alike in the process.

Kano Model and Release Planning

I am a regular attendee at the various meet-ups organised by different groups on meetup.com. All my groups revolve around technology, particularly Agile and product development. At one of these meet-ups, the speaker briefly mentioned the Kano model. My interest was aroused as I recalled having studied about it during MBA (and eventually forgotten). The speaker mentioned how the Kano model can be helpful in backlog prioritisation and release planning. That was enough for me to decide to learn more about it. This blog post is the result of that research.

I will briefly describe the model for those who are new to it. The Kano model is a technique developed by Prof. Noriaki Kano to identify customer needs and ways to satisfy them. While this model is studied with great interest by marketers in the making, it is equally important to product managers who would like to see their product grow in the market.

Kano Model

Image source: Wikipedia

The model plots the level of functionality provided on the X-axis and the customer satisfaction on the Y-axis. Customer needs (and the features developed to meet them) are divided as follows based on their position in the graph:

Basic Needs/ Dissatisfiers/ Must-be Quality/ Expected Needs/ Thresholds
All these terms are used to describe the needs (or features satisfying these needs) that fall in this category. This is the minimum level that must be met in order to enter the market. Even though they cannot satisfy a customer all by themselves, their lack may cause significant dissatisfaction or, possibly, abandonment of the product. For example the ability to send text messages from a phone. These needs correspond to “hygiene factors” in Herzberg’s Two-factor theory. When entering a market, even a small increment in functionality increases satisfaction by a significant amount. However, once a basic level of satisfaction has been achieved, the needle on satisfaction hardly moves by subsequent increments. On the positive side, once you reach the threshold, you don’t need significant investment to sustain it.

Performance Needs/ Satisfiers/ One-dimensional Quality/ Normal Needs
Needs that have a direct correlation of satisfaction with the increment of change in functionality fall in this category. The more a product has of these, the more is the satisfaction. An example for this is the battery life of a phone (even though most of us usually change our phones before the battery’s life comes to an end). Based on the cash position of the company and its marketing strategy, it can continue to pour money into these type of needs and keep increasing its customers satisfaction proportionally.

Exciting Needs/ Delighters/ Attractive Quality
These needs are those that the customer is not necessarily aware of and is not expecting. But, they provide the “wow-factor” to customer experience and increase the likelihood of repeat purchase. Their absence does not decrease customer satisfaction but presence greatly increases it. These needs correspond to “motivators” in Herzberg’s Two-factor theory. For example, a free extended warranty plan with your phone. Over time, as competition matches your delighters, they could turn into basic needs. An example could be the front camera on a phone which was an exciting need a few years back but a phone without one would barely be able to make a sale today.

Indifferent Quality
The customers are indifferent to the presence or absence of these qualities and they do not affect his satisfaction. For example, (under normal circumstances) the quality of the box the phone is sold in.

Reverse Quality
As weird as it may seem, the presence of these “qualities” makes the product less desirable to the customer and affects his satisfaction adversely. For example, the iPhone 6 had a protruding camera to accommodate better optics but it was disliked by a lot of users worldwide.

Now how can we use the Kano Model for better Release planning and Backlog grooming? To start with, it might make sense to remove features that are perceived to fall under Reverse Quality or Indifferent Quality. You might not know these features upfront which is why market validation and lean analytics go a long way in identifying such features. You can choose to open the throttle on Satisfiers and Delighters based on your financial situation and your market strategies around your customer base (whether you want to expand it, retain it, consolidate it, etc.). However, it is worth investing in features that satisfy basic needs before going all out on delighters. Nobody has ever bought a car without a provision for spare tyre in the boot even if it had all the power under the bonnet!