Communication of bad news

img src: https://commons.wikimedia.org/

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.

If you (or someone in your org) need coaching in this area, please ping me at gcmouli at gmail. 

Decisions, decisions, decisions …

Much has been written about the functions of a Product Manager (PM). I usually do not subscribe to the ‘textbook’ definition of a ‘mini-CEO’ of a product/feature. I feel that, while there are a few overlaps between the roles, it is unfair for the CEO and for the PM to be called the ‘mini-me’ of the other.

One of the overlaps that I find very interesting is that of decision making. For a PM, and more so, for a PM leader, this is one of the key attributes. In fact, as you rise up the ranks of PM-ship, more and more of your tangible time would be going towards decision-making.

There are a few things that I wanted to talk about in this post, about decision making – in no particular order.

  • A lot of times, you would have enough data that you can lean upon, to make a decision. Why do I say ‘lean upon’? If the decision is perfect, then kudos, but then human tendency is to fall back on the data as a crutch, when the decision is wrong. The key thing in the latter scenario, is to learn from it. There is nothing more you can do from it. Accept that, data, can sometime fail you, and try and find a pattern that you can recognize in the future.
  • There are definitely times, when you would not have enough data. In a subset of these times, you also do not have the luxury of waiting for data to be got/collected. In these cases, a seasoned PM would need to take decisions based on extrapolating whatever data she has, or to be able to correlate with an analogous event/incident/feature/project and take a gut call. The key thing here, is to stick by the decision, immaterial of its outcome. Human tendency is to exhibit ‘excusitis’. Like in the previous point, learning is key.
  • There are three typical classes of decisions that PMs make on a regular basis – assumptions/trade-offs ; prioritization/road-map ; go/no-go.
    • Assumptions and trade-offs occur during mostly the planning phase. During the planning phase, the PM, along with business, and the tech-lead, need to freeze on assumptions/trade-offs to be able to ship within a certain deadline, or be able to ship with constrained resources. Resources, here, can be team, compute resources, or technology stack. These decisions sometime creep in during the execution phase – typically due to late realizations or plan changes etc. The PM’s negotiation and influencing skills also play a key role here, along with the decision making skills. Example – Given that a new feature would be hand-held by the feet-on-street teams, the first version of the feature need not have as many educational prompts.
    • Many think that prioritization and road-map decisions occur during planned times (month/quarter beginnings etc). It definitely is not. The best PMs are continuously prioritizing. Devs get sick. Servers go down. Unexpected bugs turn up. Features get new requirements. In an agile environment, a PM needs to manage all of this, and still be able to ship reasonably on time, with adequate communication to all stakeholders. New ideas do not wait for quarter beginnings to pop-up. As and when they pop-up, PMs prioritize and add to the road-map. Again, a continuous process. Example – The biggest issue is to identify if IMEI numbers of returned products match the ones in our system. Let us build a first version that will let the call-center support team do just that. Further versions can be fancier and accept direct requests.
    • Lastly, a go/no-go decision. This is when a PM works closely with QA and business teams to decide, whether a feature can go live (or not!). Time pressures and business requirements often require a feature to be shipped at a certain date/time. A lot of times, this is non-negotiable. However, a PM can take a call to go live, with a version that probably has a non-show-stopper bug. Breaking design perfection paralysis also falls into this bucket. Example – When the seller does not have stock of products, and he is prompted to give multi-tier pricing, the UI might break. Ship the feature, and fix the corner case UI in a subsequent merge.

I have not counted hiring decisions in the above list. PM leaders would need to make hire/no-hire decisions for hiring PMs in their teams. In some companies, PMs are also called up on to do an interview round for senior dev leads and designers.

PMs – have I missed anything? Let me know in the comments below. Would also love to hear examples of key decision making techniques that you follow.

Modiji, Bullet trains, and the Prioritization conundrum

PM Modi and the Japanese PM Abe jointly laid the foundation stone for the first bullet train in India. Enough has been ranted about this in social media. About, why this is not the thing that is needed now. And why the Govt should fix all the issues that is plaguing the railways and so on.

I think this is a problem that Product managers face too (Hmm. Just a coincidence that, they are PMs too.).

The feature prioritization conundrum is the scenario where a PM is faced with a host of small urgent + Important  issues/features to deliver in a short time-frame ; and a smaller bunch of longish important but more challenging hard problems to solve. The engineers want to do the latter, but the former are very important too.

A PM cannot keep prioritizing the smallish important problems higher, because they will never end. You will never get to the largish challenging problems. This will lead to your engineers getting demotivated and doing mundane familiar stuff. But at the same time, you cannot just prioritize the challenging projects – this will keep your engineers happy – but the business suffers. Some of these urgent+important tasks are most likely important for the business.

One of the solutions to this is to assign more than one task to engineers. This should be a mix of the smaller urgent tasks and the longish exciting tasks. This will keep your engineers happy and the business going.

So, does that make, what our Prime Minister did, with the bullet train right? I do not know, since I do not have enough context. But if I see the PM as a PM ( 🙂 ), then I guess he is doing the right thing.

What are we shipping today?

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.

 

(Cover image source)

 

Hiring decision should not be democratic

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.

Demo day at Shotang

Earlier this month, we, at Shotang, held our first demo day. It was a Friday afternoon event on our terrace. We could not have had better weather that day. The intent of this event is to showcase the technology and the product that is being built to enable the first large scale retail distribution platform. This would hence enable all the functions of the Shotang family to literally play with the product and gain a deeper understanding.

This was driven by the awesome product team at Shotang, ably supported by the equally awesome tech team. The product team coined a name for the demo day as well – Shotgun. We ran with a Wild West theme through the communications.

This being the first demo day, the event focused on the journey of an order on the Shotang platform. We wanted everyone to experience the full flow – from the retailer placing an order through the Shotang retailer app, to how it flows through the seller dashboard ecosystem, and the falcon logistics apps, which powers our pickers and the delivery executives.

We had set up POD stations on the terrace – one each for the retailer experience, seller experience, and the logistics platform. Engineers and PMs manned these booths and explained the flows with pride. There was a complete test bed that had been created on a test city, where guests could place orders, and trace their order through the entire platform.

It so happens that in a company such as Shotang, day to day agility forces each function in the company to focus deeply on their own domains. For example, the corporate finance team spends its waking days poring over the sales and spends numbers, but often do not get enough visibility into the actual product. Similarly for other teams such as our customer delight team, our commercial finance team, alliances team, and so on.

What did we get out of this?

  • Singular pride for each PM and engineer who showcased the products that they develop. You should have seen the energy on the floor.
  • Zonal leaders (P&L owners) from each of the 7 cities that we are live in, got insights into what is the current state of product and tech, and what is in store for the future.
  • Greater visibility on the amount of tech that goes in to developing our platform
  • Increased empathy for our end customer and what she goes through.
  • So much feedback that came in from non-tech folks on improvements that could be made with respect to user interfaces.

Moving forward:

We intend to have a Shotgun event every month. Product and tech developments since the previous month would be demonstrated. We would sync the event to the monthly planning meeting of the Zonal managers. We anticipate that the local field leaders and the zonal leaders would take back to their respective field teams, the latest developments and future plans.

At the end of the day, It is also a fun event, where we celebrate all the hard work that has gone in, to do, what we all love doing – ship!

Wayanad-Kozhikode roadtrip – May 2017

Started off early at 6:15AM on a Thursday morning. Route plan was Bangalore – Nice Road – Mysore Road – Ramanagara. Breakfast at Kamat Lokaruchi. Took roughly an hour (usual time) to get there.

The route from Ramanagar is – Mysore Bypass – Nanjangud – Gundlpet. At Gundlpet, you fork off towards Wayanad/Sultan Battery (the other road goes towards Ooty). After a few miles from Gundlpet, you get into forest territory. Awesome road and scenery all around.

Super roads all the way. Took another half hour to get Windflower Resorts. Reached around 1:30PM – right in time for lunch.

If you went all the way to Vythiri town, you went too far. There is a town just before it called Chandel Junction. At Chandel, look out for Canara Bank and SBI ATM on the left, and a road that goes down hill right opposite it. The corner is also an auto stand. Easy to miss. You go down the road, or what is called a road for 3.5km. Horrible horrible driveway. Apparently they have not repaired the road because it is under some court stay order.

The resort is just fantastic. Isolated. But beautiful. We had booked a villa with a private jacuzzi. Totally enjoyed the room and the resort. Some pictures of the resort below.

Windflower. Vythiri. Wayanad. #wayanad #vythiri #roadtrip #prisma

A post shared by @ gcmouli on

Infinity pool. Windflower resorts. #wayanad #vythiri #prisma

A post shared by @ gcmouli on

The patio. Windflower resorts. #vythiri #wayanad #prisma

A post shared by @ gcmouli on

Room with a view. Windflower resorts. #vythiri #wayanad #prisma

A post shared by @ gcmouli on

We went to Pookode lake one of the days, and totally not worth it. Super crowded small (compared to Ooty/Yercaud) lake. There is also a view point on the Kozhikode road that is pretty darned good. But we had to run off quickly. Too many rowdy monkeys demanding stuff from the tourists.

There is one other place near by, called Banasura Dam. It is the second largest earthen dam in Asia (largest in India). You can do a speed boat ride (super awesome – my son loved it!) and just get some awesome views of the dam and the Kabini river.

We stayed there Thursday and Friday. We were planning to leave Saturday back to Bangalore. But we realized that Kozhikode was just 2 hours away. And the beach beckoned. So we made a flash decision. Was able to snag a room in a beach resort in Kappad beach, which is 20 km from Kozhikode. The resort (Renai Kappad Beach resort) is separated from the beach by just a small road. We did Banasura on Saturday morning, on the way to Kozhikode. Reached Koppad beach by lunch time.

Evening was spent on the beach. Super time was had.

Beautifully pristine Kappad beach. #kappadbeach #kozhikode #prisma

A post shared by @ gcmouli on

Oh boy. This sunset is gonna be fun. #kappadbeach #kozhikode #prisma

A post shared by @ gcmouli on

Back to Bangalore on Sunday morning. Had breakfast in Kozhikode. It is a long ride back to Bangalore. Almost 10 hours including breaks. Lunch was at Gundlpet. There are a couple of decent restaurants just outside of the town. Reached home around 6PM.

 

Affiliate Programs in Travel

img src: http://www.geograph.org.uk/photo/1133475

This idea just came fleetingly to me today morning. Large ecommerce companies like Amazon and Flipkart have affiliate programs. You become an affiliate, and the platform lets you create a special URL to advertise products on their platform. You make a sale, and based on the product, and current ‘schemes’, you earn a % of the revenue. This is almost like a micro-store-front.

Large OTAs such as goibibo and yatra have b2b platforms, which they open up to travel agents. They also have APIs which third party platforms can consume and create their own booking interfaces. But these are complicated interfaces. Only a serious large player can invest in these. For instance, in the case of goibibo b2b interface, the travel agent would need to create a “wallet” like interface within goibibo, deposit a certain large amount (depends on the client – but mostly a few lakhs to begin with). Transactions that happen through the travel agent interface (or API) would consume money from the wallet (after deducting the % commission due to the travel agent).

The other class of “agent consumers” are of course, the travel agents who pose as individuals (create regular goibibo accounts) and book through these accounts. These are smaller operators, and tend to do all kinds of circus tricks such as referring their own accounts, playing with the go-cash between the accounts etc. And the OTAs hate these guys. Incentives are given, assuming, these are individual accounts, but they are not.

My question is – why haven’t the OTAs yet brought in the affiliate model for selling flight tickets and hotel rooms yet? This would have two major advantages:

  1. Bring in the above latter set of small scale travel agents to formalize on their transactions. Since they are not a separate class of consumers (affiliate partners), incentives to these guys can be controlled and distinguished from the other individual consumers.
  2. Bring in a whole new set of consumers, multiple thousand micro-store-fronts, who are not really booking tickets, but proliferating links to your deals with their affiliate codes on them, so that they can earn their commission.

The OTAs keep talking about how the online travel agent market has just touched the tip of the iceberg, and how there is a significant majority of our populace who have not even been exposed. This might be one of the ways, by which the net can be widened.

Oyo Airport

img src: https://www.flickr.com/photos/derekskey/7656182704

It has been a while since I wrote a product feature post. A friend and me were having a conversation about the accommodation industry near airports. The Delhi airport has a neat strip of Airport hotels at the AeroCity area – mostly standard chain hotels such as Ibis, Lemon Tree etc. This is not quite true of all metros. Chennai has a couple, but mostly high end. Mumbai is slightly better, but the others just do not cut it. Bangalore has very few.

When it comes to Tier 1 cities, there are at least options in the city, but when it comes to Tier 2 towns, the need for a standardized hotel near the airport is much more. These are places, where the business traveller needs to fly in, stay, finish his work, and fly out, quickly – sometimes the same day.

So, I envisioned a chain like Oyo starting a vertical called Oyo airport. Let me attempt to list down the specific features that such a property should have.

  1. Proximity to the airport. This should be extremely close to the airport. It should be close enough that, at the end of the day, the traveller, having checked out of the Oyo Airport, should be a few minutes away from the airport.
  2. Shuttles to the airport. This is paramount. It should be a brain dead simple thing that the traveller should not even think about. When booking an airport oyo, the traveller should have an affordance to enter his incoming flight number (and outgoing, if he has already a return ticket). Technology should enable the concierge at the airport hotel to send the details of the cab/shuttle/van to the traveller. The same affordance stands for his return trip back to the airport.
  3. Flexible check-in times. People fly in at all kinds of hours. The check-in policy should be 24 hours.
  4. Flexible stay durations. There should be options to be able to book a room for half a day or other intervals. There are many a time, when the traveller would be arriving at a very late night flight. He needs a few hours shut-eye, and a shower, and he would be off for his work. The traveller might not return to his room at all. So why pay for 24 hours.
  5. International flights. Most international flights have long layovers. So the same point as the previous should hold good. Check-in at 11PM and checkout at 4AM. Why would I have to pay for 24 hours. Technology should also be able to help in allocating ground floor rooms for these travellers, so as to not disturb other guests. Room accessibility should also be taken care of, since these travellers would be travelling with large suit cases and bags.
  6. Food. Considering the uniqueness of timings of this kind of a hotel, there should be available a 24 hour cafe – serving light eats at all times, and breakfast, lunch, and dinner at specific times.
  7. Concierge cab services. Given that, folks are flying in, and mostly for business, these travellers would most likely need cab bookings done. An integration with a service like Ola b2b services, to be able to make cab bookings in advance.
  8. Oyo Airport vertical should ideally be in the premium segment, given the fact that, most people staying here are flying in, which is a higher spend demographic.
  9. Tie-ups could be made with airlines for check-in kiosks in the lobby as well.
  10. Tie-ups with flight+hotel deals with LCCs such as Indigo and Spice, could result in very high intent customers, leading to win-win for the airline and the hotel.