“Just-in-time” requirements: when to move from exploring solutions to a delivery plan tied to business value

Amy Mitchell's article (Product Management IRL) addresses when it makes sense to write product requirements and when it's too early to do so. Her proposal is not to lock down all requirements at the outset, but to maintain a living outline that connects what teams are learning to the business opportunity, and to consolidate it into formal requirements only when delivery depends on a shared understanding.

The starting scenario is a product team exploring a solution that leadership has made a priority. The team's charter is to scale an existing product into a new market. Because it is a priority, four teams explore solutions in parallel: engineering investigates a developer kit to scale through automation; support studies how these customers will want to get help; product management considers how to build a community around the new customers; and platform product managers look at educating customers on the technology. The teams make progress, but neither the business opportunity nor the requirements for the overall solution have been defined yet.

The author stresses that leadership backing is a reason to explore in parallel, but it doesn't on its own decide what to build or how much to invest. Each sub-initiative ends up identifying work that needs people and budget, and gaps open up between the pieces. Her examples: a development kit for installing the product with no plan to maintain it; a support team with the know-how but no way to route customer queries to it; customer contacts for a community with no way to engage them; and training material on the product but not on its installation. The key question is whether the combined solution will achieve the business outcome and what investment it requires.

On why writing requirements too early can slow a team down, the piece explains that when requirements are unclear, solution and feasibility decisions go around in circles. She gives the example of one team that depends on IT changes while another doesn't want to commit to manual customer follow-up: everyone is willing to explore alternatives, but no one can commit alone. Trying to nail down all requirements before exploring trade-offs delays progress; simply letting teams explore creates another problem, because one team's choices affect the others. So instead of requirements and plans, she proposes capturing what the team is learning and connecting it to the business opportunity.

That "living outline" is built alongside the exploration and rests on customer benefits and organizational constraints. The first component is the customer journey across the usage lifecycle: purchase, implementation, ongoing use, maintenance and renewal. It helps explain why customers buy, how the solution creates value over time (usage, expansion, renewal) and what they need to succeed (performance, quality, support and maintenance). This view changes as the team talks to prospective customers, and trade-offs also emerge from the possible solutions.

The second component is an initial estimate of the business opportunity. According to the piece, there are too many combinations to produce a forecast, but a rough order of magnitude can be reached in two ways. The first is a market analysis: take the size of the serviceable market, estimate the percentage the solution covers and apply the usual success rate. The second is by analogy: review the launch of a similar product or feature, your own or someone else's, find its growth rate in revenue or units and apply it to estimate the opportunity. Either way, the result is an initial estimate.

Placing the customer journey alongside the business opportunity is valuable for parallel explorations: the opportunity establishes how much investment is justified, and the journey identifies the capabilities and ongoing costs that opportunity requires. The living outline is a working summary that changes as the team learns and serves to compare approaches and understand how each decision affects the overall solution. It includes the customer journey, the rough opportunity and its assumptions, constraints and likely cost drivers, and the open questions and decisions affecting the team.

The author points to three signs that it's time to formalize requirements: teams keep revisiting effort estimates because scope or dependencies are unclear; decisions get reopened because one team's approach changes another's requirements or costs; and leadership asks for a stronger business case before committing people or budget. At that point, requirements stop being pending documentation and become the shared decisions the team needs to move forward.

AI's role, according to the article, is to consolidate the living outline into four connected artifacts: a business case (opportunity, expected value, investment, costs and assumptions); the requirements (what the product must do, with constraints and acceptance criteria); a delivery and maintenance plan (work, dependencies, owners and ongoing effort); and a readiness summary (what is resolved, what remains uncertain and which trade-offs need leadership sign-off). The author cautions that the team must validate the outputs and resolve the decisions that affect investment: AI speeds up consolidation, but it doesn't replace agreement.

In conclusion, the approach is to explore while the solution is uncertain, keep the customer outcome and business opportunity visible, and consolidate what has been learned once delivery depends on a shared understanding. The resulting document gives teams a shared foundation for delivery, gives leadership enough information to commit the investment, and gives go-to-market teams a clearer idea of what the solution will do and what it's worth.

The article closes with a Q&A section. It distinguishes the living outline (which connects what is learned about the customer, opportunity, constraints, costs and decisions), the business case (which explains why the investment is worthwhile) and the requirements (which define what the product must do). It argues that this is product management's responsibility because whoever holds that role connects the customer problem to the business opportunity, while program managers can use the same context to coordinate dependencies and track delivery readiness, and each team remains responsible for its own technical and operational decisions. As for what happens if requirements change after commitment, it answers that they are not a promise of immutability: new customer evidence, technical findings or cost changes may require changes to scope, timeline or investment, so the impact must be made visible, the shared requirements and plan updated, and agreement obtained from those whose commitments are affected.

Editor's note: the downloaded text is the full article (not a paywall teaser), although it includes links to other materials by the author that could not be consulted, so this summary is based solely on the content received.