Which do you like first, the good news or the bad news?
I like good news first. It will elate my mood so I will be able to take bad news better. If I get bad news first that I might miss the gravity of the good news.
Have you been in a situation where the team has let you down and you've to take the blame?
Yes it has recently happened. I provided reqs to engineering about a product feature. They were supposed to send out data of certain time period. Instead they sent out data for a longer period. We realized it when we received our invoices and they were higher than usual. Now there is no point blaming them but to own it up. I did bring it up with the engineering team and requested them to stick to the requirements.
As a fallback mechanism, I added a QA process for all the outgoing data. I had a rough estimate of numbers that can be sent out for all new requests. So for every new request, I asked them to provide me with the total size. If it matched or was within a specific range, we went ahead with sending out the data. This happened for only new requests so we didn't had to worry about them providing me with updates all the time since subsequent similar requests were automated.
How has your tolerance for mistakes changed over the years?
It has increased a lot. I have realized that people will make mistakes all the times and most of the times, they are genuine. There is no point getting upset over honest and genuine mistakes. And some people does mistakes because they don't know any better. For ex: Kids are just being kids, no point getting upset/angry at them when they are being themselves. New hires might deploy a bug in the production, it will not be productive if we start doubting them. So bottomline is: Mistakes will happen, we just need to learn from them and move on. However I am careful when someone conducts same mistakes over and over again. Now that is being careless and would hurt a business in a professional setting. Such behavior should be addressed in timely manner before the person becomes habitual of mistakes.
What have you learned about saying no?
It is a very important skill to have. And you can't say no to all the audiences. But to whosoever I am saying it to, I make sure that I say it nicely and precisely.
- Recently I got a project request from Engineering. They wanted to prioritize an infrastructure project over a revenue generating one. Now infrastructure is important but not over revenue. I requested information on how they were planning to impact the revenue via it and they didn't come up with solid backing. The project would have added stars to the engineering manager's profile but wouldn't have generated any revenue for the company. Based on preliminary analysis, I politely said no and suggested them to get a budget approval from their Execs to move forward. But Product was not ready to buy the idea at the moment. I suggested to talk to my manager and exec level if they thought so strongly about it. They didn't so we didn't moved ahead with the project.
- We get a lot of feature requests that are one time use. Now we want our users to be honest to us but we can't tell them no on the face directly. We ask them for ROI on these features and its apparent that those features are not going to be extensively used for a lot of projects. One project that might not see the light of the day requires such features but we can't commit all our resources to build something that is not showing a lot of promise.
- And in product management you'll have to say no a lot then yes. If you say yes to everything then you will busy executing someone's vision and not your vision of the product. Trying to understand the impact or ROI is best way to weed out must haves from good to have features.
Do you manage people from different functions differently? If so, how?
Yes I do. Exec level is way different from Customer/user and that is different from Engineering or Legal or Procurement or Finance.
- Exec level wants to know more about strategy and Product vision. They care about numbers with focused plan, about business goals, product goals, KPIs.
- Engineering cares about how well the Product fits in the vision. If it is high visibility product or a supporting product. What technology to use? What technology is used by integrating partners? How to integrate well to improve the performance? Are the requirements clear enough to build a solid foundation? Is there scope of automation?
- Legal cares about fine print on the contracts. They want to make sure that business is executed as expected and we are conducting it by adhering to all the rules.
- Finance cares about if our product is generating the revenue. How can we decrease cost without affecting performance or any business goals?
- Procurement worries about getting the contracts signed to continue the business or initiate a new business quickly. They try to lock down a great deal at a good rate for few years. This way we are not reinventing the wheel all the time and are making sure that the deal is in place so that different functions can focus on achieving the business goals.
- Customers/users want to learn about a new feature. Want to know when a specific feature will be available. Will communicate with them to provide hope that their feature is on its way or politely turn them down telling them we are focussing on something else that requires our attention.
What would somebody do to lose your confidence?
Lie to me multiple times and double standards. If I catch someone constantly lying about something then that's it for me. If you lie one time its ok. There might be some reason why you did it. May be you were trying not to hurt me. But lying every time a tough situation comes up or when you are confronted tell me that the person shouldn't be trusted.
Second, if you say one thing in private but something else in public then bye bye.
How do you get a team to commit to a schedule?
- Explain them the bigger picture and product/business goals.
- Make them feel that their contribution is making a difference to motivate them.
- Create a roadmap and associate key tasks/stories to different items on the roadmap.
- Define key metrics/KPIs and associate them to the tasks/stories and map.
- Setup a meeting to go over above steps and define the project plan.
- Email out the plan with people held accountable to different tasks/stories.
- Check periodically to monitor progress.
- Ensure you are available to help prioritize if competing projects are showing up regularly.
- Ensure to send updates when tasks are completed or are falling behind schedule
- Send out emails to key stakeholders once project is completed.
- Celebrate the success!
- Document the learnings and measure the metrics and KPIs.
- Refine metrics if need be.
- Iterate.
Tell me about a time when a team didn't gel. Why do you think that happened, and what have you learned?
What types of people have you found it difficult to work with?
People who never get along with anyone. Anything is a huge task for them. They are just trying to finish off something so quickly and don't want to think through things. Since they are in such a hurry that they resent any new task that is added to their plate.
What kinds of people do you like to work with?
- People who like to own the responsibility and don't mind few challenges here and there. A daily challenge might be an issue for many.
- Those who like learning and are open to teach any acquired skills.
- Those who are able to focus on bigger picture while executing day to day activities.
What's the difference between management and leadership?
| Management | Leadership |
| Focuses on just day to day. | Involves the team on strategy
and help with the bigger picture understanding |
| short term thinking | Long term thinking |
| Focuses on onself | Focuses on the team |
| Not aware of employees goals and long term plans | Is aware |
| Build processes and systems | Build relationships |
| Direct | Coach |
How do you earn the respect of the engineering team as a product manager or someone outside that team?
- I usually provide them goals of the projects and how they will impact the revenue.
- If its an urgent ask, I try to get hold of someone in Sales or Planning team to understand how much revenue it is going to bring. If I know it, I communicate it to the team.
- If we are running an experiment then I am upfront with them by telling them this is just an experiment that might not result in a full blown project. So I tell them to do it in a quick and dirty way. Don't need to think about it and doesn't need to build a solution out of it.
- Since I have technical background, I try to communicate in the same language and they are usually comfortable explaining things further.
- I am usually polite most of the times. It helps. If I put someone on their plate I make sure other low priority items are moved out.
- While writing specifications, I write them out as detailed as possible.
- While they are releasing something, I help them out with the plan and am available if they identify a bug and need approval to roll back new features.
