Discovery & decision readiness
How to Prepare for a Useful Software Discovery Conversation
A useful first software conversation does not require a finished specification. It requires enough shared context to identify the real decision, understand the operation around it, and decide what should be investigated next. Preparing a few concrete inputs helps the discussion move beyond a generic capability pitch without forcing the solution too early.
Start with the decision, not the proposed software
Describe the decision your organization needs to make. You may be deciding whether to replace a manual process, modernize an existing product, connect systems, test an AI-assisted workflow, or prepare a larger investment. The same project idea can require a very different first step depending on what must be decided and by when.
State why the decision matters now and what happens if nothing changes. This gives the conversation a business boundary without assuming the outcome in advance. It also helps separate the urgent condition from the first solution somebody suggested.
- The decision the next stage needs to support
- The operational or customer condition creating pressure
- The consequence of delay, failure, or choosing the wrong path
- The date or event that makes the decision time-sensitive
Bring one real workflow and its difficult cases
Choose a representative workflow and describe how work moves today. Identify where it starts, who contributes, which systems or documents are involved, where approvals occur, and what useful completion looks like. A concrete example is more informative than a broad request to automate the business.
Include the exceptions that consume attention or create risk. The happy path may be easy to demonstrate while duplicate records, missing data, unusual approvals, reversals, or unavailable reviewers determine whether a production system is dependable.
- Trigger, inputs, steps, approvals, output, and operating owner
- Systems, spreadsheets, messages, documents, and manual handoffs
- Common exceptions and the cost of resolving them
- A small number of representative, safely redacted examples
Identify the people needed for useful answers
A decision owner and a subject-matter expert often see different parts of the problem. The decision owner can clarify priority, acceptable tradeoffs, and commercial authority. The people who perform or support the work can explain the real sequence, exceptions, data quality, and operating constraints.
Not everyone needs to attend the first conversation. Know who can answer the initial questions and who will need to review later evidence. If legal, security, procurement, finance, accessibility, or another specialist will influence the path, identify that dependency early instead of treating approval as a final-stage event.
- Accountable decision owner
- Workflow or product subject-matter expert
- Technical owner for current systems and access
- Reviewers whose requirements could change the delivery path
Map the systems, data, and access boundary
List the important systems and the role each one plays. You do not need complete technical documentation for an initial discussion, but it is useful to know where authoritative records live, which platforms must exchange information, who owns them, and whether supported APIs or exports exist.
Classify sensitive boundaries before sharing examples. Explain that regulated, personal, financial, client-confidential, or proprietary information exists without placing it in a public form or ordinary email. A later authorized process can establish minimum access, redaction, retention, provider, and deletion requirements for the actual material.
Never place credentials, authentication codes, private keys, full payment-card data, production exports, or client-confidential records in an initial inquiry.
State constraints as planning inputs
Budget context, timing, operating capacity, required platforms, contractual obligations, and internal policies can change which next step is responsible. Share what is fixed, what is preferred, and what remains uncertain. A deadline tied to a launch, renewal, audit, or regulatory event is different from a general desire to move quickly.
Budget context does not need to be a commitment. It helps test whether the decision should begin with a focused investigation, a prototype, a staged improvement, or a broader delivery plan. Hiding an important boundary until after a proposal wastes effort on both sides.
- Decision and launch timing, including immovable external dates
- Planning range or approval threshold when one exists
- Technology, vendor, hosting, procurement, or policy constraints
- Internal capacity for review, data preparation, and change adoption
Define what evidence would make the next decision safer
The first conversation should not manufacture a quote from incomplete information. It should identify what evidence is needed next. That may be a workflow map, integration check, data sample review, architecture option, prototype, risk register, delivery stage plan, or a conditional estimate with explicit assumptions.
Agree on the question each artifact will answer and who will review it. This turns discovery into a decision-producing stage instead of an open-ended series of meetings. It also makes it easier to stop, narrow, or change direction when evidence contradicts the original idea.
- Unknowns that could change feasibility, value, risk, or cost
- Fastest safe way to test the most important assumption
- Review criteria and people needed for the next decision
- What can be decided now and what must remain conditional
Use a compact preparation packet
A short preparation packet is usually enough: a one-paragraph decision statement, one workflow example, a system list, named participants, major constraints, and the questions you want answered. Existing documents can be referenced without sending them until an appropriate access and confidentiality path exists.
Treat the packet as a conversation aid, not a hidden requirement. If important information is missing, say so. A capable discovery process should make unknowns visible and help determine how to resolve them rather than rewarding confident guesses.
You do not need a complete specification, polished presentation, finalized feature list, or approved technical architecture to begin a responsible fit conversation.