On this page I share a curated selection of product case studies covering some of the main product areas I’ve worked on. This list is not comprehensive, but the stories themselves are highly representative of my work. Though I can’t provide specific details in some cases due to confidentiality, the lessons remain highly illustrative.
Life Sciences: Pharma, Biotech, agrosciences
My current team, Experimental Workflow Solutions, manages and develops products to support life science research. Specifically, these products empower life scientists by saving them valuable time, effort, and materials when designing and validating experimental procedures. Having previously focused on content discoverability, I’ve most recently been leading efforts in developing AI and agentic AI powered co-scientist systems that accelerate experimental design, troubleshooting, and validation.
Building Trusted, Agentic AI Systems for Experimental Design
Problem: By now, most researchers use AI every day but mostly for low-risk work like drafting, summarizing, and synthesizing a research papers. That's genuinely useful, but it isn't the hard part of science. The hard parts are experimental design, lab protocol creation, and troubleshooting failed experiments. And in those tasks, a plausible-sounding answer is worse than no answer at all. The cost of being wrong isn't an awkward annoyance. Being wrong can directly lead to wasted days or weeks, wasted reagents, blown budgets, and potentially entire research studies sent down the wrong path.
My team had already shipped a generative AI co-scientist and field-tested it with real users (see below). That test made one thing obvious: to be genuinely useful for experimental design, we needed far more than a chatbot sitting on top of a document corpus. We needed connected context, life science specific reasoning, and most critically, a way to check an answer before a scientist ever acts on it. So I steered the team back to first principles and asked the unglamorous questions that many AI conversations skip. Where does the context come from? How is it connected? What tools can the system actually call? How is an answer checked, and when do humans need to be in the loop? In scientific workflows, those aren't implementation details. They're the foundation.
Solution: The answer took the shape of a three-layer architecture for created trusted scientific workflows. I'll resist the temptation to lead with the model, because the more of this work I do, the more convinced I am that the model is the least interesting layer. Also, building truly trustworthy systems should, by design, be model independent!
The first layer is a set of MCP servers, a connective tissue that brings fragmented research inputs (research articles, scientific databases, standard operating procedures, protocols, lab tools) into one connected environment. This is what lets the system stop merely generating language and start navigating a structured world of real scientific tools and data.
The second layer is a set of multi-agent systems that use those servers to plan, retrieve relevant evidence, analyze it, and generate outputs across protocol creation, troubleshooting, scientific Q&A, and experimental planning. Agentic AI, it turns out, is far more useful when it operates inside a connected ecosystem than when it sits alone as an isolated assistant. Our agentic system was dubbed ‘EWS’, which stands for Experimental Workflow Solutions.
The third layer, often unfortunately as an afterthought, is an AI evaluation framework. And I want to dwell here, because for scientific AI, trust is not a nice-to-have you bolt on at the end. It's the whole game. The reason is simple: hallucinations that look credible are especially dangerous in life sciences, where a confident-but-wrong protocol can quietly undermine reproducibility and every decision downstream of it. Working with life science subject matter experts, we built an evaluation framework around an "LLM-as-judge" approach paired with domain-specific metrics (17 and counting, e.g., completeness, tone, plausibility), grouped into two dimensions: how good the response is, and how well it's grounded in trusted underlying data. The pipeline is itself agentic: one agent resolves and prepares the evaluation set, another orchestrates response generation and scoring (fetching sequentially, then scoring in parallel), and a third aggregates, normalizes the scores, and returns a clear PASS / PARTIAL / FAIL verdict against a defined threshold.
The design choice I care about most is this: our experts define what "good" means, and the LLM only scales that judgment. Expert human judgement is never replaced. That's how we answer the fair objection about "AI grading AI." Humans stay in control of the definition of quality while the machine just makes applying it consistent and repeatable at scale. A group of life science experts can easily and quickly evaluate a few dozen outputs, but evaluating potentially tens or hundreds of thousands of outputs daily far exceeds human capacity.
None of this is free, and I won't pretend otherwise. Multi-agent systems run slower and burn more tokens than a single model call, and adoption is still slowed by the usual suspects like researchers over- or under-estimating what the tools can do, trust concerns, and a genuinely noisy, overcrowded AI market. Being honest about those trade-offs is part of product leadership, not a distraction from it.
Impact: The most immediate outcome is that this system is now being integrated into the protocols.io platform, extending the co-scientist work into the environment where researchers already build and run their protocols. But the deeper impact is a shift in how we treat quality. In digitized and automated labs, traceability and auditability were always important; with AI in the loop they become more important, not less. Evaluating outputs by whether they're grounded, consistent, and reproducible rather than by how fluent they sound is what earns an AI system the right to sit inside real research workflows.
There's a commercial dimension too, and it's the part I find most exciting as a product leader. Because the architecture is modular, it positions the team not just as a destination product for researchers, but as an integration layer: trusted scientific-workflow intelligence delivered through MCP, agents, and APIs. That opens a different class of opportunities like enterprise integrations, platform licensing, premium AI features, and data and API monetization. The best product work tends to create option value, and a well-designed foundation doesn't only solve today's problem; it expands what we can credibly do next.
I remain an AI realist, but not because I think the technology lacks potential, quite the opposite. The potential is real precisely because experimental design in the life sciences is difficult, consequential, and still underserved. That makes it a far more interesting place to build than yet another generic assistant running on the same public models everyone else can access. In experimental contexts, better answers depend on better context, better tooling, and better validation. Put differently: if we want AI to be useful in research, it has to earn trust the hard way. This project is a deliberate step in that direction.
Zero to Launch: An AI-based Life Science Co-Scientist
Problem: Lab protocols are the unsung heroes the research lab. Protocols contain detailed, step-by-step instructions on how to achieve a specific results (e.g., purify a protein, grow cells, analyze genomics datasets, etc.). These procedures are the foundation of lab research as they ensure reproducibility. Despite this importance, problems with lab protocols and reproducibility abound, hampering research progress. A staggering amount of time, money, materials, and effort are wasted, on reproducibility problems - one study estimated up to $28 billion per year is wasted in preclinical R&D alone (see below). Reproducibility is thus a clear opportunity space where good solutions are desperately needed.
Solution: The scale and complexity of life science reproducibility is enormous. Where does one even start? Leading a product team that builds digital products for life scientists, I approached the problem as a scientist would: from first-principles. We developed a solid understanding of the main problems researchers face, based on extensive quantitative and qualitative research and product analytics. The uncovered insights gave us a sense for what attributes a good solution should have. For example, any solution should comprehensively cover as many subject areas as possible. The solution should also go beyond being a search tool since the most severe user pain points centered around designing and optimizing procedures plus troubleshooting failed experiments. The solution should thus be an extension of what a researcher does when designing and validating experimental results. But how might we build such a solution?
Artificial intelligence.
I’m going to be blunt - I’m an AI realist. I think the absurd levels of AI overhype are really frustrating because the noise just obscures the genuinely transformative opportunities. It’s true that no one needs a generative AI-powered toothbrush. And yet the AI boom, with its ongoing deluge of large language models, vector database solutions, agents, and many other tools, really do offer a solid foundations for a new solution to the abovementioned
Building on our well-established product discovery process, my team ran through multiple rounds of prototype testing, both lo-fi and hi-fi, to access fundamental desirability, feasibility, and commercial viability. Using AI as part of the process was, in fact, a game changer. User interview analyses were done in hours instead of days. Workable, ‘vibe coded’ prototypes let us rapidly our hypotheses. And yet, we never answered all questions had during testing . We therefore resorted to a well-established (and personal favorite) testing method: open beta testing of new platform Methods Muse.
Impact: There were many noteworthy aspects to launching this new AI-powered system. To start, Methods Muse is part of the ‘first wave’ of new Springer Nature products built around generative AI to reach the market. Next, Methods Muse launched as a public beta version, or a field test as I like to call it. My team reached the limit of where smaller scale research and ideation could take us: the only way forward collecting real-world usage data to address key questions around things like usability and performance. Though uncommon in the digital life science space, open beta testing is a fantastic method for gathering usage data at-scale and for keeping a close contact with users. Open beta testing also falls under my general preference for Open Innovation, as detailed at length here.
The results were very encouraging - during the test run we achieved returning user percentages of ~33% and consistently achieved USAT scores ≥ 80%. The insights we gained on things like user prompting, AI evaluation, technical integration were invaluable to understand the value and potential of the Methods Muse solution. For example, we expanded our product development to now cover agentic workflows (e.g., building out MCP servers). We also realized that integrating the Methods Muse capabilities on various platforms would be a tremendous value add. The first (of hopefully many) examples of this integration is with the protocols.io platform.
Despite the fast changing nature of AI-systems, researcher behaviors, and the competitive/collaborative spaces, we can be confident in our ability to quickly build (and utilize) AI-based solutions that are delivering real outcomes instead of riding hype cycles.
materials science: semiconductors, eletronic materials, chemical manufacturing
In my first product management role, I worked on Springer Material, the largest data platform of curated materials science data. Based on the historic Landolt-Börnstein series, the Springer Materials platform evolved to broadly cover major areas of materials science research and development, such as semiconductors, chemical manufacturing, and energy (perovskite) materials. In this section, I one of my most prominent experiences from this time.
Springer Materials Interactive
Problem: SpringerMaterials is well-regarded a compendium of incomparable depth and breadth for materials science data, ranging from mechanical properties of high entropy alloys to semiconductor band gap energies. However, due to outdated workflows, this highly valuable data was ‘trapped’ in the form of PDF documents, drastically hindering machine readability of the data. In an age where (AI-based) computational modeling and simulations are standard approaches in materials science, machine-readable data was desperately needed both to support changing researcher (user) needs and to improve the commercial positioning of the product.
Solution: As the lead product manager, working closely with in-house data scientists and developers, we designed interactive data interfaces that allowed users to both manipulate data on-platform and to the export machine-readable data to their own applications. After analyzing product usage and customer/market data, I determined the interactive datasets should focus on thermophysical properties of organic solution mixtures and then on semiconductor properties.
Impact: The initial rollout was a success. Not only did platform traffic increase by ~10% after solution deployment, but the new functionality moved previously stalled sales negotiations with major prospects. These prospective customers, two major American universities with large materials science research programs, were both converted into now important customers.
A Fabulous Failure
Problem: I had the objective to streamline the experience on the SpringerMaterials homepage. Analyzing platform usage, I determined one feature should be removed: a button leading to a collapsible menu of individual book volumes - books whose original data formed the basis of the platform. My analysis showed that only 3% of homepage visitors clicked the ‘Bookshelf’ button. This observation was corroborated by data that showed searching, rather than browsing, was the user flow to find data. Obviously the ‘Bookshelf’ button could be removed and thus it was.
Unfortunately, removing this button enraged a critical stakeholder: the buyer personas of the product! The backlash to removing the ‘Bookshelf’ button was swift: angry buyers began calling and emailing to voice their fury at removing this button. After being berated for 45 minutes straight by an angry customer, I asked myself: why this backlash over such a little-used feature?
Solution: One of the biggest challenges in B2B product management is the disconnect between the product users and product buyers, who are not the same are rarely interact in many (most?) organizations.
The product buyers for my main customer segment (academic research institutions) needed to justify their purchases to higher ranking budget holders. One of their main arguments was that the SpringerMaterials platform contains huge amounts of data across many materials science areas. This fact was not readily apparent from the clean and simple search bar but it could be more easily visualized with collapsible menus of the bookshelf feature.
The ‘solution’ in this case was then obvious: bring back the ‘Bookshelf’ button but also make it easier to navigate, thus meeting the needs of the economic buyers.
Impact: Reviving the ‘Bookshelf’ feature not only smoothed relations with angry buyers, but also created some good-will with customers. In particular, the responsiveness to listen to buyer needs proved pivotal in retaining key customers at government research labs in North America. To date, this debacle is one of my favorite ‘failure’ stories in my product management career!