Software Project Discovery: What to Learn Before an Estimate

Before estimating a custom software project, establish who will use it, which problem it should solve, what the first useful release includes, and which unknowns could materially change the work. Let qualified delivery staff validate the estimate. A feature list is an input to that decision, not evidence that the project is fully understood.

Atlassian connects product discovery with customer needs and business context. Atlassian product-discovery guidance. Atlassian describes story points as relative effort, not a direct time measurement. Atlassian story-point guidance. The practical workflow below is a proposed management approach, not a claim that a particular tool or provider produces guaranteed results.

Ask what the software must change for a user

Start with the people and workflow. Ask how work happens now, where it breaks down, and what a successful change would allow someone to do. A requested portal, dashboard, or application can describe a preferred format without explaining the outcome the buyer intends to achieve.

Identify the first users and the customer person who can speak for their needs. If several groups need different things, record the conflict instead of quietly combining every request into the initial release. Sales should facilitate this clarity while product and technical specialists assess the proposed response.

Build an uncertainty map

List the parts of the project that are known, assumed, and still unknown. Focus on uncertainties that could change scope or delivery decisions. Existing code quality, data access, integration behavior, stakeholder approval, and operational support can matter as much as the number of screens.

• User outcome and the evidence that would demonstrate it.
• Initial release boundary and work explicitly deferred.
• Existing systems, interfaces, data, and access dependencies.
• Security, performance, accessibility, and operating requirements for qualified review.
• Customer responsibilities and availability for decisions.
• Acceptance process, deployment authority, and ongoing ownership.
• Unknowns requiring investigation before a reliable commitment.

Use the map to explain estimate confidence. Do not present a number with false precision while material assumptions remain untested. Equally, avoid suggesting that every project requires a lengthy preliminary engagement. The amount of discovery should reflect the uncertainty and responsibility involved.

Distinguish three different outputs

A rough early range can help a buyer decide whether to continue exploring, provided its conditions are clear and the firm approves how it is communicated. A scoped estimate reflects better evidence and delivery review. A commercial commitment follows the approved contracting process and its actual terms.

Keep these outputs distinguishable in the opportunity record. A salesperson should not turn a developer's exploratory comment into a promised delivery date. Relative engineering estimates also should not be converted casually into a customer schedule without considering the team's actual planning approach and capacity.

Choose a useful discovery outcome

Define what discovery should make decidable. It might validate an integration, identify an initial workflow, compare implementation options, or define acceptance for a first release. Agree the participants, inputs, boundaries, and output before the work begins.

The result can be a smaller project, a different approach, or a decision not to build. Those are useful outcomes when they prevent an unsuitable commitment. Avoid promising that discovery will remove every uncertainty; software work can continue to reveal new information as delivery proceeds.

Illustrative example: an apparently simple customer portal

Imagine a prospect requesting a portal with login, account information, and a few reports. During initial discovery, the team learns that account data comes from two systems with inconsistent customer identifiers. The customer has not named a person who can approve how those records should be matched. This example is hypothetical.

The major uncertainty is not the visual design of the portal. It is the data and ownership decision behind it. The agency can propose a bounded investigation or a smaller first release, with technical staff validating the options. The buyer then sees why an immediate fixed implementation promise would depend on unresolved assumptions.

Review the estimate across disciplines

Before issuing an approved proposal, ask engineering, design, quality, and the delivery owner to review the relevant work. Include deployment, handover, documentation, and customer review responsibilities. A project can look manageable when only feature construction is counted and become difficult when the full delivery obligation appears later.

Record which assumptions the reviewers accepted and which need a customer decision. Keep the estimate version linked to the proposed release boundary. If the customer changes the boundary, revisit the estimate through the agreed route rather than treating an earlier version as a permanent promise.

Make the next sales step concrete

End the conversation with a customer-owned action. That might be providing an integration contact, confirming the product decision-maker, reviewing a discovery scope, or choosing between validated release options. Explain what your team will do in return and when both parties will review the result.

Review opportunities where the next action remains entirely internal. More presales work is not automatically progress if the buyer has not agreed to participate or established a purchasing path. A credible project needs both a technical direction and a customer willing to make decisions.

Improve estimates using actual learning

After delivery, review which assumptions changed, what information was missing, and which estimate differences came from changed scope rather than execution. Use that learning to improve the next uncertainty map. Do not hide changes inside a claim that the team simply estimated badly.

Start with the project type your agency quotes most often. Identify the recurring unknown that creates the largest disagreement, then make resolving it part of the next relevant discovery conversation. Better evidence is more useful than a more elaborate estimating template.

Put clear ownership around the work

Escencion provides Managed Sales & Business Operations for technology companies. Our current client focus is MSPs and MSSPs. Explore our Managed Sales approach, or discuss the responsibilities you need managed. Your technical team retains technical validation, approved commitments, engineering, and service delivery.