Product Manager

DataDrone Inc.; Cheyenne, Northern (WY, KY); Híbrido; USD 95 000 - 150 000; Tempo integral

Resumo da oferta

DataDrone Inc. is seeking a Product Manager to own the product roadmap, PRD, and the non-technical knowledge base. You will translate user feedback into prioritized features and write specs that engineers can implement without questions.

You’ll balance user needs with business goals, say no when appropriate, and track adoption metrics to prove what’s delivering value. Join a fast-moving team that values clarity and accountability.

Qualificações

• Shipped features in a live product used by real customers.
• Able to write a feature spec that an engineer can build from without clarifying questions.
• Understand the difference between a user problem and a feature request and articulate why that difference matters.
• Able to say "no" with reasoning when necessary and communicate it clearly.
• Use data to prioritize, not just gut feeling.

Responsabilidades

• 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.

Conhecimentos

Product management

Data-driven prioritization

User research

Written communication

Ferramentas

Trello

Google Drive

Product analytics

Web analytics

Slack

AI copilot

Descrição da oferta de emprego

DataDrone 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.

What You'll Do

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 Rhythm (How You Operate)

• 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.

Key Responsibilities

• 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

What We're Looking For

• 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.

Bonus Points For

• 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

The Mindset We Hire For

• 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.

Success in This Role

• 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.

Tools You'll Use

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

Why Join Us

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 real code, and watch metrics that tell you if you were right.

5 hours of focused work per day. No meeting overload. Sustainable pace.

Self-Check Before You Apply

• Can you write a feature spec in under an hour that an engineer can build from cold?
• When a stakeholder requests a feature, is your first instinct "what problem does this solve?" not "how do we build this?"
• Can you say "no" to a feature request from a paying customer and explain why without damaging the relationship?
• Do you maintain documentation proactively — or does it take a crisis to update it?
• Can you describe the last product you worked on's core success metric in one sentence?
• When a shipped feature doesn't get adopted, do you investigate why — or move on to the next one?

If three or more are yes, that's you — apply.