If you know that customers are not willing to adopt your solution, that's a bad spot to be in. 1. Re-evaluate what led you to the decision to build & when to do it. Was there a gap in your methodology, or a piece of research that led you down this path? How can you avoid this for the next piece of strategy planning? 2. Don't hope for better adoption -- test and prove this out. Can you get a high quality signal that customers will adopt, e.g. customers will pay you now for access to it? 3. Is there a wider org that will bear the cost of holding this solution, and values it for reasons other than direct revenue?

There are many potential signals – just one of these is enough! * You're starting to hear the same problems repeated in a lot of your research * You don't have a clear view of feasibility of the solutions you're thinking of (you need to start prototyping) * You have a potential customer willing to pay for the solution you've shared with them Bear in mind that bringing eng resources to the project isn't a binary, and you should be partnering with an eng lead from the start of your discovery so they can pressure test your ideas and explore potential architecture/approaches in parallel. You'll need to prototype and validate before an entire squad starts building, of course. Think carefully about how much engineering resource you need - always start as small as possible, as larger teams have more operational overhead.

This one is fairly easy, add value. We as Product Managers need to ensure that we are adding value for our organization by understanding the market (and our customers) and guiding the strategy to be successful in that market. It's easy to be a product expert, but we need to focus on being market and strategy experts. In my career, some key examples of adding value are: 1. Knowing My Market Better Than Anybody Else. When I am the expert on what our market needs, both short and long-term, I add significant value in defining and driving our strategy. My product can't be successful without this. When we are proven right in terms of our strategy definition and market validation, we win. 2. Build and Foster Relationships I work hard at establishing relationships around the organization where I am working. These enable me to be effective in cross-team collaborations and makes driving alignment across the organization easier. My relationships add value to me and my team. 3. Be an Expert When you are viewed as an expert and continually show your expertise in an area that is needed within the organization, it's easy to be seen as somebody who deserves that promotion. Show that your expertise drives direct value for your organization with clear successes.

'What is a project that you are proud of accomplishing'. I like asking this as one of the first few questions. The reason I like this question is for a few reasons: * When people think of their proudest accomplishment, they typically tend to share more, get into the details organically * By using this question as a jumping off point, you can go deeper into a number of areas like problem-solving, strategic thinking, communication, ability to influence and more * Some examples include how do they proactively think through the different scenarios and plan accordingly, how does the candidate react when there is misalignment, how do they influence other team members, how do they communicate to exec stakeholders, when their assumption does not turn out to be true, how do they work with other team members to accomplish their goal and so on. With this format, I have had the best conversations including when a candidate talked about a difficult situation and how they persevered through the journey and as a result, how they have determined the team culture and environment that they can do their best work and drive business results.

A great product manager starts not by convincing people of value, but by listening and exploring problems faced by their customers and team members. So, start with understanding what challenges your partners are facing - they can range from engineering-specific issues to business performance. Pick a few of these problems that seem approachable and explore them deeply, partnering closely with the people on the team responsible for them. Then deliver an improvement. It does not have to be a complete solution - but a measurable improvement that you were able to design and implement with your partners. Getting points on the board together and celebrating a shared win is the best way I see product managers that are new on the team quickly establish their value and build reputation as a strong team member.

The following stand out to me for what I've witnessed: * The team is acting like the product they're creating is going to be successful. I'm amazed at how many successful companies try to build new products like they do for their existing successful ones: same processes, same success metrics, etc. They don't have the urgency, move too slowly, learn too little, are complacent. The market is a graveyard of failed products and businesses: the most likely outcome, when creating a product, is that it will fail. As a result we shouldn't assume success but instead focus on doing everything we can to de-risk, test and validate - and make sure we don't over-invest too early. I recently was interviewed in Lenny's podcast to talk about that: if you're working on 0-to-1 in a bigger company I think it's worth your time. * The team built a solution to their own problem and they assumed that many more people would face it in the same way. We hear a lot of success stories that started like that, and while it's true that some successes began like this, it's also where a lot of failures came from. You're not the customer of your product: work with real customers! Or it's only going to work for a small population, and that may not make it a viable business. Mehdi, the founder of Cycle, shared openly a great example of this for how they changed their approach to user onboarding. * The product manager tries to get a big team from day 1. Honestly a small team can move 10x faster than a big one. You need a team of people you can trust who can move mountains on their own and continents together. For the first year of creating Jira Product Discovery we only had 5 engineers, and we moved really fast. It forced us to focus on the most important things, to be nimble and creative when testing solutions, and we could do this with very few meetings (it's very easy to get everyone on the same page at that scale). Once you've proven you have a solution that solves real problems for a small number of users - you can then go back and ask for a (slightly) bigger team. Resist that urge to grow too fast! * The team is fighting too many battles at once. This happened to us at Atlassian when we tried to rebuild Hipchat into another product called Stride. We were trying to launch a new product built on top of a new platform that could be used for all other Atlassian products. We faced this tension product<>platform from day 1, and it was much slower to move on the product front. Like with any failure there's of course more than one reason this product didn't pan out, but this is definitely one of them. * The PM fails to get the right level of buy-in internally - if it's about creating a product inside a bigger company. It's very important to "build chips" in the company (gain trust from leadership) so you can spend them, gain more chips, etc. And it's key to communicate your learnings and progress in a way thatmake your team look like a high speed train - no one wants to get in front of a high speed train. This is one of the topic I cover in an interview on Lenny's podcast.

While project management and product management require similar soft skills (communication, negotiation, structured approach etc.) there are some fundamental differences. For instance, project managers need to be risk averse because their job is to make sure projects are delivered as promised. Whereas, product managers must have a higher risk appetite as their job is to maximize outcome for the business and must explore unconventional paths get to the outcome. So it's important to recognize that these are fundamentally different jobs and approach product management career with a sense of curiosity. Other than, the approach to getting into product management is the same for people transitioning from any other craft. The easiest way is to find product management opportunities within your current team / organization, rather than job hunting in the open market, because they already know you and your work.

* PM interviewing tools like tryexponent, Igotanoffer, product alliance, etc have a good breadth of various PM interviews, especially for popular companies like Meta who have focus rounds for Product Design, Product Sense, etc. * Mock Interviews: Similar to above, there are various services that offer both paid and unpaid mock interviews, usually done in a real-life interview setting with time dedicated towards the end for feedback. You can also rope in friends and your PM network to help with conducting these mocks * Building a story bank: Usually a number of PM interviews start with a specific question that leans on an example from your career. I recommend creating a story bank from your experience that addresses some of the most common cases. * What was a product/feature you are most proud of? * Tell me about a time when you worked on a project with a cross-functional partner (engineer or designer are the most common ones). What were some of the challenges in collaboration? How did you overcome them? * What is a hardware/non-tech product that you like? Why? How will you improve it? How will you monetize it? * Tell me a time when you relied on your intuition vs data? Why?

Many data-driven Product Management (PM) teams often overlook long-term strategic KPIs, such as Customer Lifetime Value (CLV), by focusing on short-term metrics like quarterly margins or one-off transactions. This approach can be detrimental, as retaining customers typically yields higher CLV and reduces churn-related costs. Another critical KPI often missed is Feature Discoverability and Time to Value. Despite having sophisticated features, users rarely utilize them due to: Difficulty Finding Features: Users struggle to locate necessary features. Longer Time to Realize Value: Understanding and realizing the benefits of these features often takes longer than competing alternatives. By prioritizing these long-term strategic KPIs, product teams can enhance adoption rates, accelerate customer value realization, and ultimately drive sustainable growth and customer loyalty.

The hardest part in this scenario is to accurately capture the moment when you tap out of your own capacity and need to bring on someone else. One potential framework for this: keep a list of things (as in, capabilities to explore/build) you would want to start today if you had bandwidth; the moment this list has five items on it is the time to hire another PM. Make sure you're honest with yourself and only list things that you 100% believe in and that are truly major, not small improvements. Then, repeat this process for every net new five items on the list until you hire 3 PMs under you. When you are looking for those early PMs, take note of their ability to scale as team leads during the interview process. Do not hire someone brilliant if you think they would not scale to lead a team within 12 months. This generally implies you want to opt for somewhat senior PMs; however, keep your eyes open for folks that are hungry and capable and can hyper-scale quickly.