It is becoming increasingly evident that companies should be establishing labs inside their entities, for exploring new deep tech independently.
The labs should have the autonomy to go far-out into futuristic new deep tech without having to worry about current limitations.
The research function should be independent and should encourage creativity.
To a large extent the labs work should not have time pressures.
Productising these research ideas would be the key to differentiating the companies offerings in this hyper-competitive space.
These labs should not be led by architects or EMs. They should be led by people who have experience in doing research, preferably PhD.
Research rigour is important.
Some companies have been doing this for a very long time – Mercedes, Airbus, Sabre etc. Ixigo Kitchen Sink is a classic example from a few years ago. I am hearing of more newer companies starting to do this – Amadeus Labs, Rivigo labs etc.
It would be refreshing to see this happening in all the unicorns. For instance, I would imagine Swiggy would benefit immensely — so much funky stuff can be done on IoT, route planning, kitchen optimization etc. Similarly Go-MMT does a lot of research along with the day-to-day work. I believe that this is not the right approach. You should separate these two out – for best optimality. Else, engineers and PMs are permanently at a conundrum to see which is more important – long term research drivers or short term revenue drivers.
We keep hearing about Big data everywhere – sometimes in places where we do not even expect to here it. I was listening to the latest Trailblazers podcast from Walter Isaacson, and he just casually dropped this nugget.
Small data is the capturing of the small, subtle nuances of a customer. A lot of times, these small seemingly insignificant subtle pieces of information lead to huge product insights.
While extracting big data, and distilling data out of it is important – it is still generalisation. It is amortised data. It is a collective. It is very important for PMs to observe customers at close quarters on a regular basis.
In my three years of observation, being a product leader, I have seen that insights distilled from big data, can only result in incremental improvements.
To get 10X improvements, we need to observe and incorporate these behavioural, often times visual, subtle insights. These are few in number – viz small data.
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.
If you (or someone in your org) need coaching in this area, please ping me at gcmouli at gmail.
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.
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.
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.