When pharmacists say they want to work in healthcare technology, the ambition often sounds much clearer than the path. Does working in tech mean learning how to code? Becoming a data scientist? Going back to school for computer science? Or leaving pharmacy behind entirely?
A current Optum job posting offers a much more concrete answer. On November 9, Optum posted a remote Pharmacist Product Owner, Clinical Products and Technology position. The role requires a PharmD or Bachelor of Science in Pharmacy, an active pharmacist license, and experience across pharmacy, healthcare, product development, or clinical technology. The listed salary range is $91,700 to $163,700.
What makes the position especially interesting is the work itself. The pharmacist helps own product vision, roadmaps, feature priorities, clinical workflows, user stories, acceptance criteria, and business requirements. They work across engineering, architecture, data, quality assurance, clinical operations, and business leadership. In practical terms, the pharmacist’s job is to take a healthcare problem and help translate it into something a technology team can actually build.
The pharmacist is not being hired to write the software. They are being hired to help determine what the software needs to do.
Healthcare technology still needs people who understand healthcare
Imagine an engineering team building a medication-management platform. The engineers may know exactly how to build APIs, connect databases, design system architecture, automate workflows, and scale the application. What they may not know is what happens when a prescription enters the healthcare system, which information a pharmacist actually needs, how formulary rules affect coverage, where medication errors tend to occur, or which workflow changes could create risk.
Those are not purely technical questions. They are healthcare questions, and they often require someone who understands medication use in the real world.
Optum’s posting describes the Pharmacist Product Owner as a bridge between clinical, business, product, and technology teams. That person translates healthcare problems and clinical requirements into instructions that an Agile software-development team can execute.
That translation is the heart of the job. The pharmacist understands one world, while the engineers understand another. The product owner helps the two sides build something useful together.
Product ownership is more than suggesting features
It would be easy to imagine a role like this as a pharmacist joining meetings and occasionally telling developers what pharmacy teams need. In reality, product ownership carries much more responsibility.
In Scrum, the Product Owner is accountable for maximizing the value created by the product and for managing the Product Backlog. That includes defining product goals, prioritizing features, communicating requirements clearly, and helping the team understand what matters most.
Optum’s job description reflects that level of ownership. The pharmacist is expected to help define product vision, manage the roadmap, prioritize features, evaluate requests, establish measures of success, and balance clinical value with business priorities, technical feasibility, risk, and dependencies.
That means the product owner has to make choices. A clinical team may want one feature, operations may need another, and engineering may say a third project has to happen first because of technical dependencies. The product owner helps determine what gets built, in what order, and why.
A pharmacist can be especially valuable in those decisions because medication workflows are difficult to prioritize correctly if nobody involved understands how those workflows affect patients and pharmacy teams.
This is what domain expertise looks like inside technology
Pharmacists often underestimate the value of knowing how healthcare actually works.
Consider how much invisible knowledge exists inside a normal pharmacy workflow. A pharmacist understands how prescriptions move through healthcare, how benefit design affects medication access, where claims can fail, how prior authorization creates delays, when medication-safety alerts matter, and how apparently simple workflow changes can create unintended consequences.
That knowledge is domain expertise.
Optum specifically asks this Product Owner to apply pharmacist knowledge to make sure products support safe, clinically appropriate, and efficient workflows. The posting references areas such as medication management, clinical decision support, adherence, medication safety, and pharmacy programs where pharmacist expertise can influence how products are designed.
The PharmD therefore becomes useful for a reason that has little to do with dispensing. The pharmacist understands the environment the technology is being built for.
Clinical problems have to become technical instructions
One of the most revealing parts of the Optum posting is its emphasis on business-to-technology translation.
A healthcare professional may describe a problem by saying, “We need to make it easier for pharmacists to identify patients who are overdue for an intervention.” That statement makes sense clinically, but an engineering team needs much more detail before it can build anything.
The team has to know which patients qualify, which data determine eligibility, how often the system should check, what happens if information is missing, where the alert should appear, who sees it, what happens after an intervention occurs, and how the system knows the problem has been resolved.
The Product Owner helps turn that original clinical problem into features, user stories, acceptance criteria, business rules, and functional requirements that a technical team can use. Optum specifically expects the pharmacist to work with engineers, architects, analysts, data teams, and QA to make sure those requirements are clear enough to build and test.
That is where clinical knowledge becomes product development.
User stories force the team to think about the person using the product
One of the bridge skills Optum wants is the ability to write user stories.
In Agile product development, a user story is a short description of desired functionality from the user’s perspective. Acceptance criteria then define the conditions that need to be met before the team can say the feature works as intended.
Imagine a pharmacy technology team trying to help clinical pharmacists identify patients who may need adherence outreach. A basic user story might say that a clinical pharmacist needs to quickly identify patients who meet defined adherence criteria so outreach can be prioritized.
From there, the team still has to decide what defines the patient population, which claims count, what date range matters, how exclusions should work, and what the interface should display.
The pharmacist’s value appears because they can recognize when an apparently logical technical rule would produce a clinically meaningless result. That can help the engineering team avoid building the wrong feature.
The pharmacist does not need to become an engineer, but technical fluency matters
Optum does not expect the pharmacist to become a software developer. However, the posting makes clear that the Product Owner needs enough technical fluency to work effectively with technical teams.
The role involves understanding how workflows interact with APIs, data sources, business rules, applications, integrations, and downstream systems. Familiarity with tools and platforms such as Jira, Azure DevOps, Confluence, cloud environments, databases, and data pipelines appears among the preferred qualifications.
This is an important career lesson for pharmacists interested in health technology. You may not need to write an API, but you should understand what one does. You may not need to build a database, but you should understand that the information displayed on a screen comes from somewhere and follows defined rules.
Technical fluency allows clinical expertise to travel further.
Knowing the workflow can prevent bad technology decisions
Healthcare technology can create problems when a team underestimates how one change affects everything around it.
Suppose a product team wants to reduce the number of medication alerts pharmacists receive. That sounds useful because alert fatigue is a legitimate problem. However, removing alerts without understanding which ones matter could create new risks.
A pharmacist might immediately ask which alerts are disappearing, whether some are uncommon but high-risk, and whether the system has another way to catch the same problem. The solution may involve removing certain alerts for one population while preserving them for another.
Optum expects the Product Owner to identify workflow impacts, dependencies, gaps, and edge cases before development begins. The role also considers patient safety, privacy, compliance, and regulatory requirements throughout product development.
That is another form of PharmD value. The pharmacist can see consequences that may not be obvious in a technical specification.
Product owners define the problem, while engineers determine how to build the solution
The title can make it sound as if the pharmacist is telling engineers how to code. That is not the role.
Engineers bring the technical expertise. The Product Owner brings clarity around the problem, user, priorities, requirements, and intended outcome.
A pharmacist may say that a system must prevent a certain clinical scenario from moving forward without pharmacist review. The engineers determine the best technical architecture for making that happen. The Product Owner then works with the team to determine whether the finished functionality actually solves the original problem.
That distinction should make health technology feel more accessible to pharmacists.
You do not need to know how to perform every engineer’s job. You need to become very good at understanding the healthcare problem and translating it into something the technical team can solve.
Someone also has to decide whether the technology actually works
Building the feature is only part of the process.
Optum requires experience with user acceptance testing, commonly called UAT. The Product Owner reviews completed functionality and helps determine whether a feature satisfies its acceptance criteria and is ready for release.
This is another place where pharmacists can contribute.
A feature may technically function but still fail inside a real pharmacy workflow. Perhaps it takes seven clicks to complete something that happens hundreds of times each day. Maybe the system works in the normal scenario but breaks when a prescription is reversed. The medication name may display correctly, but the user actually needs strength and dosage form before the information is useful.
Testing helps reveal the difference between software that works technically and software that works operationally.
Product ownership also requires deciding what not to build
Healthcare organizations can generate endless technology requests. Every department has a problem, every client has a feature request, and engineering capacity remains limited.
Optum asks the Product Owner to continuously prioritize the backlog while balancing clinical value, business value, technical complexity, risk, strategic alignment, dependencies, and timelines.
That means the pharmacist needs business judgment in addition to clinical judgment.
One feature may help a small number of users. Another could save thousands of pharmacy employees several minutes each day. A third might create substantial business value but require months of engineering work.
The Product Owner has to compare those opportunities and decide what deserves limited resources.
That is far removed from traditional pharmacy practice, yet the pharmacist’s understanding of healthcare still influences the decision.
This is one way pharmacists move from using technology to shaping it
Most pharmacists experience healthcare technology from the receiving end.
A new system launches, a workflow changes, an alert appears, or a button moves. Pharmacy teams then adjust to decisions that were made somewhere upstream.
A Product Owner sits much closer to those upstream decisions.
Instead of learning the workflow after someone else designed it, the pharmacist helps shape the workflow while the product is being built.
That creates a completely different relationship with technology. Pharmacy experience stops being something the software acts upon and becomes an input into the software itself.
Health tech is much larger than software engineering
This is why pharmacists should be careful when they say, “I want to work in tech.”
Technology is an industry, not one job.
Product ownership is one function inside that industry, but pharmacists can also work in clinical product management, business analysis, implementation, healthcare technology consulting, clinical informatics, product analysis, product operations, customer success, solutions consulting, and other roles that sit between healthcare and technology.
A pharmacist trying to move toward formal product work may first enter through one of those adjacent functions. A clinical business analyst could gain experience gathering requirements and mapping workflows. An implementation pharmacist might learn how technology changes real operations. A clinical informatics pharmacist can build experience at the intersection of medication systems and technology. Product analysts or product operations roles may offer exposure to testing, metrics, prioritization, and cross-functional product work.
The function matters more than the title.
The better career question is not simply, “How do I get into tech?” It is, “Which function inside healthcare technology matches the way I want to use my clinical knowledge?”
The job description gives pharmacists a concrete skill map
The Optum position provides an unusually clear roadmap for someone interested in product work.
Across the posting, the same capabilities appear repeatedly: Agile, Scrum, product backlogs, user stories, acceptance criteria, requirements gathering, user acceptance testing, workflow mapping, roadmaps, prioritization, technical communication, and cross-functional collaboration.
That turns a vague career goal into something much more actionable.
A pharmacist no longer has to say, “I want to work in technology, but I do not know what to learn.”
The market is already showing the skills it values.
The next step is building them intentionally.
You can begin learning product thinking before you have a product title
A pharmacist does not need to wait until someone gives them the title Product Owner to understand how product teams work.
Start with the basic language of Agile and Scrum. Learn what a backlog is and how teams prioritize it. Understand the difference between a feature, an epic, and a user story. Practice writing acceptance criteria and learn how product teams conduct sprint planning, backlog refinement, reviews, and retrospectives.
The official Scrum Guide defines the Product Owner as accountable for maximizing product value and effectively managing the Product Backlog. That includes defining the product goal, creating and communicating backlog items, ordering priorities, and making sure the backlog remains understandable.
Then begin applying that thinking to pharmacy problems you already understand.
Choose one workflow that frustrates you. Instead of immediately proposing a solution, identify the user, the problem, the current process, where it fails, and what a better outcome would look like. From there, write a basic user story and think through what would have to be true before you could say the problem was actually solved.
That exercise begins developing product thinking without requiring you to write a single line of code.
Your current pharmacy experience may already contain pieces of product work
Pharmacists interested in technology should also examine their existing experience more carefully.
Perhaps you participated in a pharmacy software rollout, tested a new workflow, worked on a pilot, reported bugs, suggested system changes, helped implement a clinical program, or explained a pharmacy requirement to an IT team.
Maybe you helped create a standard operating procedure after a technology change or validated whether a new tool worked before launch.
Those experiences are not automatically equivalent to formal product-management experience, but they may contain parts of the product lifecycle.
The opportunity is learning how to describe them in the language product teams use. A system rollout may involve implementation. Testing could become UAT experience. Explaining pharmacy needs to IT may involve requirements gathering. Helping redesign a workflow may demonstrate process mapping and stakeholder communication.
That translation matters when trying to move into an adjacent career.
This Optum role is still a destination, not an entry-level jump
The PharmD requirement is exciting, but the rest of the job description matters just as much.
Optum asks for at least five years of experience across pharmacy, healthcare, clinical technology, product management, product ownership, or related work. More importantly, candidates need experience serving as a Product Owner, Product Manager, Clinical Product Lead, Business Product Owner, or similar role. The company also wants hands-on experience with Agile/Scrum teams, user acceptance testing, backlog prioritization, and translating business needs into user stories and requirements.
That makes this a destination role rather than a direct jump from traditional pharmacy practice.
That distinction is useful.
A destination role shows you what the market rewards when clinical expertise and product expertise come together. The goal is to work backward and identify the experiences that help someone reach it.
For some pharmacists, the first bridge could be clinical informatics. For others, it may be implementation, clinical business analysis, product support, or a pharmacy technology project inside their current organization.
The exact title matters less than getting closer to product work.
Certifications can teach the vocabulary, but experience still matters more
Optum lists certifications such as Certified Scrum Product Owner, Professional Scrum Product Owner, and SAFe Product Owner/Product Manager among its preferred qualifications.
Those credentials can help pharmacists understand how product teams operate and give structure to learning.
They are not substitutes for experience.
Someone can complete a product-owner course and still have no experience prioritizing competing stakeholder requests, testing features, working through an Agile sprint, or translating a messy healthcare problem into requirements.
The strongest path combines the framework with opportunities to use it.
AI may make clinical product expertise even more valuable
Optum also lists experience with AI, automation, analytics, and clinical decision support among its preferred qualifications.
That could make pharmacist product expertise even more important over time.
Healthcare organizations are going to build more AI. The difficult question will increasingly become what those AI systems should actually do.
Should an algorithm automatically act, or should it recommend something for pharmacist review? Which clinical data should influence the recommendation? What happens when the model and pharmacist disagree? Which errors would be most dangerous? How much explanation does the user need before trusting the output?
Those questions cannot be answered by engineering alone.
They require clinical, operational, compliance, product, and technical perspectives working together.
A pharmacist who understands both healthcare and product development can help connect those perspectives.
The PharmD can become an input into product strategy
Pharmacists are trained to think deeply about medications, but medication use increasingly happens inside systems. Claims platforms determine whether prescriptions are paid. Electronic health records organize clinical information. Prior authorization platforms influence access. Decision-support tools affect clinical workflows. Patient apps, adherence systems, specialty-pharmacy platforms, automation, and AI increasingly shape what happens before and after a medication reaches the patient.
Someone designs each of those systems.
Someone decides what information the user sees, which workflows get automated, when a pharmacist should be interrupted, what business rules the software follows, and how success gets measured.
Those decisions affect pharmacy practice every day.
There is no reason pharmacists should only encounter them after the technology has already been built.
Search for the function, not just “pharmacist tech jobs”
If healthcare technology interests you, start searching differently.
Look for titles such as Product Owner Healthcare, Clinical Product Manager, Clinical Product Lead, Pharmacy Product Manager, Clinical Product Specialist, Clinical Business Analyst, Implementation Pharmacist, or Clinical Informatics Pharmacist.
Then open several job descriptions and look for repeated requirements.
You will likely see skills such as Agile, user stories, workflow mapping, UAT, requirements gathering, roadmaps, data interpretation, APIs, Jira, and stakeholder management.
Those repeated skills become your roadmap.
You can then ask which ones you already have, which ones you can develop inside your current role, and which ones may require a bridge position.
That is much more useful than simply saying, “I want to work in tech.”
The pharmacist does not have to leave pharmacy behind to enter technology
This may be the most important lesson inside the Optum posting.
The company is not hiring a generic product professional who happens to work in healthcare.
It is specifically looking for a pharmacist who can operate like a product owner.
The pharmacy knowledge is part of the value.
The pharmacist understands how medications move through healthcare, where workflows break, which risks matter, and what pharmacy teams actually need. Then they add another skill set around product strategy, Agile development, requirements, testing, prioritization, and technical communication.
That combination creates an entirely different career.
Instead of simply using the healthcare technology someone else built, the pharmacist can help decide what gets built in the first place.
Your PharmD does not only qualify you to practice inside the pharmacy system.
It can also become the domain expertise that helps build the systems pharmacy operates inside.
Resources & Citations
- UnitedHealth Group / Optum. “Pharmacist Product Owner, Clinical Products and Technology – Remote.” Posted November 9, 2026. Requisition 2391898. The role is remote within the United States and requires a PharmD or BS Pharmacy degree, an active pharmacist license, product ownership experience, Agile/Scrum experience, user acceptance testing, and demonstrated ability to translate clinical needs into user stories, acceptance criteria, and technical requirements. The listed annual salary range is $91,700 to $163,700. (careers.unitedhealthgroup.com)
- UnitedHealth Group Careers. Current OptumRx Clinical openings. UnitedHealth Group’s live job search continues to list Pharmacist Product Owner, Clinical Products and Technology among its remote OptumRx Clinical opportunities. (careers.unitedhealthgroup.com)
- OpenNash Jobs. “Pharmacist Product Owner, Clinical Products and Technology.” Current mirror of the UnitedHealth Group posting, originally posted November 9, 2026. The listing details the product vision, roadmap, backlog, business-to-technology translation, Agile leadership, clinical workflow, and cross-functional responsibilities of the position. (jobs.opennash.com)
- Schwaber K, Sutherland J. “The Scrum Guide.” Current official version, November 2020. The guide defines the Product Owner as accountable for maximizing product value and managing the Product Backlog, including developing the Product Goal, communicating backlog items, ordering priorities, and maintaining backlog transparency. (scrumguides.org)
- Atlassian. “User Stories With Examples and a Template.” Current Agile product-development guidance. Atlassian describes user stories as functionality expressed from the user’s perspective and explains how acceptance criteria establish the conditions required for the feature to be considered successful. (atlassian.com)