Before 0 → 1 Comes 0.0

*If this posts resonates you can find more like it over at substack: https://maharveyswe.substack.com/

There’s something uniquely intimidating and exciting about starting a greenfield project. For a product manager, it might mean drafting the first PRD for a customer-facing product the company is only beginning to consider. For an engineer, it could mean kicking off the initial system design for a large-scale piece of software that’s already been greenlit. Either way, the sheer scope of “starting from scratch” can feel paralyzing, especially at big companies, FAANG or otherwise, where the stakes are high: funding approvals, leadership visibility, and dependencies that ripple across multiple teams.

I felt that polarity firsthand when my manager asked me to draft a PRD (Product Requirements Document) for a potential new data product. This wasn’t about incremental improvements to something that already existed, this was a multi-million-dollar bet with the potential to shape the company’s future. The PRD would determine whether leadership funded the effort at all. And I was starting with… nothing.

Thanks for reading The Hard Thing About FAANG Things! Subscribe for free to receive new posts and support my work.

That’s when my manager gave me a piece of advice that’s stuck with me ever since:

“Make a plan for the plan.”

At first, I laughed, half thinking he was being funny because he was a goofball, and also thinking that seemed a little redundant. How could I plan the plan before I even had the plan? But the wisdom clicked almost immediately. Before you can map out a cross-country road trip, you don’t need to know every hotel or restaurant stop, you just need to know which highways you’re taking, how long you expect it to last, and who’s coming along for the ride

That little meta-plan was the spark I needed. Instead of staring at a blank PRD, I outlined the scaffolding for how I’d get to the PRD. And from there, momentum started to build.

Why the “Plan for the Plan” Matters

Large projects feel overwhelming because they represent so much ambiguity. Where do you even begin? Do you start with research? With stakeholders? With the final document?

Here’s why making a “plan for the plan” works:

• It beats procrastination. Let’s be honest: sometimes over-planning is a form of procrastination. We obsess over frameworks, perfect timelines, or the “ideal” kickoff instead of taking action. A lightweight meta-plan lowers the activation energy.
• It creates focus. Instead of spinning in circles, you’re defining a small, achievable first step. That sense of clarity can shrink something that feels impossibly big into something achievable.
• It builds momentum. Big projects don’t just happen at once, they move in small pushes. Once you’ve created the scaffolding, it’s easier to expand into the real thing.
• It sets expectations. Even if you don’t yet have every answer, a meta-plan communicates to your stakeholders: “Here’s how I’m approaching this.” It signals thoughtfulness and direction early.

What Should Go Into the Plan for the Plan

This isn’t meant to be a 15-page doc, save that for your PRD, LLD, HLD, whatever else acronym’d doc you write for your work. The beauty of the meta-plan is that it’s short, directional, and flexible. But it does need a few core elements:

1. Key Deliverable Dates & Timeline

When do you need a first draft? What’s the total timeline for the project? A timeline doesn’t just help you stay accountable, it’s visibility so your stakeholders know when they’ll see progress.

Example:

• Week 1: Draft outline
• Week 3: Circulate for stakeholder input
• Week 6: Final draft ready for review

2. Hypotheses or General Vision

Even if it’s rough, jot down your early hypothesis about what you’re building and why. You’re not “solution-i-sizing” here, you’re anchoring the conversation.

Example: “We believe a new data aggregation service could cut reporting latency by ~40% and unlock faster insights for partner teams because...”

3. Upfront Research To-Dos

What do you need to validate before you can make confident decisions? These are your “blocking questions.”

Examples:

• Pull baseline metrics for “X”
• Interview three internal teams who would consume the data
• Review compliance requirements with legal
• Could this have any product security impact?

4. Stakeholders & Roles (RACI-lite)

Who’s Responsible? Who Approves? Who Contributes? Who must be Informed? You don’t need a full spreadsheet, just enough to know who you’ll be working with.

Example:

• Responsible: Me (author)
• Accountable: Eng Director
• Consulted: Analytics team, Legal
• Informed: Partner PMs

Optional (But Powerful) Additions

Beyond the essentials, you can add a few extras to sharpen the plan:

• Risks & Unknowns: What’s most likely to derail you? Flagging these early helps you be proactive and better outlines what you need to address in your deliverable doc.
• Definition of “Done”: Not for the final project, but for the plan itself.Example: “PRD drafted, reviewed, and ready to be considered for leadership funding by “X” date”
• Example: “PRD drafted, reviewed, and ready to be considered for leadership funding by “X” date”
• Communication Cadence: A simple note like “weekly check-ins” with XFN can prevent surprises later and also gain excitement and visibility for the product.Example: “Will update “X” slack group on progress at “Y” Frequency
• Example: “Will update “X” slack group on progress at “Y” Frequency

Avoiding the Trap of “Meta-Procrastination”

Of course, there’s a danger here. You don’t want to fall into the trap of endlessly planning the plan. Let’s not mistake motion for progress. The whole point is to move forward, not to create a Russian doll of documents inside documents.

So how do you avoid it?

• Timebox it. Give yourself a day (or even just a few hours) to draft the plan for the plan.
• Keep it lean. One to two pages max. If you’re writing more, you’re probably drifting into the actual plan.
• Treat it as disposable. This isn’t a formal artifact, it’s scaffolding. Don’t over-polish it.

Remember: the value is in the clarity it brings, not in the document itself.

Takeaways for PMs and Engineers

Whether you’re a PM writing a PRD or an engineer tackling a system design, the “plan for the plan” is your friend. It:

• Shrinks big, scary projects into manageable chunks
• Signals direction early without overcommitting
• Builds momentum that compounds over time

It’s a tool for breaking through paralysis, not an excuse to delay.

Closing

Every greenfield project starts with a blank page, and blank pages are scary. But if you can make a plan for the plan, you’ve already taken the first step away from seeing your cursor blink an an empty white word doc.

The next time you’re staring at a daunting new PRD, design doc, or product idea, don’t pressure yourself to have all the answers. Just sketch the scaffolding: timeline, hypothesis, research, stakeholders. That’s enough to get moving.

Because once you start, momentum carries you. And consistent momentum, more than perfection, is what gets big projects across the finish line.