AMA: Former Observable Head of Product, VP, Deepti Srivastava on Building 0-1 Products

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. 

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.

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.)

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.

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.

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 my experience working even pre-pandemic with hybrid, remote and globally distributed teams, the most important things for product development teams are: * clear and open communication channels * written objectives, priorities, and any decisions for all stakeholders so all parties are clear on overall product direction, priorities, tasks and metrics to optimize for. If everyone involved is on the same page, product delivery can be smooth regardless of remote work.

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.

First, while I understand the sentiment, I never want to be embarresed by any version of the product my teams launch. I prefer to subscribe to the saying "perfect is the enemy of good enough". The point really is, you need to get early versions of your product that are usable in the hands of users quickly, so you can get real world user feedback in order to know what needs to be fixed/enhanced/perfected to gain user adoption and growth. If you spend too long iterating internally on the product or feature without real user feedback, chances are high that you and your team are wasting time iterating on the wrong things from your buyer's and user's perspective, which is dangerous when bringing new products to market. However, as a PM, it is important for you to understand the incentives of the company/business within which you are running your product. For large companies, the main focus is on reducing business and user risk, so the idea of releasing products that may not meet the highest QA standards is met with resistance, as expected. In that case, I recommend using version labels such as "EAP", "Alpha", "Beta", "GA" etc. to set expectations both internally and externally that this is an early verion of the product, *and* that the product will be refined based on user feedback. I've found success with this approach when launching early versions of products and features in larger companies.