Saturday, June 05, 2010

On selling customer experiences

I was looking at how much of a dent an iPad will put in my wallet when I noticed the mandatory field reminder on Apple.com's shopping cart. Then I came to this realization, Apple isn't a mobile device's company, nor a computer company, its a customer experience company. So much time is spent on just tweaking and perfecting the whole cycle. From the moment you browse their online store or their mortar-and-brick store, to the point you make your purchase, including the point when you receive your product, unwrap it - perhaps even record that joyous moment - and then finally start using it and then officially become a fan boy or girl. This happened to me in 2003/2004 when I purchased my first Mac, a PPC PowerBook G4.

Sorry, I went on a tangent there. Anyway, they are a customer experience company. The developers who built this form did not have to do it the way they did. This sick tooltip reminding you of the mandatory fields could just have been a red asterisk. However, because they are a customer experience company, they didn't do what every average Jack and Jill developer would have. As simple a page it is - a personal info page - it most definitely went through multiple iterations before it reached its current state.

Another example, lets say you don't look like a pirate but have a speech impediment. I'm a nice guy. If you seem like a nice person too, I'm going to do my best to understand you. However, that doesn't apply to your website or application. Don't make your product seem like it has a speech impediment - even if it looks great. Its just going to be awkward.

Learn from Apple guys, they don't have to do their site the way they do, they don't have to finnish their products the way they do, they don't have to meticulously design the packaging inside and out. But they do. And because they do, they're in the business of selling customer experiences. That is a very profitable business, and that is why Apple's stock P/E is twice that of Microsoft's.

Here's a great TED talk on "People don't buy what you do, they buy WHY you do it":

Friday, May 28, 2010

Chefs, Curators, & Developers

Besides that these people all eat, sleep, and lineup for the latest iStuff, developers ought to have another thing in common with chefs and curators. I would say software development is part engineering/science and part creativity, even as high 50/50 or maybe a little more.

Curators

The term "custodian of a collection" doesn't describe what curators really do. It almost makes it sound as if they just take care of a collection, but not necessarily care for it. A museum without a curator simply turns into a warehouse. It is the curators job to prevent that from happening. To care for the collection and keep an eye at the big picture.
Every piece, big or small, serves a purpose and delivers an essential part of the experience. The opposite of a curator is a hoarder.

Chefs

Similarly the chef does not just cook the food, they keep an eye on how the items on their menu works together, how the dishes enhance the experience, and how every ingredient in a dish works with the other ingredients. Every detail counts, and great head chefs will look after it all. They are food curators.
Musuems, food, and software is made better by what has been left out - purposely - and not what's included.

How do they do it?

Great museums don't happen overnight, they happen over time, time spent doing the same thing - improving the museum. The task is never done. It's iterative, and perpetual. Curators aren't afraid of tossing things out because they don't work, or something better came along. Curators are careful not to hoard shit, even if it's all good shit. They don't go about it alone, they get feedback from other curators, from their clients, and finally their gut & others' guts. Your unconscious brain has a lot to do with this task, sometimes it is hard to explain, but often your gut is on target.

Lessons from Chef Ramsay

The number one thing Gordon does to fix a failing restaurant is "cut the crap" - after he is done ripping through the owners of course. If you watch the show, you probably have seen him throw out half the menu - if not all of it in some cases. Take the episode of the "Curry Lounge", tons
of curry based dishes. None of the waiters guessed what any dish was during the blind fold taste test - except for the french fries; at an authentic Indian restaurant. Chef Ramsay tweaks and iterates over the food, how it's made and served over the course of the week. That's his formula. That is why he is a great head chef.

Don't be scared of "No"

There are many good reasons for saying "No". There are also wrong times to say "No". Say you are at a restaurant, and you ask the chef to skip the pistachio on your baked chicken because of allergies. That is a valid request you cannot say "No" to. On the other hand, don't be surprised if the chef says "No" while at an authentic Italian pizzeria and ask for extra cheese on your Pizza Terreno - he knows better than you. A good way to say "No" is to always provide reasons and alternatives. Most clients will consider alternatives, after all they are paying you to provide the best possible service you can afford them. Sadly, you don't always win, or you are just wrong and you lose the battle and have to provide exactly what you have been asked.

"But that is not how we do things around here"

There is always room for improvement, and there is always areas and times where you can play the role of the curator at what you do. Always start with the things you control. What if you work at a hypothetical restaurant that followed the Waterfall model? retarded right? but at every point in the process a curator could help, and a curator can make the experience better - even a little. This Waterfall restaurant basically takes orders at 5pm, by the time they are validated and cooking starts at 8pm. Then the dishes get checked, fixed and reheated. Food starts to come out at midnight. And into the wee hours of the morning the cooks have gone mad trying to
figure out what was ordered eight hours ago. Every single role in this kitchen can play the curator in what they are doing. As badly suited the experience is, it's much worse if everybody minds their own business and blindly follow the blind.

Kitchens get dirty one dish at a time

"Too many chefs spoil the soup" True, and applies everywhere. Why else do the Marines and special commandos operate in small, tightly knit groups? Do you seriously believe that anything will need an army of develop
ers yet the army elites can perform heroic missions with a team of 15?
Don't let your kitchen get dirty, it's easy to say you will do it later, but know that your effort to clean it does not have a linear relationship with how long you left it dirty.

Everybody can be a curator

Whatever business you are in, you are involved in curating and improving the product/service you provide. Whether you design buildings, write software, an author, or a sales guy, a president, or an army general. We all do it. We all know that the first draft of an essay is always the worst. When you walk into a board room to make a pitch, how many times do you revise and tweak that slide deck? how many times do you do it the night before? or even 30 minutes prior? We all do it.

So here is the big question, when did we say that code should be written once and done with? What tends to happen with development teams is this task is not performed as often as it should - specially as the team size grows. It gets worse when dates start to slip, as things like continuous improvement and cleaning up the kitchen are ditched. Here is the other problem, managers, executives, planners, etc. don't like to see tasks that don't have end dates on the plan. They want to know things like effort spent, time elapsed and percentages for each. An iterative task only has elapsed time, but nothing to identify how much is left because it's never complete. The affects of this curating task are phenomenal. Almost always you will be amazed by how little you changed or even better removed and how substantial the improvement was.

Making something better is never easy

...but the harder the decision, the better shape that thing is. To be successful at being a curator you really need to understand what your customer wants. Not just a little, you need to get in their head and figure shit out. You need to figure out how you can add value, or if you just can't. Value add is highly dependent on the context. If I am in a rush, fast food will be the best value for me at that time. I'm hungry, and need a quick solution. On the other hand, you wouldn't take your wife there on your 10th anniversary. The best way to bring yourself to a point where you can understand how you can add value, is by aiming for the simplicity on the other side of complexity. If you are looking for a good healthy relationship, you need to invest the time up front, you need to climb that complexity hill, sometimes it's steep, sometimes it's long, but rest assured it will flatten out after the peak. Thats where you want to be. Not many people make it to the other side, most will be hanging around at the base or on the way up. That region is highly competitive. The elite don't hang out there. Take Apple for example. We can consider Apple to be one of the elites of the tech industry - almost like they have the Midas touch. People have tried to replicate the iPod with little success. This week, slowly but surely Apple wrestled the 2nd highest market cap from Microsoft - without even dominating the market. They know their customers, and they don't even want everyone to be their customer.

Everything looks great on paper, it's not until it comes to life you start spotting glitches and things to improve. Good restaurants will shutdown for a day occasionally and just cook the whole menu and their staff will critique everything and make adjustments. Iteration is key. In school you are taught to review your essays, read them out loud, tweak and adjust the paragraphs, shuffle things around, all of this to find the essence and flow of what it is you are trying to accomplish.

There are only two kinds of developers.

Those that just get shit done - literally -, and those that will get it done very well. From a time line point of view, you won't be able to tell the difference. They both finish on time, and their stuff will work. However, the first, don't care about what it is they are building, don't care about who they are building it with, they put in their hours, get paid and that is it. Excellent developers don't have to be geniuses or come with Masters & Phds. These are the ones that want to be proud of what it is they are building. They are the ones that think several steps ahead, and design for change. They will embrace change if it makes what they are building better. They will try to resist change that adds no value. They are the ones that keep an eye on the big picture. Those are the ones that will invest the extra time to re-factor the redundant classes they spotted. They are the ones that experiment and try stuff out because they are always on the look out for a better option. They are the ones that will tell you "No, you shouldn't do that". That is how you separate the two. An excellent developer will wave his hands and yell when something is just not right. The first kind will shrug their shoulders and pile on the dishes.

Monday, May 24, 2010

The Mythical Man-Month

I think it was in first year software engineering that we had to read this book, and nine years later I really, really understand the underlying purpose of this book. It may just be yet another book back then, but the lessons that are hopefully learned from it will last a life-time - not just for software projects, but any project.

The Mythical Man-Month

Unfortunately on software project plans, developers, designers, testers, business analysts, product managers, etc. etc. are considered "just another resource" that are added and removed off of tasks. The assumption is that all are equally effective and skilled in all the required domains, and all will produce the same volume and quality. So in a perfect world it makes sense to scale the team to meet deadlines, although we don't live in a perfect and linear world, this is still the method of choice. Even though the biggest effect of this method; drastically increased non-linear communication time is widely known but mostly ignored.

Sadly this is the state of this industry, project plans that are too often disconnected from reality. I think part of the problem is driven by dividing tasks into a unit of time, after all that is how budgets are built, teams are put together, and progress is tracked. However on the other hand, this unit of time does not measure the real size of the task. Its just an illusion. Its like a building, we don't measure building size in number of months it took to build, we measure it by number of floors or in meters i.e. something relevant and real. If a 40 meter building was estimated to take 12 months, and in 6 months we are at 10 meters, then we are 25% done, and not 50%. However if this building were a software project its assumed we are 50% complete. Then at 10 months we realize we won't meet the deadline, forget about the Mythical Man Month and scale up. Why did this happen? Because software does not have a realistic metric, software is abstract.

Some say you get better at estimating over time, but that too assumes we live in a linear world. Ex. Project X took us 3 months, so we will estimate that project Y will take 9 months. We don't live in a linear world, and humans aren't good at estimating non-linear stuff. We may think that the second project is 3x as long as the first, but it could be x^2. However the hope is that over time you can make a non-linear project more linear by improving the processes for the non linear components. That effort is also non linear.

You can try to measure by team size, effort, or lines of code, etc. but all are just an illusion of measurement, none are real. Whether you measure buildings by floors or meters, you can translate between both. On the other hand, you can't translate lines of code into time, effort or team size.

I don't know what a better alternative is, but surely it is not this. Perhaps the problem is just trying to estimate that far into the future with too many unknown variables. Feel free to comment.

I recently read the book "ReWork" by the guys at 37Signals and one paragraph I absolutely loved has to do with project estimation.


The book is a must read.


Tuesday, April 20, 2010

Crash 'n' Burn: The 11th hour for Flash

Adobe's rhetoric continues after the curve ball Apple threw. The whining continues with this post: On Adobe, Flash CS5 and iPhone Applications.

Sadly, the whining doesn't change anything, and Adobe's argument would have been more valid if they didn't trying to lock developers into Flash/Flex and if it -Flash- were really open. Also, I think Adobe's Flash/Flex tools favor developing using Cold Fusion on the server side... you can use other server-side technologies however I believe the tools "play" better with Cold Fusion.

Apple's decision makes 100% business sense to me. They're advocating for their own platform, or open standards. Just like Adobe advocates for their own platforms, or open standards. What's wrong with that?

Flash filled a void in the 90s, but where is that void today? Is it even still needed? Yes its far superior technology, but its a closed technology. And to think that Android will succeed because it has Flash is just absurd. Android could be the iPhone's real challenger ONLY because it is open. The above post also seems to confuse "open" with "cross-platform". They're very different. Flash is cross-platform because its not open.

Flash needs something different right now, we don't need Flash to deliver rich content online anymore. We don't need flash to deliver sexy fonts. We don't need Flash to scroll and fade text. Soon we won't need Flash to play video - my Youtube embed below is still in Flash- . We don't need navigation built in Flash. So much stuff we needed Flash for (right or wrong) , that are just not needed today.

On to Flex, Flash's younger cousin. We - the majority - don't need that as well. Slowly but surely applications will move to the web. They may have some Flash components that could now just be as easily done in HTML5 or even HTML and some nifty JavaScript. Where I can see Flex fitting, is for these extremely specialized software, such as CAD or medical imaging. Such software is expensive and time-consuming to write, and would be a pain to translate into different operating systems. Such software also comes with heavy visualization, so its a good fit with Flash. Maybe thats where Flash will head, who knows? But there is definitely hardly any room today for Flash on the web.

This song is dedicated to Adobe Flash, I don't know who your savior will be, but you really need one right now...bad.

How to throw usability out the window - Part 1

Sometime between when I paid my Rogers bill last month, and when I tried to look it up this month, the Rogers site was "upgraded" to portal. I'm not sure what it used to be before, but I think now it sits squats on top of the BEA Weblogic portal - now owned by Oracle.

Note: This is only part I, the Rogers Portal went offline while I am writing this. To be continued when its live again...


The Loading Dial Syndrome


Who hasn't seen one before? its a great little technique to let the user know something may take some time to come up - note the keyword is "something" not "time". If in your site's case "something" is replaced by "everything" then something is definitely wrong. Sometimes you just can't make things any faster, especially today when portals by nature provide seamless integration between different internal and external applications. At some point, its just out of your control. However, if your site suffers from the Loading Dial Syndrome you are definitely doing it wrong, and its just not out of your control.

By the way, when the loading dial in the middle disappears - after a minute or so-, nothing actually loads. I end up with all this blank space in the middle of my screen. Obviously a bug of some sort, but hey I'm trying to pay my bills here, not QA your application. For the record I wouldn't mind doing it if it was optional (i.e. I choose to jump to the Beta version) plus I receive a reduced bill.

Navigation


So after going to the "Bills & Payments" tab I see a list of my previous bills and I can dive into any of them by clicking the "Bill" link next to each. I then see the screen below:


Whats the problem? How do I go back to seeing all my bills again? I can't even click on the same tab again. The only way I found is to click on another tab, and then click back on to "Bills & Payments" and then the view is reset to the initial state. Almost like driving a car that can't be put into reverse.

The other thing about this screen, is that effort was spent on meaningless details, such as the red dropdowns with the white gradient background.

The thing about usability is that when you get too deep into something, you miss these obvious issues. I'm sure they looked like non-issues during develeopment, but take a step back and Don't Make Me Think. Sure, there's rounded corners, pretty shadows and loading dials, but none of that will make me login more often if its too darn slow. Now I have two things to dread about the end of the month, finding out how much $ I am about to spend, and trying to use this PoC. - and that doesn't stand for Proof of Concept.


Monday, April 19, 2010

there will always be someone who can do it cheaper

For most companies offering professional services, the business model is based on cost plus billing. This includes people like lawyers, consultants, accountants, marketing agencies, etc.
This is fine for starting up and getting the $ rolling to keep the lights on. However at some point you realize that that was fine for starting out and that it is completely flawed and doesn't make any economic sense in the long run.

I'll start with one issue with this model, basically you are capping yourself - I cannot generate anymore revenue than:
Number Of Hours I can reasonable work per year X my hourly billing rate

You work an hour, you earn an hour. Growth is extremely tough because for professional services, you end up doing two things:
  1. Hire more people to effectively generate more hours per day to sell (ex. just like a manufacturing company would build more and bigger factories)
  2. Improve and automate certain processes so that you focus on tasks that add the most value. (ex. just like a manufacturing company invests in better technology like robotics to increase throughput)
Number 1 is bad. Number 2 is great.

But the biggest problem is that you are now distracted. You are doing everything you can to generate more hours because that is what your business model is telling you need to do to make money. You are now faced with a dilemma with your customer because your business model has put you in a position to choose quantity over quality in order to be profitable. You then get into the argument of convincing your customer some task will take that many hours, while they try to convince you it will take less. This wouldn't happen if you focused on selling and delivering value.

Nobody gets into the professional services business to sell time. They want to sell value. Not hours. A salesperson can talk you into buying a Hyundai. They can't talk you into buying a Ferrari. People who buy Ferraris say "I'm buying that". People who buy Hyundais say "I need a car". There are many providers for the Hyundai class of cars, you don't want to be in that ruthless, volatile, price based market. Just like the whole Mac vs. PCs. Apple isn't in the $500 computer market for a very very good reason. You don't want your competitive advantage to be your price or hourly rate. Just like driving on the highway there is always someone behind you driving faster; there will always be someone who can do it cheaper or quicker. And with a global economy that is a fact.

So what is one to do? Don't tie your price to effort - easier said than done of course. Its hard because you are selling something mostly invisible, something customers will not see until "it" has been delivered. But people usually like to see what they are getting for their investment. I don't want to just give money away, but since I can't see "it" I'll settle for seeing hours. Then you fall into the trap of believing that more hours equals more of "it" or better of "it" - which we all know is not the case.

You can't stop tying your price to effort if you are delivering the Hyundais . You need to have the Ferraris of whatever service you are providing. Take an accountant. At first you'll charge an hourly rate. After some time you realize you are consistently providing your customers a better tax return than other accountants in the area. Now you can step out of that ruthless, price based market and start charging a premium or a percentage around a service that kind of looks like a product. Now if customers want cheap, they can go to Joe Blow and Co for their tax needs. Why? because you don't deliver cheap. You deliver value, and you have the numbers to prove it.

So now you got rid of your hourly rate, and are focused on delivering value. What can go wrong? You could still get distracted about what value is. Your perception of value may not be shared by the customer. Here's an example. I did my taxes an H&R Block when I was a student. I loved it because I got my tax return right there, and it only cost me $50 or so. Why wouldn't I love it, I pay them $50, and they give me a cheque for a $1,000 on the spot. A couple of years ago, I went to do my taxes there, and their printer was broken; they couldn't print the cheque. They then sold me on taking my return on their H&R Block debit disaster card. They thought it was an added value, I can use it just like a debit card; and it will charge me a fee per transaction just like a debit card. I was livid. But it didn't end there. The bank that sponsored this debit card, wasn't the bank I use. That bank also stopped issuing bank drafts to non-customers, so I couldn't easily transfer my return to my own bank account. I was left with one option, go to my bank's ATM machine, withdraw the limit I can withdraw, walk to the teller, and deposit it. Rinse and repeat until my tax return was in my account. So here we have a typical case were one's "value add" idea wrecked havoc on a customer of at least five years.

Understand your customers' needs. Understand how to add value. Don't confuse value with effort, then learn how to charge for that value add. Don't be the "cheaper" or "quicker" service, its only a matter of time before someone else figures out how to do it for less or faster.

Saturday, April 10, 2010

First Google Maps Mashup Turns 5 Years

Last Thursday the Google Maps mashup turned 5. Paul Rademacher posted this on Craigslist announcing a Google map mashup of housing properties. That post started it all. Back then, there wasn't even an official API for Google Maps. That mashup now lives at housingmaps.com.

Congrats to Paul on this milestone. That experiment started the whole mashup building community, and the reason why Google Maps has an API today and why we have sites like zoocasa, University of Ottawa Campus map, twittervision, and many more mashups built on top of the Google Maps API.

If you are interested in building a Google Maps mashup, get in touch with ThinkWrap's Google Maps Gurus.