Hiral Shah

There are several things that you can consider mistakes, but I do view them as learning opportunities. Every PM goes through some of these in their career (including myself). Here are some of the common mistakes I have seen PMs make: * Not talking to customers to validate the problem: A lot of times I see PMs jumping to solutions for a not well-defined problem. How will you know you have solved the problem when the problem definition itself is not correct? * Ignoring customer feedback: Worse than not talking to customers is talking to them to tick a box but not listening to their feedback. You become so fixated on the solution that you believe they know what's best for users. * Trying to build too much: Combination of creating a feature factory and going after shiny objects vs truly understanding the pain points and narrowing it to start small. In this scenario, PMs spend months or a year to build the right product and then when it gets launched no one uses it * Lastly not communicating enough: You should be able to articulate the value proposition of your product to anybody, your teammates, your customers, your cross-functional partners, investors, media, etc. This is why Amazon press release has taken popularity to force you to think through everything and communicate to inspire your team and others

I have a very simple framework for building 0-1 product - IVC framework 1. Identify: * The first step in developing any product or feature is to identify the user's needs. Hence, your goal should be to talk to as many users as you possibly can to understand what they say, do, think, and feel. This also helps you learn who you are solving for and who you are not solving for and create a problem statement 2. Validate * Building Conviction by testing Discovery, MVP, market analysis, possible conversion. During this time also you should be talking to customers to validate the problem and solution 3. Create: * Create the right team to build the product and also a plan on how you will bring the product to market.

Validating the problem is of course a critical step in building a great product. A couple of signals to look for * Do you have a clearly articulated problem statement you are trying to solve * Did you conduct robust user research to narrow down your problem statement to know what you would be solving? Users' desire to buy and use a product to solve the problem is the best signal you are looking for to keep marching forward * Business viability of the problem statement - This reflects the market you are playing in, and the business model you would consider. Have you estimated the cost of development and compared it to the potential return on investment? For B2B companies a great way to validate this is by getting Letters of Intents (LOIs). Its a nonbinding document saying the customer is willing to pay for it * Lastly, I would say you should have a proof of concept in Figma or some prototyping tool and put it in front of customers. This step is critical because you will truly know what works or doesn't work. You can also start small with 1 engineer and slowly grow the team. Hence, before you put a ton of resources, try to take above actions. Once you have conviction, start small might teams who will build and iterate

Prioritization is an art + science thing. The reason I say this is no matter what frameworks you use or apply, you will always be working with less than 100% data. Hence, your past experience is going to guide the recommendation on prioritization. That said here are a couple of dimensions to look at how to prioritize: * Company Goals: * Product Goals: * Define a criteria * Score the problems * Identify enough customer development partners * Constantly Re-evaluate

When thinking about Solutions, think they can come from anywhere - From you, from customers, from cross-functional peers, from industry, competitors, or from your everyday experiences with other products. Hence, it's important to keep you mind open and think of different things where you can get inspiration. When I was at Apple, I would actually monitor how kids used the iPhone (without any manuals) and that was the bar for everybody, how can you make it that simple that no one needs training. Coming to more of the process of brainstorming, we do a couple of things regularly * Regular brainstorming sessions: Holding quarterly brainstorming sessions with the immediate team. In the end allowing people to put the ideas in a 2x2 of effort vs impact. Then we allow people to vote so we have the buyin. * Design Sprints/Workshops: If you don't know what they are, I highly recommend reading the book Design Sprint by Jake Napp * Common tools: I love MIRO for this brainstorming. Once we have the list of idea, we figure out the MVPs to validate them and I called this validating the solution hypothesis. Make sure you are married to the problem and not the solution

There are a couple of different things you have to do and validate that can help demonstrate the revenue potential. * You have to do is TAM (Total Addressable Market) analysis. For this, you are looking for industry reports - how an industry has grown, how spending has grown, back of the envelope calculation in how big the market size is * From this, you get into the SAM (Serviceable Available Market), what portion of the TAM you will serve based on your product. You can extrapolate that if you already have a product and are expanding into adjacent verticals and the core problems you are trying to address * With this, you start with some basic assumptions and build a model of potential revenue you can realistically capture every year. As your product matures you will be able to capture more so there is a baked-in growth rate.

Phenomenal question, I recently gave a full talk on this topic. I think about going multi-product as a way to transform your company for the long run and to expand companies life cycle. Every company has a cycle of life - Companies are in startup mode, growth phase, and peak before start declining. Hence, best time to innovate is during the upward trajectory in the growth phase. Read more about it in this article: https://www.gsb.stanford.edu/insights/mark-leslie-key-enduring-growth-strategic-transformation

When you are thinking about problem statements, you need to first rephrase the problem as a hypothesis, then try to gather as much as data as possible quantitative (usage patterns, experiment results, etc) and qualitative (user research), analyze competitors trying to solve a similar problem, creating prototypes and lightweight experiments. The most critical and fun for me is customer research. This information can be gathered through surveys, interviews, focus groups, 1-1 discussions or observational studies. The insights you gather can help to validate or invalidate problem statements very quickly. 

Great question! I do agree with Reid's quote, that said I do think your first version should still be "valuable" so then you know whether it will really solve the problem. Regarding how to get buy-in from stakeholders in large companies, think about what they care about and frame what you are doing accordingly. Bring customer quotes and audio/video clips on why you are trying this out and propose this as an experiment you are trying to run. Start small so that you are not impacting every customer and once you have build conviction, go solve for more. Be creative about how you get those customers, sometimes it could be that you don't target the same customers but run it in a more controlled environment. Sometimes we get too worried about what our stakeholders will say and hence we never try it. I am a big believer in asking for forgiveness instead of permission. 

Getting user feedback is a very important element of building any AI feature. Without the user input, you cannot improve your AI, which means you cannot improve your product. Treat the AI feature similar to any product feature, you need to be nimble, agile and adaptable. There are a number of ways you can gather this feedback and depending on that you can incorporate it in many different ways * In feature feedback: Think about this as the thumbs up or down you do on your chatGPT or ask it to re-generate. This is one type of user input to feed back to the algorithms that the output produced was not satisfactory to the user. This is human in the loop * I have used this when I was building chatbots 7 years ago by providing 5 emojis at the end of generating a response to the question. The ones that are on lower satisfaction, we would go analyze each of the answers manually to see what went wrong. * Feature on/off: Lets say if you have an Opt-in / Opt-out feature, tracking the number of people option out can be a good way to know whether AI is working or not. * If customers are not signing up for the feature, there can be an awareness and onboarding problem. This can be fixed with some education material in the product as well as branding and messaging outside. * Qualitative feedback - This is sitting down with your customers and showing them the AI and gathering input. This method us true of any product feature, even more important in the AI feature