Product discovery: define the smallest complete release

The first-release decision is an allocation of capital under uncertainty. The organization is deciding which customer problem to address, which assumptions it is prepared to test, and how much operating complexity it can justify before demand and delivery feasibility are understood. A feature list does not answer those questions.

Product discovery should produce a small but complete operating capability, with a rationale for its boundary. Complete matters: an attractive interface that leaves essential review, status, and exception handling undefined can be inexpensive to demonstrate and expensive to launch. Small matters too, because adding capabilities before testing the central assumption increases both exposure and the difficulty of interpreting what the release teaches.

The CTO’s role is to connect product intent to system obligations. That includes integration feasibility, data authority, nonfunctional requirements, and the cost of the manual work the first version will retain. The discussion below uses a hypothetical supplier-onboarding product to show how those decisions change release scope.

Define the business transition the product must complete

A supplier-onboarding proposal might begin with registration, document upload, email notifications, and a dashboard. Those are interface features. The business transition is a supplier becoming eligible to transact after the required information has been checked and approved.

Following that transition exposes work behind the screens: identifying the legal entity, handling duplicate applications, checking documents, resolving missing information, recording a reviewer’s decision, and explaining the resulting status to the applicant. Some work may remain manual, but it still belongs to the operating design.

Separate the needs of the applicant, reviewer, and business owner. The applicant wants understandable requirements and reliable progress. The reviewer needs sufficient information to make a decision without searching across systems. The business owner needs appropriate acceptance rules and a traceable outcome. A release that optimizes only applicant registration can move effort into the review team while appearing successful in front-end analytics.

Define completion and the important exceptions before estimating the release. Can an applicant correct a submission? Who can reject or approve it? What happens when an existing supplier submits again? Which status is authoritative? These questions reveal the system boundary more reliably than counting screens, and they prevent essential work from arriving later as supposedly unexpected scope.

Test the assumption that could invalidate the investment

Discovery activities should be selected according to the decision they support. A prototype can test whether an applicant understands a document request. It cannot establish that the organization can access an authoritative legal record, apply approval rules consistently, or maintain the proposed turnaround under expected review demand.

Identify the assumptions that would change whether or how the product should be built. For the supplier portal, these might concern the willingness of suppliers to use the channel, the consistency of review rules, and the availability of data from an existing system. The most consequential unknown deserves attention before the most visible feature receives polish.

Keep the confidence level proportionate to the evidence. Interviews identify needs and concerns; observed task behavior can expose difficulties people do not describe; technical tests reveal dependency limitations. Each contributes something different. An enthusiastic stakeholder response should not be treated as proof that an operationally complete product is feasible.

Select a vertical slice that can operate

A useful first release takes one defined applicant population through submission, review, correction where necessary, and an authoritative decision. The population may be narrow, and some review steps may be manual. The release should nevertheless support a complete journey within that boundary.

This differs from building the first few screens of a larger system. A horizontal slice can accumulate interface work while postponing the architecture and operating decisions that establish whether the product works. A vertical slice forces the team to connect identity, data, business rules, and user feedback early enough to learn from them.

The supported population should have a reason. Selecting suppliers with one document pattern may reduce rule variation and make the first operating assessment interpretable. Selecting only unusually cooperative applicants may create a misleading result if the business later expects wider use. Record who is excluded and why, and treat expansion as another scope decision rather than a routine switch.

Manual work is acceptable when it is deliberate and measurable. A reviewer can perform a check while the team learns how the rules behave. The system still needs a queue, a decision record, and a reliable applicant status. Describing the release as automated while ignoring those responsibilities understates both the cost and the implementation scope.

Settle identity and data authority early

The portal needs to distinguish the person submitting an application from the supplier organization and from an existing approved supplier record. Those identities can overlap without being interchangeable. An email address alone may be insufficient for establishing which organization the application concerns or which users are authorized to act for it.

Choose an authoritative record for the application and its progress. If the portal, reviewer spreadsheet, and existing business system can each independently change the approval status, the product will struggle to provide trustworthy feedback. An apparently simple dashboard then becomes a reconciliation problem.

Agree on how approved applications create or update downstream records. A repeated submission, lost response, or retried integration should not create another supplier unintentionally. The API integration design needs an operation identity and a recovery path suited to that transition. The first release should include those guarantees where the downstream effect is material.

Avoid treating integration discovery as a final implementation task. Test permissions, identifiers, error behavior, and representative records before a delivery estimate assumes the dependency is straightforward. When access is unavailable, distinguish a temporary experiment from an approved production design. A manual export may support learning, but its delay, handling obligations, and operating ownership need to be visible.

Use prototypes to investigate behavior, not approve architecture

A prototype should create conditions in which a representative user can attempt the task and reveal misunderstanding. Ask an applicant to submit a document, correct a problem, and interpret the resulting status. Observe where they hesitate, what they assume happened, and whether they can recover without coaching.

A visual preference is weaker evidence than task behavior. Users may like a clean screen while misunderstanding an important instruction. They may complete a coached demonstration while failing when the same task is attempted independently. The research design should separate those observations rather than collapsing them into a general satisfaction judgment.

Include relevant accessibility needs and experience levels. Include user participation alongside technical accessibility evaluation, because a technically valid interaction can still be confusing or difficult to complete in the intended workflow. For this product, that means testing instructions, errors, focus behavior, and status communication with the people who will actually encounter them. A usable happy path does not establish a usable correction path.

Keep the prototype’s limitations explicit in the delivery discussion. Simulated status changes do not prove the backend can enforce the same transitions. A mocked external record does not prove the organization has the necessary data rights or operational access. The prototype informs the interaction design; the architecture needs its own tests of the dependencies and guarantees it will rely on.

Include the retained operating work in the business case

Suppose the first release reduces repetitive data entry but sends every application to a reviewer. Its commercial value depends partly on the resulting review workload. If the new portal attracts more applications or creates more ambiguous submissions, some front-end efficiency may be offset by additional operating effort.

Measure the work that remains: time spent locating records, interpreting documents, requesting corrections, and resolving duplicates. Distinguish review that requires judgment from rework caused by poor information or interaction design. That separation helps determine whether the next investment belongs in automation, integration, or the user journey.

The product also needs support after launch. Applicant account problems, interrupted submissions, and disputed statuses require a response path. Include the information and permissions support staff need to investigate a case. A team should not have to borrow a developer’s production access to answer a routine question about an application.

Set requirements for sensitive information and retention alongside this operating design. Documents copied into test environments, reviewer exports, and support attachments can create additional handling responsibilities. The first-release scope should minimize unnecessary copies and establish suitable access boundaries. Those choices can affect architecture and delivery effort, so they belong in discovery rather than in cleanup after the interface is complete.

Decide what the release must teach

A first release should have both an operating outcome and a learning objective. For the supplier portal, the operating outcome could be a defined supplier population reaching an approved decision through the new channel. The learning objective could be whether a shared application record and structured correction path reduce avoidable reviewer work.

Measure the complete journey. Registration completion is relevant, but accepted applications, correction cycles, decision delays, and repeated support contacts describe whether the business transition improved. Customer journey measurement should connect interface events to the authoritative application state so a change in instrumentation cannot masquerade as a better product.

Choose the next investment from the findings. If most delays arise from a slow external verification step, additional dashboard features may have little effect. If applicants repeatedly submit the wrong evidence, clearer instructions and correction behavior may outperform deeper automation. If rules vary unpredictably between reviewers, the organization may need to resolve the policy before implementing it in software.

The approval discussion should make those alternatives visible. Commit to a complete, bounded release with known dependencies, operating ownership, and a clear interpretation of success. Then use the observed result to decide whether to expand, revise, or stop. That gives discovery a financial and architectural purpose: it keeps the organization from paying for a larger product before it understands which part of the proposed system will create the value.