Password: abc#
Dates:
Apr 2017 – July 2017
Skills:
Product management
Writing user stories
Short-term and long-term roadmap
Personas & user story mapping
SWOT analysis
Wireframing
Software:
JIRA
Axure RP
Adobe Photoshop
Adobe Illustrator
WebEx
Collaborators:
Pi2 Product Management Team
User Experience Design Team at ProQuest
Pi2 Development Team
Pi2 Project Management
Progress:
100%
Overview
I worked on the ProQuest Pi2 team, which includes two drug-safety products: PinPoint and Drug Safety Triager.
PinPoint is a product literature database for managing and tracking relevant literature for medical affairs, compliance, clinical development, marketing, regulatory affairs, and competitive intelligence.
Drug Safety Triager is a pharmacovigilance literature-monitoring database that facilitates the detection of adverse event information.
ProQuest acquired Pi2 from Thompson Reuters because of its vertical integration with ProQuest Dialog. Dialog is a global content and information database, for which ProQuest also markets and sells subscriptions. Pi2’s clients include the world’s top pharmaceutical companies.
Role
I was both a product manager and a user experience designer and researcher. ProQuest recruited me specifically for my experience in creating wireframes and translating them into detailed user stories. In addition, I prioritized the backlog and worked with clients to collect requirements.
On the Pi2 team, I worked on fulfilling our statements of work (SOW) for clients. Items in the SOW included the environment setup and configuration, client data migration, scheduling alerts, importer configuration, configuring of full text access, IP authentication, UI branding, and documentation.
My team consisted of 3 software developers, 1 software lead, 1 quality analyst, 1 project manager, and 1 Dialog product manager. We worked incrementally in an iterative agile/scrum fashion on a weekly development cadence. I jointly led daily stand-ups and grooming sessions with the software lead and the Dialog product manager.
Much of our collaboration was over WebEx since the team members were distributed across the globe, in Ann Arbor, New York, and London.
We partitioned the work along approximate lines of domain expertise. I led the front-end efforts, the software lead led the back-end efforts, and the Dialog product manager led the data-ingestion efforts.
Both the Dialog product manager and I reported to the director of product management for Pi2. In addition, I reported to the director of user experience as my functional supervisor.
Conducting a SWOT analysis
SWOT (strengths, weakness, opportunities, and threats) is a strategic planning technique used to help organizations identify strengths, weaknesses, opportunities, and threats related to their business competition or project planning.
As part of my onboarding process, the director of product management asked me to reach out to the members of the Pi2 team to introduce myself and get to know them.
I structured my conversations as SWOT interviews, which helped me to adroitly navigate the ins and outs of the team, identify the strategic opportunities and dead-ends, and understand the immediate actions to take to contribute to the team’s success.
I analyzed the interviews by coding and anonymizing snippets from the interviews, printing and cutting out the snippets, mixing up the snippets to randomize them, and rebuilding the snippets into themes.
The director of product management said that the SWOT interviews were an “outstanding” idea.
Findings of the SWOT analysis
The SWOT interviews revealed a number of insights, which helped me hit the ground running:
| Finding | Recommendation |
| Members were constrained by the realities of working on legacy software developed in 2000. One member stated, “In order to change the color of text, we need to change [the code] in five different places.”
Members were concerned about the quality of the end product that we were delivering to customers. Two members stated, “We were not conducting regression testing.” Another member stated, “If we fixed one thing, it broke another.” |
Given the constraints of working with legacy software, make light/conservative, incremental fixes. Make changes that are not likely to break other parts of the application, and do not introduce new complexities that the team is not ready to cope with. |
| Members felt that the Product Management Team “wasn’t there for them” and that some user stories were inadequate and lacked important details. One member said, “[User stories] should be longer than one sentence.”
Members wanted someone who could be a proxy for the customer by understanding their workflows and do product management work seamlessly on both the Drug Safety Triager and PinPoint teams. |
Conduct user research to better understand the work practices of both Drug Safety Triager and PinPoint users. Be available to answer developer questions and to address uncertainties and ambiguities about the workflow.
Create detailed user stories with wireframes, and spell out the necessary spec details so developers can complete their work independently. |
| Members felt that the leadership should put more effort into creating a redesigned application. The team was putting their efforts into a product that was outdated and difficult to service, maintain, and scale.
Developers were anxious that they were not developing marketable skills by working with outdated technology. Some team members wanted more responsibilities and a promotion. |
Prepare a long-term roadmap to: (1) better align our goals with senior leaders and motivate them to dedicate resources for a redesigned application, (2) differentiate which efforts belong in the short-term versus long-term roadmaps, (3) motivate developers with an opportunity to work on cutting-edge software, and (4) understand the lead time necessary for software architects to design and code the core of a new application.
Use modern Web technologies for the redesigned application, such as HTML5, CSS3, and JavaScript and frameworks such as Angular, Vue, or React. Give team members opportunities to learn and grow. |
Personas and user story mapping
A persona describes the end users, their motivation, and their goals when using the application.
As a follow-up, a user story map details the steps a persona takes to complete a task.
Being unfamiliar with the work practices of PinPoint users, I worked with leaders from both the User Experience and Product Management Teams to construct a user story map. On sticky notes, we mapped out each step a persona would have to take to accomplish a task.
The two key personas we identified were those of the research scientist and the information professional.
Their key workflows included searching, refining searches, creating alerts, saving searches, creating reports, and graphing data.
Short-term vs. long-term road map
Our short-term mission was unmistakably to fulfill our SOW. Working with current customers is how we pay the bills.
Over the long term, it became clear that the legacy application could only take us so far. We could only profitably work on limited enhancements and bug fixes without getting ourselves into complexities that were not worth dealing with. Any effort we put into the legacy application was unlikely to accrue profits.
However, a new application could help us maximize profits by introducing new functions and features, which we could sell for more. With an updated look and feel, the redesigned application would be easier to market and be less expensive to service, maintain, and scale.
Therefore, I created a parallel set of redesigned wireframes, which acted as our long-term roadmap. The wireframes helped to align our goals with stakeholders and maintain our strategic direction by differentiating between which efforts belonged in the short-term versus long-term road maps.
Writing user stories
As a product manager, my two key responsibilities were to write and prioritize user stories.
A user story consists of a “why” statement and a list of detailed acceptance criteria (AC).
The “why” statement explains, from the end user’s point of view, why the members of the Product Management Team wrote the user story. Explaining “why” is a form of respect: it gives the developers clarity and involves them in the problem-solving in case there is any ambiguity. The developers may also have ideas, which they can communicate back to the Product Management Team.
The second part of a user story is its AC, which are a set of accepted conditions and testable statements that developers and the quality analyst use to execute their responsibilities.
A lack of necessary detail in a user story will inevitable slow down work and cause unnecessary tension, by the user story being kicked back to the product management team.
Call-out to Drug Safety Triager
I consulted on a popup feature with which users can add drugs to a list of pre-existing drugs. As the wireframer, writer, and groomer of the user story, I saw firsthand how miscommunication and lack of detail in a user story could potentially contribute to problems on a team.
In addition, when pressing “Add Drugs,” a user could press “Cancel” to undo any changes a user made in the popup. While I had spelled out what happens if a user presses “Add Drugs,” I failed to specify how the popup would behave if a user pushed “Cancel.”
While the developer had technically completed the user story, it did not meet my intended vision. Upon getting the complete code in testing, the quality analyst spotted the problem and brought this oversight to my attention. We worked one-on-one over WebEx to fill in the gaps and return the user story back into the backlog, where it could be worked on again by the same developer.
Grooming sessions
During my onboarding process, I observed how other product managers and scrum masters at ProQuest led stand-up and grooming sessions. Grooming sessions are for writing, modifying, and deleting user stories. During the grooming sessions, I shared my JIRA screen with the software lead, the Dialog product manager, the QA analyst, and the project manager so that they could provide useful feedback. Our goal was to provide sufficient detail such that developers can work independently without stopping. Once a user story was groomed, we would place it into the backlog, where it could be picked up by developers, who would then mark it “in process” in JIRA. Once the developer was done, quality analysts compared the AC against the developer’s work to determine whether they all were satisfactorily completed and reached our definition of being done.
Pre-grooming user stories
While grooming sessions are for writing, modifying, and deleting stories, one person can sometimes do a better job than many. As a domain expert on the front-end, I was responsible for creating wireframes and spelling out their spec details. In order to make the best use of everyone’s time, I wrote and pre-groomed some stories in advance to avoid using up everyone’s time. I also made a list of any questions that the team might want to address.
Daily stand-ups
Daily stand-ups are an opportunity for the team to share updates and ask for assistance. For example, a software developer in New York was struggling with CSS, so I introduced him to a senior software architect in Ann Arbor, who assisted him in solving his problem. Given that the team was distributed globally, we conducted stand-ups over WebEx. Each session typically lasted 15–30 minutes.
