Product and project, I do both
A product manager decides what to build and why. A project manager makes sure it ships on time and on budget. Across 18 years I have worn both hats, often at the same time. On the IBC bridge program at Datachain I owned the product bet and the delivery plan together, because in a small Web3 team you cannot separate the two.
Discovery before delivery
I never let a team start building before the problem is framed. I run a short discovery with user interviews, data and a competitive scan, then write a one page brief: the problem, who has it, why now, and what done looks like. If I cannot fill that page honestly, the feature is not ready for the backlog.
A plan is a communication tool
The Gantt chart is not for me. It is for the ten people who need to know what depends on their work. I keep plans lightweight: milestones, owners, dependencies, and the two or three risks that could actually blow the date. Everything else is noise.
Scope is the lever, not the deadline
When a project is behind, the deadline is usually fixed and quality is not negotiable, so scope is the only honest lever. I keep a ranked backlog so cutting scope means cutting the least valuable thing. That is a decision I can make in an afternoon instead of a crisis meeting.
Real example
At SmartNews I ran the product and the delivery for an Ads reporting revamp: discovery with the sales team, a phased rollout, and a hard launch date tied to a quarterly advertiser cycle. We shipped the core on time by moving two secondary reports into a fast follow, and nobody noticed they were missing.