> ## Documentation Index
> Fetch the complete documentation index at: https://oratory.co/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Common pitfalls

> The most common ways sprints slow down — and what to do instead.

These are the common issues that can slow a sprint down. None of them are fatal — they just add churn.

<AccordionGroup>
  <Accordion title="What slows a sprint down the most?">
    **Lack of a single owner** (someone to consolidate feedback) and **delayed decisions**.

    If multiple stakeholders give conflicting direction, we end up iterating on opinions instead of shipping.
  </Accordion>

  <Accordion title="Do we need a project owner and a decision maker?">
    Yes.

    * **Project owner:** consolidates feedback into one set of priorities.
    * **Decision maker:** gives final approval when we’re ready to move to the next phase.
  </Accordion>

  <Accordion title="What happens if we’re late with product access or a walkthrough?">
    We can still move, but the early design work will rely more on assumptions.

    The faster we can see the real product (Loom walkthrough is perfect), the faster we can create accurate feature visuals and a stronger narrative.
  </Accordion>

  <Accordion title="What if our copy isn’t ready?">
    That’s normal — we don’t need “final” copy to start.

    What we *do* need is enough structure to design the page well:

    * who it’s for
    * 3–5 core use cases
    * differentiators
    * top objections

    If those inputs arrive late, the wireframe and section structure get shakier.
  </Accordion>

  <Accordion title="What’s the best way to give feedback?">
    Anchor it to **a specific section** and **the goal**.

    Examples:

    * “The hero doesn’t explain *what the product actually does*.”
    * “This section needs proof (logos, metrics, outcomes).”
    * “This feels too enterprise — we want it simpler / more technical / more direct.”
  </Accordion>

  <Accordion title="Why do you push back on covering every feature?">
    Because homepage clarity wins.

    Trying to cover everything turns the page into a feature dump. We’d rather make 3–5 core capabilities obvious, then support everything else with secondary pages.
  </Accordion>

  <Accordion title="What happens when we add “just one more page” mid-sprint?">
    It usually forces a tradeoff:

    * timeline slips, or
    * quality drops, or
    * we cut something else.

    When scope changes, we’ll propose the cleanest swap or the right add-on.
  </Accordion>

  <Accordion title="What if our assets (logos/photos/screenshots) aren’t ready?">
    We can keep moving with placeholders.

    Waiting for perfect assets is one of the easiest ways to stall progress. We’ll design the system first, then drop assets in once they’re available.
  </Accordion>

  <Accordion title="What if stakeholders disagree late in the process?">
    That’s where churn happens.

    Best prevention:

    * make sure the decision maker is present at kickoff
    * have them watch the Loom updates
    * keep feedback consolidated
  </Accordion>

  <Accordion title="What launch-day issues can cause surprises?">
    Common ones:

    * DNS ownership or access isn’t clear
    * redirects weren’t planned
    * forms weren’t tested end-to-end

    We’ll flag these early, but we’ll need you to confirm owners and any constraints.
  </Accordion>
</AccordionGroup>

***

<Card title="Book a free intro call" icon="calendar" href="https://oratory.co/meeting" horizontal>
  Schedule a call to talk through your project.
</Card>