The medication exists. The patient just can't find it.

Medication shortages create a frustrating and often stressful experience for patients. A prescription may be valid. The pharmacy may be nearby. The medication may technically exist in the market. But none of that matters if the patient cannot find a location that actually has it in stock. For patients dealing with high-demand or shortage-affected medications, the process becomes manual: call one pharmacy, wait on hold, call another, repeat, sometimes for hours. MedHound was created through Tech Serving Society, a nonprofit focused on building technology for public benefit, to explore a better way. The project received funding to investigate and prototype a system that could reduce the time and friction involved in locating medication during shortages.

The challenge is not simply that medication shortages exist. It is that availability information is fragmented. The healthcare system contains the information needed to solve much of this problem, but that information is rarely exposed in a way that is useful to the patient. Patients often have no reliable way to know:

• which nearby pharmacies have a medication available
• whether a pharmacy recently ran out
• how recently availability information was updated
• whether other patients are encountering the same shortage
• whether it is worth calling or traveling to a specific location

Product Lead on a funded nonprofit initiative through Tech Serving Society, responsible for product strategy and product design.

1. 1.

   A shared availability layer

   The core idea: help patients identify where shortage-affected medications may be available before they begin calling or traveling from pharmacy to pharmacy. Users search for a medication and view availability information associated with participating or reported pharmacy locations. The product is designed around community-contributed signals rather than assuming perfect real-time inventory data will always exist. Those signals show where a medication was recently found, where it was reported unavailable, how recent the information is, and which locations may be worth contacting first. The goal is not to replace the pharmacy; it is to make the search dramatically more efficient.

2. 2.

   Designing around imperfect data

   Pharmacy inventory is dynamic. A medication can be available at 9:00 AM and gone by noon, so MedHound could not present availability as a permanent fact; the experience had to communicate confidence and recency. That required thinking carefully about how people interpret information: a report from ten minutes ago is different from one from three days ago, a single report is different from several consistent reports, and a confirmed shortage is different from an unknown status. The principle that came out of it: availability data should communicate uncertainty, not hide it.

3. 3.

   Crowdsourcing as infrastructure

   Crowdsourcing wasn't simply a feature here, it was part of the operating model. A patient who successfully finds a medication can help the next patient. A user who discovers that a pharmacy is out of stock can prevent others from wasting the same trip. Over time each contribution improves the usefulness of the network, creating a feedback loop: search, confirm, report, help the next patient. That network effect is what lets MedHound function as a lightweight public information layer around medication shortages.

4. 4.

   Product strategy without a revenue line

   Because MedHound was developed as a nonprofit initiative, the product strategy differed from a traditional commercial startup. The primary success metric was not revenue; it was time saved and friction removed from the healthcare experience. A few minutes saved for one patient may not seem significant, but medication shortages affect large numbers of people. When thousands or millions of patients repeatedly call pharmacies, wait on hold, travel between locations, or contact providers, the cumulative cost becomes enormous. So the product focused on reducing the amount of unnecessary searching required to find medication.

5. 5.

   Turning frustration into an impact model

   One way I approached MedHound was by translating user frustration into economic impact. If a patient spends even an hour trying to locate medication, that time has value. Multiplied across a large population experiencing recurring shortages, the societal cost becomes substantial. Our analysis estimated that reducing medication-search time at scale could represent more than $1 billion in recovered time value. The problem may feel individual when someone is on the phone with pharmacies, but at scale it becomes a systems problem, and MedHound was designed to address that systems-level inefficiency.

6. 6.

   Designing for public benefit

   Because the project came through Tech Serving Society, accessibility and public usefulness were central. The objective was not to create another healthcare product that required users to already understand the healthcare system, so the experience stayed simple around one question: where should I look first? That meant clear medication search, straightforward location results, recent availability information, simple reporting, visible recency, and minimal friction between searching and acting. The complexity belongs behind the product; the user should simply receive a better starting point.

7. 7.

   Balancing mission, feasibility, and trust

   This was neither an internal enterprise tool nor a personal prototype; it was a funded nonprofit initiative with a public-benefit mission, which meant holding five perspectives at once. User need: would the product actually make the medication search easier? Technical feasibility: could useful availability information be collected and maintained reliably? Public trust: how should health-related information be presented responsibly? Sustainability: could the product operate and grow without an expensive infrastructure model? Mission alignment: does the technology meaningfully improve access rather than simply digitize an existing process?

8. 8.

   From concept to live demo

   The project moved beyond research and product strategy into a functioning public demonstration. MedHound is currently available as a live demo, letting users and stakeholders experience the concept directly rather than evaluate it through a presentation. That was an important milestone: it turned a project about medication shortages into something tangible that could be tested, demonstrated, and improved.

• Many of the hardest product problems are coordination problems. The medication may already exist. The pharmacy may already have it. The patient may already have the prescription. The failure happens because the right information doesn't reach the right person at the right time, and technology can create enormous value simply by connecting those pieces more effectively.
• Imperfect information is still worth surfacing, if you're honest about it. Communicating confidence and recency lets people make better decisions with incomplete data instead of creating a false sense of certainty that collapses the moment a pharmacy's stock changes.
• Impact doesn't have to be a revenue line. Product managers should look beyond engagement metrics and conversion funnels when defining impact. Sometimes the most meaningful metric is how much frustration we removed from someone's day.
• A live demo changes the conversation. Once people could use it, the project stopped being a pitch about medication shortages and became something they could test, critique, and improve.