What are the top mistakes product managers make when building a 0 to 1 product?

I think the two most common mistakes in building 0-to-1 products are:

1. Not acknowledging or checking some assumptions about the problem your product is meant to solve
2. Over-investing in the first iteration of that product (the MVP) without having proven out the riskiest of your assumptions
3. Under-investing in product market research (specifically the other products in the problem space and their strengths/weaknesses)

I see a lot of PMs attempt to build things that are bigger and more complicated than the most core thing they need to build to prove out whether a solution to the problem at hand is viable. This often manifests as other features that you may think are necessary, when in reality they are useful asides that don't actually get to the heart of what you are trying to prove out. The other side of this is knowing what makes YOUR solution unique in its ability to meet an otherwise unmet need. We see a lot of new products launch (eg. on Product Hunt) that look like a clone of something else - in some cases, that's definitely true, but in others, the creator has found a particular niche that makes the product useful in a way that other similar products are not. Not thinking about this creates risk that your brand-new product is easily dismissed as a clone of something else.

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 work — is to be obsessed with the problem and not the solution. It can be really easy to think you know what the answer is based on what a user tells you in research, what a PMM counterpart reports back or what sales is saying the customer wants. Solutions are sexy and it's fun to build! And yet, being obsessed with the solution is less important than making sure you're 100% sure what the problem is. 

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. Often times, this is an after thought and expensive to pivot.

3. Giving up too soon. Its easier said than done to validate the problem statement. Sometimes this take iterations where you get live feedback from real users. So you might be dancing around the problem space for a bit and that's okay. 

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.

Building a 0 to 1 product is challenging even for experienced product managers. Here are a few things that can make it challenging to successfully build a 0 to 1 product.

• Ignoring market research: It's important to conduct market research to understand the needs and preferences of your target audience. Ignoring this research can lead to building a product that doesn't meet the needs of your target audience.

• Focusing on features, and not customer problems: Product managers can get caught up in building the product capabilities and forget to focus on the needs of the customer. It's important to stay focused on the customer problems throughout the development process.

• Overcomplicating the product: In an effort to build a product that is differentiated and innovative, product managers can make the mistake of adding too many features making the product too complex. This can lead to confusion and make it difficult for users to understand and adopt the product.

• Underestimating the time and resources required: Building a new product from scratch takes time, resources, and a lot of hard work. Product managers and engineers can make the mistake of underestimating the time and resources required, which can lead to delays and cutting core capabilities to meet the business team's needs and demands.

• Failing to prioritize features: When building a 0 to 1 product, it's important to prioritize features based on their importance to the customer and the business. Failing to prioritize features can lead to a product that doesn't meet the needs of your target audience.

• Not testing the product early and often: Testing the product early and often is critical to ensuring that it meets the needs of your target audience. Failing to test the product can lead to building a product that doesn't work as intended or doesn't meet the needs of your target audience.

• Not partnering with product marketing: Building a great 0-1 product is not enough for it to be successful. The product needs to be marketed to the target audience to generate interest and usage. It is critical for product managers to work closely with their product marketing team to build a solid launch plan.

Overall, building a 0 to 1 product requires a lot of hard work, attention to detail, and a focus on the needs of the customer.

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

These are based on my experience:

• The most important one, that is often overlooked is expecting immediate success - this can result in unnecessary pressure and compromises in quality

• Insufficient customer research/validation - being too carried away with the idea leading to confirmation bias

• Poor stakeholder communication, expectation setting - resulting in unrealistic timelines/expectations.

• Overengineering or scope creep.

• Lack of clear product vision.

Here are some high level issues that come to mind:

1. No market or end user need: many startups try to build a tech that is in search of a problem. Like Steve jobs said, find a real user issue and build tech that solves it. Validating this need is important.

2. The user need is just not large enough: the market has to be substantial for it to gain traction.

3. Not iterating fast enough: if feature set is not gaining traction, key is to iterate on it quickly and pivot as many times as needed. Continuing to refine a solution that does not fit user needs is futile

4. Ignoring the competition: always keep an eye out on new features and see if you can learn from it

5. Not prioritizing ruthlessly: limited resources mean that the feature set needs to be very carefully sequenced. Spending time/effort on something that does not add value severely impacts the success of the product.

6. Carefully planning the product launch: failing to target the right users with the right message means the adoption is going to be poor.

7. Not Iterating on the pricing/packaging model: sticking to a pricing/packaging model that is not working means the product will struggle in the market even though it may have the right feature set.

A common pitfall is over-engineering the solution. Instead of complex features and functionality, focus on delivering a simple, compelling first product launch that addresses the primary problem that customers will want to use and will find beneficial. 

Minimizing scope not only accelerates your time to market but also facilitates quicker feedback collection. To architect your chance of success, focus on a specific sub-segment of your target audience, that is the most engaged and will actively participate in your betas and provide actionable insights. This will create an environment for rapid learning. 

Another frequent mistake is failing to iterate quickly based on the feedback you receive. Continuous learning and iteration are essential for refining your 0-to-1 product and ensuring its successful delivery. Embrace feedback as a vital part of the development process to enhance your product’s relevance and effectiveness.

The following stand out to me for what I've witnessed:

• The team is acting like the product they're creating is going to be successful. I'm amazed at how many successful companies try to build new products like they do for their existing successful ones: same processes, same success metrics, etc. They don't have the urgency, move too slowly, learn too little, are complacent. The market is a graveyard of failed products and businesses: the most likely outcome, when creating a product, is that it will fail. As a result we shouldn't assume success but instead focus on doing everything we can to de-risk, test and validate - and make sure we don't over-invest too early. I recently was interviewed in Lenny's podcast to talk about that: if you're working on 0-to-1 in a bigger company I think it's worth your time.

• The team built a solution to their own problem and they assumed that many more people would face it in the same way. We hear a lot of success stories that started like that, and while it's true that some successes began like this, it's also where a lot of failures came from. You're not the customer of your product: work with real customers! Or it's only going to work for a small population, and that may not make it a viable business. Mehdi, the founder of Cycle, shared openly a great example of this for how they changed their approach to user onboarding.

• The product manager tries to get a big team from day 1. Honestly a small team can move 10x faster than a big one. You need a team of people you can trust who can move mountains on their own and continents together. For the first year of creating Jira Product Discovery we only had 5 engineers, and we moved really fast. It forced us to focus on the most important things, to be nimble and creative when testing solutions, and we could do this with very few meetings (it's very easy to get everyone on the same page at that scale). Once you've proven you have a solution that solves real problems for a small number of users - you can then go back and ask for a (slightly) bigger team. Resist that urge to grow too fast!

• The team is fighting too many battles at once. This happened to us at Atlassian when we tried to rebuild Hipchat into another product called Stride. We were trying to launch a new product built on top of a new platform that could be used for all other Atlassian products. We faced this tension product<>platform from day 1, and it was much slower to move on the product front. Like with any failure there's of course more than one reason this product didn't pan out, but this is definitely one of them.

• The PM fails to get the right level of buy-in internally - if it's about creating a product inside a bigger company. It's very important to "build chips" in the company (gain trust from leadership) so you can spend them, gain more chips, etc. And it's key to communicate your learnings and progress in a way thatmake your team look like a high speed train - no one wants to get in front of a high speed train. This is one of the topic I cover in an interview on Lenny's podcast.

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 eventually successfully sold:

🥇"Always run user research."
Back in 2015, I and Ahmed Sulaiman released our first product.

It Failed Dramatically. We spent one year of development without proper user research, without defining the customer journey, or even having personas.

Obviously, we built something we imagined users would need but ... users had their own opinion. That taught me the importance of knowing users and their needs.


🥈 "Start small"
Really? Who doesn't know that? Everyone read about the lean startup framework except for us... We built FOUR products as our first MVP: a plugin for Sketch, a plugin for Xcode, a plugin for an iOS simulator, and a web version.

The release cycle of one year made our feedback loop ONE year long! If you'd see me now, you'll notice me blushing from shame. Start small...


🥉 "Do you know what your competitors are doing?"
In 2018, we didn't know until...

a competitor copied one of our main features. Well, doing a competitive analysis could mitigate the risk of this happened unexpectedly. This situation taught me the importance of competitive intelligence, competitive differentiation, and the power of product stickiness.

I hope, you will learn from my mistakes and will avoid them in your products.