Insights / Product strategy
What a serious software discovery process should produce
Anthony Ogundipe · Founder and CEO · 26 May 2026 · 9 min read
Discovery is not workshops for their own sake. It should leave you with decisions, boundaries, and artefacts you can build from—without pretending uncertainty has disappeared.
Software discovery fails in two opposite ways. One is theatre: sticky notes, journey maps, and a slide deck that everyone applauds and nobody uses. The other is premature certainty: a fixed scope document written before anyone has pressure-tested the problem with real users, real data, or real constraints. A serious discovery process sits between those poles. It does not claim to know everything. It produces enough clarity that building is no longer guesswork dressed as commitment.
Discovery should answer a small set of hard questions. Who is this for, in roles not personas-as-marketing? What job must succeed on day one for the product to be worth keeping? What is explicitly out of scope for the first release? What constraints are non-negotiable—regulation, integrations, offline needs, languages, devices, existing vendor lock-in? What does “done enough to ship” look like in operational terms, not feature counts? Who decides when those questions conflict?
The artefacts matter more than the ceremony. Expect a problem brief that names the pain in business language. Expect a stakeholder map that shows who can block progress and who actually uses the system daily. Expect a prioritized outcome list for the first release—outcomes, not a backlog of buttons. Expect a risk register that is honest about unknowns: data quality, third-party APIs, change management, seasonal load, single points of failure in staffing. Expect a technical shape note: likely architecture choices, integration points, hosting assumptions, and what must be validated before heavy build. Expect a draft success checklist that operations and product can both read without a translator.
User research in discovery should be short and concrete. Observe a handful of real workflows end to end. Capture the workarounds without mocking the people who invented them. Ask what people do when the current tool fails at 4:55pm on a Friday. Avoid survey theatre that produces averages without decisions. If you cannot speak to operators or customers during discovery, write that as a risk with an owner, not as a footnote that everyone forgets.
Prototypes and spikes belong in discovery when they reduce expensive uncertainty. A clickable flow can settle whether a multi-step booking is viable on mobile with real addresses. A one-week integration spike can prove whether an external system will authenticate, rate-limit, or return incomplete payloads. A data sample review can kill a fantasy about “just importing everything.” These are not early development dressed as research; they are evidence for build/no-build and sequencing decisions. Time-box them. Publish the finding even when it is inconvenient.
Discovery should also produce commercial clarity. Rough effort bands, engagement model options, dependency owners, and assumptions that would invalidate the estimate help leadership decide without demanding fake precision to two decimal places. A discovery that ends with “we need another discovery” may be valid once when the domain is genuinely opaque; as a habit it usually means the questions were never forced to a decision or stakeholders refused to choose.
What discovery should not produce is a frozen eighty-page specification treated as law. Markets move. Learning continues in build. Competitors ship. Regulations shift. The contract with stakeholders should be: discovery narrows the first release and names the open questions; delivery revisits those questions with evidence. Change control then becomes a conversation about trade-offs, not a battle over whether someone “missed a requirement” that was never tested against reality.
Governance of discovery itself matters. Set a fixed window. Name a decision forum. Require written outcomes at the end—not a verbal “we are aligned.” Archive recordings and notes where the delivery team will actually look. If discovery artefacts live only in a consultant’s laptop, you bought temporary comfort.
At the end of a solid discovery, a team should be able to say: here is what we will build first; here is what we will not; here is how we will know it works; here is what still needs validation in the first sprints; here is who owns each external dependency. If those sentences cannot be spoken plainly in a room with finance and operations present, discovery is incomplete—regardless of how polished the deck looks.
A useful discovery checkpoint is the “decision log.” Capture every choice that would be expensive to reverse: primary user for release one, must-have integrations, data residency assumptions, offline requirements, and the commercial engagement model under consideration. When debates reopen later, the log prevents reinventing the same argument with new participants. Pair it with an open-questions list that has owners and review dates so uncertainty stays managed instead of ambient.
Discovery also benefits from a thin compliance and security pass even when the product is not “enterprise” yet. Note authentication expectations, personal data categories, audit needs, and who will host production. Teams that postpone these notes until build week discover that architecture choices were made without the constraints that actually matter to legal and IT. Naming them early does not mean solving them all—it means the build plan does not pretend they are optional.
Finally, treat discovery as a product for the delivery team that follows. If another squad could pick up the artefacts and start without a three-hour oral history, you produced something durable. If the only transferable asset is a charismatic workshop facilitator, you bought temporary alignment.
Africoders Works uses discovery to de-risk product and technical decisions before spend accelerates. If you need that clarity before committing to a build, start a project and we will structure discovery around decisions, not decoration.
Discovery should answer a small set of hard questions. Who is this for, in roles not personas-as-marketing? What job must succeed on day one for the product to be worth keeping? What is explicitly out of scope for the first release? What constraints are non-negotiable—regulation, integrations, offline needs, languages, devices, existing vendor lock-in? What does “done enough to ship” look like in operational terms, not feature counts? Who decides when those questions conflict?
The artefacts matter more than the ceremony. Expect a problem brief that names the pain in business language. Expect a stakeholder map that shows who can block progress and who actually uses the system daily. Expect a prioritized outcome list for the first release—outcomes, not a backlog of buttons. Expect a risk register that is honest about unknowns: data quality, third-party APIs, change management, seasonal load, single points of failure in staffing. Expect a technical shape note: likely architecture choices, integration points, hosting assumptions, and what must be validated before heavy build. Expect a draft success checklist that operations and product can both read without a translator.
User research in discovery should be short and concrete. Observe a handful of real workflows end to end. Capture the workarounds without mocking the people who invented them. Ask what people do when the current tool fails at 4:55pm on a Friday. Avoid survey theatre that produces averages without decisions. If you cannot speak to operators or customers during discovery, write that as a risk with an owner, not as a footnote that everyone forgets.
Prototypes and spikes belong in discovery when they reduce expensive uncertainty. A clickable flow can settle whether a multi-step booking is viable on mobile with real addresses. A one-week integration spike can prove whether an external system will authenticate, rate-limit, or return incomplete payloads. A data sample review can kill a fantasy about “just importing everything.” These are not early development dressed as research; they are evidence for build/no-build and sequencing decisions. Time-box them. Publish the finding even when it is inconvenient.
Discovery should also produce commercial clarity. Rough effort bands, engagement model options, dependency owners, and assumptions that would invalidate the estimate help leadership decide without demanding fake precision to two decimal places. A discovery that ends with “we need another discovery” may be valid once when the domain is genuinely opaque; as a habit it usually means the questions were never forced to a decision or stakeholders refused to choose.
What discovery should not produce is a frozen eighty-page specification treated as law. Markets move. Learning continues in build. Competitors ship. Regulations shift. The contract with stakeholders should be: discovery narrows the first release and names the open questions; delivery revisits those questions with evidence. Change control then becomes a conversation about trade-offs, not a battle over whether someone “missed a requirement” that was never tested against reality.
Governance of discovery itself matters. Set a fixed window. Name a decision forum. Require written outcomes at the end—not a verbal “we are aligned.” Archive recordings and notes where the delivery team will actually look. If discovery artefacts live only in a consultant’s laptop, you bought temporary comfort.
At the end of a solid discovery, a team should be able to say: here is what we will build first; here is what we will not; here is how we will know it works; here is what still needs validation in the first sprints; here is who owns each external dependency. If those sentences cannot be spoken plainly in a room with finance and operations present, discovery is incomplete—regardless of how polished the deck looks.
A useful discovery checkpoint is the “decision log.” Capture every choice that would be expensive to reverse: primary user for release one, must-have integrations, data residency assumptions, offline requirements, and the commercial engagement model under consideration. When debates reopen later, the log prevents reinventing the same argument with new participants. Pair it with an open-questions list that has owners and review dates so uncertainty stays managed instead of ambient.
Discovery also benefits from a thin compliance and security pass even when the product is not “enterprise” yet. Note authentication expectations, personal data categories, audit needs, and who will host production. Teams that postpone these notes until build week discover that architecture choices were made without the constraints that actually matter to legal and IT. Naming them early does not mean solving them all—it means the build plan does not pretend they are optional.
Finally, treat discovery as a product for the delivery team that follows. If another squad could pick up the artefacts and start without a three-hour oral history, you produced something durable. If the only transferable asset is a charismatic workshop facilitator, you bought temporary alignment.
Africoders Works uses discovery to de-risk product and technical decisions before spend accelerates. If you need that clarity before committing to a build, start a project and we will structure discovery around decisions, not decoration.