How to pivot a startup idea without losing the work

Before announcing a new direction, list the assumptions behind the old one and the evidence for each. Separate customer observations from interpretations and proposals. Identify assets that might transfer: interview notes, waitlists, domain names, design components, integrations, code, or distribution relationships. Do not assume an asset is reusable simply because it exists. Mark what needs review, what remains valid, and what should be archived. This prevents sunk-cost reasoning from disguising itself as continuity.

Without Hark, use a dated decision memo and a simple table with columns for evidence, old assumption, new implication, confidence, and follow-up. Link source material rather than pasting claims without provenance. Tell collaborators which previous commitments are paused. With Hark, keep the former rationale in the decision journal, update the venture's audience and problem statement, and make Current state explicit about what has changed. Preserve only relevant links and artifacts in the project. Proposed changes from an agent should be reviewed; they are not automatically the team's decision.

A pivot is a hypothesis, not proof of product-market fit. Define the next test, the observation that would count against the idea, and when you will review it. Keep the roadmap narrow enough to learn. A clear record is useful when an investor, teammate, or future version of you asks why direction changed. For continuing post-launch learning, see roadmap after launch.

Imagine a billing prototype originally aimed at freelancers. Interviews suggest small agencies have the more urgent problem. The useful output is not “build the agency version.” Write down which interview supports that interpretation, what the freelancer version already does, and which requirements change for agencies. Treat this as an example, not evidence about your own market. Keep a list of unknowns, including who buys, who uses the product, and whether the proposed workflow actually solves their problem.

Without Hark, create three dated lists: keep, revisit, and stop. Put each existing feature or document in one list and give the placement a reason. Select one experiment that can disprove the new assumption before commissioning a larger rebuild. Send that memo to the next builder and ask them to restate the scope before touching code.

With Hark, put the experiment in Work, relevant research links in Inventory, and the new constraint in Authority. Record the accepted change in Decisions; keep uncertain results explicit in Health. Have the agent read the current brief before implementing anything. The working-with-agents connect guide explains the explicit session workflow. Ask for a closing handoff that distinguishes an implemented change from a validated business outcome. When the experiment finishes, compare the result with the original question instead of letting completed code decide your strategy.