Product Manager

This role is Product Manager for Aedeon, the platform itself. Aedeon turns the systems already running an enterprise applications, databases, data platforms, business rules, workflows into governed AI agents, grounded in a persistent Code Intelligence Graph of the customer's own code and verified through behavior-equivalence proof. Aedeon is delivered as a product, not a services engagement, and runs without mandatory forward-deployed engineers.

The founders write product notes that set what gets built and why. You take those notes and turn them into epics, acceptance criteria, sequenced releases, and the daily scrum cadence that gets releases out the door on time and to the quality the founders signed off on. Founders own the strategy. You own the finish line.

This is a delivery-heavy role with real product craft. You'll decompose product notes into epics, write the acceptance criteria that define when an epic is actually done, make intra-release prioritization calls when reality forces trade-offs, and review the product every single day so issues surface before customers see them. You'll run scrum, own the release cycle, and be the person engineering looks to when "is this on track?" needs an honest answer.

Two things this role is not. You won't be the primary voice for customers, the founders and GTM team bring the customer signal. And you won't set strategic direction, the founders write the product notes. What you will do is take a clear strategic input and convert it into a shipped product, on a cadence enterprise customers can plan against.

We're looking for someone who came up through engineering before moving into product. You should read code comfortably, sit in agent-design reviews with a technical opinion, and push back on engineering estimates when the math doesn't add up. Aedeon's engineers are senior. The PM operates at their level on the technical questions and owns the product judgment they don't.

.

What will you do?

Decomposition and planning

• Take founder-written product notes and decompose them into epics, stories, and engineering-ready work items.
• Combine epics into releases with realistic dates. Defend the dates against scope creep and against unrealistic compression.
• Maintain the release plan as a living document. When reality shifts, the plan shifts with it - transparently.

Acceptance criteria and definition of done

• Write the acceptance criteria for every epic. What "done" looks like is your call, anchored to the product note.
• Define release readiness: what must be true before a release ships - test coverage, behavior-equivalence verification, governance hooks, customer-facing documentation.
• Sign off on epics before they go to release. No epic ships without your acceptance.

Intra-release prioritization

• Make the day-to-day calls within a release: which bug first, which epic blocks which, what gets cut when the math doesn't work.
• Escalate to founders only when a decision crosses the strategic line. Inside that line, you decide.

Daily product review

• Review the product every single day. Use it like a customer would. Find the issues before customers do, and route them to the right engineer.
• Maintain a running quality bar the team can point at. "Would I demo this today?" is the test.

Scrum and release cycle

• Own the scrum calls: planning, daily stand-ups, retrospectives.
• Own the release process: cut, validate, ship, post-release review.
• Coordinate with DevOps and engineering on the deployment pipeline. Keep it clean and repeatable.

Release accountability

• The founders set the release. You ship it.
• Surface blockers and risks with enough lead time to mitigate. No surprises on release day.
• After every release: what shipped, what landed, what didn't, what needs iteration. Write the retro, share it, apply the lessons.

What are we looking for?

Product management experience

• 5 to 8 years in product management at a B2B SaaS or developer tools company.
• Owned the delivery of a product surface at least once - scope to ship to post-release iteration.
• Strong written communication. Acceptance criteria, release plans, scrum notes, decision docs, retros - the PM's job is partly written, and the writing must be good.

Engineering background

• Came up through engineering. Built and shipped production software for at least 3 years before moving into product.
• Read Python comfortably. Read other common languages (Java, TypeScript, SQL) well enough to follow a code review or a design doc.
• Comfortable in design reviews for distributed systems, agent orchestration, or data pipelines. Has an opinion, not just questions.

Delivery discipline

• Treats commitments as commitments. If a release date is on the calendar, you defend it or renegotiate it openly. You don't silently slip.
• Runs scrum cleanly. No theater. The ceremonies exist to remove blockers, not to fill time.
• Treats acceptance criteria, release plans, and retros as first-class deliverables, not paperwork.

Operating mindset

• Comfortable in a founder-led product environment where strategy comes from above and you own execution.
• Bias to action. Decisions made and revised beat decisions deferred.
• Strong English communication, written and spoken. You'll be in product reviews and customer-impacting release discussions.
• Available to work US business hours from India.

You'll be preferred if

• Enterprise modernization domain experience (mainframe, SAP, Oracle, large Java / .NET estates) or AI/agent orchestration product experience.
• Familiarity with AWS production environments (EKS, ECS, Bedrock, DynamoDB).
• Exposure to regulated industries (BFSI, healthcare, insurance) and the release discipline they require.
• Prior experience as the only or first PM at a company.

How we work?

Delivery dates here aren't aspirations. Mactores runs fixed-date engagements and absorbs overage cost for delays inside its control; Aedeon's releases carry the same discipline on the product side, because enterprise customers plan cutovers against them. The feedback loop is tight by design, field delivery informs the platform roadmap, and platform capabilities change what delivery can commit to. Your job sits at the point where a founder's product note becomes a release a customer can bet a migration on.