pWin
pWin.ai
Home01 Work02 About03 Contact04 Resume05 ↗ Let’s Connect
0 → 1 · AI-native SaaS GovCon · Federal proposals End-to-end UX

The AI copilot that drafts winning federal proposals.

I led the end-to-end UX for pWin.ai, defining how government-contracting teams move from a 24-month capture pursuit to a compliant, evaluator-ready draft, with AI they can actually trust. I took it from an incubated proof of concept to a commercially viable platform with ≈$2M ARR and 30+ customers in its first year.

−0%
Team hours
per bid
−0%
Time to first
draft response
+0%
Average
win rate
app.pwin.ai/projects/enterprise-cloud/dashboard
Loading live product
Open live ↗
Redesigned Proposal Studio, readiness, workflow and win strategy in one view
Scroll for the full story
The 30-second brief

Winning government work is a high-stakes, 24-month sport.

Federal agencies buy through solicitations, RFPs. Contractors respond with proposals that government evaluators score against strict, line-by-line compliance criteria. A single bid can decide a company's year, and the pursuit runs 6 to 24 months and costs six figures before a word is drafted.

The method

Shipley & the color teams

The industry runs on the Shipley method, a sequence of review gates (Blue strategy → Pink first draft → Red evaluate-like-the-customer → Gold final) that move a bid toward submission.

The metric

Pwin, probability of win

Every go/no-go and resource decision is governed by Pwin. The product is named for it. The whole job is moving that number up.

The edge

Methodology, not just generation

pWin.ai is the only proposal copilot co-developed with Shipley Associates, built for Azure Government (CMMC Level 2), trust is the product.

The stakes

Teams rooted in decades of practice

Proposal professionals carry deep, hard-won process, and real anxiety about handing control to AI. Earning adoption was as hard as the engineering.

Lifecycle Blue Strategy→ Pink Draft→ Red Evaluate→ Gold Win
Go-to-market & goals

Earn GovCon's trust first, then own the whole lifecycle.

pWin.ai wasn't trying to be another AI writing tool. The thesis was narrower and harder: earn the trust of federal proposal teams on live, high-stakes pursuits, methodology, compliance, and security as the wedge, then expand from a single proposal into the full capture-to-submission lifecycle. My remit started at the foundation, establishing the company's design language, then translating each business goal into product the team could ship, across two phases.

Phase 1Pre-MVP · establish & prove
1
Define pWin.ai's identity
Establish the company's founding design language and product identity from a blank slate.
2
Prove product-market fit in GovCon
A focused MVP that turns RFx documents + company knowledge into review-ready drafts for live pursuits.
3
Build trust for high-stakes AI
Source-grounded, editable, traceable outputs with citation, compliance & hallucination checks, and human review throughout.
Phase 2Post-MVP · scale & expand
1
Drive early adoption & ARR
A product teams adopt across teams, reuse across pursuits, and expand into new workflows, repeatable enterprise revenue.
2
Evolve into an enterprise-ready, AI-native platform
One end-to-end experience for the full capture-to-submission lifecycle, trusted and source-grounded.
3
Expand beyond proposal drafting
Connect capture intelligence, the Knowledge Repository, RFIs, proposal generation, and Gold Team review into one platform.
Where it started

A promising engine trapped inside a SharePoint site.

When I joined, pWin.ai existed only as a proof of concept built on SharePoint. Inputs lived in a rigid Excel form, the "Flight Plan", pushed through a linear response engine. It proved the idea could work, and nothing more: no product identity, no interaction model, nothing that could earn an enterprise customer's trust.

The AI was ahead of the market, but no one would adopt it. My job was to turn a working engine into a product proposal teams would let into their process.

sharepoint.gov/sites/captures/EnterpriseCloud/Documents
POC, the SharePoint proposal site
POC, the SharePoint and Excel “Flight Plan” origin.
The adoption wall

We shipped the MVP. Then we hit a wall, and it taught us everything.

The first web app translated the proof of concept faithfully, and adoption stalled anyway. Five failures defined the redesign brief, and I'm including them because each one is where the real design happened.

The MVP, the first pWin.ai web app: a three-step proposal workflow with Response & Reports generation.
A faithful translation of the proof of concept, the work that revealed the five failures below.
MVP step 1: upload and ingest RFx documents.
MVP step 2: build the proposal outline in the Outline Builder.
MVP step 3: map RFx requirements to sections in Section Mapping.
MVP step 4: refine the response strategy in the Flight Plan.
1 / 4 · Upload RFx documents, the ingestion queue every proposal started from
The five failures

Where the MVP broke down.

01

The capture blind spot

The product began at the RFP, and stayed silent through the long capture phase before it, where teams first shape the opportunity. The work that decides the win had nowhere to live.

→ Opportunity Studio
02

The Formatting War

Our outline builder fought 30 years of Word muscle memory. Outlining is exploratory; ours behaved like a recording tool that assumed the thinking was already done.

→ New Outline Builder
03

Context with no map

Annotations were a checkbox list of parsed section titles, no view of coverage or context, so managers kept the source documents open in separate tabs.

→ Highlight-to-annotate
04

Single-player tool, team sport

No awareness of who else was in a project. Multiple editors meant accidental overwrites and lost work, in a process that is collaborative by definition.

→ Narrow lanes
05

No room to iterate

Improving one section meant regenerating the entire draft by tweaking the Content Plan. The cost of one change was the whole document.

→ Section refinement
How we listened

Four channels into the user's reality.

01

Customer emails

Analyzed direct client emails and technical questions to find where the UI broke their mental models.

02

In-app feedback

Built a contextual feedback feature on every screen to capture friction in the moment.

03

Demo & POV signals

Monitored what Sales heard during product demos and proof-of-value walkthroughs.

04

End-to-end testing

Watched experienced proposal managers take an unseen RFP through the whole system, live.

Five personas, one shared anxiety

Every role feared the same thing: losing control to the AI.

Proposal Manager
Orchestrator

Proposal Manager

Most operationally stressed, owns compliance, deadlines, coordination. Often felt they assisted the tool, not the reverse.

Capture Manager
Strategist

Capture Manager

Owns the opportunity months before the RFP. Their winning work was lost in fragmented slides and notes.

Solution Architect
Technical Lead

Solution Architect

The core of technical credibility. Needed a space to infuse solutions the AI couldn't guess.

Proposal Writer
Translator

Proposal Writer

Translates SME jargon into evaluator-optimized language. Biggest pain: context-switching to Word.

Subject Matter Expert
Specialist

Subject Matter Expert

Time-poor, billable, frustrated by proposal tools that interrupt the real work.

The insight that reframed the product

By the time the RFP drops, the race is already half over.

Across every channel, the feedback kept circling one structural truth: win probability peaks before the solicitation is ever released, during capture, when teams shape the opportunity. Our MVP was silent for that entire stretch.

Win probability across the pursuitPwin
RFP RELEASED most tools start here → BLUE PINK RED GOLD −24 months RFP day submission

The Capture Manager does up to 90% of the winning work months before the RFP, in scattered slides, notes, and spreadsheets. That realization reframed the whole product, and produced its first new module.

What the insight built

The Opportunity Studio, designing for the work before the work.

If winning starts in capture, the product had to start there too. The Opportunity Studio gives capture teams a home for the intelligence they gather in the months ahead of the RFP, then carries it, intact, into the first draft.

What failed first

The MVP began at the RFP, ignoring the 6 to 24 months where Capture Managers do up to 90% of the winning work.

The move

A dedicated capture space that centralizes slides, notes, and spreadsheets, structured as reusable objects, not buried files.

The tradeoff

It expanded scope well beyond "RFP response" and complicated the data model, but it's the line between a writing tool and a winning tool.

app.pwin.ai/opportunity/enterprise-cloud
Loading live product
Open live ↗
Opportunity dashboard, the pursuit's health, gaps, and next capture actions at a glance
01

Centralize capture intel

Slides, notes, and spreadsheets from the pursuit live in one structured place instead of scattered drives.

02

Object-based authoring

Inputs become reusable objects the system can reason over, not static files to copy and paste.

03

Carry into the draft

That intelligence flows straight into the Content Plan, so the first draft is grounded in the real strategy.

app.pwin.ai/opportunity/enterprise-cloud/capture-plan
Loading live product
Open live ↗
Opportunity Studio, capture intelligence structured as reusable objects, ready to flow into the Content Plan
The system, end to end

One continuous flow, capture to compliant draft.

STEP 01

Upload & validate

Solicitation documents are parsed autonomously; the user confirms relevance so the system reasons from the right source.

STEP 02

Outline & annotate

Shape structure in Outline Mode, then link requirements to sections by highlighting the source, and review before generating.

STEP 03

Import & steer strategy

Inputs flow from the Opportunity Studio into a Content Plan; SMEs steer AI-drafted substance instead of authoring from scratch.

STEP 04

Refine & finalize

Section responses stream in for targeted refinement; the final draft and reports land ready for review and export.

app.pwin.ai/projects/enterprise-cloud/upload
Loading live product
Open live ↗
The full workflow, from upload to a submission-ready package, one continuous flow
The decisions that mattered

Five more calls, each with a road not taken.

Beyond reframing the product around capture, five decisions shaped the rest. Product goals were set with the VP of Product; the end-to-end UX, and the tradeoffs below, were mine to own.

Decision 01

Split the landing page into a meaningful dashboard and a workspace.

The proposal project opened on a landing page that was neither a dashboard nor a workspace: a stepper navigation sitting on top of a response package vault that stayed empty until the whole flow was finished. I split it into two tabs, a dashboard that answers "where does this proposal stand," and a workspace where the actual work happens.

What failed first

No insight or overview on the project apart from the workflow progress, wasting real estate on something that remained empty till the very end.

The move

A meaningful dashboard for full project overview, plus a dedicated workspace where all the magic happens.

The tradeoff

Two tabs add a navigation step, but each surface earns its own density instead of splitting the difference.

Before: the original proposal landing page, a stepper over a response package vault
Loading live product
BeforeAfter
The original landing page behind, and the dashboard tab it became
Decision 02

Rebuild the outline as a text-first instrument.

Outlining is how proposal pros think, divergent, exploratory, fast. I rebuilt the builder as a keyboard-first Outline Mode: type, restructure, set hierarchy at the speed of thought, with AI assisting rather than gating.

What failed first

v1 was structured like a recorder, it assumed the thinking was finished and fought Word-shaped muscle memory.

The move

Keyboard-first editing, intuitive hierarchy controls, AI assistance on demand, fluency first.

The tradeoff

We traded rigid up-front structure enforcement for speed, then layered compliance checks on top instead of in the way.

refine annotated outline · draft
Loading live product
Open live ↗
Keyboard-first Outline Mode with AI assisting on demand
Decision 03

Make annotation match how managers already work.

Proposal managers mark up PDFs by highlighting. The MVP made them tick checkboxes against parsed titles instead. I rebuilt annotation around the gesture they trust: highlight the source to link Instructions, Evaluation Criteria, and Requirements to the outline.

What failed first

A checkbox list of section titles, no view of coverage or context, driving the multi-tab workaround.

The move

Highlight-to-annotate directly on the document, mapping requirements to sections in one view.

The tradeoff

More investment in the document-reading surface, but it folded the workaround into the product.

refine annotated outline · review
Loading live product
Open live ↗
Annotations mapped from the source to the outline
Decision 04

Refine sections, not the whole draft.

Fixing one paragraph shouldn't cost the entire document. I introduced section-level refinement with streaming responses and a prompt library, plus role-based "narrow lanes" so each persona works in their own space, not one overloaded screen.

What failed first

One change meant regenerating everything, in a single-player UI where teammates overwrote each other.

The move

Section-level refinement, streamed results, a reusable prompt library, and role-scoped workspaces.

The tradeoff

More states and permissions to design, but it killed the biggest source of wasted regeneration and lost work.

refine draft · section
Loading live product
Open live ↗
Refine one section at a time with streamed responses and a prompt library
Decision 05

Design the glass box, not the black box.

In a compliance-bound world, trust comes from seeing the AI's work, not from speed. Every generated response shows its sourcing and reasoning; users validate and steer rather than accept blind.

The move

Traceable sources, visible reasoning, the human in control of the output, on every AI surface.

The tradeoff

Surfacing the AI's working adds steps and density. We chose informed control over one-click magic, an evaluator-bound draft no one trusts is worthless.

refine · intelligence
Loading live product
Open live ↗
Every response shows its sources and reasoning
The outcome

From skeptical pilots to a category-defining platform.

Speed
−0%
Average time to first draft
vs. traditional workflows · a further −64.3% vs. the MVP
Effort
−0%
Team hours spent per bid
for our customers
Win rate
+0%
Average win rate
across deployed teams
Business traction
≈ $2M
ARR within the first year
30+
paying customers · incl. BlueHalo & Parsons
5 to 20×
more efficient than manual drafting

From an incubated proof of concept to a commercially viable, AI-native SaaS platform, adopted across teams and expanded from proposal drafting into capture, RFIs, and knowledge. The design didn't just earn adoption; it became how customers win.

What I took from it

Designing for AI is orchestration, not automation.

01

The Glass Box philosophy

Trust in AI isn't won by the speed of generation, it's won by the transparency of the output. That principle shaped every screen where the model met the user.

02

Paper cuts, not painkillers

Generic labels and missing empty states compounded into "this is hard to use." A UX Standards System made every screen self-explanatory, cutting the need for training.

03

Narrow lanes for a team sport

Proposal writing is collaborative, but one-size-fits-all interfaces overload. Role-based workspaces keep each person in their lane, and in flow.

04

From feature designer to strategic architect

The highest-leverage work wasn't a screen, it was deciding the product should start at capture. That's where design moved the business.