Context and problem

Flow cytometry as a method requires highly trained staff and is often performed in specialized laboratories. In a clinical diagnostic context, a specimen arrives, is prepared, gets acquired on an analyzer, gets analyzed in desktop software, and the results are transferred to a laboratory information system. Product plans typically focus on how one product is used in one specific workflow step. To add value with an integrated software ecosystem, the design needed to focus on the outcome rather than the product. Our hypothesis was that laboratories needed to come up with compensating behaviors to build workflows across product boundaries.

Approach

I designed the customer engagement as a repeatable protocol, because I knew from experience that unstructured site visits would not provide us with the detailed information we needed to support product development.

1. Stakeholder interviews before the site visit, to understand the service the lab runs and who does what.
2. One to two days on site. Ideally, a full shift of ethnographic observation, following the work from specimen receipt to reported result and writing down every discrete step, tagging where errors got introduced and where people were waiting.
3. A findings review with the lab.
4. Ongoing touchpoints afterwards, e.g. for future concept testing.

Each site got mapped in two ways: following the individual patient specimen and following the work of each person in the lab. This was summarized as a role swimlane diagram, because the same sample may go through many sets of hands.

Findings

Real-life observation surfaced things that interviews and surveys had not: how user accounts and quality controls were handled day to day, data retention obligations measured in decades, and analysis workflows that spanned multiple screens.

To make the findings usable by people who had not been on the visits, I built a jobs-to-be-done matrix mapping distinct lab roles to what each role was actually trying to accomplish and the problem in their way.

Conclusions

I provided ranked design inputs, each traceable to observations made on site, together with three conclusions:

• While each lab is unique, the tasks and patterns are shared across labs.
• Integrating the flow of information from accessioning through to reporting has the potential to materially improve the workflow.
• Taking a structured generative research approach allowed us to be more targeted in follow-up Voice of Customer qualitative and quantitative studies.

Outcome

The protocol ran four times and produced comparable output each time — journey maps, personas, a jobs-to-be-done matrix and ranked design inputs instead of an unstructured trip report. That set became the design-input basis for a next-generation platform program, which is the subject of the case study on requirements and prototyping.

Artifacts

• Multi-step customer engagement protocol
• Annotated lab floor plans
• Role swimlanes across the end-to-end workflow
• A full day-in-the-life journey map with emotion coding and verbatims
• Jobs-to-be-done matrix across different laboratory roles
• Personas and ranked design inputs

Site names, staff names and customer operational data are withheld. All visuals have been rebuilt from scratch with identifying detail removed.

Context and problem

After the acquisition, the platform's commercial performance did not meet expectations. The root causes identified were feature gaps compared to competing solutions and a lack of strong differentiation. While the platform's roots were academic, its users were split between biopharma and academic research, and the requests coming through support were a poor guide as they showed what existing users wanted next, not what potential customers who had evaluated the software and walked away had needed.

The roadmap I inherited had a similar problem. It was built from what existing customers asked for, and it carried over the commercial approach of the company we had acquired: concentrate on a small number of large accounts with a small sales team. To meet commercial expectations, we needed to sell through our established commercial channels — and with little overlap between those existing accounts and the rest of the portfolio, the segment sat outside our commercial priorities. The inherited roadmap therefore depended on a go-to-market motion we were unlikely to be able to scale globally.

We needed to develop a plan that supported retention of existing customers and acquisition of new customers in alignment with long-term business strategy and priorities.

Approach

I designed the work as three stages building on each other.

Internal workshops first. I ran a cross-functional workshop series that mapped the workflow we expected for research and clinical flow cytometry, and set down the pain points in it along with the solutions we thought might address them. That gave the customer research something specific to test rather than an open-ended conversation.

Qualitative research. Single-blind expert interviews with scientists and lab leaders across biopharma and academia, structured around hypotheses synthesized from the workshop outcomes. Separately, I reanalyzed existing transcripts on whether a cloud-based analysis platform was acceptable in a clinical setting at all and built on this with semi-structured interviews with lab leaders and IT professionals.

Quantitative research. I designed and directed a conjoint analysis using ASEMAP (adaptive self-explication of multi-attribute preferences), run with an external research agency with more than 100 respondents across the US and Europe. It measured how often each workflow step was performed and how important each of twenty-plus candidate benefits was relative to the others. It also segmented the respondents by attitude, which produced three groups of very different size and very different preferences.

I then plotted every candidate benefit on an opportunity map: importance to the market against how well existing products already delivered it. That splits a feature list into three categories that mean different things commercially — cost of entry, potential differentiator, and market development.

Alongside this I led the competitive analysis and supported the intellectual-property work: segmentation and price-performance benchmarking against both instrument vendors and software-only competitors, and an IP landscape review which found the landscape sparse enough that trade secrets plus a small number of targeted filings was a better strategy than broad patenting.

Findings

The most useful finding was structural: the benefits we considered for our roadmap were mostly cost-of-entry items. They were important, and competitors already did them well, but delivering all of them would have consumed the whole roadmap period without providing much differentiation.

The cloud-acceptability interviews identified security and regulatory compliance as the primary adoption barrier in the clinical space. Of note, lab leaders largely deferred to IT on those decisions, and IT's concerns differed markedly from theirs. That informed how we prioritized security investments.

Recommendations

I built the long-term roadmap as three time horizons rather than a feature list, with layers for the problem being solved, the feature that solved it, and the technology it depended on. The resulting three-year roadmap closed the major barriers to entry and left enough room for differentiation to appeal to the customer segment most aligned with the overall company strategy.

I took it through the gate process as a full business case: prioritized product concepts, price-performance positioning, the three-year release roadmap, the IP landscape and strategy, a risk register, staffing against planned accomplishments, and a five-year financial model comparing investment against doing nothing. It won approvals from IP, R&D, Finance and business-unit leadership.

Outcome

The roadmap was funded and delivered. Across the period I owned seventeen releases of the platform, and the release train went from one release in 2020 to six in 2022.

My main takeaway was that the opportunity map was the artifact that changed the conversation. Once every candidate sat in one of three commercial categories, arguments about what to build stopped being arguments about taste.

Artifacts

• Three-stage research design with hypotheses stated in advance
• Relative-importance driver study across the US and Europe
• Opportunity map across twenty-plus candidate benefits
• Attitudinal segmentation of the respondent base
• Competitive and price-performance benchmarking
• IP landscape review and resulting strategy
• Three-horizon roadmap linking problems, features and enabling technology
• Investment gate submission: financial model, risk register, staffing plan

Competitor pricing, absolute financial figures and internal program names are withheld. All visuals rebuilt from scratch.

Context and problem

Requirements management on this program sat with systems engineering, who owned the process and the formal record. My responsibility was what went into that record: functional requirements for a design that would add value for customers, work and cover every use case, be clear enough for the development teams to build, and be acceptable to all stakeholders.

The first difficulty was scale and coverage. The workflow ran from specimen intake through acquisition and analysis to reporting, and included lab operations. On top of that came cross-cutting requirements that every component shares but no single team owns, such as accessibility, internationalization and licensing.

The second difficulty was that the system was new to the world. For an incremental feature, you can observe how customers use the current product, interview them to understand their gaps and challenges, and synthesize what you learn into what should change. For a new-to-the-world system there's no current product to observe. You'd expect a well-written specification to be enough to collect feedback on, but stakeholders and customers couldn't give meaningful input on a document describing something that didn't exist yet. They needed to interact with it before they could form an opinion.

The development teams had a related problem. Multiple independent teams were building the platform, and each needed guidance that a requirements document doesn't carry well on its own: a cohesive UX design, internationalization, accessibility, and which functions to prioritize. Every handover from product to a team is a place where intent gets lost, and with multiple teams it can get lost in different ways. Each team could build its component well, and the lab would still end up with separate products that looked and behaved differently.

That left two risks. One was good requirements with a gap nobody noticed until validation, which in a regulated product is the most expensive place to find it. The other was three components that each met their requirements but didn't feel like one product.

Approach

I wrote the working specification. The official chain of user needs, design inputs and software requirements specifications (SRS) was still being set up, so I wrote the specification the program could work from in the meantime. The usability guide served as the general specification. More than twenty high-level requirements documents covered all functionality, the user's interaction with the system, and the workflows and user flows. These high-level requirements were later translated into the official design inputs and SRS. To manage it all, I broke the solution down into three components, their features and their functions, so that one structure covered the full set of functions. I wrote regulatory-readiness requirements into the first pass: 21 CFR Part 11 requirements such as audit trail, electronic signature and traceability of who did what to which result, as well as accessibility and internationalization. Retrofitting any of these late is the usual and more expensive path.

I built a working traceability framework to bridge the gap. It was an interim framework that product management, the development teams and I could use in the meantime. It summarized the detailed design inputs and system requirements into features and discrete functions, and a validation pipeline checked data integrity and schema compliance on every change. That made gap analysis and coverage reporting possible. At this scale, checking coverage by reading documents would have missed gaps.

I tested the architecture against the clinical workflow. The architect owned the architecture. I evaluated whether it could support the clinical workflows we were specifying, and I designed and ran user research on what labs would accept and what constraints they'd put on it. That gave the architecture discussion evidence from the people who would have to run the system.

I made the system tangible, at the fidelity the tools allowed. The work started before AI coding tools were widely available or as capable as they are now, so fidelity increased over time. I started with wireframes at several levels of detail, moved to PowerPoint-based clickable mockups that stakeholders and customers could walk through, and finally built an interactive, high-fidelity browser-based prototype of eleven connected modules, using AI coding assistance to write the code. Each step gave people something to react to instead of a document they had to imagine, and gave the development teams a shared picture of what they were building together. Clicking through a flow also exposed requirements we hadn't written yet, which reading the documents hadn't.

I gave the development teams a common reference. I grounded the usability guide in the generative research and adopted it across every component, so design decisions were made once instead of being re-argued per component. Together with the requirements and the prototypes, it gave the development teams the same answers on UX, internationalization, accessibility and the priority of different functions.

Findings

The biggest shift came with fidelity. Feedback on documents tended to stay at the level of clarifying questions. Once people could click through a workflow, they told us what they needed it to do, and that held for internal stakeholders and customers alike.

The prototypes also exposed requirements gaps. A sign-off flow can look complete in a requirements document, but clicking through it raises questions such as what happens when the second reviewer disagrees, which fields stay editable after the first signature, or what the operator sees when the instrument's quality control has expired but the run is otherwise valid. In a regulated product these are requirements gaps with regulatory consequences, and the prototypes surfaced them while they were still cheap to fix.

The structure also changed how I could support the development teams. The teams expected answers to come with context, and a plain yes or no wasn't valued much. Because the design inputs, requirements and functions all sat in one structured set of files in VS Code, I could give comprehensive answers quickly and with little extra effort. The same structure helped us find gaps and inconsistencies.

Recommendations

I pushed for two things, and both were adopted. The first was prototypes as a gate before production commitment. This costs time up front, so I'd scale it to the kind of feature: for new-to-the-world functionality it's worth it, while for an incremental change to a familiar workflow a wireframe review is usually enough. The second was regulatory-readiness requirements in the first pass rather than in a later hardening phase. That doesn't have to slow the program down. What matters is knowing which areas are high-confidence, so the teams can start on those while the others are still being hardened.

Outcome

I delivered more than twenty high-level requirements documents on schedule, covering the clinical workflow end to end plus accessibility, internationalization and licensing. The traceability framework summarized design inputs into features and discrete functions with automated validation, and product management and the development teams used it for gap analysis and coverage reporting. The wireframes, clickable mockups and the eleven-module interactive prototype gave stakeholders, customers and the development teams a shared vision of the system. The usability guide was adopted program-wide, and a reusable wireframe and mockup library cut demonstration preparation time across the program.

The platform hadn't shipped when I left, so I can't claim a commercial result. One capability I owned as product owner on the clinical platform was later deployed in the commercial research-use product.

Taken together, the requirements, the framework and the prototypes gave everyone the same picture of a system none of them had seen. With today's AI-assisted tools, the interactive prototype that came last here could be built at the very start, and I'd expect that to bring the most useful customer feedback much earlier in a project like this.

Artifacts

• Working specification and its translation into design inputs and SRS
• Traceability framework with automated schema and integrity validation
• Wireframes at several levels of detail
• PowerPoint-based clickable mockups
• AI-assisted interactive browser-based prototype of eleven connected modules
• Annotated wireframe set covering analysis, reporting and sign-off
• Usability guide adopted program-wide
• Reusable wireframe and mockup library

Program and component names, unreleased product detail and mock clinical content are withheld. All visuals rebuilt from scratch.

Context and problem

The first release I inherited as product manager on the platform was a rewrite of its core illustration editor, the tool users build their figures and reports in. It was the hardest piece of work I've done, and it was the only release we shipped that year. When I later scored my releases with an instrument I designed (described below), it was also the release built with the least structured customer input. I came to see those two facts as connected, and the rest of this work grew out of that connection.

The wider problem was organizational. An agile SaaS product had been acquired into a company whose governance was built for instruments and in-vitro diagnostic devices: waterfall stage gates and a launch process that assumed roughly one launch a year. These work well for the products they were designed for. Applied to a product that needed to ship at least quarterly, they slowed every release down. The company's business system is strong on manufacturing and launch discipline, but it had no tool for continuous customer feedback across the phases of software development.

Approach

I built a product management team around the business. When I hired our first product manager from outside in early summer 2020, I was still an individual contributor and the only software product manager, covering three products: a legacy desktop analysis application, a third-party laboratory middleware and the cloud platform. The organization was splitting product management into technical and commercial roles at the time, so my first hire took on commercial product management for the platform and I kept the legacy products.

The two roles we added later each covered a different kind of work. Around 2022 I added a second product management role, and the person in it took over the legacy products and their sustaining and life-cycle management. In early 2023 we hired a UX researcher from outside, because we were doing a lot of market and user research and needed someone with the skills and the time to focus on it. By then the team ran the customer-insight process and the launch process described below, and I'd moved into a sponsor role.

I got the software business funded through a process that wasn't built for it. I took a three-year roadmap through sequential gate approvals from intellectual property, R&D, Finance and business-unit leadership. The gates required the full submission: prioritized product concepts, competitive and price-performance positioning, an IP landscape review and strategy, a technical roadmap, a risk register, staffing against planned accomplishments, and a multi-year financial model comparing the investment against doing nothing. The second case study covers this in detail. For this one, what matters is that it was the company's first agile SaaS development to clear that governance.

I redesigned the process rather than working around it. The hybrid we arrived at as a team compressed the stage gate's four decision points to two for a feature package, which is what made a quarterly cadence possible at all. Separately, I worked with an advanced-certified practitioner of the company's business system to redesign the enterprise launch framework for an agile cadence. The redesign replaced three week-long cross-functional workshops per release with one go-to-market strategy at roadmap level, a playbook spanning the planned releases, and a lightweight follow-up event per release.

I led a redesign of the pricing model. Per-seat licensing limited adoption and encouraged account sharing, which reduced the value users got from capabilities such as data management, and it left little room to upsell. We defined three tiers built around the value each delivered to a different use case, and ran a hands-on simulation to confirm that the ordering and billing systems could support the new model. Turnover on the commercial side meant it was never fully implemented.

I built the missing customer-insight capability. I designed a phase-gated framework covering each step from problem definition through concept development and prioritization to validated acceptance criteria. For each phase it named the question being answered and the deliverable required. Discovery ran at two levels: once for the roadmap as a whole, and again for each feature package. At package level, the questions depended on the type of work, because a new feature needs much deeper customer research than an improvement to an existing one or a piece of sustaining work. The framework also included a bottom-up model of the effort and cost of each research activity. I explained the approach publicly in a short video for the Cytobank Learning Center (archived copy).

Outcome

We shipped seventeen releases between 2020 and 2024, and the release train went from one release in 2020 to six in 2022. Over the first two years of those releases, the work existing users did on the platform more than doubled. The customer-insight process grew from ad hoc practice into a formal process, and when I wrote it up it was treated internally as a reference for integrating customer needs and for sizing a process to fit a project. The launch framework was rebuilt for an agile cadence. On the technology side, the team delivered a GPU-accelerated dimensionality reduction suite, a new-to-the-world statistical analysis capability, and a validated machine-learning automatic gating capability. The gating capability won the company's Excellence in Innovation Award, and I presented it publicly at a clinical cytometry conference. For its launch I did the analysis for the application note and whitepaper, wrote and designed both, took them through regulatory review, and presented the four tutorial videos on the Learning Center page (archived copy).

When I moved into R&D in 2024, the product managers stayed with the business unit, and the UX researcher stayed with me as a direct report through 2026.

Taken together, the work gave the software business a way to ship, a way to learn from its customers, and technology to build on once the company's attention could come back to it.

Artifacts

• Phase-gated customer-insight framework, deliverable named per phase
• Research-approach matching rule, by innovation level
• Customer-insight scoring instrument and process-maturity assessment
• Bottom-up effort model per research activity
• Process maps: stage-gate governance, and the hybrid that replaced it
• Frequency–frustration matrix of organizational challenges, from coded interviews
• Release cadence analysis, 2019–2024
• Go-to-market playbook spanning planned releases

Interview transcripts, internal cost figures, absolute commercial data and internal program names are withheld.