The zero-to-one playbook: Building products (and teams) from scratch

Let me paint you a picture of two very different product management scenarios.

In the first one, you join a company as a product manager. Your first 30 days look pretty familiar. You spend time with users, dig into the existing product, and chat with engineering about the architecture. Leadership walks you through your goals. Within a couple of months, you're comfortable. You know what you're solving for, and you start delivering.

Think of it like being handed the keys to a train network. The stations exist. The trains run on schedule. The tracks connect everything. Your job? Keep those trains running, make them faster, and make them safer. In short, optimize what's already there.

Now, let me tell you about my recent experience at US LBM. My boss said, "Manish, you own digital customer experience."

I waited for more details. Nothing came.

No trains. No tracks. No stations. We had an idea of the destination, but everything else? That was on me to build.

Through this experience, I learned that zero-to-one work follows a different playbook – one built on restraint, evidence, and clarity of vision. Today, I’m going to share that playbook with you. Here’s a peek at what we’ll cover:

• The hiring trap most PMs fall into
• How to earn budget with proof, not slides
• Four hard-earned lessons from the zero-to-one trenches
• The Five-Star Vision framework for aligning teams and stakeholders

The hiring trap: Why your first instinct is wrong

When you're handed a zero-to-one challenge, your brain immediately jumps to solutions. You think about the seventeen PMs you had at your last gig, write a job description, and reach out to potential candidates on LinkedIn in an effort to recreate that empire. 

Stop right there.

Every company and every customer is different, no matter how similar the problem space sounds on paper. 

Starting with hiring is like being asked to compose a symphony and immediately recruiting an orchestra. Try playing solo with a piano first. Understand the tune you want to create, figure out what kind of musicians would complement it, and then build your band accordingly.

"Solve supply chain." "Own digital customer experience." These mandates sound clear until you actually have to execute them. What does that even mean in your specific context? What exactly are you hiring for? Do you need someone for inventory visibility? Network planning? Forecasting?

You can't answer these questions until you understand the problem space within your company's unique context. Only then can you articulate what needs solving and who can help solve it.

The power of a small team

In the age of AI, we're all becoming significantly more efficient – perhaps two or three times faster than we used to be. This changes the math of team size. 

Since speed is often a function of team size (fewer people means fewer meetings and less coordination overhead), keeping your team small for as long as possible is a competitive advantage.

Don't assume that more people equals more progress. Often, it just equals more noise. Prove that you cannot possibly scale further with your current headcount before you ask to expand. A lean, high-performing team will almost always outpace a bloated department in a zero-to-one environment.

Moving from victimhood to evidence

Here's an unpopular opinion: when it comes to leadership, product managers love playing the victim card. 

"They don't understand how important my problem is." 

"They never have budget for my ideas." 

"They always prioritize other things."

We have to remember the reality of their roles: leadership deals with constant context switching and a thousand competing priorities.

They aren't "bad" leaders for not giving you $2 million for an unproven idea. They’re being responsible. If you want investment, you have to stop pitching and start providing evidence. Remember: proof before PowerPoint. It's easy to create a deck promising $17 million returns on a $2 million investment, but you need to approach your ask incrementally.

Think back to that train network. If someone hired you to build a new route, you'd start by putting them on a cart and taking them from point A to point B. Prove you can do that, and they'll fund one coach and a track between two stations. Prove that works, and they'll fund more coaches and multiple tracks between multiple stations.

Show evidence that there's value here and that you can deliver it – I promise the budget will follow.

Four lessons from the zero-to-one trenches

Over the years, I've identified patterns in what makes zero-to-one journeys succeed or fail. These lessons apply to product management in general, but they're especially critical when building from scratch.

Lesson #1: Talk to customers (but don't always listen)