Feasibility & Pricing
— Internal Decision Platform
As product design lead on a zero-to-one initiative, designing the internal platform that lets Sales, Operations, and Research evaluate whether a project is viable and how it should be priced — supporting confident decisions at scale.
Context
Inside the healthcare
research ecosystem.
Pharmaceutical companies rely on research agencies to understand physicians' perspectives on treatments and medical products. These agencies design the studies but depend on specialized platforms to recruit qualified physicians and run surveys.
Research platforms provide the physician panels and survey infrastructure that make these studies possible — generating a continuous flow of projects that must be evaluated for feasibility and pricing before they can be proposed to clients.
Workflow
One request, three teams,
and a wall of spreadsheets.
Each client request required Sales to define scope, Operations to verify physician availability, and Research to estimate survey parameters — before the team could decide if a study was feasible and price the proposal.
That coordination ran on Excel for feasibility math, Salesforce for assembling client-facing quotes, and a chain of internal messages to validate assumptions. It worked at small scale. As volume and complexity grew, it became fragile.
Pain Points
Decisions that were
slow, opaque, and inconsistent.
Critical feasibility and pricing logic were scattered across multiple spreadsheets. Calculations were difficult to review, validate, or explain. Knowledge depended heavily on individual experience — and small input changes could significantly impact the project outcome.
The result: feasibility and pricing decisions were inconsistent and slow, making it hard for teams to respond quickly to client requests.
It was turning scattered logic into a shared, reviewable source of truth.
Strategy
Centralize the logic.
Then guide the decision.
Rather than digitizing the spreadsheets one by one, I framed the platform around a structured decision workflow — moving teams progressively from request definition, through feasibility signals, to pricing configuration and a generated bid.
Each step would build on the previous one, surfacing only what mattered for that decision and exposing the data behind it on demand.
The Workflow
From scattered inputs
to a guided evaluation.
The platform walks users through three modules — define the request, review feasibility signals, and configure pricing. Each step refines the project scope, surfaces a clearer signal, and feeds the next.
A centralized view before the workflow begins
The dashboard gives teams a centralized view of all feasibility requests — status, ownership, and quick navigation. Creating a new request opens a structured input form where users define the project scope before evaluation begins.
Define the project request
Users define the project by entering target audience, geographic scope, survey parameters (LOI, incidence rate), and requested completes. The form surfaces only critical inputs first — advanced configuration stays tucked behind progressive disclosure.
A clipboard import accelerates intake: users paste structured project information and the system auto-populates audience, geography, and survey parameters.
Review feasibility signals
After the request is defined, the platform combines user inputs with panel availability and historical survey performance to evaluate feasibility — letting teams quickly determine whether a project is viable before adjusting pricing or specifications.
Configure pricing & generate the bid
In the final step, teams configure pricing parameters and project specifications. The system generates a structured bid summary that consolidates feasibility signals, recruitment difficulty, incentive assumptions, and expected margins — reviewable, explainable, and ready for the client proposal.
Complex Cases
One workflow.
Many configurations.
As the platform evolved, research requests grew more complex — multiple audiences, regions, and survey configurations within a single project. The same evaluation workflow had to extend cleanly without fragmenting the experience.
The decision path stays consistent — request, feasibility, pricing, bid — even as the underlying configurations multiply.
Outcome
Spreadsheets out. Shared truth in.
Replaced fragmented spreadsheets across three teams with a single, trusted decision platform — now used by 20+ people across Sales, Operations, and Research. Pricing logic that previously lived in individual spreadsheets became visible, reviewable, and explainable.
This is an ongoing engagement: weekly design reviews with three team leads, feedback that prioritizes the next round of improvements, and a ticket-tracked path for issues.
What I Learned
Designing decision-support
is designing for trust.
Designing for complex operational workflows. Feasibility evaluation involves many teams and variables. Structuring the experience around a guided workflow simplified the decision and reduced cognitive load.
Balancing flexibility with clarity. Users needed many parameters, but too many visible controls overwhelmed the interface. Progressive disclosure exposed advanced configuration only when necessary.
Supporting trust in system outputs. Because pricing and feasibility calculations directly impact client proposals, users needed transparency into how results were generated. Drill-down details and clear feasibility signals helped teams understand and trust the system's recommendations.