Discovery vs. Delivery
The two skills every software partner needs — and why most vendors have only one
By Steele Consulting
Every failed software project has a post-mortem, and most post-mortems end at the same shrug. The requirements were fine. The code was fine. The team was competent. And yet the thing that shipped either didn’t solve the actual problem, didn’t ship on time, or shipped and got quietly abandoned.
Something between the specification and the software didn’t work. Almost always, when we dig into it, it’s the same thing: the vendor had one of the two skills a software partner needs, and not the other.
We covered the general question of how to evaluate a software partner in an earlier post, What to Look for in a Software Partner When You’re Not Technical Yourself. This one is the sharper version of the same conversation. Because after 24 years at Steele Consulting building custom software for clients across every industry, we’ve watched the same pattern play out over and over: firms that are excellent at one half of the work and unreliable at the other.
The two skills, honestly
Building software takes two fundamentally different kinds of thinking, done by two often-different kinds of people.
Discovery is the skill of figuring out what should actually be built. It’s asking the right questions, listening to what the business is really saying (versus what it’s asking for), spotting the hidden constraint that will kill the project in month six, translating operational language into technical requirements, and — critically — knowing what not to build.
Delivery is the skill of actually building it. Engineering execution. Project management. Quality assurance. Deployment. Keeping the timeline. Communicating progress. Hitting the specification. Shipping something that works.
Both are hard. Both take years to develop. And they tend to live in different personalities. Discovery people are curious, empathetic, socially skilled, strategic. Delivery people are systematic, detail-oriented, execution-focused. Firms rarely have both in equal measure, and when they do, the two sides don’t always talk to each other.
The result is that almost every software vendor you’ll ever evaluate is asymmetric.
The four archetypes
Combine strong or weak on each skill and you get four kinds of vendor. You’ll recognize all of them.
The Strategist — strong discovery, weak delivery
Great in the sales conversation. Asks smart questions. Understands your business. Walks in with a well-framed problem statement and a plan that makes sense. You leave the meeting energized.
Then things get slow. Deadlines slip. Communication goes quiet between milestones. The final product is close to what was scoped, but late and rough. The Strategist can see clearly. They just can’t ship consistently.
You end up with a project that was well-conceived and half-executed. In the worst version, you spend a year and the software never actually goes live.
The Coder Shop — weak discovery, strong delivery
Great engineering. Great processes. Ships on time. Hits the spec exactly. Reliable.
But the spec was wrong. The vendor didn’t push back when it should have. Didn’t ask about the constraint you didn’t know you had. Didn’t tell you that half the features would go unused. They took the requirements and executed them.
You end up with software that works — and doesn’t solve the actual problem. Then you pay for a second phase to fix what the first phase missed.
The Amateur — weak at both
Avoidable if you did any diligence. The 5 Tests we wrote about in the earlier software partner post are designed largely to filter this archetype out early. If you’re seeing more than one of the tests fail — no real references, no translation ability, no track record — you’re looking at this quadrant. Walk away.
The Complete Partner — strong at both
Rare. Genuinely rare. The firm asks the right questions AND ships on time. Understands your business AND builds working software. Tells you what not to build AND executes the yes cleanly.
This is what you’re actually trying to hire. And this is the archetype most non-technical buyers underestimate the value of, because it’s easy to over-index on whichever half of the skill you’re currently in the sales conversation with.
Why most vendors are asymmetric
There’s a specific reason firms tend toward one side or the other, and it’s structural.
Firms that grow out of consulting — often started by former strategy or product people — tend to be discovery-strong. They win business on ideas and framing. Their weakness is that the engineering team is often smaller than it needs to be, and the delivery culture treats execution as a follow-up to the “real work” of strategy.
Firms that grow out of engineering — often started by former developers or agencies — tend to be delivery-strong. They win business on portfolio and technical depth. Their weakness is that discovery is treated as an input from the client, not a service the firm provides. If the client walks in with the wrong requirements, the wrong software gets built.
Neither structural background is bad. Both produce firms that ship real work for real clients. But if you don’t know which one you’re evaluating, you’ll walk into the failure mode of that firm without seeing it coming.
Three diagnostic questions to ask
The 5 Tests from the earlier post are the general filter. These three questions are specifically designed to expose the discovery/delivery balance.
Question 1
“Tell me about a project where you talked a client out of what they originally asked for.”
A vendor with strong discovery has an answer immediately. They’ll tell you a story about pushing back on a feature, redirecting to a simpler solution, or convincing a client to buy off-the-shelf instead of building custom. A vendor without discovery skill either can’t think of one, or tells you a story about how they built exactly what the client asked for.
Question 2
“Walk me through your last three projects — did they ship on time, and what happened when they didn’t?”
A vendor with strong delivery answers this honestly and precisely. They know their track record. They can tell you which projects went over, why, and what they did about it. A vendor with weak delivery gets vague, defensive, or blames past clients.
Question 3
“Who from your team is going to be in every meeting on this project?”
A complete partner has both a discovery-strong person and a delivery-strong person in the room, and they work together. A discovery-only firm will assign a “strategist” who disappears after the first month. A delivery-only firm will assign a project manager whose job is to keep the ticket queue moving, not to reframe the problem when new information emerges.
What good looks like: the handoff
The single most reliable indicator of a complete partner is how they handle the moment when discovery ends and delivery begins.
At a weak firm, discovery produces a document, the document gets handed off to engineers, and the discovery people move on to the next client. When something changes — and something always changes — nobody circles back. Engineering keeps building against a spec that no longer matches reality.
At a strong firm, the handoff isn’t a handoff at all. The discovery person stays in the project. When engineering hits an assumption that doesn’t hold, discovery re-engages, reframes, and adjusts. The specification lives, breathes, and evolves as the team learns. This is how good software actually gets built — not by executing a fixed spec, but by a partner who can move fluidly between “what should we build?” and “let’s build it.”
How this connects to the other decisions you’re making
The Discovery/Delivery diagnostic slots in next to the 5 Tests from the earlier software partner post — same evaluation, sharper lens. It also connects to the Build, Buy, or Bend decision: if you’ve concluded that Build is the right answer, this is the very next question you need to answer about the vendor. And it connects to Process Problem or Software Problem, because a discovery-strong partner is exactly the one who will tell you when the problem you brought them isn’t a software problem at all.
How we approach this at Steele Consulting
We’ve built our practice around the assumption that discovery and delivery are equally important, and we structure engagements around it. The person leading discovery on your project stays with the project through delivery. The person leading delivery has been in the discovery conversations from day one. Neither hands off to the other. Both stay in the room.
That structure is more expensive to operate than the alternatives, and we make no apology for it. It’s also why our long-term clients are long-term. When your business changes mid-project — and it will — you have a partner who can move with you instead of a spec that has to be renegotiated.
If you’re evaluating a software partner right now and want a second set of eyes on which side of the discovery/delivery line they sit on, reach out. That’s the diagnostic conversation we’re happy to have.