It’s been more than a year and here are the things I wish I had known or had been told as I made this transition:
- It’s a completely different role
- Focus on getting things done more than doing things
- Be clear on what you are driving and what your team is driving
- Communicate! I thought I was good at it but managing a team requires more written communication, more documentation that I thought
- Read “Good group product manager, Dead Group Product Manager”
- Accountability – be explicit. Folks don’t just do the right thing.
Is this obvious? Probably to many but honestly it was not to me and I’ve managed a team before.
One of the difficult things for me is to make good habits stick. With the amount of travel I do, it’s been hard to hold the team accountable for their tasks. I have started to use Trello to track tasks assigned to the team. I love that you can email directly to a Trello board. This allows me to bcc task emails to the Trello board. A little bit of housekeeping later, I can remember to follow up on these tasks in 1 on 1s. Travel makes it harder to follow up on tasks. This is why a Group product manager role is very different from other management roles.
Also, you spend a lot of time prepping decks for internal pitches and driving alignment between various other groups in the company and championing your causes. Your wins and losses are public and drive team morale more than you think.
Have been lapping up the Fizzle.co podcast over the last few weeks. It has been motivating me to write the book on Delhi that I wanted to write and got me to start the email sign up list for the same on Delhishoppingtour.com.
It has also prompted me to develop a course on how to go from being a developer to becoming a product manager.
While I don’t think I need to sign up just yet, I think this might be the best $35/month you can spend if you are interested in starting your on business online or are pursuing passive income or want to just be a life hacker!
Listen: The podcast
Saw today that there are 20,000 drivers in the SF bay area on techmeme.
Comparing this to Delhi, where population density is almost 30 times that of SF bay area. But no more that 30% of the population would really be relevant, I’ve come up with the following figures when I try to keep the same number of drivers/person in both the cities.
||area (sq kms)
||density (people/sq km)
||driver per person
|SF bay area
||5025971(30% of total)
Seems like Delhi needs a lot less drivers than the SF bay area unless more people can afford taxis here.
I got promoted in December 2014 and started building my team post Christmas. This involved hiring two associate product managers and one product manager.
I started hiring for a these roles in the first week of January and got the last person to join on the 27th of April 2015. It look almost 4 months from start to finish when sourcing resumes was not a problem because I work at Adobe in Noida and that other PMs referred almost 90% of all candidates. I looked at about 60 resumes.
The resumes seemed remarkably consistent on the surface. All of the candidates were engineers and had an MBA. Very few of them had any entrepreneurial experience or had a background in design. This is typical.
The candidates were rejected for the following reasons:
- Attitude and fitment – this mostly happened in the interview stage
- Claiming more than they actually knew – rejected during phone screening by me
- Lack of fluency in English – rejected during phone screening by me
- Lack of understanding of software analytics – rejected during phone screen
The candidates that were hired had the following characteristics:
- Hunger to learn
- Excitement about the job
- Basic analytical skills or sharpness to converse on various topics in the software industry
- Strong communication skills –written and oral
What did I learn from this experience:
- Do not trust resumes
- Talk to every candidate on the phone or skype before bringing them in for an interview
- Ask them to present the plans for the product they are interviewing for before interviewing them to ensure they can really build a POV on the product and communicate it well
- Ask for a writing sample where the candidate explains why they will be good for this job
I will post a follow up with more details on the demographics and educational qualifications of the candidates soon.
I’ve written before about the importance of storytelling skills for product managers. It’s the one skill that product management teams in India have not focused on much. While we test for analytical skills at academic qualifications, we don’t test for storytelling skills in product management interviews.
As I’m building my team, I’m really looking for the following skills in candidates:
How good are they at:
- Storytelling – Can they pitch their idea? Can they weave a cohesive story around their idea?
- Writing and speaking skills in English – A great product manager, who is hard to follow when speaking or in her written words, will not be able to lead very well nor motivate
- a team.
- Love for technology – can the candidates demonstrate a love for technology and a good understanding of SDLC, etc.
Going back to storytelling… here is a good post to help you pitch your ideas. I’m also linking to a couple of sites that have pitch decks from various startups that you can review to see how entrepreneurs pitch their ideas internally or to VCs.
I love Jack Dorsey’s presentation skills. This particular presentation at Stanfords scorner website is really engaging and inspiring. This is how we should aspire to tell stories
At each release or a push to production, we defer a set of bugs and add to our technical debt. Unless you keep aside time for fixing these issues, you will keep adding to your technical debt. This will become an issue sooner or later. But doing this is hard. It is easier said than done.
Setting aside time has been really difficult for me as I’ve tried to chase more strategic priorities with a 2-3 year payoff instead of fixing old bugs. I’ve also noticed that very few bugs that we’ve deferred ever come back to haunt us via user to user forums or through social media and have wondered if it even makes sense to go back and fix these bugs
So… what is the optimal number of deferred bugs or legacy issues that we should fix in a given 3-4 month release? Generally, for highly functioning and customer connected teams, this number is much less than what the product management team feels comfortable with at the time of shipping an update.
This means that product management teams can be stricter about the total number of bugs to reopen for fixing after a release has shipped. I believe that we will get much better results if we let the feature team or “squad” decide which bugs to reopen and fix in their area.
Once we have a list of bugs to reopen, it has not been easy to get these fixed in time for the next release. We’ve tried different strategies like:
- Assigning a bucket of bugs to the team and letting them fix the bugs over an 2-3 month period
- Prioritizing deferred bugs and letting the team fix as many as they can within a month after release
- Setting aside a 2 week period where the team only fixes bugs in the order of priority of the bugs
We have had the most success with option #3 since it gives a clear goal and time to the dev team to go after these bugs. This said, we still don’t get all of the bugs fixed since fixing long standing issues is not trivial, otherwise we would have fixed them already. Other options lead to teams fixing easier bugs rather than going after the hard, important ones.
had a great time presenting the ShaperTool at Adobe MAX this year. The presentation was really well received. I have never received so many compliments for a presentation. In fact, buy cialis two women came up to me and wanted a photo with me. This was a career first for me.
I’m sharing the books and podcasts that I’ve read and listened to over the last few years on product management, business and life in general that I’ve found useful. Hope you get a chance to read and listen to them.
I have a one hour meeting starting at 10PM India time, which is 3 minutes from now. I’m writing because I am acutely aware of the tolls such meetings have on your private life. Since this meeting involves crucial conversations, I have been distracted since I got home at 7 today. I had dinner and played chess with my son but I was irritable and really not there. My mind kept wavering to what I have to say and how it will be interpreted at 10. I have also been up since 5AM this morning helping the wife with kids and breakfast since my daughter had to leave early for school today.
This is the part I hate about working at a US based multinational software company. You can’t really be at home even when you are at home… especially if you care about the outcomes of these meetings. It is hard to have the mental discipline to be keep anxiety away and truly be at home when you are at home.
Additionally, I have an 8AM meeting as well where I need to refute/question the results from a user study. This is not ideal as you stretch on both sides of the day.
Today, I’m traveling to San Francisco for a 30 minute presentation to the Sr. VP and GM for my BU.
This is the first time in the last 3 years that he wants to pay attention to what we are doing. I’m hoping that it is a good thing 🙂
While I’m really well prepared, I am concerned if he want to review our work or he wants to tell us what to work on. I know what’s important to him and have enough data to show that what we are doing will help him meet his goals. But.. like most execs, he is working on a 3 year vision of where we need to go and aligning the organization behind this vision. So.. will what I show him resonate with him? I’ll find out soon enough.
This happens a lot in product management. As a product manager, you are thinking 2 years out.. while tradeshow demos show feature you worked on 6 months ago. These demos, while exciting to customers look stale to you already. You have seen early and fully developed designs for what you plan to build in the next 12 months already. This is further amplified at the executive level as they are solving much larger problem with much longer gestation cycles. So.. just like what’s presented in tradeshows for your product looks old to you, your latest thinking looks old to your exec. So.. focusing on making it relevant for him and the problems he or she is trying to solve is they key to a positive strategy review experience.