Show Notes
New project planning hinges on shaping the idea first, then iterating with a concrete pre-PRD process. Parker shares a practical framework from his PM and design background to help you avoid rushing to code and wasteful rework.
Why planning matters
- Coding too early is costly: engineers are expensive, and a late-stage discovery can blow up timelines.
- Time is money: move fast, but with guardrails to catch big flaws early.
- The goal is to reduce gaps and “guesstimates” by shaping the idea before any build starts.
Start with why, what, and how
- Why: identify the problem you’re solving for your audience (in Parker’s case, questions from his viewers and community).
- What: define the offer and the value you’re delivering (service or product).
- How: outline the planning scaffolding - product goals, distribution, and a design vibe that fits the project.
Market pull and signals
- Audience signals matter: large view counts and recurring questions indicate a real demand.
- Comments and community questions can guide scope and framing before you write a PRD.
- Use these signals to validate the core problem you’re solving and the demand for a solution.
Pre-PRD ideation framework (breadboarding)
- Breadboarding: sketch the screens/flows on paper first (name the screen, its affordances, and how they connect).
- Decide scope: is this for a new product, an add-on to an existing product, or a hybrid?
- Architecture sketch: outline the key components and tech decisions early (storage, database, web framework, payments, search, accounts).
- Start with a simple architecture: storage for media, a database for metadata, a lightweight web framework, and a clear path for distribution.
- Don’t over-detail yet: capture fat sketches and high-level flows to avoid premature commitments.
Build vs. buy: the critical fork
- Evaluate whether you’ll build in-house or buy/partner for components.
- Parker’s stance: prefer building for core capabilities when you’ve used existing options and they’re subpar or unsuitable.
- This decision drives your early design and the MVP scope.
Pitch first, then PRD
- Write a high-level pitch before a full PRD.
- Narrow the problem to a 1–2 sentence statement.
- Outline the solution and potential rabbit holes or risk areas.
- Set a time box (the bet size) to constrain scope and urgency.
- The pitch informs the PRD and helps align the team before diving into details.
Design vibe and distribution planning
- Visual and UX vibes matter: outline a rough front-end feel early to keep design aligned with the product’s purpose.
- Distribution channels shape the product: think about how people will discover and consume (YouTube, website, community, partnerships).
- Pricing and offers: consider what you’ve charged before, price sensitivity, and how to structure introductory offers or discounts (e.g., course pricing, school access, etc.).
Concrete architecture considerations (quick starter)
- Storage: where will videos and media live (e.g., a simple object store or a managed solution)?
- Database: what metadata needs to be stored (video IDs, user progress, access control)?
- Web framework: pick something lightweight that you can iterate on quickly.
- Payments and access: plan if you’ll need one-time payments, subscriptions, or access per course.
- Optional features: search, account management, and a video player flow (likely minimal for a single-product distribution).
- Keep scope tight: decide what to include in the first pass and what to defer.
The AI caveat
- AI tools are useful but can mislead if you don’t have a formed frame.
- Treat LLM outputs as inputs to your process, not the final authority.
- Use them to accelerate planning, not to replace structured thinking and risk assessment.
Actionable takeaways
- Do not skip shaping the idea. Run quick design exercises and hole-poke the concept before coding.
- Use a pre-PRD workflow: ideation, breadboarding, and a lightweight architecture sketch.
- Frame a clear pitch first. Limit scope with a time box to guide decisions.
- Decide build vs. buy upfront to anchor the tech plan and distribution approach.
- Define the distribution plan early and map it to your product design and cost model.
- Validate with market signals (views, comments, community questions) to inform scope and pricing.
- Use fat sketches for flows and screens first; only code what truly adds value.
- Treat AI as a tool, not a substitute for structured product planning.
Links
- Hacker Noon - Parker's prior work and profile (2018)