Book page Appendix C: Build Permission Checklist

Appendix C

Build Permission Checklist

Introduced in Chapter 4. Reused in Chapter 21.

A feature request is evidence that somebody wants a feature. Build Permission asks whether there is evidence that building it changes buying behavior. The larger the build and the weaker the evidence, the more valuable it is to test the commercial assumption first.

Before an important feature enters the roadmap, answer:

  1. Who needs this? Paying customers, qualified prospects, free users, one vocal person, or the founder. Label the source accurately. There is nothing wrong with wanting a feature; there is something wrong with mislabeling why.
  2. What do they do today without it? The workaround, or the absence of one.
  3. What financial or operational consequence exists? For the person in question 1, in their terms.
  4. What decision is blocked? Specifically. “They would like it” is not a blocked decision. “They cannot begin the evaluation without it” is.
  5. What commitment has been made? Verbal interest, agreement to evaluate, acceptance of a price, a dated conditional commitment, a paid pilot contingent on the feature, or nothing.
  6. What result would justify the build? Written before the build starts. If the feature ships and this result does not follow, what will you conclude?

Decision rule. A feature with concrete answers to 4 and 5 from a qualified buyer has Build Permission. A feature with strong answers to 1 through 3 and weak answers to 4 and 5 is a hypothesis: ask the requester what they would commit to if it existed, and let the answer decide. A feature the founder wants for product reasons can still be built; it should not be described as monetization work.

The one question that saves the most time. If we deliver this by an agreed date and the rest of the product performs as demonstrated, are you prepared to proceed at the proposed terms? The answer is the evidence.