Essential product skills: 0 to 1 products

Building new products from scratch can be thrilling. You get to go from nothing to something, and you’re fully responsible for the product’s success. But it’s quite different from “normal” product management.

I’ve worked on several 0 to 1 products; some were a success… some were not. Here’s seven mistakes to avoid.

When working on existing products, you already know there’s demand for it. For new products, that’s not the case. Priority number one is making sure you’re solving an actual problem, and that the pain is big enough for your customers that they would try your product. Oftentimes your biggest competitor is not another product… it’s simply them not solving the problem at all.

How do you know if the pain is big enough? In my experience, if you’re not sure… it’s not. For products I worked on that ended up being a success, I could immediately tell in interviews that customers desperately wanted their problem solved. Just by asking about their problem, they were already asking me for a solution.

And your solution often won’t need to be perfect. It just needs to work. If you catch yourself thinking “if I just make the app prettier, then they’ll get it”, you’re on the wrong track. You can’t put lipstick on a pig.

Imagine you come into a company with the mandate to build a new product. On the one hand, your fresh perspective and lack of bias allows you to challenge the status quo. On the other, companies with existing customers have a wealth of knowledge and expertise that you would be remiss to ignore.

So start with a round of onboarding chats. Understand the customer, the business, what has historically worked, and what hasn’t. Here are five questions I like to onboard with.

The other high-impact, low-effort thing you can do is look at real-life examples and usage. Your new product may not exist yet, but users may be using existing products to replicate what you’re building for them. If that’s the case, look deeply at 5-10 users - what did they order, how did they use your product, try to understand why.

Alternatively, interview 5-10 people who have solved the problem you are solving (e.g. manually, or with a competitor’s product) and ask them to take you through their process. Your company’s resources include access to potential customers - make the most of it.

Now imagine you started working on a first prototype. Showing this to real users is terrifying. You know it’s not good enough yet. With just a few more days of effort we can make it look better, function better. Just one more week.

Before you know it, months have passed. The product is finally in a good state, you show it to users… and it turns out you’re solving the wrong problem. Or you made the wrong assumptions and users hate the product. You need to derisk this as soon as possible, and you do that by talking to users as early as possible.

New products usually have two aspects: some form of intelligence (e.g. AI), and the user experience (e.g. how the app looks). In my experience, we often spend too long on the intelligence part before testing - for fear of it not being good enough yet. But you can usually get 80% of the way with a simple heuristic, and get a lot of valuable feedback that way: about how far off you really are from it being good enough, and about the user experience.

There is one risk here: if you are testing your “80% heuristic” version, and it turns out to not be good enough yet, you will be tempted to fix those quality issues through a better user experience. But if you had the final, more intelligent version, that would not be needed. This is a tricky balance: do you build for the current capabilities, or where you aim to be later?

What helps is writing down your assumptions about how good the intelligence will be in the future, so that you can 1) plan the user experience around that, and 2) test if those assumptions are realistic or not. If not, you know you need to cater for it in the user experience.

Let’s imagine you have a first prototype, and you are interviewing potential customers to show it to them and get feedback. You may be tempted to go straight to testing the prototype. The problem is that you don’t know if your user is actually a good fit for the product.

Usually you will have an Ideal Customer Profile (ICP) in mind, e.g. their age, job title, willingness to pay, technical sophistication. Your interviewee may seem like your ICP on paper, but when you start showing them the product it just doesn’t land, and you can’t tell why. Is it the wrong solution? Do users not actually have the problem you think they have? Or are you just talking to the wrong user?

So don’t go straight into testing. First, really understand your user. Start with general questions about them, their work, the problem you think they have, how they solve it right now. Really go deep to understand their pain.

By the end of those questions you will already know if they have your problem, and whether your solution will land. You now also know whether to pay attention to this user’s feedback of your product, or to ignore it.

As a bonus, if you later decide to change your ICP, you can quickly identify which interviewees fit your new ICP, and therefore which insights are still relevant.

Dogfooding - regularly using your own product - is key to building a new product. If you don’t love using the product yourself, why would your customers? You’d be surprised by how few employees regularly use, or even have tried, their own company’s products.

Now, you may not fit your Ideal Customer Profile. Fortunately, you’ve been interviewing your ICP users from early on (#3), and deeply understanding their problem (#4), so you actually have a lot of empathy for them. You can channel their mindset when you’re testing the product.

One format that I find helpful is to do a team-wide weekly dogfooding session. Everyone sits together, fires up the new product, and writes down all the things they love & hate. Together you can then prioritise the most critical issues.

At the start of a new product you will have a lot of energy to get started. You make a lot of progress, and speed is of the essence.

But over time, this fire fizzles out. It’s only natural - you can’t keep sprinting forever. You get settled into a routine and slow down. This can be needed to get a breather and bring some needed structure. But make sure to periodically take a step back and determine if you’re still moving in the right direction, and at the right pace.

If things are starting to feel slow, think about this: what is the biggest risk to my product, and what information can I gather in an hour, a day, a week? Progress may be closer than you think.

Existing products often have a lot of structure - planning meetings, check-ins, stakeholders, quarterly goals. This can slow you down.

In contract, new product teams start with no structure at all. This can lead to chaos, and running around like a headless chicken. What’s the right balance?

What works for me is starting with minimal structure: just a daily standup, every morning. On top of that, doing a weekly retrospective - reflecting on what went well this week, what slowed us down, and what 2-3 things to do differently next week. This way you can introduce tiny bits of structure for your biggest problems, without going overboard.

Speed of learning is essential for new products. We need to make sure we are working on a problem worth solving, and iterating quickly towards the right solution.

The challenge is that we are overwhelmed by options - ICPs, problems, sub-problems, solutions, features. As AI is bringing down the cost of developing new products, it’s even more essential that we as product managers bring strong conviction about what problem and solution to focus on. We do this by talking to customers, understanding the business, and building a product you & your customers will love.

I hope avoiding the above mistakes will lead your product to success.