Deepti Srivastava

For a new product in a new market, I don’t think you can ever validate the problem space enough. Once you have reasonable confidence that the users (and buyers) exist for the problem space your product tackles, and there are viable ways to create a business out of that solution, the best next step is to involve engineering to build a prototype of the solution. Then you can test that prototype with a representative sample of the expected user base to get early feedback and iterate on building out the product and grow the business. For 0-1 products, involving engineering early as a partner to the overall product definition and development process is best, so you can iterate together on building the right product for the right audience.

At a high level, a 0 --1 product offers a completely new solution or functionality to a user problem, often creating a new market category or sub-category within an existing large market. The top thing in developing a 0--1 product is validating that there is a real user need in the market that will be served/solved by this new product, and, that the need is big enough to build a viable business around it. * Identifying/defining the top user persona for the product – their motivations, goals, tooling needs, and pain points with existing solutions, if any * Defining the buyer persona (if different from the user) – motivations, incentives, goals for themselves and their teams, and pain points with existing solutions, if any * Understanding the market – what existing market segment or category would the new product fit in, the competitors, incumbents, market sizing and basic TAM (total addressable market) analysis to validate there is a big enough market (or potential market) to build a business * If creating a new market category with the product, it is still important to understand what is the closest market segment to the new category you want to create. It helps gauge the TAM for business development purposes as well as the closest competitors to the new product.

When setting up any new line of business, revenue projection is an important step to understand the expected outcomes and viability of the business. For new a new product, you should have: * The basic market analysis including market sizing and TAM (total addressable market) * Competitor growth rates and revenue acquisition at comparable stages of growth * The market segment you are positioning the product in, and its current and projected growth rate * Revenue and monetization strategy for your new product, including pricing, expected paid user acquisition and retention rates (based on initial product/market testing) You can use these inputs to create an initial revenue projection model. You can do a best-guess estimate for rates where there is little data available. You can always tweak these models as data starts coming in post-launch. I recommend creating three projections – expected or target growth, above target growth, and below target. This will help you get a basic floor and ceiling or bounding box of your revenue in the first year.

Once you have a good picture of your target user persona(s), their goals, tooling needs, and pain points, design sprints are an effective way to brainstorm the user journeys and experience you want to provide with the product. Design sprints, if run well, can be a structured, efficient, and a fun and inclusive way to get different team members to collaborate on the potential solutions. It's a good way to get input from designers, engineers, PMs as well as sales/customer success teams where appropriate. It can be done in two phases: * Brainstorming solutions * Prioritizing the solutions (based on predetermined criteria) There are a number of books and articles out there on how to run an effective design sprint. Or ask your design leads for help. 

There are multiple definitions out there for "mature products", but it ultimately depends on the product and business leaders in a company to define that as they know their products and services the best. Generally speaking though, we'd consider products to be mature when they meet the following criteria: * broad adoption in market (adopted by most/all applicable verticals and industries) * feature set is broad, and there is narrow differentiation from competition in the market based on features * a new feature or update will not unlock a new vertical or a significant portion of the market * growth becomes incremental (and feature requests also become incremental rather than fundamental)

Any prioritization exercise needs to start with first having clarity yourself as the Product Manager on the top business goals and related product priorities, and then to communicate those clearly to your teams so everyone is on the same page on features and growth initiatives and their relative priorities. Also, having a clear framework for managing competing efforts so it doesn't compromise on existing product quality, delivery timelines for new projects, and eng team focus and velocity is extremely important. In addition, when managing different competing initiatives like features for mature products and separate growth projects, I advocate for separating the two initiatives into separate sub teams. This makes the roles and responsibilities very clear to all parties and avoids confusion and thrashing within the team. It also avoids burdening a team to do multiple things, which leads to loss of focus and lack of clarity on delivery schedules and timelines.

Usually, there is a pre-determined prioritization framework that your product org should use to prioritize which problems to work on. There are multiple inputs with different weightage that are used in the prioritization framework, depending on the phase of the product, business and company. The most common inputs are: * business and strategic product priorities * degree of user friction (eg: adoption blocker vs nice to have) * market and sales priorities (eg: is delivery of a feature important to win against a competitor in this cycle) * internal priorities (eg: technical debt removal, infrastructure upgrades etc.)

For early stage products, a feature or solution is usually ready to ship when it meets the functionality for the main user journey(s) i.e. "golden paths" defined in your PRD or user journey maps, and passes the predefined usability bar from a QA perspective – user can complete the common tasks within expected reliability and performance metrics, all expectation cases may not have been hardened yet. In basic terms, a user should be able to use the solution to complete the predefined task in a reasonable manner, and be able to provide feedback that can be used to enhance the product. For example, if the product keeps crashing in the middle of the user task journey, then that leads to a bad user experience such that the user can’t really provide effective functionality feedback for you to evolve the product, and they may never adopt the product at all. 

Not focussing on the user. I tend to be pretty heavily user-focussed when building products. I believe strongly that without users, you may have cool technology, but you don’t have a product. The first step towards building a 0-1 product is understanding who you are building it for, why is that the right target audience for your product, and how will this product make their lives better. If you don’t have clear answers to those questions, you’re not building a product.

In general, the main thing I look for when validating any problem or solution is data. As a PM, it is important for you to figure out where to get the right data for what you are validating. For example, if it's a problem statement around a user need or pain point, the first step would be to run user research panels to get data directly from users or potential users. I recommend you augment that with market research data such as independent analyst reports, research reports published by competitors of their user base, and related user data available to you such as broad user surveys.