Building 0-1 Products

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

"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

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

It's never going to be "as ready" as you want it to be. Because we don't work in a vacuum, the product is never built to 100% (I've never worked on anything where we had P2 requirements built into the

It depends on the lifecycle of the product and goals.  0>1 product: Goal - to find product-market fit. Here its very important to think through your hypotheses, possible outcomes (Prove, Disprove,

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

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

Not at all - it just changes how I think about product delivery and the tools my teams and I use. In the office, it was common to rally a bunch of teammates together in a "war room"-like setting, head

After 2.5 years into working remotely, the two areas that have been the most challenging for me are 1) cross functional exploration and ideation and 2) user research outside of video interviews.  Fir

Working remotely has impacted each individual and their team differently. For some it has boosted productivity and flexibility. For others, it has impacted morale and connection to the mission. I enco

In my experience, real human interactions help in building relationships and trust. There may be other effective ways of achieving this too. Once you establish those, working remotely does not adverse

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 writt

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

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

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

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