Building 0-1 Products

I think the two most common mistakes in building 0-to-1 products are: Not acknowledging or checking some assumptions about the problem your product is meant to solve Over-investing in the first itera

I might even abstract this out further to answer "What are the top mistakes product managers make when building a product period?" The best advice I've been given — and what I try to follow in my own

Hello from ex-founder who built startup and launched 3 products from scratch. Please meet my favorite personal mistakes with the biggest learnings. All coming from my startup Flawless App which we eve

1. Not validating the problem statement enough. Is this really a problem? 2. For a B2B product, I think its important to think through early on whether this is a problem they are willing to pay for. O

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 f

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 comm

I would say there is no substitute to real user data.   User research is table-stakes. But in my experience, not always representative of "actual" usage, so don't overindex on specifics. Rather valid

There are a lot of ways to gather feedback about a problem and build conviction around them, and all of them involve talking to your potential target customers. For this partnering with a designer/use

So, in my experience of building 0-to-1, I've never had to do this before exploring a potential new product 😅 and candidly, I really don't like doing it because any projections are in my experience ed

Start with a Total addressable market (TAM) * share of TAM you can get in next 3-5 years *confidence level *Revenue per user per year * 3-5 years. In the RICE framework, you would divide TAM * Share

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

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 looki

I don't think I have a great answer for this; I think there are a few possible points to consider though, and I think it ultimately comes down to how you understand the user/market problem your compan

Great question that goes beyond product strategy and into larger company strategy. Every product serves a given user job or jobs. When you have product market fit and things are going well, you then h

This can be tricky! It will depend on a triangulation across a number of factors including: 1. The room to grow in your existing product (both in terms of TAM, the competitive dynamics and your curre

I would consider the following factors: What are the goals at that time? How best are the goals served? e.g need a product-2 to monetize and sustain product-1, which is growing but no line of sight t

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 compan

This is hard! For me, it's a mix of having a good understanding and confidence that you have  (1) a clear hypothesis that you can test with a minimally viable product that is shaped by data and custom

Before investing in engineering resources you want to build conviction around the following: 1. Is there a market need? Are you fulfilling a true gap in the market? 2. Do you have a differentiated vi

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 produc

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 co

I think the quote has validity in some contexts and less in others. If you are building a 0-to-1 product in a company where the culture is anxious about, say, the brand impression your "embarrassing M

So much about product management is about stakeholder management — getting everyone from engineers to exec team aligned on 1) what you are building and 2) what the goal is. With goals, we're very good

Great question! My response to "At what point is a solution ready to be shipped?" applies here.  The aspect of launching a true MVP is harder in a large organization, when the expectations from the c

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 po

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

"0-1 product development" is the idea of building something from nothing. That is, you have an abstract customer or business problem you need to solve and no solution for it (0) and, as a PM, you need

Part of the fun of building something 0-1 is that you have a green field in front of you — you can build anything! (Or that's what we wish as PMS....) As much fun as it would be to the world is your

Start by forming assumptions and making hypotheses around the desirability, feasibility, and viability of your new product. Then validate those assumptions, learn and iterate. Desirability assumptio

0 -1 product development refers to building a new product or service line from scratch (0) to bringing its first iteration into the hands of customers and users (1) The first step to develop a 0-1 pr

I will share first two steps that I follow. Step 1: Is this problem worth solving? 1.1 Problem definition and user segmentation B2B product: A business customer must have a genuine painpoint that t

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 t

I have a very simple framework for building 0-1 product - IVC framework Identify: The first step in developing any product or feature is to identify the user's needs. Hence, your goal should be to

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

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 produ

One way I like to prioritize problems is based on the level of risk these will pose to the final solution. Which are the riskiest assumptions or riskiest bets that will affect the success of your prod

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 i

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

I recommend thinking about these questions: 1) Is this worth solving? What is the problem statement? Who are the users? Is this a real problem? What is the TAM? What can we influence?  What is the de

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 exam

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,