Good technology decisions start with a clear problem and a realistic view of the work involved. This guide sets out the questions we would bring into a discovery conversation, the tradeoffs to examine and the evidence worth collecting before committing to a delivery plan. The aim is practical clarity for Australian product teams and business owners.
Define the learning goal
A minimum viable product should test a meaningful assumption, not compress every future feature into a short deadline. Decide which behaviour would justify further investment and how you will observe it. Pick one primary user group and one coherent journey. Write down what the first release intentionally leaves out so stakeholders can distinguish a deliberate decision from a missing requirement.
For a booking product, the first learning goal might be whether a customer can find and reserve a suitable appointment without calling. A loyalty programme or a complex referral system does not help answer that question initially. Write the success condition in observable terms and identify the evidence you need. That gives the team a principled way to decline additions while keeping the customer’s actual task complete.
Weeks one and two: reduce uncertainty
Interview users, map the journey and test a lightweight prototype. Investigate the integration or policy question most likely to change the plan. Establish a prioritised backlog, delivery responsibilities and a release checklist. If a core assumption fails, change the approach now. A fixed date should encourage clearer decisions, not prevent you from responding to evidence.
End discovery with a short release narrative: a named user encounters a problem, uses the product to complete a task and receives a clear result. List the dependencies that could interrupt that story. A prototype tests the experience; a technical spike tests the uncertain integration. Neither needs production polish, but both should produce evidence that changes the delivery plan or confirms a consequential assumption.
Weeks three to six: build the spine
Deliver one end-to-end journey before adding secondary features. Connect authentication, core data and deployment early so architectural assumptions are tested in working software. Show progress frequently and keep feedback focused on the agreed learning goal. Use explicit acceptance criteria to avoid polishing low-impact details while a critical dependency remains unresolved.
An early vertical slice might let a test user sign in, create a record, see its status and retrieve it in a second session. It can look simple while exercising the important connections. Demonstrate it from the shared environment rather than from a local machine. That makes configuration, deployment and permission problems visible while there is still time to change the approach.
Weeks seven to nine: make it dependable
Strengthen error handling, accessibility, permissions and operational visibility. Test realistic data, interrupted sessions and the less common states in the journey. Prepare support materials while the interface is still being refined. Reserve capacity for issues discovered by real users instead of treating all remaining time as available for new features.
Keep a release-readiness list next to the feature backlog. Include the empty states, permission errors, cancellation paths and recovery steps that make the primary journey dependable. Assign owners to unresolved issues and distinguish a genuine release blocker from a later improvement. This protects the final weeks from becoming a scramble in which the most visible request always displaces the most important remaining work.
Weeks ten to twelve: launch to learn
Rehearse deployment and rollback, confirm who watches service health and agree how feedback is triaged. Release to a manageable audience before opening access more widely. Measure completion of the core journey and talk to people who abandon it. A launch is useful when the team can interpret what happened and respond, not merely when a URL becomes public.
Agree before launch what happens when a person gets stuck. The support route should be visible in the product, and the delivery team should know how a report becomes an investigation. Collect the context needed to reproduce a problem without asking users to send sensitive information unnecessarily. The first cohort is an opportunity to learn from real use, not simply to celebrate a release milestone.
After the first release
Compare the evidence with your original assumption. Decide whether to improve the journey, test a different audience or stop investing in the idea. Document the decision before the next feature discussion takes over. Twelve weeks is a planning pattern, not a promise for every product; external approvals and complex integrations may require a different schedule.
A first-release review should lead to a decision. Perhaps the core task works but onboarding needs attention; perhaps a different audience is responding; perhaps the assumption was wrong. Keep that conclusion separate from the backlog of requests. A product can accumulate attractive improvements without answering its original business question. The next investment should follow the evidence you set out to collect.
Bring the right questions to the table
Before choosing a supplier or solution, write a short decision brief. Describe the outcome you need, the constraints you cannot change and the assumptions you can test. Ask your team to review it from the perspective of customers, operations and ongoing ownership. Differences in those perspectives are useful: they often reveal an overlooked requirement before it becomes expensive to change.
You do not need a perfect specification to begin a conversation. You do need a shared understanding of the next decision. BonsaiCo can help frame a discovery engagement, work through options and prepare a practical delivery plan. Start small, make the work visible and let evidence guide the next stage of growth.