I have a soft spot for side quests.
They are often where a team notices a user job that does not fit the current roadmap, a strange behavior that might become a product, or a capability the core business has never learned to use.
The danger is not that the idea sits to the side.
The danger is that a small exploration starts making roadmap-sized claims before it has earned them. A prototype needs production data. The pilot needs another integration. A promising conversation becomes a quarterly commitment. The team keeps funding momentum because stopping now would make the prior work feel wasted.
I want a side quest to buy information before it buys a roadmap.
Treat the first investment as an option
Real options are a useful analogy. A financial option gives its holder the right, not the obligation, to take an action later. In strategy, a limited early investment can preserve the opportunity to invest more after uncertainty changes.
A product prototype is not a traded financial instrument, and a real-options analogy does not give us a ready-made valuation formula. What transfers is a way to separate today’s bounded commitment from tomorrow’s much larger one.
We are not buying a miniature version of the final business. We are buying the right to make a better next decision.
That framing changes what belongs in the first build.
Imagine a hypothetical invoicing product whose small-business customers keep asking for cash-flow forecasting. The roadmap-sized version includes bank connections, categorization, scenarios, alerts, permissions, and mobile support. The information-sized version might use uploaded invoices and a manually confirmed expense file to generate one four-week projection for twelve research participants.
The smaller version is intentionally incomplete. Its job is to learn whether customers make a different near-term decision when they can see the projection, not whether the team can build an entire forecasting suite.
Reversibility protects the learning question
Amazon describes one-way and two-way door decisions in its 2015 shareholder letter. The popular shorthand can become too casual, but the distinction is useful. Some choices are easy to reverse and should be made with lighter process. Others create commitments that are expensive to undo.
A good side-quest prototype keeps as many doors two-way as possible.
Use a manual operation before building a rules engine. Import a file before negotiating a permanent integration. Recruit a bounded group before exposing every customer. Promise a defined research period rather than an indefinite beta. Avoid changing core data models until the behavior is clearer.
This is not an argument for fake products or careless prototypes. Participants should know what is manual, how their data is handled, and what may disappear. Reversibility for the company cannot become unreliability for the user.
The UK Government Service Manual guidance on using prototypes emphasizes choosing the right fidelity to test an assumption. That is the discipline I want. Build enough reality to answer the question, not enough surface area to create institutional gravity.
Expiry is part of the design
Side quests linger when they have a budget but no expiry.
The team spends four engineer-weeks. Early users seem interested. Nobody has specified what evidence unlocks another four weeks, so interest becomes the exercise condition by default.
An option should expire. By a particular date, the team should exercise it, redesign it around a newly discovered question, or let it close.
Expiry prevents a pilot from becoming an unofficial permanent service. It also makes research sharper. If the decision is due in three weeks, the team has to recruit the right participants, observe the important behavior, and distinguish flattering feedback from decision-grade evidence.
The artifact I want is an option card
Keep it small enough to sit beside the prototype.
Opportunity
Help invoice customers anticipate a short cash gap before bills are due.
Learning question
Will a four-week cash projection change a real payment, collection, or spending decision for customers with irregular income.
Reversible prototype
Generate one projection from uploaded invoices and a confirmed expense template, with manual review disclosed to participants.
Capped spend
Three weeks, one designer, one engineer, and twelve research participants. No production bank integration.
Expiry
The card closes three weeks after the pilot starts, even if recruitment or results are incomplete.
Exercise condition
At least five participants use the projection in a documented near-term decision, the decisions match the job we intend to serve, and no unresolved trust problem makes automation irresponsible.
Abandon condition
Participants treat the output as interesting but do not use it, or accurate-enough inputs require ongoing service work that breaks the intended model.
My hypothesis would stay close to the learning question.
If customers with irregular income can see a credible four-week range from information they already maintain, some will change the timing of a collection, bill, or discretionary purchase.
These participant counts are hypothetical decision rules for a small discovery pilot, not evidence of a population-level effect. A promising result would justify a better-powered next step. The artifact makes the next commitment conditional. A few enthusiastic interviews do not automatically exercise the option. Neither does completing the prototype.
A side quest should return a decision
Some explorations will reveal a large adjacent opportunity. Others will expose a narrower feature, a partnership, or a job the company should not pursue.
All of those can be good returns if the question was worth asking.
The waste is not a prototype that ends. The waste is an exploration that accumulates commitments while leaving the original uncertainty intact.
Before giving a side quest a roadmap, I would give it a learning question, a cap, an expiry, and an exercise condition. That lets curiosity stay ambitious without asking the organization to pretend curiosity is already strategy.
