I design decisions before I design products.
The quality of a product is rarely defined by the features you build. It's defined by the decisions you make long before the first line of code is written.
I'm Gabo. I work at the intersection of strategy, technology, and business, turning ambiguity into a direction a team can actually build toward. Lately that's meant deciding which AI platform gets which job, and why "pick one winner" is usually the wrong question.
I think a good product conversation should feel like a good brainstorm: structured enough to go somewhere, loose enough that a good idea can still surprise you. I'd rather ask an uncomfortable question early than write a polished roadmap around the wrong assumption.
Most of what follows isn't about features I shipped. It's about the calls I made before shipping was even on the table, and what I'd do differently now that I've seen how they played out.
Where most of the last five years went
Product management for real clients at Imaginex Studio, from a 20-person healthcare build to three-week sprints. Each one opens with the decision, not the feature list.
A 90-day pilot to decide whether AI agents belonged inside a global fashion brand, and if so, on which platform. Five vendors, ~30 real use cases across six departments, one weighted scorecard, and a mid-pilot call to cut the vendor that wasn't working.
A home care platform built with CAB, a caregiving company with 15+ years in the market who founded a software company, Sophicare, to build it with us. I was the only PM on a team of about 20 across UI/UX, DevOps, mobile, frontend and backend, over roughly two years.
Care plans drive the work: a client's required tasks get embedded in their profile and matched against visit hours. Open visits get filled by finding care partners whose skills fit and who live close enough to make the assignment realistic. Payroll and billing ran externally but pulled from an exportable report, and a dedicated mobile app let care partners clock in, clock out, and log completed tasks in the field.
Digitized the permitting process for construction on Montana's watersheds, with an applicant side and an admin side. Instead of a straight PDF-to-form port, we integrated Mapbox so reviewers could see exactly where construction was proposed and where existing permits sat, turning a stack of documents into decisions made with spatial context. A team of about eight developers plus UI/UX.
A structured conversation product in the family of video-call tools, but built around timed turns: a host gives each participant a fixed window to speak, say five minutes, then the floor passes automatically. The constraint is the feature, it forces the kind of turn-taking that free-for-all calls never produce.
Discovery, tuned to the business every time
Four startup discoveries. The core discipline holds across all of them, listen first, prioritize against what the business actually needs, map the user flows, and draw a defensible line between MVP and what waits for v2. What changes every time is the calibration: a phishing-defense product and a home-care platform don't get the same MVP, even when they get the same method.
The full range
Not everything is a two-year build. I've run three-week migration sprints, launched products from zero, and led projects the other direction, all the way to shutdown, owning the offboarding documentation so nothing got lost on the way out.
And the ones that are mine
Outside client work, these are the products I've owned end to end. One is live, one closed, and all three taught me something the day job couldn't.
Natural hair care for kids, co-founded with a designer partner. Four SKUs, fully automated e-commerce, national fulfillment through Correos de Costa Rica. Built the operational backbone before touching a single Instagram post.
A study app built for a physician preparing for a physiatry specialty exam. Spaced repetition scored per topic, a two-voice audio pipeline for review on the move, and a driving-safe mode for the commute between hospital shifts.
An e-commerce brand I co-founded and ran for six years, alongside a full-time job. It worked while I could give it my weekends. What closed it wasn't a single bad call, it was a model built on assumptions that were true when we started and stopped being true over time: demand softened, and a business that leaned on my personal time to move orders couldn't absorb that. It's exactly why the next brand was designed so no part of it depended on me being physically available.
Where the habit started
Before "Product Manager" was the title, this is where I learned to build the criteria a decision gets measured against, not just the decision itself.
Kuehne+Nagel
Philip Morris International
Covid cost me my job the same year everything else got harder. So I did two things at once: I made empanadas through the early morning, sleeping in snatches until about 7, then went out to deliver them around 9, and I started Loggicare. Neither was a grand plan. One paid this month, the other was a bet on next year.
I'm not going to package it as a lesson. But running a business off my own weekends for six years, and watching it eventually close for exactly that reason, is why the brand I built after was designed so nothing depended on me being physically there.
Where the judgment actually happens
Not a skills list. The criteria I use before a roadmap exists.
Question the premise before the feature
Most bad roadmaps aren't badly built, they're built on an assumption nobody stress-tested. I'd rather spend a week arguing about the premise than a quarter building the wrong solution well.
A single winner is usually the wrong frame
Given five options, the instinct is to rank them and pick one. Sometimes the actual answer is a routing rule: different tools for different technical constraints, not one tool for everyone.
Weight the criteria before you see the scores
A scorecard is only honest if the weights were set before you knew who'd win. Otherwise you're not evaluating, you're justifying.
Uneven data is still data, if you say so
When some inputs are more rigorous than others, the answer isn't to hide that. It's to name it, and fix the process next time so it's comparable from day one.
What I actually believe about this work
The PM role got wider, and pretending it didn't is the mistake
In one quarter the job can mean leading a 20-person build, owning a product from discovery to production, running a vendor evaluation, writing the system prompt, and translating all of it for executives. That's not scope creep, it's what the role actually is now. The title didn't shrink, the job description everyone keeps copying just hasn't caught up.
Progress over perfection, but the criteria don't get to be vague
Moving fast is fine. Moving fast without a clear definition of done is just deferred rework.
Bad news should sound the same as good news
A schedule slip, an underperforming vendor, a channel that isn't converting: none of it needs spin, and none of it needs alarm. It just needs to be said plainly and early.
A pilot exists to validate cheaply before anyone commits expensively
The point of a pilot or an MVP isn't to ship something small, it's to find out whether the expensive version is even worth building, while the cost of being wrong is still low. Kill it early or scale it with evidence. Either one beats guessing.
Skip the resume, ask a real question
A small model with just enough context about my work to answer honestly, including the parts that don't flatter me.
The tools, if you want the list
Product
- Discovery
- Roadmapping
- Prioritization (RICE / MoSCoW)
- Executive reporting
Delivery
- Agile / Scrum
- Stakeholder management
- Change management
- Risk tracking
AI & platforms
- LLM evaluation
- Prompt design
- Leading LLM platforms
- Agentic workflows
Data
- Excel (advanced)
- Tableau / Power BI
- SQL basics
- Weighted scoring models
Got a complex problem to work through?
I like the ones that don't have an obvious answer yet.