Capture Management
- role
- Product Designer
- skills
- 0-1 Product Design
Customer Research
Cross-functional Leadership
Enterprise UX - with
- Param Mehta
Veda Jammula
Michael Lee
Matthew Zepf
Outcome
Capture Space's first MVP shipped in a two-week sprint ahead of the Global SOF Foundation conference, and the push behind it drove 20% more leads at the event. I owned the design end to end and built the entire front end myself, while the team split the backend schema work and the agents and automations system between them. The product is still active, and MVP-1 is now the foundation for the fuller end-to-end capture platform.
Challenge
Teams found opportunities on Usul, then left. Everything after that, gate reviews, inviting engineers, assigning sections, tracking deadlines, scattered across Slack, Teams, and email, with no system of record once an opportunity moved into a team's own CRM. Usul had no way to see what happened to an opportunity after a team found it.
Capture Space started as a hypothesis, not a confirmed need, born out of a broader brainstorming session about improving Proposal Writer, before there were any customer calls on it yet. It was a calculated guess, part of a conversation about keeping teams on Usul instead of navigating away for tasks and capabilities it didn't yet own, and the research that followed existed to validate or kill that guess before we built anything on top of it. Looking at how teams actually used Usul end to end, find an opportunity, research it, drop it into a CRM stage, then leave for Google Docs and ChatGPT or Claude to draft, coordinate with engineers over Slack for technical input, and finally submit, made clear that Usul only owned the first step. Everything after that lived somewhere else.
The first fix we considered was smaller than what Capture Space became. We looked at turning Proposal Writer itself into a centralized home for proposal creation, one place with a holistic view of a team's capabilities, its own past proposals matched against the opportunity, and an outline generated from both, so nobody had to leave Usul to draft. That framing held up under research, but it was still only solving the writing step, not everything happening around it.
User Research
We ran exploratory conversations with five companies of different sizes to understand how capture actually worked instead of guessing at it.
One company walked us through their end-to-end capture management process. Shipley showed up again and again as the reference framework, though not every company followed it fully, how closely a team followed Shipley's gate reviews depended on their size and how much time they had. The most consistent pain point was the lack of supporting information during the opportunity research stage, there was no holistic view of an opportunity to work from.
The second company was especially useful. Their proposal writer manager was effectively the knowledge system herself, undocumented, held in one person's head. Once a go/no-go decision was made, her team built a shared Google Doc, color-coded to assign questions to different people, and deliberately kept engineers at arm's length from the writing itself so the proposal's messaging stayed accessible instead of turning too technical. Gate reviews happened, but informally.
Her specific pain points were the clearest signal in all the research. She had no systematic way to reuse answers to similar RFI questions and had to manually search through old documents to find something usable, even though roughly 80% of a typical answer came from something written before, since RFI questions repeat thematically across proposals. She'd tried Claude for this, but it was only about 75% accurate without the context to know which past answer actually applied. Coordination was all manual too, no reminders, no notifications, just personal tracking and follow-ups, with reference material scattered across loose documents and folders.
The other three companies echoed the same shape of problem, work spread across Google Drive, Google Docs, and Slack, with no shared system underneath it. One of them used a tool called Rogue for proposals, which stood out as worth watching. Another followed a simplified version of Shipley's gate reviews.
The throughline across all five conversations was that there's no single right way to run capture, the product had to flex to support different methodologies rather than impose one. The two moments that ate the most time were finding the right contract in the first place, and everything manual that happened right after a go/no-go decision.
Solution
Scoping what to build
From the research, I put together an early, loose product spec, a generic way for teams to collaborate across an opportunity that didn't force a single workflow on top of teams already living in Slack, SharePoint, and documents. It had to support teams using Usul's own CRM pipeline and teams that didn't, equally.
I worked through the harder scoping questions directly with the CPO, how opinionated the product should be about how capture gets done (organized around an opportunity, a proposal, or a team's own workflow), who the primary users actually were, and what success would even look like. We landed on end-to-end capture as the focus, meaning once an opportunity moved into the CRM, Usul's job became speeding up everything from there, running agents and automations to get work moving before a person even opened it.
We were deliberate about who'd get this first. Teams still fully living inside Slack, SharePoint, and loose documents, exactly the pattern research kept surfacing, were the initial rollout target, alongside teams that already ran through Usul's own CRM pipeline. And we held ourselves to real accountability questions before writing a line of code, how would we actually track whether it was working, and what would our success rate need to look like to call it real.
Mapping the build
I mapped the MVP-1 scope into large diagrams and an architecture overview so the whole team could see how the pieces fit together and who owned what. Capture Space MVP-1 broke into several pieces, a settings page, agents and automations as their own sub-feature, brand-new in-app and email notifications, tasks, and a major overhaul of the pipeline itself, including revamped filters and stages teams could rename, edit, and reorder. Inside each opportunity, users could create tasks, leave notes, upload documents, manage the proposal itself, and trigger agents that completed work like generating reports, deterministically and automatically.
One piece mapped directly back to the proposal writer manager's problem from research, the proposal library. It let teams upload past proposals, and on the backend, proposal agents pulled from those past responses and matched them to the specific product or capability a new proposal was for, populating the outline with related content automatically. Instead of someone manually searching through old documents to find an answer that had already been written, the system surfaced it against the outline before anyone opened it.
Building under a two-week deadline
I split the work into two pieces and assigned owners in a single planning meeting. Param Mehta owned agents and automations along with all the notifications work, and engineers handled the backend schema and migration work, all coming together over a two-week turnaround. I owned the entire front end of Capture Space myself, the redesigned pipeline, every new feature and sub-feature, and the workflow tying agents and automations into it, built for an MVP-1 an entire team could actually ship in two weeks ahead of the Global SOF Foundation conference.
Not everything on the mapped-out scope survived that timeline. Notifications were the hardest call, Usul had no queue infrastructure to build on, so engineers were building that from scratch inside the same two weeks, and a handful of other nice-to-have features got cut so the team could still hit the deadline. I led the calls on what stayed and what got dropped, weighing what teams would actually need on day one against what could wait for the next iteration.
Capture Space is still active, and we're continuing to iterate on it past MVP-1.
Guiding principles
- Flex to the workflow, don't replace it
Research found no single right way to run capture. Teams were already living in Slack, SharePoint, and loose documents, so the product had to support their methods rather than impose one.
- Decide how you'll know it worked, before building it
We answered how we'd track whether this was working, and what success rate would make it real, before anyone wrote a line of code.
- Cutting scope is design work
Notifications had no queue infrastructure underneath them. Deciding what teams needed on day one and what could wait was the same job as drawing the thing.