Product Management Philosophy
Good product work starts with a real user problem and a clear business objective. I define what to build, why it matters, and how engineering will know it is done — then stay close through delivery.
Not project coordination — product ownership with engineering depth. Business → product strategy → user problems → PRDs → UX → engineering → cloud → delivery.
How I build products
A simple loop I use across SaaS and marketplace work — short enough to stay honest, complete enough to avoid skipping discovery or measurement.
Understand →
Start with the business goal and the user problem — not a feature request.
Discover →
Learn what users need and what competitors already do, then test assumptions.
Define →
Turn insight into clear product requirements, user stories, and acceptance criteria.
Prioritize →
Choose what matters now based on value, effort, and revenue impact.
Design →
Shape the flow — especially onboarding, booking, and checkout — before build starts.
Build →
Stay close to engineering so intent survives implementation and tradeoffs stay visible.
Measure →
Look at whether the change helped users and the business — not just whether it shipped.
Iterate
Use what you learned to improve the next cycle of decisions.
Why DevOps experience helps
Most product managers stop at requirements. Most engineers stop at systems. I work across both — so I can challenge a feature that is expensive to build, spot delivery risks early, and write requirements engineering can actually ship.
Good product work starts with a real user problem and a clear business objective. I define what to build, why it matters, and how engineering will know it is done — then stay close through delivery.
I align founders and stakeholders on direction before features multiply. Strategy means choosing tradeoffs: who we serve first, what success looks like, and what we explicitly will not do yet.
I use customer and competitor research where available, then pressure-test ideas against technical feasibility. Discovery is about reducing uncertainty before committing engineering time.
I prioritize by user value, delivery cost, and revenue impact — not by who shouted loudest. Roadmaps stay honest about sequencing and dependencies.
I write PRDs, user stories, and acceptance criteria that engineering can implement without guessing. Ambiguity is expensive; clarity is a product skill.
I pay special attention to onboarding, booking, and checkout — flows where product decisions show up as activation, trust, and revenue.
I contribute to pricing and revenue models, including marketplace markup structures, so product decisions support a viable business.
Because I have shipped infrastructure myself, I can discuss APIs, CI/CD, cloud constraints, and feasibility without treating engineering as a black box.
I weigh user value against technical cost — especially for AI features and cloud-backed products — so the roadmap stays ambitious and buildable.
Capabilities in practice
I connect business goals to a clear product direction before features are scoped.
I work with founders and stakeholders to sequence work by user value, feasibility, and revenue impact.
I write requirements engineering can build against — clear enough to reduce ambiguity and rework.
I start from the user problem, validate options, then define the smallest useful product change.
I design critical conversion flows where product decisions directly affect activation and revenue.
I contribute to pricing models and revenue mechanics, including marketplace markup structures.
I translate product intent into technical requirements and stay close to delivery constraints.
I sit between stakeholders and builders so business requirements become shippable product and technical work.
Case studies
Primary · Current role
Technical Product Manager
SaaS marketplace product work spanning roadmap prioritization, seller onboarding, feature definition, and monetization.
Independent Product Management
On-demand device repair platform — booking, checkout, policies, and pricing designed with founder and engineering.
Product ownership (Pietech)
Community product features — local circles, discussions, and engagement — from concept through shipping.
Product ownership (Pietech)
AI-powered product — feature requirements, feasibility vs value tradeoffs, roadmap and positioning contributions.