Product Manager

Data Drone builds 0-1 SaaS products and the team that ships them. No bosses, no managers — the playbook manages, the copilot tracks. Every role owns a small, defined space with extreme accountability. We ship fast, measure what matters, and build what users actually need — not what sounds good in a brainstorm.

You'll own what the product builds and what it doesn't. You'll maintain the PRD — the single source of truth for the product. You'll write feature specs that engineers can build from without asking questions. You'll synthesize user feedback into a roadmap that drives the proof-moment metric up. You'll say "no" to most requests and "yes" to the ones that matter.

• Daily: keep the PRD and Co-pilot Knowledge Base accurate as decisions land. Triage incoming feature requests against the user problem behind them.
• Weekly: synthesize user feedback from support, sales, and direct conversations into roadmap signal.
• Monthly: re-prioritize the roadmap against the proof-moment metric and write the specs the cluster will build next.
• Quarterly: review the product against adoption evidence and prune what isn't earning its place.
• Always: every spec ships with acceptance criteria, edge cases, and a definition of done.

• Own and maintain the PRD — accuracy, currency, completeness
• Own and maintain the Co-pilot Knowledge Base — product truth for all non-technical teams
• Define and prioritize the product roadmap based on user feedback and data
• Write feature specs with acceptance criteria, edge cases, and definition of done
• Synthesize user feedback from support, sales, and direct conversations
• Define and monitor the proof moment — the metric that proves users adopted the product
• Own the New Business Type Launch playbook

• You've shipped features in a live product used by real customers. Not prototypes — production.
• You can write a feature spec that an engineer builds from without clarifying questions.
• You understand the difference between a user problem and a feature request — and you can articulate why that difference matters.
• You can say "no" with reasoning. Most requests are "not now." Some are "never." You can tell the difference and communicate both clearly.
• You've used data to prioritize. Not just gut. Gut is the tiebreaker, not the driver.

• Experience with SMB SaaS products
• Experience maintaining technical documentation (PRDs, specs, knowledge bases)
• Experience working with junior engineering teams
• Comfort with AI copilots for spec writing and research

• Clarity over cleverness. A clear spec beats a clever one. A simple feature beats a complex one.
• Evidence over opinion. "Users tell us X" beats "I think users want X."
• No over maybe. A clear "no" is kinder than an indefinite "we'll consider it."
• The PRD is sacred. If it's wrong, everything downstream is wrong. You treat PRD accuracy like an engineer treats test coverage.
• Users are the signal. Not competitors. Not trends. Not what other products do. What YOUR users need.

• 30 Days — PRD verified and updated. Specs written. User pain points understood from direct conversations.
• 60 Days — Spec quality proven — engineers don't ask clarifying questions. Feature request process running. Roadmap updated with evidence.
• 90 Days — Proof moment trending up. PRD is a trusted living document. You can answer "what are we building and why?" for anyone who asks.

Trello, Google Drive, product analytics, web analytics, Slack, AI copilot.

You won't sit in stakeholder meetings debating hypotheticals. You won't write decks that justify features nobody asked for. You'll own a live product, talk to real users, write specs that become…