Recently, I had the awesome opportunity to do an AMA with Product School’s Slack community. For those of you who aren’t familiar, Product School provides product management training to professionals across the world. With 16 campuses worldwide, the school offers specialized Product Management, Coding, and Data Analytics classes, taught by real-world product managers who work at top technology companies such as Google, Facebook, Snapchat, Airbnb, LinkedIn, and Netflix.
Their Slack community is an open network where you can join thousands of other current, and budding, product managers to talk about all things related to building software products. At the AMA event, I talked about my transition from engineering to product management, the challenges that arose, and what skills are needed to bring great products to market.
Originally published on the Product School Blog.
What led you to product management? What was the main factor?
Great question to start off with. I was an Android developer at SignEasy first – and I was fortunate to be exposed to an environment where we are OBSESSED with the customer and solving their problems. That really influenced me and I realized that for me, being a PM was a natural extension to being an engineer – I loved solving problems and figuring out solutions. So it felt like the best next move.
As a PM, are you the person who makes decisions regarding the “how?”
I’m usually not the one deciding that, but having a solid knowledge of the tech stack and what’s possible-not possible through our infrastructure truly helps, especially during the spec’ing stage of a process. I’m also typically involved if the engineers are debating on a certain solution, just to provide insight into how the roadmap might potentially unfold in the future – and if that can help them make their decision.
What would you say are the main challenges of being a PM? What’s the hardest part of your job?
I think one of the most challenging aspects is that being a PM is not a very defined job – if that makes sense. As an engineer, I would go in and execute my tasks and be done with my day. But as a PM, you sort of have to figure out what the right problem to solve is first and then figure out how to solve it, when to solve it and why to solve it now. It’s quite abstract in that sense and comes with a lot of decision-making around uncertainty. That is probably the most challenging bit.
Is there a different person that you work with for more technical problems?
It could probably differ from company to company. A technical product manager (TPM) usually helps out in those decisions – but that person is probably not very focused on the business side of the product then. At SignEasy, while the PMs are aware of these decisions, the decision maker is usually the tech lead of a particular product line.
What does a day as a Product Manager at SignEasy look like?
It’s usually a mix of multiple things – product management comes with a LOT of context switching and that’s something I’ve learned to be comfortable with over time. It involves project-related stuff – I find myself looking at 3 projects at any given time. This includes tracking the D1, D7 .. D30 numbers for any project that went out, keeping tabs on the progress of a project in development currently and working on spec’ing an upcoming project. We also spend a lot of time focusing on customers – be it looking at support tickets, looking at reviews, sending out surveys, taking calls with customers, or anything else that can give us more insights. That’s usually what the day entails.
How do you conduct market research to determine what features need to be prioritized in the roadmap?
I’d say a lot of factors contribute to the roadmap and the priorities of projects. A lot of times, you just know what some of the features that you need to include are because your users are asking for them! The problem statement is quite clear then and you just need to figure out what the right way to solve it is and if now is the right time. The most effective way then is to speak to these customers and figure out the right solution that would solve the problem today and also possibly scale in the future, if need be. Another way to go about this is by looking at industry or tech trends – in my case for example, if Apple is releasing iOS 12 in September, I know that this needs to be included in my quarter roadmap.
Which user-testing platforms have worked best for market research for you?
I’ve used usertesting.com quite extensively in the past, which is a great tool. It takes a few tries to get your script and test right, but it’s definitely worth the effort. I’ve also run Beta programs where I’ve literally shared a built-under development with existing paying users and asked them for feedback – this provides a lot of insight early on in the development cycle. And if you have a high fidelity mock ready, just showing users or random people prototypes and just watching them interact with the product is a quick, cheap way to get early feedback.
Can you tell us a little bit about your journey?
Well, I have a complete tech background – I did my Engineering Bachelor’s in computer science and then did my Master’s in that as well – focusing mainly on algorithms. I joined SignEasy as an Android developer and after 2 years of building the app, moved on to being a PM for the mobile products. It was a natural calling for me to be honest – I really enjoyed figuring out solutions to problems, and also identifying problems! Which led me to today – now I lead both the iOS and Android efforts at SignEasy.
What is your opinion on “customizing open-source tools” vs. “building product from scratch”?
I think there’s no one-size-fits-all solution. Sometimes, customizing an open-source tool or integrating with an existing solution might make most sense – these are usually more suitable if you don’t want a lot of control over the solution, or if building it from scratch is just too much of an effort. But a lot of times, the investment into building a product from scratch is your best bet, from a long-term impact and benefit perspective. It depends on the situation and it’s a decision based on the resources you have available, the quality of available solutions, the timeline you have in mind and the long-term business impact.
What’s the most critical part of your job and one activity that you have to nail?
Moving my North Star Metric – every business has this and it’s the one thing that keeps us up at night. If this isn’t moving up, pushing out tens of projects has no value. So a lot of my time goes into figuring out what the right problems are to solve that would impact this North Star metric the most – either immediately, or in the long run. I really need to nail this one.
Do you think being a developer is essential for this job?
I wouldn’t say it’s essential, but it helps. Having a developer background just makes it easy for me to have conversations with engineers in their language – especially when we’re trying to figure out a solution to a potential blocker. But I don’t think this is necessary – as long as you’re able to understand what the problem is – remember it’s not your job to provide technical solutions as a PM.
Do you find yourself getting your hands dirty to code or do you try to exercise restraint?
Haha I HAVE to exercise restraint, as much as I want to code! Honestly, the closer you are to the code, the harder it gets to take the 30,000-feet view which is so important to build a product. You should definitely be close to engineers and understand their constraints and issues, but getting into the code is probably not a good idea – it hinders your ability to step back and look at the main problem you’re trying to solve. I had to learn this over time, the hard way.
How do you balance the act of committing work to a sprint or promising outcomes with estimating stories?
The golden rule is to factor in the time for production support and factor in a buffer for each project. You shouldn’t typically pack in a quarter completely – leave some breathing room for these inevitable creeps. It’s usually helpful to do a quarter look-back over a few quarters and figure out what your velocity and release cadence is. For example, maybe your team is able to push out one large project, 4 medium projects and 5 small projects in a quarter. That’s something to measure and keep in mind, once established. That’ll help you plan your roadmap better.
How many of your mobile skills have transferred to being a PM? Do you still develop?
I don’t develop anymore, but knowing the tech stack so well definitely has its advantages. For example, a lot of times while spec’ing I already know what’s possible and what’s not with the current infrastructure, so it gives me a sense of how big of an engineering story this could potentially be. Plus, I can converse with engineers in their language and figure out solutions to potential blockers easily. I think my love for problem-solving is something that has carried over seamlessly. Earlier I did it through code, now I just do it one step earlier.
Do you think there is an issue with decision-making being top-down and the roadmap being shaped primarily by product? If so, what needs to happen in order for the company to be more democratic?
This is a great question and it’s something every team goes through. Typically, the roadmap should be defined by product – but it’s important to bring in key stakeholders early on in the decision-making process. When the roadmap is being defined, you are probably speaking to your sales, support, success teams to figure out what needs to be built. But it’s also crucial to ask your engineering leads if there’s any tech debt that needs to be factored in and your design leads if there is a similar design debt that needs to be considered – if that needs to be picked up is still product’s decision, but you need to hear them out. Plus, once you have a rough idea of the roadmap, bring in the teams early and communicate the ‘why’ behind each line item. Why was a particular project picked up and what’s the hypothesis behind it? It definitely can’t be a complete democracy, but it’s important to get their buy-in as they are going to be instrumental in the success of your project. Taking an extra week to communicate with your team early on in the quarter will save a lot more time as you go along because everybody will be on the same page from the word go.