SHOKRI FRANCIS
RAOOF
Technical Product Owner / Software Developer
MedCred
Hospital Visitor Credentialing Platform
MedCred was an early-stage healthcare startup building a credentialing platform for hospital visitors and external professionals. The product operated in a regulated, high-trust environment, where clarity, accuracy, and reliability were critical.
Context & Problem
The product was explored in collaboration with Irish healthcare stakeholders, including alignment with HSE environments, which increased the importance of scope clarity, reliability, and conservative demos.
The core challenge was not just building features, but managing the gap between:
- Customer expectations formed during demos
- Evolving product capabilities
- Engineering delivery constraints
Without a clear translation layer, this gap risked overselling unfinished functionality, unclear scope entering engineering, rework caused by misunderstood edge cases, and loss of trust in a sensitive healthcare context.
As with many startups, there was no strict separation between sales, product, operations, and engineering. Live demos to potential buyers often doubled as real-world product validation, and misalignment between what was shown, what was technically feasible, and what was production-ready carried significant risk.
My Role & Responsibilities
I operated at the intersection of customers, founders, and engineers, owning the operational layer that translated real-world usage and technical constraints into clear, actionable product work.
Product-facing responsibilities
- Served as the primary point of contact during product demos and presentations for potential buyers
- Explained both frontend behavior and backend processes to non-technical stakeholders
- Identified points of confusion, friction, and objections during live demos
- Collected and synthesized customer feedback and fed it back into the product team to inform iteration and improvements
Technical operations responsibilities
- Created and triaged engineering tickets across bug fixes, integrations, and customer onboarding/configuration issues
- Defined expected behavior and documented edge cases surfaced during demos and customer interactions
- Acted as a technical sanity check on sales and founder assumptions, clarifying what the product could realistically support
- Pushed back on demos or presentations when functionality was not stable or ready to be shown
- Translated technical constraints and implementation details into language founders and non-technical stakeholders could confidently communicate
While I also contributed as an engineer, my primary value was reducing ambiguity at the boundary between customer needs and engineering delivery, ensuring that work entering development was well-scoped, realistic, and aligned with real-world usage.
Key Decisions & Judgment Calls
Working in an early-stage healthcare startup meant that decisions were often made under uncertainty, with incomplete information and evolving requirements. My role required exercising judgment to balance speed, credibility, and technical reality, particularly in customer-facing situations.
Delaying or pushing back on demos when functionality wasn't ready
Because live demos directly shaped customer expectations, I made the call to delay or push back on presentations when features were unstable, underspecified, or likely to misrepresent the product's actual capabilities.
This was especially important given the regulated healthcare context, where overpromising or showing incomplete functionality could quickly erode trust. Prioritizing credibility over speed helped ensure that what customers saw aligned with what engineering could reliably deliver.
- Example: In one instance, an integration-related workflow was technically functional but relied on incomplete configuration and had several unresolved edge cases that only surfaced during internal testing. Rather than demoing it as "ready," I flagged the risk, advised against presenting it in a live customer setting, and worked with engineering to clarify expected behavior before it was shown externally. This avoided setting unrealistic expectations and prevented follow-up rework driven by customer confusion.
Acting as a technical sanity check on sales and founder assumptions
I regularly reviewed assumptions coming from sales conversations and founder discussions, validating them against the current state of the product and technical constraints.
When expectations drifted beyond what was feasible, I translated those constraints into clear, non-technical language and proposed safer alternatives or phased approaches. This helped prevent misaligned commitments and reduced downstream delivery risk.
Surfacing edge cases early to avoid rework
Many of the most important product issues surfaced during demos and onboarding conversations rather than through formal requirements.
I made a deliberate effort to capture edge cases observed in real usage, define expected behavior clearly, and feed this context into engineering tickets. By addressing these issues early, we reduced ambiguity in development and avoided repeated cycles of rework caused by misunderstood customer workflows.
Choosing conservative scope in a high-trust domain
In a healthcare environment where reliability mattered more than feature breadth, I consistently favored conservative scope over ambitious but unstable functionality.
This meant advocating for clearer behavior definitions, incremental improvements, and stable configurations before expansion. These decisions helped maintain trust with stakeholders and ensured that product progress did not outpace operational readiness.
These judgment calls helped protect product credibility in front of potential buyers, reduce delivery risk for engineering, and create a more reliable feedback loop between customers and the product team. More importantly, they reinforced the importance of operational ownership in a startup environment where formal product processes were still emerging.
Operational Workflow
In the absence of rigid product processes, I helped establish a practical operational workflow that connected customer-facing activity with engineering delivery. The goal was to reduce ambiguity, surface risk early, and ensure that work entering development reflected real-world usage rather than assumptions.
From demo to delivery
Live demos and onboarding conversations were a primary source of insight into how the product was actually being used and understood. During these sessions, I actively observed points of confusion, implicit assumptions made by customers, and edge cases that were not captured in existing requirements. Following each interaction, I translated these observations into concrete follow-up actions, ensuring that customer-facing insights did not remain anecdotal.
Translating feedback into actionable work
Customer feedback and demo observations were distilled into engineering tickets with clearly defined expected behavior, documented edge cases, and contextual background explaining why the work mattered. Tickets covered a mix of bugs, integration issues, and configuration or onboarding gaps. This helped engineers understand not just what needed to be built or fixed, but how it affected real customer workflows.
Scope validation before development
Before work entered active development, I acted as a scope filter, checking that requests were technically feasible, clearly specified, and aligned with what had been shown or promised externally. When scope was unclear or risky, I worked with engineers to refine requirements or with founders to reset expectations. This reduced rework and prevented partially defined features from reaching customers.
Ongoing alignment during delivery
Throughout development, I stayed closely aligned with engineers to answer clarification questions, confirm expected behavior, and validate that implemented solutions matched the original intent. Because I understood both the technical implementation and the customer context, I was able to resolve ambiguities quickly without blocking delivery.
Release and demo readiness
Before features were shown externally or used in demos, I helped assess readiness by considering stability, configuration completeness, and likelihood of customer misunderstanding. If risks remained, I recommended delaying demos or narrowing scope to ensure that what was presented was reliable and defensible in a healthcare setting.
This operational approach reduced ambiguity between customer needs and engineering execution, minimized rework caused by misunderstood requirements, and protected product credibility in front of healthcare stakeholders. It also created a lightweight but effective feedback loop suited to an early-stage startup, where formal product processes were still evolving.
Outcomes & Impact
While MedCred operated in an early-stage startup environment without formal product analytics or large-scale deployment metrics, the operational approach I took had clear qualitative impact across customer interactions, delivery reliability, and internal alignment.
Improved demo credibility and customer trust
By pushing back on unstable or underspecified functionality and ensuring that demos reflected the product's true capabilities, customer-facing interactions became more consistent and defensible. This reduced the risk of misaligned expectations and helped establish trust with stakeholders operating in a regulated healthcare context, where accuracy and reliability were critical.
Reduced rework and clearer engineering scope
Capturing edge cases early and translating real-world usage into well-scoped tickets helped reduce ambiguity for engineering. Engineers received clearer context around expected behavior, integration constraints, and configuration requirements. As a result, work entering development was better defined, reducing avoidable rework caused by misunderstood requirements or incomplete assumptions.
Stronger alignment between founders, sales, and engineering
By acting as a translation layer between technical implementation and non-technical discussions, I helped align founder and sales expectations with delivery reality. This improved internal communication and reduced friction caused by mismatched assumptions about what the product could support at a given point in time.
More reliable onboarding and configuration workflows
Addressing onboarding and configuration gaps surfaced during demos led to smoother initial customer interactions and fewer follow-up issues after first use. These improvements supported more predictable customer experiences, particularly when integrations or environment-specific configurations were involved.
In a healthcare startup where credibility, trust, and operational reliability were essential, these outcomes helped ensure that product progress remained aligned with real-world usage and delivery capacity. They also reinforced the value of operational ownership in environments where formal product processes were still emerging.
What I Learned
Working at MedCred clarified for me how critical operational ownership is in early-stage, regulated products — particularly when formal product processes are still evolving.
Product credibility is fragile and must be protected
In healthcare contexts, even small misalignments between what is shown and what actually works can quickly undermine trust. I learned that saying "not yet" or narrowing scope is often a stronger product decision than pushing forward prematurely. Protecting credibility required resisting short-term pressure and prioritizing accuracy and reliability over speed.
Translation is a core product skill
A significant part of my impact came from translating between different perspectives: customer expectations formed during demos, technical realities understood by engineers, and strategic assumptions held by founders. I learned that product effectiveness often depends less on formal authority and more on the ability to create shared understanding across disciplines.
Real-world usage reveals requirements that specs miss
Many of the most important edge cases and workflow gaps only emerged during live demos and onboarding conversations. This reinforced the importance of grounding product decisions in observed behavior rather than relying solely on theoretical requirements or assumptions.
Technical context improves product judgment
Having a technical background allowed me to assess feasibility, risk, and delivery implications more accurately. It also helped me communicate constraints clearly and early, reducing friction and rework. I learned that technical fluency is a force multiplier for product and operations roles when used to clarify—not dominate—decision-making.
Product and operations are deeply interconnected
At MedCred, product decisions and operational execution were tightly coupled. Poorly scoped decisions immediately created delivery and trust issues, while clear operational workflows enabled faster and safer progress. This experience shaped my interest in Product Owner and Technical Product Operations roles, where bridging strategy and execution is central.
These lessons continue to inform how I approach product work: prioritizing clarity, conservative scope, and real-world validation—especially in environments where trust, regulation, and reliability are non-negotiable.
What I'd Do Differently
This role required stepping into a fast-moving startup environment with limited structure, where learning and decision-making happened in real time. While this accelerated my growth significantly, it also highlighted areas where I would intentionally operate differently with hindsight.
Establish structure earlier in a high-velocity environment
Much of my early impact came from adapting quickly and solving problems as they emerged. However, with experience, I learned that even in fast-moving startups, introducing lightweight structure early can amplify effectiveness. If starting again, I would put earlier emphasis on lightweight documentation of recurring edge cases, shared definitions of "demo-ready" or "deliverable," and clearer handoff points between customer-facing and engineering work. This would have reduced reliance on tacit knowledge while preserving speed.
Be more deliberate about slowing down to protect long-term clarity
Early on, the pace of work required rapid context-switching between demos, tickets, and delivery support. While this helped me learn quickly, it sometimes deferred opportunities to step back and systematize what was being learned. With hindsight, I would more deliberately create space to consolidate learnings from repeated customer interactions, identify patterns earlier, and formalize them into clearer product and operational guidance.
Name the role I was already playing sooner
Operating in the "deep end" meant that responsibilities expanded organically before they were explicitly defined. If starting again, I would more proactively name and align on the product–operations bridge role I was already fulfilling, helping set clearer expectations with founders and engineers and making ownership boundaries more explicit earlier.
This experience taught me how quickly capability can grow when operating close to real users, real constraints, and real consequences. More importantly, it shaped how I now approach product and operational roles: balancing adaptability with intentional structure, and speed with long-term clarity—especially in regulated, high-trust environments.
How This Experience Shapes My Work Today
This role reinforced my interest in product work that sits close to real users, real constraints, and real delivery trade-offs—particularly in regulated or high-trust environments.
The experience also confirmed the value of Product Owner and Technical Product Operations roles, where success depends on translating customer reality into well-scoped, actionable work and ensuring that engineering effort aligns with what can be responsibly delivered. These lessons continue to inform how I work today—especially when protecting product trust, managing scope in ambiguous environments, and designing workflows that connect customer needs with engineering execution.
Operating in a fast-moving healthcare startup required comfort with ambiguity, strong judgment under pressure, and the ability to bridge technical and non-technical perspectives without relying on formal process or authority. Over time, this shaped how I approach product and operational responsibilities: prioritizing clarity over assumptions, credibility over speed, and delivery readiness over theoretical completeness.
Technical Context
MedCred was implemented as a full-stack, web-based healthcare SaaS platform, designed to support multiple user roles and operate reliably in regulated environments.
Backend
Node.js with Express.js (REST-based web application), MongoDB with Mongoose (document database), and Passport.js (local authentication strategy).
Frontend
EJS (server-side templating), jQuery (DOM manipulation and interaction handling), Bootstrap and Material Design for Bootstrap (MDB), and SCSS / Sass for styling.
Key Integrations
AWS S3 for file storage (credentials, avatars), Stripe for payment processing, Nodemailer for transactional email notifications, and Chart.js and DataTables for reporting and data visualization.
Architecture & Deployment
Role-based access model supporting three user types: Cardholder (primary users managing credentials and dashboards), Hospital (healthcare providers managing visitor access and zones), and Admin (system and platform management). Environment-based configuration with MongoDB, deployed via Heroku.
This technical context informed many of the product and operational decisions described above, particularly around demo readiness, scope validation, integrations, and onboarding workflows.