Leo Sadeq

There are a few things I can use here to get things less surprising and more efficient. First off, you need to streamline decision-making. The RACI matrix is useful here so you can identify who's calling the shots for each project area and empower them to make quick decisions. Next, overhaul your communication by having daily standups for the core team, bi-weekly updates for key stakeholders, and monthly executive briefings. You can use tools like Slack and Asana to keep everyone in the loop without constant meetings. Id consider the possibility of running the project into sprints and have teams work in parallel. Two-week cycles work well. This helps to make rapid decisions, everyone is invloved, and changes are not drastic if any. Create a doc or something that acts like the single source of truth for everyone to reference to whenever they run into issues. This is good to cut time on time to issue solution. And perhaps the most key point here - Use rapid prototyping and demos instead of long discussions. Show, don't tell. It's faster and more effective.

From my experience, you should never invest in another product unless your first product has achieved PM-fit because you dont want to kill the momentum and growth youre already seeing by splitting your customer's attention in two different directions (unless your new product is serving another ICP and totally different GTM). Otherwise, Id introduce another product if: 1. Your current product’s growth is plateauing and you dont have any more innovative ideas to add to the product. 2. Pay attention to what your customers are saying. Are they showing signs that there is a demand for a specific feature (maybe you can make it as a standalone product or reflect it in the first one). Anything youre missing solving? These signals can be helpful to consider. 3. Be honest about 4 main things here because they form the backbone of this new product (do you have enough resources? team that is ready for this? are you sure its adding up to your product vision or market share? are you able to get buy-in by proving the impact this new product will have on business OKRs? Id focus on these key areas first to make sure nothing is lost in the cracks.

Before going in, we have to know who owns what. This is how Id go about it: Generally, a PM owns the what and why. Marketers own the when and how. Product should own the GTM strategy, not marketing, even though a PM with a marketing background can. The reasoning is simple: the product team knows the user better than anyone else. A lot of traditional thinking places this burden on marketing, but high-performing companies are moving away from this siloed approach by mixing product and growth (sometimes revenue) together. And thats why the PM is increasingly seen as the "CEO of the product" . i.e. knows how to develop and supervise the product cycle but also how to deliver it to market. If the PM drives the GTM, the product gets built in alignment with market needs from the very beginning to remove unnecessary revisions and misaligned messaging at launch. Marketing should be the executor, not the strategist. This doesn’t mean marketing is a support function, but it plays the role of amplification rather than direction-setting. Normally, the product teams get involve the AAARR metrics. But I think marketing can also play a role in the acquisition process and retention. The reality is: the first 30 days of using a product are critical. What happens if the messaging isn’t consistent post-purchase? Marketing plays a pivotal role in customer communication after launch. Hope that helps

The first step isn't building, it's figuring out the problem you're solving. Too many founders jump into development without validating the core issue. Id start with customer discovery: talk to potential users, understand their pain points, and map out the unmet needs in the market. What matters is that youre solving for real users and not chasing tech trends. If you don’t have a crystal-clear understanding of the problem, your product will end up as a solution in search of a problem. Build fast, but only after you've validated the pain points. Once you're confident in the problem, you can define your MVP based on those insights. Then the heavy things will come later like user mapping, roadmap, etc.

I like this quote but it's a hell of a lot easier said than done when dealing with corporate bureaucracy. Id really focus on going hardcore on this: 1. Find allies who get it - product leads, engineers, designers who are hungry to move fast. You need a core team that's ready to break some eggs. 2. Create an MVP as a limited test to gather data but label it as a controlled test. it's harder for risk-averse execs to shoot down a "learning opportunity." This WILL be rough around the edges so have stakeholders to explicitly sign off on an imperfect v1 if that makes sense. 3. The once its ready, ship fast, gather real user data, and let the numbers speak for themselves. 4. During this process, I believe a rapid feedback loop post-launch is key. Remember, this is a rough test. So youll have some stuff out of sync. So this feedback will help control anxiety 5. Bonus - Win over legal/compliance early. These teams can be major roadblocks. Bring them in as collaborators, not gatekeepers when you see fit. The thing about big companies is that they move slow and minimize risk. Your job is to flip that script. Not easy, but it can be done :)

I think the answer here varies depending on what level of the PM ladder youre in. But, if I were to list down the key pillars, Id say: 1. communication skills - A PM must articulate vision, strategy, and rationale in a compelling way to inspire and align teams so that everyone is aware of what theyre doing with no issues. 2. Prioritization 2.0 - Let me explain. The traditional approach to prioritization often revolves around short-term gains or stakeholder pressures. A forward-thinking PM should prioritize with a long-term vision, balancing immediate needs with future growth and innovation. Sometimes, this means making unpopular decisions that may not show immediate results but are crucial for the product’s future (youre a visionary!) 3. Strategic - Some might argue that PMs should focus on execution, but without strategic vision, execution can become directionless. It’s not enough to manage what’s in front of you; you need to lead your product into the future. If you have no vision or strategy, then youre a project manager, not a PM. 4. A bit of technical knowledge wont hurt - Not all PM should be coders because we have other stuff to work on. But to avoid product delays and clashes with the dev/eng teams, knowing the basics is beneficial (I took a JS on Udemy and Im glad I did for many reasons). Adjacent to this note is to involve data in your decision-making so you know what to do vs avoid. 5. Adaptable - Im pulling the trigger on myself here but we tend to think about the end goals more often. A good skill is to learn when to adjust and accept the new changes that may come up.

In a sales-driven org, an alignment with the product vision is the most crucial. Listening to what the sales team is dealing with, complaining about, wish to have, etc is key here. You can aim to remedy most of that and be open to sensing the changes on the ground and make pivots when needed without harming the product vision. You must also address why what you suggest is ideal for them and can ultimately boost revenue, sales satisfaction and user's. One common issue here that comes often is the one-off sale the sales team has brought. Push back against feature requests that serve only one-off deals and steer focus towards features that benefit a broader set of customers. Explain how prioritizing long-term features will help sales win multiple deals instead of just one. The more involved sales leadership feels in the process, the more autonomy they will grant you.

If I were to narrow it down even though its not necessary to learn much technicality, Id focus on: 1. data analytics and interpretation - because good PMs mix qualitative with quantitative data to decide what features to have, things to drop, etc Most analytics platforms like Mixpanel and Amplitude offer courses and resources on how to use their products can be a good starting point. For the interview here, just share examples where data directly influenced product decisions. Mention specific tools used, metrics tracked, and how the insights you had led to a successful or failed product outcome. 2. Understand what the engineering team is talking about and how they communicate. Its a good idea to learn more about the concepts or lingo they use. 3. Great to know software dev methodologies like Agile and Scrum. For the interview, mention that you had planned sprints with others and backlog prioritization using JIRA. How that came to life and what resulted can be a good point to showcase your affluence in the area. I dont think its a must to learn in-depth technical skills as opposed to knowing how to strategize, roadmap, communicate, and other key metrics of a PM.

For me, two main KPIs that should be the center of attention, time to value and product activation rate. It's shocking how many product teams obsess over metrics like churn, retention, or NPS while completely overlooking how long it takes for users to experience the core value of the product. TTV mainly directly correlates with customer satisfaction and long-term loyalty. If your users don’t quickly experience value, they’re more likely to leave, no matter how great your onboarding is or how strong your features are. I’ve seen companies invest heavily in sales and marketing, only to see user frustration boil over when it takes weeks to hit that "aha" moment. So to have a high TTV, optimize onboarding, remove unnecessary friction, and give users a clear path to the value your product provides. Have a clear user mapping/journey plan that reflects and shortens the path to the value of your product.

I might contradict some of the PMs out there when I say this but here we go and Ill prove it: 1. The numbers of released features I think this is a bad one to track because it encourages quantity over quality whereby PMs would ship features that add little or no real value to users. 2. DAU with no context DAUs can be misleading if they aren't tied to meaningful engagement or conversion. A product might see a spike in users from a promotional campaign, but if those users don't convert or stick around, what’s the point? It's better to focus on metrics that reflect the AARRR for the most part. 3. Time spent on app Youre probably saying (dude, really?!, yes! really) This often sounds good in theory but can be disastrous if your product is designed to simplify or streamline a task. Optimizing for more time in-app contradicts user value in many cases. For example, think of tools like Slack or Trello, users want efficiency, not prolonged interaction. I hope that delivers the point. 4. reducing churn without knowing the 'why'. Many focus on reducing it (as they should) but without analyzing user behavior or feedback. For example, you might be able to reduce churn temporarily through heavy discounts or aggressive tactics, etc, but without solving core product issues, you're just delaying the inevitable. 5. Meeting deadlines. Let me explain. Hitting a timeline sounds great but at what cost? Forcing releases to meet arbitrary deadlines often leads to cutting corners in my opinion since it may affect product quality or usability. In a nutshell, getting the right product out is far crucial than getting the product out fast. Hope that helps :)