Discovery and scope
Define the users, problem, core journey, boundaries, and assumptions behind the first release.
Product development teams for startups
Build the first release around the user problem you need to test. ACW connects scope, design, engineering, and release preparation so founders can review the product and its investment requirements together.
Explore the startup delivery scopeContact UsEstablish what the first release needs to teach you
An early product can accumulate features before the team agrees which behavior would justify further investment. Separate the core user journey from features that can wait, and identify assumptions that need research or a prototype first.
Connected product and engineering work lets those choices inform the build. Launching software provides evidence about its use; it does not automatically validate market demand or willingness to pay.
Take the selected scope through delivery
What the founder and team can review
Outputs can include a first-release scope with exclusions, product designs, implemented functionality, test evidence, and a release checklist. A measurement plan states which user actions or findings will inform the next decision.
The result is a defined release and an explicit basis for reviewing what to improve, investigate, or defer. Architecture decisions reflect known requirements and assumptions rather than a promise that no future rebuild will be needed.
Commit in stages as uncertainties are resolved
We begin with the product context and available evidence, agree the discovery questions, and develop the release scope. Design and technical reviews expose issues before implementation commitments expand.
Development, QA, and release preparation follow the agreed scope. A post-release review can be included to examine usage and feedback with the founder.
Define release acceptance and the next decision
Agree critical user flows, supported environments, integration dependencies, test criteria, and handover materials. State who recruits initial users, provides content, and approves decisions.
Fundraising, ongoing acquisition, and support need explicit scope rather than being implied by startup development.
Illustrative example
A first booking product
A founder wants users to find an available service and request a booking. The first scope could focus on that journey, with clearly defined operational handling behind it. Tests and measurement would examine whether users can complete the flow and which assumptions remain unresolved before expanding functionality.
Questions from startup founders
Do we need to build before speaking to users?
No. Interviews, workflow research, or a prototype may answer an important question before production software is needed. Choose the method around the uncertainty.
Can we launch with some manual operations?
Where appropriate, the scope can define manual steps, their owner, capacity, and effect on users. Security and critical operational requirements still need assessment.
Does a launched MVP mean the idea is proven?
No. Define the question and evidence needed in advance, then assess usage, feedback, and commercial signals within their limits.
Bring the user problem and the assumptions behind it
Tell us what the first users need to do and what you need to learn before investing further.