How I Use AI as a PM With a Real Workspace
The useful version of AI product work is a real workspace where notes, files, drafts, and outputs stay connected.
Writing
Writing on product, platform, and AI work
Short notes on AI workflows, platform work, incidents, small tools, and the day-to-day details that usually decide how the work goes.
Featured writing
Developer Platforms Mostly Fail On Friction
Most platform products lose in the first hour, not in the roadmap review.
Growth Breaks In The Operating Model
A lot of growth problems are really handoff, pricing, and service-definition problems wearing a growth label.
Published elsewhere
Selected Oracle posts plus my author profile.
Functions Design Patterns
A practical pattern guide for routing, validation, async execution, and the design checks that keep Functions examples useful.
Introducing Long-Running Functions and Response Destinations with OCI Functions
How detached execution and response destinations change the handoff boundary for longer-running serverless workflows.
Announcing support for larger memory functions in OCI Functions
A product surface update that matters when runtime limits, workload shape, and starter-pattern guidance need to line up.
Selected notes
AI Work Needs Real Tools
Months of hands-on use reinforced that useful AI work depends on tools, files, review loops, and recovery paths around the model.
What Building Internal Platforms Taught Me
Internal platforms teach product judgment quickly because the users are technical, close to the work, and too busy to tolerate fluff.
Why I Still Like Small Python Tools
Small scripts still earn their keep when they remove one repeated annoyance from the week.
Trustworthy AI Products Need Recovery Paths
Trust comes less from the best answer than from what the system does when it is unsure.
AI Support Is A Workflow Design Problem
The hardest part of AI support is usually not the model. It is deciding what the system can do, when it should stop, and how it fits the real workflow.
Migration Readiness Is A Product Problem
Migration pain is often designed into packaging, docs, and defaults long before a customer ever starts.
Feature Registries Are About Operational Clarity
A registry matters when it can answer what broke, who owns it, and what changed while something is already going wrong.
Dependencies Need Owners Before They Need Slides
Planning artifacts become more useful when they expose overdue, unowned, and blocked work instead of just presenting milestones cleanly.
Incident Timelines Need A Stable Shape
Incident reviews get more useful when the timeline is consistent enough to reduce debates about sequence, handoffs, and impact changes.
Show more notes
Proof points should route to evidence
A homepage stat earns more trust when it points directly to the case study, project, or note that makes the claim inspectable.
Discovery paths should name the first move
A discovery card gets easier to trust when it says what the recommended first click is instead of only naming the topic area.
Start cards should name the route
A homepage card works better when it says whether it routes to proof, context, or published work before the reader has to infer the click.
GitHub Profiles Should Keep One Context Link Per Track
A GitHub profile gets easier to trust when each repo track keeps one visible context link instead of leaving all of the explanation in a long mixed intro list.
Project Tracks Should Point to Published Work
Grouped repo tracks earn more trust when they also point to one published post or case study that shows the same preference under real constraints.
Homepages Should Offer Short Paths by Intent
A portfolio homepage gets easier to use when it offers a few opinionated routes by intent before it asks a reader to scan the larger inventory.
Alerting Starter Patterns Should Normalize Before They Notify
A starter alerting repo gets more reusable when it turns raw alert payloads into one readable message shape before the workflow hands the problem to a person.
Decision Logs Should Keep the Revisit Date Visible
A decision log stays useful when it keeps the owner, assumption, and revisit date visible enough to pull old calls back into the workflow before they turn into archaeology.
Starter Patterns Should Leave One Stable Handoff Artifact
A starter repo gets stronger when the first run leaves behind one compact artifact that a downstream system could actually consume instead of forcing every later step to re-parse the same raw input.
Docs Checks Should Point at Publish Blockers
A useful docs checker should stay close to the few issues that actually stop a draft from being ready to hand off, review, or publish.
Validation Gates Should Fail in a Useful Shape
A starter validation repo gets more reusable when the failing result is structured enough to show what broke, why it broke, and what the next fix should be.
Anchor Repos Should Carry the Batch
Once a projects page recommends one repo per track, those anchor repos need the clearest README, example, and output because they teach the standard for the rest of the batch.
Repo Tracks Should Recommend a First Example
Grouped repo tracks get much easier to read when each track names one best first example before asking a stranger to scan the full batch.
Project Pages Should Explain the Batch
A strong projects page should explain the repeated problem and standard behind a repo batch instead of flattening everything into one inventory.
Good Small Repos Should Show the Second Move
A small public repo gets more reusable when it makes the next handoff or rerun obvious instead of stopping at the first demo.
GitHub Profiles Should Choose the First Click
A good GitHub profile should make the best next click obvious instead of making a stranger sort through an undifferentiated list of links.
GitHub Should Prove and the Site Should Route
A good portfolio gets stronger when GitHub shows the proof, the site handles routing and context, and neither surface tries to do the other's job.
Repeated Work Should Become a Check
If a task keeps coming back often enough to need reminders, it usually wants a small rerunnable check instead of more memory and coordination.
Fun Projects Get Stronger When They Leave a Reusable Artifact
A small side project gets more useful when it leaves behind a clear output, handoff, or rerun path that someone can carry into real work.
Starter Repos Should Stop at the Right Boundary
A good starter repo should make the first handoff obvious by showing what it handles cleanly, what it leaves out, and where the real system begins.
Small Repo Batches Should Teach a Pattern
A good collection of small public repos should reveal a coherent workflow point of view, not just advertise that you made a lot of things.
Examples Are the Interface for Small Tools
For small public tools, a good example usually teaches faster than architecture talk because it shortens the gap between curiosity and proof.
Public Repos Need a Short Path to First Useful Success
Public technical repos land better when they make the first useful success obvious with concrete examples, usable output, and honest limits.
Fun Projects Are How I Test Workflow Ideas
Small side projects are where I test workflow opinions, interface choices, and product taste without pretending every idea needs to become a company.
One-Page Tools Beat Premature Decks
When thinking is still rough, a one-page artifact usually beats a deck because it forces structure without dragging you into presentation theater too early.
Public Surfaces Should Route, Not Recite
A personal site, GitHub profile, and short notes should route people to the right depth instead of each trying to retell the whole story.