Discovery helps you to know what to build, who you’re building it for, and what impact you want to have in the world.
You deserve a clear strategy to act on, and working prototypes to confidently prove it works, before anyone signs a contract.
We talk to the people actually doing the work, not just the people managing it. Interviews, workshops, and time spent watching how things really happen, not how the org chart says they happen. This is where every engagement starts, because the real problem is rarely the one people describe first.
Once we know what's actually going on, we help turn it into a plan an organization can act on: what to build first, what to leave alone, and how to sequence work so it doesn't stall out waiting on the wrong decision.
A lot of the hardest problems aren't technical, they're about how people and organizations work together. We design the workflows, roles, and shared processes that let multiple teams, or multiple organizations, move as one.
Discovery means real interviews with the people who actually do the work, not just the people managing it, done with enough rigor to catch what nobody says at first. Every interview is really asking one thing. What is this person trying to get done, and why. Being heard that way is half the real work. It's what makes an organization ready to change.
We look for where people's accounts of the same process quietly contradict each other, not what everyone agrees on. That only surfaces when someone asks the follow-up question, the same discipline behind a well-run verbal interview,4 held to real research standards.5
What comes out is a clear, easy-to-understand strategy the whole organization can act on, built from what we found rather than assumed. Sometimes that means new software. Sometimes it doesn't.
In practice: In 2026, the City of Santa Fe brought us in to look at how it coordinates special events, permits, street closures, and public safety across more than twenty departments, after an earlier 2014 attempt fell short. We're doing over 60 interviews across nearly every department, not just the office that asked for help.
Most government technology projects fail before anyone writes a line of code. Only 13% of large government IT projects succeed.1
Most de-risking approaches for public-sector technology assume you've already made a decision: build custom, or buy.2 We think the real risk usually lives earlier than that, in the decision nobody's made yet.
Take ownership. We always look for a single, empowered, full-time product owner before work starts.3 It sounds obvious. It's also one of the first things a real discovery process tends to surface as unresolved, not because anyone is hiding it, but because in a large organization, "who owns this" is often genuinely unsettled, in motion, or assumed differently by three different people. You cannot build the right tool, or decide not to build one at all, until that's out in the open. Software can't fix an ownership question. It just gets deployed on top of it and inherits the confusion.
This is the actual argument for discovery: not that it's thorough, but that it's where you find the things that would otherwise sink a project after money has already been spent.
In practice: In Santa Fe, discovery surfaced exactly this kind of gap: a reorganization already underway, with ownership questions still working themselves out.
We're running an ongoing discovery process into how the city coordinates permits, street closures, and public safety across more than twenty departments, after an earlier 2014 centralization attempt collapsed within weeks.
We joined an existing engagement partway through, then ran two discovery projects that shaped what came next: one into how geothermal data was used and its current state, another into how field hydrogeologists actually used data, filled out reports, and shared measurements. That research shaped a refactor of the front end and a plan for making the platform's data fully editable by the people who rely on it.
We ran an earlier discovery engagement with the city, before the special events work above. The core finding was behavioral, not technical: the providers already knew each other, they just weren't coordinating. That finding is now becoming the Many Paths Project, a coordination system we're building on our own.
We ran an eight-week discovery process for the coalition coordinating war crimes documentation across the US, UK, and EU governments, then spent three months prototyping and building the coordination system that came out of it, one that ended up working across a wide range of organizations.
If you're weighing whether your project needs discovery or a strategy before it needs a contract, or you're a prime looking for a sub, let's talk →.
We prototype because a conversation can only describe an idea. A rough, tangible thing in front of the people who'd actually use it tests whether the idea holds up, cheaply, before anyone signs a contract based on a guess.
That's why prototyping before a contract is even awarded is one of the most consistently recommended de-risking practices for public-sector software,3 treating a rough build as a decision-making tool, not a deliverable that comes after decisions are made.
It also works because people react to a thing differently than they react to a description of a thing. A room full of people who've spent months describing the same problem in incompatible language can look at the same object and finally agree, or finally see where they don't.6
We build lightweight prototypes for the same reason, at the same moment in a project, not after discovery is "done," but as part of how discovery gets tested. On the New Mexico water data platform, field hydrogeologists had spent years working from printed data sheets, and research into how they actually used those sheets shaped a rebuilt front end.
A city can't afford to break a live permitting system to learn something. It can absolutely afford to break a rough prototype of one, and that's exactly the point.
Discovery, done this way, doesn't end with a recommendation to build something. It ends with:
That's the whole bet behind starting here instead of with a procurement process: the fastest way to a solution that actually works is to first find out, in enough detail, what's actually broken.
59 Projects is a small strategic design and civic technology practice, founded by Jeremy Zilar, working with local governments, state agencies, and mission-driven organizations at moments of change. On engagements like these, we bring in a trusted bench of collaborators, many with their own background in local governments, non-profits, 18F, the U.S. Digital Service, or Code for America, sized to what the work actually needs rather than staffed by default.
Discovery is one part of a broader practice. See the full range on our Services page →.
More on the practice and the people behind it on our About page →.
If you're evaluating whether a project needs discovery or a strategy before it needs a contract, or you're a prime looking for a sub, we'd like to hear about it →.