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.
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.
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!
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.
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.
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.
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:
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.
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.
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.
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.
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.
Flexible check-in times. People fly in at all kinds of hours. The check-in policy should be 24 hours.
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.
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.
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.
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.
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.
Tie-ups could be made with airlines for check-in kiosks in the lobby as well.
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.
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.
This is my opinion, based on my research and preferences. You should do your own, to figure out, yours.
I overheard a young man say this to his father last weekend. Somehow, it just stuck inside my mind, and kept coming back. Today morning, I thought about it a little more. I stepped back, and realised that, I do this too. With family, with friends, with colleagues, with everybody. Step back yourself, and think for just a minute, on how you respond, when someone asks you for an opinion.
We are currently a generation, which gives opinions and recommendations, only with disclaimers. We are afraid of telling it as what it is. We are afraid of people coming back and saying – “you said so.”. I don’t remember it being so hesitant, when I was growing up. There are so many things, that I have done, because I trusted someone’s opinion, went to them, asked for the opinion, and just did exactly this.
Now, where am I coming to, with this? Is this a bad thing? Probably not. The newer generation is becoming more aware. They are making more informed decisions. However, I am just a little sad, that the trust factor is diminishing. Every time, I say, “This is my opinion, you should also do your checks”, it kind of feels like, I am washing it off of me.
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.