Focus on the effort… as much as the result – Another perspective

This is the second part of my earlier blog “Focus on the effort… as much as the result” – http://jwritings.com/?p=562. In case you have not read that, I would suggest that you do before proceeding to read this.
While that blog presents a good picture of a project with high stakes, riveting rush by the team culminating in a nice photo finish (almost cinematic), there are some disturbing questions too. Why did it take until 2:00 pm on the release date to figure out that there was a long list pending? Shouldnt there have been appropriate checks and balances in place (especially since this was a release that multiple regions were looking forward to)? Shouldnt the stakeholders (folks who had made commitments to customers) been sounded off earlier that there could be a slip (in which case they could at least fore-warn the customers that there MIGHT be a delay)? What if the release had not happened even after all the effort?

Is this similar to our infamous Commonwealth Games experience where weeks before the games were scheduled to start the supervising committee found stinking toilets and unpainted stadiums and deplorable athlete village? Isnt it interesting that even a senior Indian official compared the whole Commonwealth Games fiasco to Indian weddings where things are chaotic right up till the last moment before miraculously falling in place in the nick of time? Has our Indian psyche trained us to see this whole episode as a “victory from the jaws of defeat” rather than a “last minute frenzy to barely manage to deliver after screwing up all along”. Even in this case, wasnt it passion and a heroic slog by the highly charged team that delivered the win rather than a methodical and systematic process?

Now if I have to weigh both sides and choose which of these two set of qualities – passionate and heroic sloggers vs methodical and process driven marchers, I would lay more emphasis on, I would much rather pick the former. Now I am not talking about these as mutually exclusive traits, but more as the dominant characteristics of the two sides.

Here is the reasons for my choice:

Software product development is inherently unpredictable. While you can do a reasonable job of approximations earlier during the development cycle, hard release dates pretty much “emerge” during the later stages of development. After about 12 years in product development, with 8 of those as a Product Manager, I have very rarely released a product exactly on the planned release date – and I have never felt bad about it. One of the best part of this job is the opportunity to say, “I dont mind if this product is launched a few days later, but I want the wow effect”. There are always last minute changes – enhancement that you want to add for the “wow” effect or a database query optimization that’s going to deliver faster customer response times – that you did not plan for when you wrote the specs 4 months back, but want it now!!!

This is especially true in case of start ups where priorities change fast, demands from a large customer can require you to rejig or do a course correction and you are constantly trying to do more with less resources and shorter time.

With best checks and balances and processes in place, you will still have your share of “2:00 pm on release day with a long pending list” days (the frequency pretty much depends on the pace of your business)…. and on those days, you’re seriously better off with a team that’s willing to go the extra mile than a team that’s dissecting what went wrong with the process or how many times the requirements changed.

NWritings

BOOK REVIEW : The Long Tail

 

Price: 275 INR

Author: Chris Anderson

The Business world has gone through disruptive changes during the past decade – one of the main reasons being content (ex: music, books, photos) is created, maintained and consumed. Internet was instrumental for fueling this change, thanks to digitization of anything and everything. The new ‘digital’ way has literally changed (in some cases ruined) many traditional business models, which is been working for decades together. One classic example is Apple iTunes, which has democratized the way music is created and shared across billions of people across the world. Another major aspect of digitization is about providing equal opportunity for niche players by connecting them with niche audience, which did not exist previously. As the digital infrastructure can be scaled overnight (that too with global availability), many innovative models are emerging around it.

In his book ‘The Long Tail’ author Chris Anderson introduces a new model which he calls as ‘endless choices creating unlimited demand’. He explains it with the power law graph (see image on the right). The left side of the graph is about ‘hits’, which has maximum number of non-niche customers. The right hand side is about ‘non-hits’ which reaches niche customers, which also has a huge number, at least comparable to mainstream non-niche customers. The ‘Long Tail’ of business is about selling to niche customers, aided by digital infrastructure.

Let us take an example of creating and distributing rock music in the form of albums. During earlier days, a particular rock band will create an album and approach some or the other major music distributors for making a production (in form of CD/DVD) and distribution out of it. From the distributor’s point of view, they will take a very stringent approach for short-listing these bands as they want to really ensure that the album becomes a hit. This is mainly because the distributor needs to make an upfront investment of creating the physical network (CD/DVD creation, distribution to channel partners/retailers, staff expenses etc…). While this ‘hit’ based world/approach still exists, the niche based items also gaining high importance due to the digital transformation. Today any rock band can still create the music, edit is using freely available tools, make an album out of it and upload into the Internet (ex: MySpace). By doing this, they are completely getting rid of traditional distributors, thereby targeting niche audience who are bored with popular bands and interested to explore something new.

According to Chris the ‘Long Tail’ is created because of three factors:

  • Democratization of tools for production (MySpace online tools)
  • Democratization of tools for distribution (Internet)
  • Connecting the demand and supply (MySpace social networking platform)

The similar model can be extended to other industries, using which organizations like Apple (iTunes music, iPhone Apps), Amazon (Online retailing, which can literally list infinite number of items), Google (Ad-sense, Ad-words), Wikipedia (democratic content ecosystem) has become a global success by leveraging Long Tail customers. From the consumer side, the behavior has changed as they are expecting more and more choices which can be met only by such system.

Throughout the book, author explains above mentioned aspects in detail across different chapters, thereby giving complete perspective to readers. In few chapters I felt he repeated same information multiple times, but he takes examples from different industries makes it an interesting read.  In order to understand the recent business changes, aided by Digitized Internet, Chris Anderson’s Long Tail provides an excellent framework where one can put things into perspective.

An Irate customer….a lost opportunity

In the blog post titled ‘An Irate customer….a great opportunity’ by co-blogger NWritings called out few important points that organizations should take care when they deal frustrated customer.  By providing excellent service, the frustrated customer can eventually play significant role in building the organization brand image. However when it is not done properly, irate customer will become even more frustrated.  Recently I had an experience, which I would like to share along the same points mentioned by NWritings.

Let me give some background. For about a month, jwritings.com site was having some serious issues with loading its content only from Airtel Broadband network. However it was working perfectly fine when I accessed it via BSNL or office network. Some of my friends (including NWritings) who got Airtel connection reported the same problem. I called their customer compliant number 198 and raised a ticket to resolve at the earliest. However the way Airtel took up this case was really bad, where they consistently failed to meet my expectations and eventually forcing me to write this post. Let me line up the list of issues.

Delayed response: To start with, Airtel always have a Service Level Agreement (SLA) by which they will resolve the issue, whenever a support ticket is logged. I have been a long term customer for Airtel, always respected the company for the customer focus as they stuck to SLA commitment all the time. This time they failed to meet the SLA, where nobody turned up to investigate the issue reported by me. I need to do multiple follow-ups to get a customer support engineer to visit my home. Added to that, the long IVR menu made the experience a non-pleasant one.

Blame the customer: The real fun started when the customer service engineer visited my home for the first time. During my initial days of work, I was a test engineer responsible for testing DSL routers, mainly focusing on networking protocols (ex: PPPoE). With this background I did initial level of technical troubleshooting by checking out various options (LAN/WAN connections, executing utilities like ping/trace-route/packet capture etc…) which I clearly explained to the support engineer. In spite of me providing all the details, he went on checking local wireless connection, which has got no relation to the issue. Upon further conversation he made lot of loose statements like ‘once in a while such sites become inaccessible, why are you so bothered?’, ‘Airtel nowadays not paying much attention to customers’, ‘In case you are still having issues, try to change the modem’ which made me all the more frustrated. Eventually he put a request to the backend L2 support team and confirmed back saying ‘there is no issue from our side sir, there is something wrong with your laptop’ and eventually closed the support ticket without informing me. In spite of me doing most of the technical troubleshooting, this was the last answer I was expecting from them.

After doing some more follow-ups, I got a new support ticket created. Now the second support engineer visited my home, who was even worse than the first one. He had no idea about basic network troubleshooting utilizes like ping and went on complaining that there is something wrong with my machine or with the web hosting provider. Without getting into further details I politely requested him to leave my house.  Again, after multiple phone-calls, explaining to different customer support engineers the conclusion was very simple – the problem is with me (customer), there is nothing wrong with Airtel.

No proper follow-up: To provide a last opportunity, I reached their escalation department and clearly told ‘See boss! If you don’t fix the problem, I will be terminate the connection’. After couple of days, I got an SMS saying my problem will be fixed by a time-frame, which already passed. Throughout the issue, there is no proper follow-up from their side trying to understand the problem and provide the solution. As a customer I was totally unhappy to see the  ‘don’t care’ attitude expressed by them in every other step. Nobody was even able to understand the core issue and associated emotions (of my passion for writing, not having the site up and running preventing me from writing) which were clearly below the standards.

No call-back: After my escalation phone-call, the site started working just fine. I am not sure what exactly they did and where the eventual fix was made. Till date there is no call-back from Airtel to confirm whether my issue is really fixed. In case I run into the problem again, I am pretty sure it will again start from ‘square-1’.

I am one of the long term customers of Airtel, mainly because of their excellent customer service. Especially during the initial days of me purchasing the Broadband connection, the service levels were simply outstanding with 100% adherence to SLAs. In case the SLA is not met, they will pay penalty as compensation. I clearly remember getting 200 rupee deduction in my monthly Broadband bill as they were not able to meet their SLAs. This level of great customer service is something very unique in Indian context. As a matter of fact, I purchased Airtel stocks, when I started my share market investing. This was mainly because of the fundamental belief that any organization with such strong customer focus will eventually become great organizations.However my recent experience clearly indicates clear degradation in their customer service. When I put a message in Facebook about this incident, many of my friends responded with similar examples.

Never the less, I still continue to be an irate customer!

Innovation – Type 5 – Product performance [Case: Reva electric car]

In part four of ‘ten part’ innovation series, let us take a look at Reva Electric car for innovating in product design.

The idea of clean/green technology has taken main stage with main focus on having options other than petrol or diesel Reva is one of the early players in this space by inventing a city car, which is 100% battery operated. In bigger cities (like Bangalore) traffic during peak hours is a huge concern for working population, who want to move swiftly across the city. The main innovative aspect is not only for alternative fuel option, but some of the design considerations that Reva has incorporated. The key value of Reva is due to the way it is designed where it has created innovation.

To start with the vehicle is designed with maximum of 80 kilometers capacity, when it is fully charged. This basically differentiates the vehicle from other four wheelers by clearly targeting urban customer who wants to move within the city without much hassle. It has additional key features like ‘maximum 2% discharge’ concept, by which it will not run out of battery in case the customer is caught up in a long traffic jam. It also has state of charge (SOC) gauge on the instrument cluster in the car that is colour coded to give information on the charge left in your car. If you enter the red mode on the SOC gauge the car will warn you with a chime and also enter a mode where the power used for running the car is reduced (speed decreases and ac switches off) so that you can go home or to the nearest charging point comfortably. This vehicle is ideal for a family, who is looking for a second car option for moving in short distance.

Taking a strategic positioning is related with the trade-off a product or solution has voluntarily adapted. By having features mentioned above, Reva has strongly positioned, thanks to its design. With the global push towards a ‘greener’ world, a product like Reva has a strong potential to grow in the urban car segment in a big way. However the higher price range (about 4 lakh) is one of the barriers for customers to opt for this car, even though there is a significant long term can be achieved in terms of reduced fuel expense.

In spite of above mentioned advantages, commercial deployment and usage of Reva car is not of that great. Even though about 5000 cars are sold domestically, it is relatively very less compared with traditional cars. What should be done to promote this and making it better?

Related links:

[Introduction to ten types of Innovation]
[Innovation – Type 1 – RangDe]
[Innovation – Type 2 – RedBus]
[Innovation – Type 3 – Narayana Hrudhayalaya]
[Innovation – Type 4 – Mumbai Dabbawalas]

Super Long PRDs, MRDs…. on their way out?

One more take away from the Product Management session that I attended:

Closely aligned towards the more collaborative Product Discovery process is a move away from long PRDs and MRDs – specifically in the context of technology product companies.

The traditional way of building products would typically start off with the PM putting out a super long PRD and THEN kick off discussions with Engg. Now, considering that we have moved towards a more collaborative product discovery process, the focus is moving away from super long PRD.
The session presenter talked about a couple of drawbacks with these super long PRDs which I could easily identify with:

  1. They end up getting taken too seriously and lull people into a false sense of security (“It is long and impressively put together with nice illustrations… So the PM must be smart and this must make sense”)
  2. Since the whole product discovery process is exploratory and iterative in nature, with changes to the approach as found necessary, a super long PRD is not necessary – and can actually be counter productive, since it could impede you from making even necessary course corrections.

So, here is what is recommended:

  1. The PM starts with a very brief outline of what problem you are trying to solve, why it needs to be solved and for who. This is pretty much all a PM needs to kick start the product discovery process.
  2. By the end of the product discovery process, the PM has the necessary customer and the customer facing teams (or at least part of it, with more to come during the product development process), the architect has the design documents for the Engg to execute on and the UX has the necessary UI mocks available.

But clearly, what makes you do away with the super long PRDs is actually the collaborative approach.

 

NWritings

Product Discovery – a collaborative effort

Sometime back I attended a session on Product Management by an industry expert and had some good take-aways. Ill focus on the area of “Product Discovery” in this post. It takes a very collaborative approach in the whole Product Discovery process.

The Product Discovery process looks to evaluate your product idea and provides a framework to validate whether it is worth investing time and resources on building it. The starting point of this process is a Product Idea and the end goal is a “Build” or “Not build” decision for that idea.

The idea is to form a Core Product Team comprising the Product Manager, the Technical Architect and the User Experience Designer who work together to validate the idea from the perspective of “Valuable, Feasible and Usable”. As you have probably guessed, each of the team member approaches the idea and validates it from that perspective.

The PM is largely responsible for deciding if its Valuable – Is it a real customer pain point and does the product that you intend to put out solve the problem effectively.

The Technical Architect is responsible to decide if its Feasible – Is it possible to build a product based on the limitations that exist within the ecosystem and the organization – within the given time and the organization’s technology capability.

The User Experience Designer validates the Usable angle – Is the product envisioned Usable enough from the customer angle. Is it too complicated for anyone to use.

Again the entire process is very collaborative and iterative. Based on these, you come up with prototypes which you will run through potential customers. It is recommended that you have about 6 potential customers that you work with to validate this prototype. The thought being that anything much less than this will end up being a “customer specific solution” as against a product that delivers value to a customer segment. The good part is not a single line of code has been written by Engg until this point – QA or Ops hasnt yet been involved.

The idea of this process is not necessarily to sign off with a “Build” decision, but to help you rapidly validate your product ideas in an inexpensive manner. It also enables you to quickly drop ideas that wont work and focus your energies on other one. While this is not a fail proof way of building products, it sure gives you a better shot at rolling out something that will meet customers’ needs

 

NWritings

An irate customer…. a great opportunity

Irate customers….It happens with every product, irrespective of how long the product has been in the market or the number of customers you have. Products sometime just doesnt work the way they are intended to and someone who has paid to buy it is not happy. In some cases, the issue is not even with the product – the customer screwed up or tried to use it in a manner that it was not intended to be used.

But as product owners, you and your team can actually turn this into a great opportunity. You can convert him to become a happier customer than he would have been if he had not had this problem in the first place.

Here are some of the things that we did which seemed to help in converting him into a strong advocate. While large business may find these hard to follow due to the sheer scale of operations, small and even medium businesses should benefit from these recommendations.

1. Take it head on – Respond immediately – with an email or a call. Definitely call if you have a contact number. Between his reporting this issue and getting a response, hes unable to use a product that he has paid for and thats bad news – for you. The immediate response just tells the customer that you are willing to stand behind your product and that help is on its way. Its an assurance and a strong message. As I had mentioned in one of my earlier posts, this immediate response is relevant even if you dont have a solution ready yet. Call and tell him that you will look into it and provide a solution as soon as you can. Even go ahead and provide the name and contact number of the support personnel who will be responsible for solving this issue. Automatic email response doesnt replace this. Auto response tells him that he support request has been “received”. The personal response that Im talking about tells him that someone is “looking into it”. There is a big difference.

2. Dont shift the blame – The response call is a bad time to tell him that it was HIS mistake that the product is not working, even if it is. Dont ask him if he read the documentation (not many people do… and again its a bad time to ask this). You may remind him about the documentation AFTER solving his issue
(for future reference), but not now – when he’s still irate. “No one else has reported this issue” again is a bad thing to say. Direct statements like, “We screwed up” or “Sorry, it is our mistake” convey a clear message that you are willing to own up and are committed to resolving the issue.

3. Follow it up to closure – If the issue is going to take a few days or weeks to fix, keep the customer updated on the progress. Having a product that isnt working is bad… but his not having a clue on when it will be fixed is unacceptable – and a sure way to drive customers away. Ensure that the customer has a single point of contact to get updates from. Even after the issue is resolved, ask for confirmation if you can actually close the issue ticket. The customer raised the issue and he has to sign off to close it.

4. Call back to check – Evolve your own schedule to call back customers after the issue has been resolved to check if they were happy with solution and more importantly the way your overall support system responded to him. Ask if he has been able to use the product as intended since. By now, you have a general sense whether the customer is really willing to put the whole thing behind and whether your support process works.

“How many ‏irate customers are being converted into strong advocates” is a great way you measure the effectiveness of your customer support process. Strong advocates talk to their friends positively about your product, give you inputs to improve your product, are willing to be reference customers or even sign up say nice things in your press release. Start building your pipeline of Strong Advocates…. and Irate Customers are a great place to start that with.

 

– NWritings

The Product Manager and the Business Owner

I see a lot of instances where these 2 roles are somehow being confused, leading to insufficient attention being paid to these roles. The purpose of this post is to call out the distinction between these roles for sake of clarity. Let us put in my thoughts on how these roles are different.

Business owner – Responsible for assessing the market opportunity, identifying target customer segment, setting revenue targets, putting together the sales / support strategy and overall scaling the business. The Business Owner role largely operates in the WHY realm. WHY is this market worth going after? WHY are we, as a business, best equipped to do this? WHY does this constitute a strong long term play for the business?
In a small company or a single product company, the CEO may well be the Business Owner.

Product Manager – Responsible for building the right product to enable the business to meet these targets, Ensuring that the product built has an USP or a differentiator among alternatives present in the market. Demonstrates, through live instances, that the product actually solves the customer need that it sets out to solve. The Product Manager role largely operates in the WHAT realm. WHAT is the right product / solution to address this market need? WHAT is the best user experience to be built? WHAT does your product deliver that others in the market dont? WHAT is the right go to market strategy?

The extension of this would be to look at Engineering Head as the HOW guy, but let me just stick to the PM and Business Owner here.

These roles may have their own independent reporting structure, but need to work very closely together to build a successful business.

Many Product Manager profiles and job descriptions that you see are a “hybrid” of both and for smaller businesses the same person doubles up as the PM and the Business Owner. While there is nothing wrong with you doing that, understanding the distinction between these roles is important. It is critical to keep a check on the extent of your focus on each of these and be aware of the balance. For a business in scale both these are huge focus areas and need dedicated mind share.

To start with you can take up both the WHY and the WHAT, but have a good sense on WHEN you want to hire someone who can complement you on this.

 

– NWritings

Performance Management – Keep it subjective

In continuation to my earlier post, Performance Management – Keep in simple, I wanted to add another facet of the Performance appraisal process here. In case you have not already read that, please do so, so that you have a better context of the thought process.

A lot of the overhead described in Performance Management – Keep in simple, fundamentally comes from trying to make the whole performance appraisal process objective. How else do you explain having the employee set medium terms goals and measuring performance at the end of 6 months based on the goals set.

The above approach of setting goals and measuring performance against those sounds reasonable, until you factor in the following:

  1. Its hard to measure most of the time.. Lets say a goal reads, “To improve the usability of the product by 50%” or “To improve code quality and reduce bugs by 25%”…. How do you measure these goal and rate performance on a scale of 1 to 10??? Moreover, these goals are typically set based on the experience from previous assignments and may not be relevant or achievable for the next set of very different assignment that you have on hand. Additionally, you may just decide that something else took a higher priority than improving the usability of the product.
  2. The traditional approach does not factor in “soft” people issues and does not offer itself to reward people for those skillsets. Some one who goes the extra mile to keep the general team morale up, exudes positive energy and influences that across the team, someone who goes the extra mile to mentor a new joinee, someone who has a keen eye to instinctively spot the gap when a release is going awry are all example of this. I have often heard good captains and coaches say, “Suresh Raina has not been among runs of late, but the amount of energy he brings into the team dressing room and on the field is hard to replace and more than make up for this temporary loss of form. We are going to retain him”.

Here are a couple of thumb rules I have usually used in the performance appraisals:

  1. Measure an employee based on the amount of responsibilities that she can reduce for her boss (so that the boss can focus on other things).
  2. Measure an employee based on the impact to the team and the product if the employee resigned.

Keep it subjective!!!!

 

– NWritings

Random musings of a product manager!

After my stint building products in a couple of successful Indian technology product companies, I will be sharing some of my learning and experiences in a series of posts here. Here are a few random thoughts more to shake off my own writer’s block. Going forward, I will look to take up new areas from my thought process and also add more on the thoughts presented below.

1. Listen to the customer, even when they are clueless (and many times, they are): On and off you will get feature requests from customers who have absolutely no clue as to why they want it…..but they want it…. TODAY!!!! They will even offer to buy your product if you added that feature. When you enquire as to what they need from that particular feature the answers are usually vague – on the lines of “we heard this is the latest”. Its just that most of them read somewhere that this particular feature is the latest and they couldn’t be bothered to read more and thought it cool to display that new learnt jargon.

While customer inputs can come in a very useful pointers for you to gauge the customer’s pain point (which is why I ask you to listen to the customer), the product manager needs to have his or her own view of how things fit into the product roadmap. Even during this listening process, make a keen judgement of their problem statement and their solution statement (after all in most cases when they give you a feature request, they are giving you both the problem and the solution)….. and try to solve their problem, instead of taking their solution too seriously.

A very good point was made by Jason Fried on this in his blogs. The crux of his blog was, “carefully read each feature request that you get from customers and then throw it away”. His point was not that you should not listen to feature requests. Its just that there is no need to get analytical about it. If it were such an important feature that you missed, you will hear it over and over again and you wont miss it. AND….. in the event of a brilliant feature that comes up once in a blue moon from some smart user, it will stand up to be spotted and you wont miss it.  I even tried this. I made a huge list of feature requests that we had got and put feature count against each, ended up with something that looked like a grocery list and picked the top few. Then I talked to my customer support lead and asked him what he thought we should take up for the next release and his top-of-the-mind-recall top few were no different from mine

2. Importance of speed: Any market in which you make money will quickly get crowded. While you can still distinguish your offering with a great product, the fact remains that it gets a wee bit harder. Its important to make maximum use of this window where you came into the party early. Drink fast, the beer will run out soon. When one of my first products was released there were exactly 3 people in our development team. We prided ourselves on the high productivity levels and the team size did not go up significantly over the next 2 quarters. In hindsight maybe we should have gone for the jugular much earlier. The rule “If 10 people can do a project in 10 months, putting 20 people will make it 20 months” is more often mentioned as a joke, than as a truth. If we were to do the same thing again (which thankfully one cannot), we would have wanted to scale up the team more rapidly and accelerate the pace of development. Even in established markets, speed can make
competition weary.

3. Instant support: This is somewhat similar to serving steaming hot food in cold weather. If you are running a hotel in Chicago in winter, your first priority should be to serve the food hot, the taste comes next. Now I am not saying serve tasteless food, Im just saying attach the highest priority to the temperature of the food. By serving it hot, you have passed the big initial test. Customer support is similar. Just put yourself in the customer’s shoe. You buy a product, face an issue and send a mail to tech support (hoping that it would be responded to within the next 24 hours) and 5 minutes later, BANG, there a call and a guy says, “Hello, I am John from the customer support team of Acme. we just got your support request”. Even if that guy is going to go on to say, “we are analyzing it and will get back to you with in a day” the customer might only be slightly disappointed. You have scored major brownie points with this instant call. We have done this time and again and the results are almost always excellent. Even in cases where we don’t immediately have a solution, its a excellent idea to call immediately and tell him that the issue has been received, apologize for the inconvenience and assure him that the issue will be resolved very soon. In my opinion, there is no excuse for not calling when the customer has specifically provided his contact number in his request. This creates the WOW effect. Thanks to pitiable support levels that are generally available in the industry, this is a great opportunity for us the differentiate ourselves (and of course we already do). Thankfully, we have competitor who responds with a “Please leave your call back number and our engineers will return the call within 2 working days”.

4. Have the right people in customer facing roles: This is not to be read as “Have the wrong people in the non-customer facing roles”. After the product itself, the guys in the customer facing roles are the biggest thing the world sees of the product. Especially during the evaluation process, the customer makes much of his impression about your offering based on what he hears from these guys. This guy needs to FEEL that he has a great product, in fact, even before he has a great product. This strong belief is what carries through even when he has to say something as humbling as “Yes. It is a bug. We apologize for this”. When you have doubts about your products ability in your own mind, it is hard to hide when talking to some one. It is very easy for the listener to spot this. You want these guys to be polite and friendly and knowledgeable. But much more importantly, you want these guys to convey to the customer that we know what we are talking about. Add a slightly squeeze of ability to bullshit (come on, you cant be in customer facing roles unless you can bull shit a bit) and you have the right customer facing guy.

 

– NWritings