ENTERPRISE PLATFORM LEADERSHIPI build the parts of the system everyone else avoids — the coordination gap, the compliance hole, the migration nobody signed up for.
Ten years in enterprise platforms, another decade before that running restaurants — turns out it's the same job. Systems don't break because of one bad line of code. They break at the seams between teams.
MLIS in information architecture, then a decade making enterprise systems less of a mess — privacy governance from zero, a platform migration through a pandemic and a messy acquisition, an LMS launch that ended in a companywide award.
01/04 WORKThree systems, three kinds of hard
CareGraph
LIVE PROTOTYPEPatients navigating a complex diagnosis become the system holding their own care together — and nothing else is.
Independent, conceptual project — built outside my role at AbbVie. Does not use or reflect any proprietary or confidential information.
-
Something's wrong, and the patient knows it — they just can't explain it yet in a way that lands with a doctor. So they start tracking it themselves: symptoms, timing, what makes it worse. Records pile up across portals that don't talk to each other. Appointments come weeks or months apart. Over time, the patient becomes the system holding their own care together, and nothing is holding it together for them. This isn't rare — a 2024 EURORDIS study found an average 4.7-year gap between symptom onset and confirmed diagnosis for complex conditions. That's not a delay. That's years lived without answers.
-
This isn't a knowledge problem. The information exists — with the patient, in their records, across every clinician they've seen. It's just never structured, connected, or carried forward. What's missing isn't another app to log symptoms in. It's a layer that keeps the story intact and hands it to the next clinician instead of making the patient start over.
-
Used ChatGPT and Claude to pressure-test the idea and run competitive analysis before building anything, then Claude again to turn that into Figma prompts. Validated the prototype with real community input, then built it out with Lovable and Claude — a working, deployed web app on React and Supabase. Focused on the actual friction points: symptom capture that holds up over time instead of getting fuzzier with every retelling, a longitudinal view across visits, and a clinician-ready summary so nobody has to re-explain their whole history at every appointment. Offline-first, voice dictation for the days you can't type. Deliberately not an EHR, not a diagnostic engine, not a replacement for a doctor's judgment — just the coordination layer nobody had built yet.
-
Live, not just a deck. Too early to claim outcome numbers — the app is instrumented from day one to track the thing that actually matters: time to diagnosis, time spent reconstructing history, whether clinicians actually use the summaries. I'd rather tell you what it's built to measure than make up a number that isn't real yet.
-
I inherited this migration after the discovery work was already done — six new components, a full content migration, and authoring, all crammed into about five months, with a hard shutdown date already locked in for the legacy system. Two problems showed up almost immediately. The component scope had been built around what the old platform could do, not the new one. And development wasn't going to finish until the month before go-live, which meant there'd be zero time left to actually author content before the old system went dark.
-
The original scope assumed the new platform needed the same components as the old one — a fair guess during early discovery, but it didn't hold up once I actually got into the new platform and started poking around. Telling people that wasn't well-timed news, and there was no room left to just rework the deadline. So the fix wasn't finding more hours — it was going back to basics. What do users actually need to do here, and what do they hate about doing it? Once that was clear, most of it didn't need six custom-built components — it needed the platform's own tools, used well to address articulated friction points. Templates, curated user groups, things already sitting there.
-
Rebuilt the plan around what the platform could already do instead of what we'd have to build from scratch. Restructured the solution around templates and curated user groups. Shipped it on a timeline that was already tight and got tighter.
-
Adoption beat expectations the moment it launched — up 38% in six months. Business stakeholders and the agency partner were both genuinely happy with it, not just polite about it. That result is what got the next phase funded, and it's what won the team a companywide award. Turns out redefining the problem correctly is faster than brute-forcing the wrong one.
Enterprise Learning Platform
+38% ADOPTION IN 6 MONTHSInherited a platform migration on a timeline that assumed the legacy platform's rules still applied.
Content Supply Chain
37 ENTITIES — 18 MONTHSAn acquisition grew the org from ~20 to 37 unevenly-resourced entities overnight — the workflows didn't scale.
-
An acquisition took us from a tight ~20-property portfolio to 37 entities almost overnight — different staffing, different funding, different levels of process maturity, all now supposedly running the same way. The content workflows we had were still fully manual: shipping physical hard drives, FileZilla transfers, hand-tagging metadata in Adobe Bridge. That barely worked at 20 properties. At 37, it was never going to hold. And then COVID hit at the exact same time, which meant the usual fallback — fly out, sit with a team, sort it out in person — wasn't an option either.
-
The hard part was never the tooling. It was that whatever we built had to work the same way across entities with wildly different levels of readiness, with zero in-person time to smooth over the gaps. That meant I couldn't rely on 37 teams remembering to do things consistently — the standards had to be built into the system itself. Inherited metadata, automated workflows, governance that propagated by design instead of by policing.
-
Stood up an enterprise DAM with automated workflows and inherited metadata, so brand standards and content governance were baked into the system instead of something someone had to remember to check. Migrated all 37 entities over 18 months, fully remote, across North America and Australia, through a pandemic.
-
Full migration, done. Manual, error-prone workflows replaced with governed, automated ones across every single entity. The next year's content planning ran on actual inventory data instead of guesswork — that's the real shift. Not "it got easier," but the org finally knew what it had.
02/04 PROMPTSOn how I prompt
I design prompts the way I design platforms: explicit boundaries before generation, layered context instead of flat instructions, and processes built to be capable of producing a "no" — not just optimized to confirm a "yes."
Most prompting advice treats the AI like an answer machine. I treat it more like a smarter-than-me bff crossed with a governance system: define the roles, define the non-negotiables, define what's explicitly out of scope, then let it generate and layer in something witty in the response.
Pre-Discovery Evaluation
ENGINEER / PM / DESIGNERA three-persona interrogation framework that pressure-tests a proposed change before it becomes a commitment.
You are my team of Principal Product Managers, Engineers, and Designers evaluating [DESCRIBE THE PROPOSED CHANGE — e.g., "a third-party vendor integration," "a platform upgrade," "a net-new feature"].
Our platform/product context: [DESCRIBE YOUR PLATFORM IN 2–3 SENTENCES — e.g., "We run an internal logistics tool used by regional operations teams. It connects to several downstream systems and has hard uptime requirements."]
The outcomes this change is meant to serve: [STATE THE PROBLEM OR OPPORTUNITY. If you don't know yet, say so — that becomes the first thing to pressure-test.]
Our non-negotiables: [LIST 2–4 CONSTRAINTS THAT CANNOT BE TRADED — e.g., "no disruption to active production workflows, no infrastructure debt the platform team can't sustain."]
Ask me one question at a time, rotating through three personas:
🏗️ Engineer (architecture, feasibility, what breaks)
📦 PM (problem validity, scope, go/no-go criteria)
🎨 Designer (real end-user workflow, edge cases, what "good" looks like).
Before each question: name the persona, briefly explain what decision or risk it informs, then ask one specific question — not a list.
Start with the highest-stakes question across all personas — the load-bearing assumption that, if wrong, invalidates the rest. Guide me; I may not know what I don't know. Don't follow a rigid rotation if the conversation reveals a thread that needs pulling.
When I ask, generate a two-part intake log: a five-row working-backwards summary (problem, real end user, outcome claim to validate, definition of "good" at the first checkpoint, explicit out-of-scope) and a running questions log (category, persona, priority, status, owner, notes — flagging blocking vs. clarifying, and any assumption embedded in a question that should be validated first).
Standing instruction: if a question surfaces a risk I haven't asked about, name it and explain why — even outside the current question's scope.
Persistent Product Context
SKILL INSTRUCTIONSA template for standing up durable strategic context for a product — calibrated communication per stakeholder, not a task list.
I want to create a persistent strategic context layer for [YOUR PRODUCT OR PROGRAM].
Help me draft it. Before drafting, ask me:
1. What is the product/program — what it does, who it serves.
2. What's my role — owner, contributor, delivery lead — and what do I explicitly own vs. influence.
3. Who are the key collaborators, and how should communication calibrate for each (strategic narrative for a sponsor, operational precision for a business owner, acceptance-criteria clarity for engineers)?
4. What's the north star and 2–3 outcomes I'm accountable for?
5. What are the current priorities — active sequenced bets, not a wishlist?
6. What are the standing constraints (compliance gates, resource limits, dependencies)?
7. What do I most need AI help with — drafting, tradeoff analysis, stakeholder comms, risk ID?
Once I answer, draft the instructions in outcome-oriented, strategy-first style — not a task menu or delivery SOP. Think with me, challenge weak assumptions, connect every recommendation back to outcomes. Don't write it like a project manager's checklist.
Competitive Landscape & Market Gap
MARKET RESEARCHA market-research prompt explicitly built to challenge a hypothesis, not validate it.
I'm exploring a product concept in [problem space] for [primary users]. T
he core problem I believe exists is: [problem hypothesis].
Act as a senior product strategist helping me challenge that hypothesis, not validate it.
Research the current competitive landscape, including: direct competitors solving substantially the same problem; adjacent solutions solving one part of the problem or serving the same user need differently; substitutes/current behaviors users rely on when no purpose-built solution exists; and platform or incumbent capabilities that could make a standalone product unnecessary.
For each meaningful competitor or solution category, evaluate: primary user and job to be done; what problem it actually solves; core capabilities; business/model positioning where relevant; where it overlaps with my proposed concept; where it meaningfully differs; what it appears to do particularly well; and important limitations or gaps.
Then synthesize the research rather than simply giving me a feature matrix. Specifically tell me:
1. Competitive landscape — how is this market currently structured? Are competitors actually competing for the same job, or solving different pieces of the journey?
2. Market insight — what does the research tell us about the audience, unmet needs, behaviors, and opportunities?
3. Market trends — what technological, regulatory, behavioral, economic, or industry changes are shaping this space?
4. White space — what meaningful user problem, if any, remains poorly solved? Distinguish genuine white space from features competitors simply haven't prioritized.
5. Threat to the thesis — what did you find that most challenges my original product idea? Is someone already solving this well? Is the problem smaller, different, or less defensible than I assumed?
6. Product implication — based on the evidence, should I proceed, reposition, narrow, broaden, or abandon the original concept? Explain why.
Cite original/primary sources wherever possible. Clearly distinguish verified facts from your interpretation. Do not manufacture differentiation just to make my concept appear viable.
Finish with a concise executive synthesis I could use to inform product strategy — not marketing copy.
03/04 IN THEIR WORDSCorroborated, not just claimed
Director, Digital Learning
ANONYMOUS“The platform launched to 5,800 users across six business units with lower-than-expected support volume on day one — a testament to the scale, problem-solving, and agile execution the team delivered under tight timelines...leadership set the table for future expansion and long-term value.”
Sr. Director, CX & Omnichannel Operations
HEIDI RAPACH — INDEGENE“Rina was invaluable to the success of this launch. Her dedication, commitment, and ability to keep momentum high impressed both our team and the client. We couldn't have done it without her leadership.”
Sr. Engineer
TIMOTHY WITTMAN — SLINGTV“Rina is a brilliant and gifted Product Owner who really understands how to get the best out of her team and the business. Rina and I worked together on a large scale billing platform during our time at Dish — this was the backbone of SlingTV's payments. Without Rina, the team wouldn't have been successful integrating both Google and Apple payment methods. Her biggest strength is her ability to deal with conflicting priorities in high-pressure situations. She never loses her cool, which is one of many reasons she stands out.”
04/04 CONTACTTell me what's broken
I'm not chasing headcount or hype. I'm looking for platform and infrastructure problems worth solving, with people who'd rather fix the seam than paper over it. No polished pitch needed — just tell me what's actually going on.