This has been in my head for years and I have tried to blog about this. This is my attempt to contextualize my thoughts together in a digital format.
Background to this topic:
I am writing an e-commerce platform for a client residing in the UK. Weekly, we demo our completed sprint (for those who follow the SCRUM agile methodology understands what a sprint means) and await feedback from the customer about the experience of using the product. Interfacing/interacting with a customer can make one eat a humble pie sometimes.
Software developers can all tell you a plethora of events/occurrences that they've encountered & experienced when engaging with their customers and their applications. Words such as PEBKAC (Problem Exists Behind Keyboard And Chair) error, IBM (Idiot Behind the Machine) error, etc., are terms thrown around by techies to politely (or more often to) vent their frustrations about how customers don't know what they want, even after they signed and approved all documents approving the changes and development of the application project. All these problems and issues have resulted from not taking the one fundamental principle into consideration.
When building an application, there is only one fundamental principle/law that all stakeholders participating in the building of the application must keep in mind: answering what the customer want(s).
Software developers can all tell you a plethora of events/occurrences that they've encountered & experienced when engaging with their customers and their applications. Words such as PEBKAC (Problem Exists Behind Keyboard And Chair) error, IBM (Idiot Behind the Machine) error, etc., are terms thrown around by techies to politely (or more often to) vent their frustrations about how customers don't know what they want, even after they signed and approved all documents approving the changes and development of the application project. All these problems and issues have resulted from not taking the one fundamental principle into consideration.
When building an application, there is only one fundamental principle/law that all stakeholders participating in the building of the application must keep in mind: answering what the customer want(s).
A software application/product is not only viewed by your customer as a product but as a brand. This means that the customer sees 2 things when purchasing and/or using your brand:
- It will satisfy their needs (whether it be fulfilled and/or unfulfilled), AND
- It comes with a brand promise. This tells the customer that the application will do what is designed and built to do in order to satisfy the customer's need(s).
Software developers/designers/engineers/etc. tries to answer the question by using IT solutions. I often hear at demos on how one had to build a specific tool in order to implement a customer functionality and try to show off the programmable tool to the customer, inundating the poor soul with IT jargons that makes Alice in Wonderland feel like an action novel.
Alternatively, one IT genius thinks he/she knows what the customer really wants, decides to build the product in his secret lab (called the office) and will spend considerable amount of money persuading his/her future consumers that his/her product is what they need.
What do we ultimately do? We create an environment of satisfaction that we believe will please our shareholders and our customers. We do the following:
Joel Spolsky brilliantly detailed how a customer thinks when using your product (blog: Figuring Out What They Expected):
Every customer has a user model and what they expect your product to do. Further in the article, Joel speaks about the program model and how the program model must be aligned to the user model in order to have a happy customer.
We have invested millions into our product, and yet we want to make our customer happy. What do we do? We write a user manual and freely provide it to our irate customers. If gaming ever taught us anything is that USERS DON'T READ THE MANUAL!
Firstly, ask! You will never know what the customer wants without asking them.
What Joel doesn't mention here is that the customer's user model must satisfy the only need every customer wants fulfilled: their own customer experience (whether it be expected or unexpected).
Every week, when we meet our customer (after they played with the product we're building for them), we take down notes of the experience so far in using the product.
Alternatively, one IT genius thinks he/she knows what the customer really wants, decides to build the product in his secret lab (called the office) and will spend considerable amount of money persuading his/her future consumers that his/her product is what they need.
What do we ultimately do? We create an environment of satisfaction that we believe will please our shareholders and our customers. We do the following:
- We promise all our relevant stakeholders and customers that we will have a product built and ready in a record time (ok....someday when we all wake up out of the matrix).
- We work on the stakeholders and customers expectation by meeting our deadlines, accomplishing tasks within the budget, etc.
- Finally, we delivery to our promises (as mentioned above) as well as our brand promise. And that's not more.
- We promise to provide support to customer issues by creating a service support team that will guarantee to keep our customers happy.
Over time, your customers logs requests, irate/frustrated/furious and about to throw a fit about why the product doesn't function as it should.
Joel Spolsky brilliantly detailed how a customer thinks when using your product (blog: Figuring Out What They Expected):
When a new user sits down to use a program, they do not come with a completely clean slate. They have some expectations of how they think the program is going to work. If they've used similar software before, they will think it's going to work like that other software. If they've used any software before, they are going to think that your software conforms to certain common conventions. They may have intelligent guesses about how the UI is going to work. This is called the user model: it is their mental understanding of what the program is doing for them.
Every customer has a user model and what they expect your product to do. Further in the article, Joel speaks about the program model and how the program model must be aligned to the user model in order to have a happy customer.
We have invested millions into our product, and yet we want to make our customer happy. What do we do? We write a user manual and freely provide it to our irate customers. If gaming ever taught us anything is that USERS DON'T READ THE MANUAL!
How does one finds the answer to what the customer really wants?
 |
| A happy and a satisfied customer. |
Firstly, ask! You will never know what the customer wants without asking them.
What Joel doesn't mention here is that the customer's user model must satisfy the only need every customer wants fulfilled: their own customer experience (whether it be expected or unexpected).
Every week, when we meet our customer (after they played with the product we're building for them), we take down notes of the experience so far in using the product.
The approach here is that we shifted from building the product purely just with IT tools (from the specification/user stories that was provided to us) but we focused now to product design to meet what the customer wants. The product design process is really a process which must be tackled to fulfill the customers' needs/wants. This means that the product must be able to trigger the emotional receptors of your customer that will ultimately tick his/her satisfied smile and the satisfaction must remain consistent. Our weekly meetings with the customer was more to understand the interaction of the product and how satisfied they were with the functionality presented to them (was it simple to use? what frustrated them the most with just following certain process, etc.).
At the end of his article, Figuring Out What They Expected, Joel Spolsky wrote:
An important rule of thumb is that user models aren't very complex. When people have to guess how a program is going to work, they tend to guess simple things, rather than complicated things.
Essentially, the model of requirements gathering and then building the product must be reviewed as it never captures the experience of the customer interacting with the product. That is where Steve Jobs became a genius in his own right. He built products purely to enhance the experience of the customer by fulfilling the user model of the customer (by making it simple).
Once we have designed the product that fulfills our customer's experience, we then build it to function to the customer's experience or to trigger other emotional responses that takes the customer experience in a "I WANT THIS!" environment (to make them NEED what they DON'T WANT). Therefore, the customer experience feedback is crucial, to ensure that it satisfies the brand promise of the organisation, it makes the life of the developers easier in the product development lifecycle and that everyone sleeps happy every night.
Comments
Post a Comment