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)

 

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.

Why not Store Trucks?

(image source: http://decisivecravings.com.au/grocery-shopping-for-good/)

The food trucks are slowly showing up on Indian streets. People are opening up to eat gourmet or exotic (or sometimes even normal) street food out of a truck.

There is one thing that I have not seen yet on Indian streets, which I am thinking, might just work. The daily staple/grocery value chain is growing on a fairly healthy rate. The unhealthy or unplanned players have fallen (or falling). The two or three giants are innovating and moving forward.

The value chain started off with hyper-local. Guys like Grofers or Amazon Kirana, take orders from customers, purchase the goods from your local kirana shop and deliver it home. People did warm up to this idea, but was not that wildly successful. Then of course, the concept of Amazon Pantry is slowly taking shape in the country as well. You can buy everything from your tooth paste, to mustard seeds online through either of the big online retailers – the key mindshare is on Amazon and BigBasket now.

My proposal is somewhere in the middle, is where the Indian market place can really boom. This is where you will understand why I mentioned food trucks at the beginning of this article. Why not trucks with store-branded staples strategically positioned at different points. I have seen this with pop-up trucks selling vegetables, but this could very well work for staples as well.

Reasons why this might just work:

  • Online grocery ordering is a very planned activity, where you sit down and think, and look at your pantry, and decide what to top-up for the month. In my personal experience, invariably, every time after I have finished ordering from big basket, I always end up with 2-3 items that I might have missed.
  • There are always staples that might last you until half of next month, and you end up buying more stuff ‘just in case’. “Just-in-time” inventory would be perfect here, but we do not want to do this online thing at the last moment. What if, I do not get the immediate slot. What if, the item I am order is not available in Express delivery (90 min).
  • With the urban household in India, there is a significant population which travels using company provided transportation. A significant portion of this (and the rest of the) population living in housing societies, apartment complexes and the likes.
  • “On your way back from work, please get …..” is a very oft heard phrase in India urbania.
  • Store trucks with the most basic staples such as rice, wheat, lentils, spices, instant foods, would be the right middle point to be able to achieve the above task.

I wonder if BigBasket or Amazon is listening?

Inference and Insights

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. 

img src: https://www.linkedin.com/pulse/big-data-insights-found-unexpected-places-austin-wentzlaff