Product Backlog for an EHR
When I applied to Smart Management to lead their product management group, I was asked to complete the following exercise as part of the hiring process:
You are the product manager at a small software company, and you've just left a meeting with the CEO and the VP of Sales. They want you to start work on putting together requirements for a brand-new piece of software that will be web based and will allow our clients to send and receive protected health information to and from clinical laboratories. The clinical laboratory we're integrating with has an established, well-documented API that sends and accepts messages in the HL7 format.
Each clinic must be able to:
- Collect a sample of blood from a patient, label it with a unique ID, send that ID, the type of sample collected (blood), and the test panels requested (Chem7, CBC, Tox Screen,…) to the laboratory.
- Schedule a pickup of the physical samples.
- Receive the results of the test panels back, flag any positive drug results for individual patients, and display them in the Smart UI.
In order to successfully complete this exercise, you will need to provide Smart with the business logic surrounding the interactions for at least two of the features described above, identify the classes of users and write a brief persona for at least two of them, and provide a set of user stories and/or epics that you think will allow engineering to start the grooming process.
No Smart resources are available to you for this exercise. Only publicly available information can be used to complete this task. The goal of this exercise is NOT to have a set of requirements that Smart can actually use to build a product, but is instead a chance for you to demonstrate your research, analysis, and communication abilities, along with your understanding of the software design process.
In the few days I had for the exercise, I researched Smart Management (especially their products), learned some about the standards and terminology for EHRs, read about how opioid recovery centers work, and researched the problems and complaints with EHRs in general. I wanted to start my pitch by focusing on problems and not just a typical workflow.
I mapped the process in a Trello board, using columns to represent the steps in the workflow. I added roles and a few simple personas. Then I added user stories for each step, assigning each step or task to a role. For a few of the user stories, I added the business logic or acceptance criteria.
After I had enough of the workflow mapped out for the exercise I put together a presentation for the upcoming interview, including:
- problem statements,
- a product brief,
- some examples of better medical interfaces for inspiration,
- the roles and personas,
- a screenshot of and link to the user stories in Trello.
Here's the presentation deck:
The presentation went well, and I got the job.
What I learned
I learned that like most industries, the electronic health record space is (way) more complicated than it might seem. I learned also that it is ripe for improvement, but it does depend on the larger health industry and changes there seem even harder.
As a product manager doing this exercise in such a short timeframe, I learned that I can a good start toward solving a problem in a pressure situation.