I design decisions before I design products.
Most product work isn't deciding what to build. It's deciding what problem is actually worth solving, who gets a vote, and what trade-offs everyone is willing to live with. Turns out ambiguity is a lot more fun than it sounds.
I'm Gabo. I've spent most of my professional time helping teams make decisions before they build products. Recently that has meant navigating the messy world of AI tooling, where the hard question isn't "which platform wins?" but "which one should do this job?" Outside of work I'm usually cooking, mixing a cocktail I'll insist is "almost right," watching football, or getting outvoted three to one by my schnauzers.
If you're looking for polished success stories, this probably isn't that. Product work is messy. Mine certainly has been.
I'm more interested in the messy decisions that happened before anything shipped, because that's where product management actually earns its salary. And, of course, making sure the devs are delivering as expected.
A good product conversation should have enough structure to reach a decision, but enough room for someone to prove everyone else wrong. One thing I'm proud of is making quieter voices part of the conversation. 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, including the ones that worked and the ones that didn't. Thankfully there have been more of the first than the second.
Where most of the last five years went
Five years, dozens of products, plenty of trade-offs. I don't walk through features. I walk through the decisions that made those features inevitable.
A 90-day pilot to decide whether AI agents belonged inside a global consumer 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.
We partnered with CAB, a caregiving company with more than 15 years of experience, to build Sophicare from the ground up. I was the only Product Manager on a cross-functional team of around 20 people over nearly two years.
Early on, we learned that calendars weren't the bottleneck. A visit only happens if the right caregiver can realistically make it, which meant matching skills, availability, proximity, and care requirements before thinking about schedules. Once we made that decision, the rest of the product became much clearer: care plans became the source of truth, matching drove assignments, and scheduling became the consequence instead of the starting point. Mobile task tracking, clock-in/out, and reporting mattered, but only because they supported the real objective, making sure clients weren't left waiting for care that never arrived.
Gilly digitized the permitting process for construction projects across Montana's watersheds. I worked with a team of around eight engineers and UI/UX to redesign both the applicant and reviewer experience. The goal wasn't simply to replace PDFs with forms. It was to cut the endless back-and-forth between applicants and the Watershed District, where every missing location, unclear boundary, or incomplete submission meant another review cycle and more waiting.
On the admin side, we integrated Mapbox so reviewers could immediately understand where construction was proposed and see nearby permits without piecing information together by hand. The map wasn't part of the applicant experience, it was a decision-making tool for reviewers. Geographic context upfront meant fewer clarifications, fewer emails, and fewer rounds of bureaucracy before a permit could move forward.
SlowTalk wasn't built to make meetings faster. It was built to make them fairer. Instead of open discussion where a few participants naturally dominate, every person gets a dedicated speaking window while a facilitator quietly manages the flow. The platform enforces turn-taking, making listening just as important as speaking.
I worked on shaping the product around that constraint. Timers, moderation controls, and structured speaking turns weren't limitations, they were the mechanism that created better conversations. By removing the competition for airtime, the platform surfaced perspectives that usually disappear in traditional video calls.
Discovery workshops aren't a copy-paste
The process might look familiar. The discovery never does. Every discovery I've led looked different because every business had a different problem to solve. The framework stays familiar: understand the business, talk to the right people, map the user journey, and draw a defensible line between the MVP and what can wait. The questions never stay the same. A phishing platform, a home-care product, and a conversation tool don't carry the same risks, don't serve the same users, and shouldn't end up with the same priorities just because someone has a favorite framework. The value of discovery isn't following the same process every time. It's knowing when the process needs to adapt to the business in front of you.
The full range
Not every product starts with a blank page. I've joined products mid-flight, led three-week migration sprints, built new platforms from scratch, and taken products all the way through retirement. Different stages demand different decisions, but the responsibility stays the same: leave the product in a better place than you found it.
And the ones that are mine
Outside client work, these are the products I've owned end to end. Building your own product changes your relationship with every decision. There's no client to hide behind, no roadmap handed to you, and no one else to blame when something doesn't work.
Leo & Vera is a natural hair care brand for kids that I co-founded with a designer partner. Before thinking about Instagram or marketing, we built the operation: an automated e-commerce experience, payment processing, inventory management, shipping through Correos de Costa Rica, and customer communication. The goal wasn't automation for its own sake. It was making sure the business could scale without requiring someone behind a phone every time an order came in.
I built FisiaPrep for my partner while she prepared for her physiatry specialty exam. Residency doesn't leave uninterrupted evenings to study, it leaves short breaks, commutes, and the occasional quiet moment between shifts. Instead of building another question bank, I designed the product around those moments: spaced repetition by topic, confidence-based review, and a two-voice audio mode for studying during commutes. A driving-safe mode made it possible to review without looking at the screen. She later scored over 90 on the exam, but the part I'm proudest of isn't the grade. It's that the product fit her life instead of asking her to reorganize it.
I co-founded Loggicare and ran it for six years alongside a full-time job. For a long time, the model worked. Orders came in, weekends became delivery days, and the business kept growing. What closed it wasn't one bad decision. It was a series of good decisions that slowly stopped fitting reality. Demand softened, my time became the bottleneck, and the business had never been designed to operate without me. Closing it taught me something I still carry into every product I build: if the founder is part of the infrastructure, the business doesn't really scale.
Where the habit started
Before I ever had "Product Manager" in my title, I was already learning how to define success before building anything. The title changed. The habit didn't.
Kuehne+Nagel
Philip Morris International
COVID cost me my job the same year everything else got harder. For a while, my days looked strange. I'd spend the early morning making empanadas, grab a few hours of sleep, then head out to deliver them. At the same time, I started Loggicare. Neither was some grand entrepreneurial plan. One helped pay the bills. The other was a bet that I could build something that lasted longer than the next month.
I don't see that period as a motivational story. If anything, it taught me how easy it is to build a business around your own effort without realizing you've become part of the infrastructure. That's why the next company started with automation, not marketing.
Not rules. Just patterns I've noticed about myself.
Things I've noticed about myself
I ask a lot of questions.
Sometimes enough that people think I'm disagreeing. Most of the time I'm just trying to understand the problem well enough that the solution becomes obvious.
I get excited embarrassingly fast.
AI. Haircare. Watershed permits. Children's shampoo. Doesn't really matter. If I find the problem interesting, I'll disappear into it for a while.
I care a lot about the team wanting to build it.
People rarely do great work because someone asked them to. They do it because they believe the problem is worth solving. That's the environment I try to create.
I usually realize what I think halfway through saying it.
It's a weird way to process ideas, but it's served me well. Some of my favorite product decisions came from conversations where nobody, including me, knew the answer walking into the room.
Things I've learned mostly by getting them wrong first
AI didn't replace thinking. It exposed it.
AI can write a presentation in five minutes. That's exactly why knowing what you're trying to say matters more than ever. The hard part was never prompting, it's having a clear idea before you start typing. I treat AI like the friend I'm gossiping with while trying to solve a problem. Most of the time, it does a pretty good job.
Developers aren't resources. They're stakeholders.
Some of the best products I've worked on happened because the engineering team believed in what we were building, not because someone asked them to. People do better work when they actually care.
I learn by building.
Reading isn't really my thing. Building is when everything clicks. Most of what I know about AI, GitHub, Vercel, automation, pipelines, even product management, came from making things that probably weren't going to work the first time. If something catches my attention, there's a good chance it'll become a weekend project.
Not all feedback deserves the same weight.
I love criticism. I don't love cynicism (unless we're talking about comedy). Some people challenge ideas because they want the work to improve. Others just enjoy being the smartest person in the room. Learning to tell the difference has been as important as learning to accept feedback.
Say the uncomfortable thing early.
People can usually handle difficult conversations. What they don't handle well is surprises. Whether it's a slipping deadline, a product that isn't working, or an assumption that turned out to be wrong, I'd rather say it early than spend weeks pretending it'll fix itself.
People don't build great products because they're told to.
They build them because they believe they're worth building. One of the things I'm proudest of isn't a launch or a metric. It's when someone tells me, months later, "that was one of my favorite projects to work on." I want people on my team because they believe in what we're building, not because they have to be there. Turns out that's a much stronger reason to row in the same direction.
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.
These aren't superpowers. They're just the things I keep reaching for.
I talk to people.
- Product Discovery
- Stakeholder Interviews
- Workshops
- Facilitation
I bring structure to messy problems.
- Story Mapping
- Prioritization
- Roadmapping
- MVP Definition
I make ideas real.
- AI Prototyping
- AI Workflows
- Prompt Design
- GitHub
- Miro
- Canva
I make sense of data.
- Excel
- SQL
- Power BI
- Tableau
If you've read this far, you've probably noticed something.
I tend to enjoy problems that don't have obvious answers yet. If you've got one, let's talk.