Follow-up to a mini post on a very pleasant customer experience with Bigbasket. I strongly feel that, any company which is interacting with customers on a regular basis, should have a Chief Customer Experience Officer.
Penning down some thoughts on the same below.
I did think for a little while, that this should be a major responsibility of the product leader, but on hind-sight, I do not think so. It is a large responsibility on the product leader to think about the customer and evolve the products/services of the company towards that, but there is much more that the product leader does.
I strongly believe that, a role focussed solely on the customer is much more beneficial than, it being part of the role, of another executive. It demands and deserves a separate role.
The CCXO (sure, it is a four letter acronym, and overlaps the generic CXO, but this is purely hypothetical) should have far ranging powers that span cross-functional domains.
The CCXO should be comfortable with tech, marketing, business, field, operations, and most importantly with the consumer landscape.
The CCXO should be the person who knows the most about consumer environment, pain points, and behavior.
The out reach of the CCXO evolves over time, because the environment, pain points, and behavior evolve over time.
The CCXO should have be the voice of the customer and be emboldened enough to argue against any/every other function in the company and fight for them.
The CCXO and Product Head should work very closely in planning out current features and future roadmap.
CCXO should have his/her own data sets and inferring mechanisms to make sense of the customer base, and impacts being made.
CCXO should also work closely with customer support and ensure delight and redressal happens without fuss. Processes and exception mechanisms, and empowerment of the team are important here.
End of the day, the CCXO is charged with creating beautiful customer experiences that are worth remembering.
Was listening to this awesome podcast from the Knowledge Project (of Farnam Street fame) with Ray Dalio, where he talks about idea meritocracy. Found it fascinating. Such clarity in thought.
“There are two things that one needs to do to be successful in anything. 1) Take the right decisions, and 2) Have the courage to execute on these decisions.”
Ray, then talks about how he makes decision. Over the years (he has been running Bridgewater Associates, one of the largest hedge funds in the US), he has developed an algorithm on how he makes decisions. He also writes in what he calls a decision journal, where he documents the criteria for making the decision, information that he takes, and his process to take the decision.
One of the things that he talks about is idea meritocracy. Some of the key points that I understood were –
All ideas should be treated clearly and put on the table.
Each idea should be considered without a bias.
He talks about thoughtful disagreement ~ where one needs to agree/disagree and dissect the idea with an objective view.
Two kinds of decision makers – autocratic and democratic. Neither work.
Autocratic – the bossy types – who eventually make the decision, based on their own thoughts/opinions.
Democratic – who always lean towards public opinion and consensus.
He believes in making a decision based on discussion (and hence thoughtful disagreement) with people with high believability scores. Believability is based on competency and experience.
Example that he gives – I need a medical opinion. My believability score is pretty low. Doctors who specialise in this field have much higher believability scores. Get at least three of them to discuss ~ preferably even disagree and debate between themselves.
I think, I will definitely read his book – where he outlines a lot more. And will update here then.
I just read T.N.Hari’s excellent write up on “Firing someone you deeply admire.” Brought back a lot of memories of the last few days of Stayzilla. There were anxious moments, and then resignation to what had to happen, and the morbid planning sessions. Morbid because, they are just emotionally taxing, but it has got to be done. What has to be done, has to be done. And in the most humane way and with utmost empathy. A lot of thoughts flew through my mind, as I recollected those days, and I thought I should jot them down here.
Proper crafting of communication is super super important. And I feel I am still understating it. The message, the timing, the tone … all of it should be crafted very carefully. These messages touch raw nerves.
Communication should be consistent across the organization. What the sales leader communicates to his team should be exactly what the Engineering leader does, and what the Product leader does, and of course, exactly similar to what the CEO says, in the last townhall.
In the event, the above cannot be done – sometimes it happens that some functions need to be given a different message – all leaders need to know what the different messages are, and why they were different. Because, there will be questions, and you should answer them.
Timeline of events on the D-Day is very critical. There should be absolutely no ambiguity. For instance, in the first instance of letting go, at Stayzilla, in the town-hall, it was announced that, some of the folks are going to be let go, and their managers would let them know. We timed it in such a way, that we had the emails ready to be sent, and were fired off the minute the town-hall ended. Folks should not have to wait and second-guess stuff like this.
Empathy is the single most important thing during these times. And by that, I mean genuine empathy. It is extremely difficult when the decision goes against folks whom you know well, and especially hard, when you know it is not fair on that individual (decision was not made based on performance).
Organizations tend to be uneven and imbalanced sometimes. It is important to share the load of communicating bad news and lending emotional support, between leaders. For example, the dev team was much larger than the product and design teams put together. Hence, the product leaders took on some of the engineering conversations too.
Of course, care has to be taken, that the leader communicating the news has to have had some professional relationship with the person on the other side. Else it is just apathy.
I had superb leaders from whom I learnt from, during this very difficult time. One must dispose of one’s ego, and be open to learning and sharing, during these hard times.
I wish, this is one thing that founders, and other leaders, get coached on. I have seen and interacted with several people who fail miserably in these soft people aspects. And I think it is incredibly important. God forbid, such an eventuality should never occur in your org, but one must be prepared.
The above points are in no particular order. I just did a tweet-storm on it, and subsequently expanded them into this post. Would love to hear your thoughts/experiences on this.
Ask any of the PMs who have worked with me, they will say that this is my favourite statement. I ask this statement at least once a day to them.
I was talking about this with one of the PMs who works with me, and I thought I would share some of the conversation highlights here.
Shipping is the most important outcome that any PM needs to aspire towards, at any given time. The more you ship, the better you are.
The primary reason for existence for a PM (in my humble opinion) is to ship. Sure, programmers code. Designers make the product beautiful and usable. Business folks give their requirements. Marketing folks get out the word. Customer support teams are on standby. But what is the use of all of this, if you do not ship. The PM is the glue that enables all of this to come together and ‘happen’.
Example of ‘shipping’ being considered a real (and an important) thing — the famous ship-it awards in Microsoft. Every stakeholder who was part of a release used to get a Ship-it award (a tiny trophy kind of thingie). MS folks proudly display these ship-it awards on their desks.
A lot of PMs that I know (including yours truly) come into this field from Engineering, Marketing, and various other fields. In most cases, we have boarded this ship, as a leap of faith. As a matter of fact, the best PMs are the ones who learnt on the go. It is incredibly hard to ‘explain’ to someone, or to ‘teach’ someone about ‘PM-ship’ (no puns intended). In these cases, the only way to ward off self-doubt (which is bound to happen) whether you did the right thing — is to ship. You keep shipping. And the spiral is always upward.
Shipping creates tangible outcomes. And it reinforces.
Ship incrementally. If this is not an option, get your devs to at least commit incrementally.
Lastly, you are known by what you ship.
The original conversation was a very free-wheeling conversation during our 1-1. And so, was this recollection of thoughts. The above is in no particular order.
A hiring decision should never be a democratic decision.
The interview panel gives its recommendations -> and then the hiring manager gives his observations. It is the hiring manager’s single call – with the recommendations factored in.
Some mechanics and rules (such as categorization between hire/no-hire/weak-hire etc) can be brought in to break ties and help the hiring manager strengthen his view point, but it should be just that.
The hiring manager should have his veto call over the others. The accountability rests on him to hire whom he thinks is the best hire. The buck ends with him. The minute it becomes democratic, the buck starts circling. The accountability dilutes and spreads out. There is no skin in the game. Too safe. No risks. This can never end well.
Portfolios: HR sourced UI/UX candidates for me. We took on only resumes which had pointers to their portfolio (in Behance or elsewhere). If they did not have a portfolio, I did not consider them serious enough to be applying to us.
UI/UX designers vs Creative Designers: There is a fair amount of ambiguity that candidates typically play on, between UI/UX and creative designers.
My definition of a UI/UX designer is a combination of visual design and interaction design. In other words, the candidate should have designed web or app flows (or atleast part of them). These guys have the knack of leading a user through a flow. They know the importance of consistency, primary colors, templates etc.
Creative designers (per my definition) are those who focus exclusively on visual design. These are folks who are exceptional at creating marketing collateral content (such as ads, brochures, posters etc). These are guys who are awesome at designing stuff that will catch your attention. They know the contours and contrasts that will stand out. They know the colour palettes that will work better on banner ads vs print vs mobile.
While hiring for your designers, you should be able to distinguish (to a large extent) at the very beginning what kind of work that they have done, and what their strengths are. Most folks tend to sell to you that, they can do both. I am not a full believer in that yet.
Talk to the candidates: My lead designer and I used to have an intro call with every one of these candidates. You can figure out the ambiguity that I talk about (above) very easily in this call. Talk to them to get a feeling of whether they would fit in, into the culture. See if they can express themselves to you. They need not be eloquent (most aren’t) but they need to get their point across.
Sample project: Those, who pass the phone call, I had our lead designer send out a sample project to them. Depending on your timeline to hire, this can be as small as redesigning/reimagining a page on an existing app/website; to as big as redesigning a process (the payment flow for instance). We used to give adequate times for these. The smaller projects are 1-2 days, and the larger ones 3-4 days. There is a reason for this. Designers typically take time. One cannot push designers hard, like you can do to engineers. More number of hours does not equals more work, in the case of designers.
We also took a look at how these sample projects were submitted. It shows the seriousness of the candidate. There will be candidates who will submit PDFs. They will be some who will submit sketch files. And there will be some really good ones, who will give you an invision file, with sample click behavior and everything.
In-house interview: For the in-house interview, the candidate should talk to one Product Manager (PM), one front end engineer, lead designer, and the hiring manager. If all goes well, one round with the HR.
You probably guessed why the above people were chosen to interact with the candidate. Yes. These are the guys who will be working with the designer. They are the stake holders. You need to know how the designer interacts with a PM and a front end developer. These are one of the touchiest relationships.
The PM dreams of impossible stuff to design, and the front-end engineer would refuse to code it up. And the designer is stuck in the middle, typically. How assertive is the designer? How much data is being requested from the PM? Is the designer trying to understand why the front end engineer is saying, something is not possible?
The interview with the designer is typically to touch upon the technicalities. What are the tools he is familiar with? Is he an expert user? Or very novice. How well does he know his interaction design? A lot of this would have come through the sample project. Typically the lead designer (or me) would probe as to why the designer designed the sample project in a certain way. If there is any plagiarism or this was a fluke, this will come out now.
History and lessons learnt: Contrary to what everyone thinks, the designers job is a very hard one – playing to the tunes of multiple people and scenarios. They have to walk a very thin line between being creative, and delivering within time pressures ; between making a noticeable change, and preserving your style guide ; between taking up a largish revamp of a page, and making a dozen tweaks for the short term ; taking a call between what the PM thinks, the designer thinks, and the customer perceives. I typically ask the designer, what are the lessons he has learnt on the job, while being a designer, and listen. I would expect some of these above thoughts to come out. If they did not, he has been too passive a member, and has not contributed enough. I probe into some of these thoughts, and see what are the learnings that the designer has been exposed to.
Endnote: I had hired a lot of engineers in my career, but hiring designers is a totally different ball game. It is not a 0-1 decision problem. You cannot hire a designer because he knows his tools really well. Designers are creative types, and for a large fraction of them, it is hard to gauge attitude and personality. It needs time and effort to hire the best designers. But once you get them, you are set.
Disclaimers: We were a product based company. I was hiring UI/UX designers.
As a leader, the two most important things you can gift your team is pride and joy. Your team should enjoy their work and feel pride in what they worked on. These are the two fundamental premises that I base leadership on. If you are able to enable this for your team, you are a good leader.
Most other leadership traits and good working environments are derived from this base. Let us take a couple of examples, and see.
Great teams pour their heart out into building cool stuff. Have we all not realized that, we put in our best effort if we enjoy what we are doing?
Growth – Most folks grow in their career paths when they accomplish significant milestones. I measure milestones by impact. And people realize significant impact that they are making, when they feel proud. Pride swells when you accomplish more and more.
It is a cyclic process too. When you enjoy the work you do, you achieve more, feel pride, which makes you reinforce the joy in your work.
Interviews are a shot in the dark. You never know the state of the candidate on that one date, and deciding his fate based on how he solves a certain analytical problem, has never seemed the right thing to me.
What they have done earlier: I always ask about one project that the candidate has done in her previous work experience that she is most comfortable with. I ask the candidate, to then, go in depth, and explain to me. There are a few things that I can assess from this question:
Depth of knowledge: While knowledge of depth first trees and red-black trees are important, what I feel is more important, is how they have applied this knowledge. I go deep and probe into the problem, assessing, how deep the candidate has understood the problem, and the involvement with which it was solved.
Applied problem solving: How was the problem solved? You can test, how the candidate has applied existing algorithm techniques, or data structures to solve this problem. I ask “why so?” and “why not?” questions to see if the candidate took these decisions in an informed manner, or was she just implementing what she was told.
Big picture: I typically ask, where the particular piece that was developed new, or fixed, goes in the large product, or project. This gives me an idea as to how much the engineer is focused on the larger picture. The great candidates would know exactly ‘why’ they are fixing a problem, or developing a new feature.
Customer empathy: Yes. Every project has a customer. It might be external, or internal, but everything has an end-user. A developer in another team, consuming your API is a consumer too. I ask questions on how the candidate kept the consumer in mind. You get a lot from this question.
Communication skills: Was the candidate able to explain to me in a structured, lucid manner, about the problem, and how it was solved? I place very high importance in this facet. This is not to be confused with presentation skills. I do not expect engineers to be brilliant presenters (they are a few, I know of, though!). But, they should be able to communicate well enough to QA, PM, Design, and management. Else, there is huge productivity wasted here.
Attitude towards learning: Let us all agree, that, there is no one who knows everything. No one. So the best candidate, to me, is one, who realises this, and has an open slate to learn anything that is required, to do her job efficiently. There are a few ways by which I gauge this. I ask how much the candidate has learnt in the recent past. I ask about good projects and bad projects in recent past. I look for, if the candidate mentions her learnings on good and bad projects. I ask if something completely greenfield is thrown at the candidate, what would she do? Her structured methodology to crack it. I look for google, quora, online MOOCs etc.
Team player: While this seems cliche, I place a lot of important in this. I observe the candidate keenly on behavioural aspects. I ask questions such as, how the interactions with other teams such as QA, Design, PMs are? I seed sly questions such as – “These designers just don’t get technology, do they?” and observe. If there is one thing that I cannot tolerate, it is jerks. There is no place for brilliant jerks on my team. Sorry, cannot tolerate it. I will take a week more, with a slightly lesser brilliant engineer, but I would rather have fun doing it. Life is short. I want the engineer, and the team, to have pride in what they built, and jerks hamper this beautiful emotion.
Thinking process (PM interviews): I usually toss in a large green field project, such as “Growth for a Boutique Online Coffee Roasting Company”. I give the PM a few minutes alone. Once back, we work through the scenario together. I gauge structured thinking process here. I see how the PMs are making assumptions and communicating to me. I watch how the PMs react to suggestions from me. Is she accepting everything I am saying? Is she contradicting appropriately? If so, how is the dialog? Prodded deep enough, you check attitude here as well. I can sense condescension from a mile away.
I was thinking about all this today morning, and I thought, it would be good if penned these down here as well. I have been using these techniques for more than a decade for interviewing folks, and to a large extent, hit success. Sure, there were a few misses, but then, like I said, interviews are a shot in the dark. In the case of misses, you just need to realise it quickly and rectify.
This came up in a recent meeting with the Product team at work. We were talking about data and how in recent times, we have gotten a ton of it. We were also talking about how some of this data was actionable, and some was just there. In some areas, data was just becoming very hairy and unmanageable.
We spoke about Inferences vs Insights.
Inferences: You look at all your data. You crunch what you require. You ignore/delete what does not matter to you. You separate out key metrics and secondary metrics.
Insights: These are trends and patterns that you spot in your inferences. You then distill them, cross-reference them, and derive insights out of them. Because of a drop in metric x1, and a corresponding metric x2, the resulting derived metric had a double increase to x3. Add to it, seasonal variations, of a corresponding period in the last year, you get an insight as to whether what you have ‘built’ has been worth it or not.
Getting inferences is more or less a science, but distilling insights is almost an art. It takes experience, and an open perspective to effectively derive insights.
Insights also serve another purpose. They serve as basis for hypothesis, and experiments. You get insights using a subset of data, for a period of time, which leads you to make a hypothesis, which in turn you experiment for a different period of time (or a different subset of data), to prove it.
The above was the effective crux of the discussion that we had, and I thought this might be valuable as food-for-thought (if not anything else), for the few folks who read my blog.