Skip to content
Parikh AdvisoryLogic Before Code

Go-to-Market & Positioning

A Working Product Is Not Necessarily a Market-Ready Product

Technical readiness and commercial readiness must meet.

A working product still needs a buying journey.Technical readiness and commercial readiness must meet. Customer can achieve the promised job Buyer can approve and adopt the offer Team can fulfil support and delivery promises. Procurement or support gap → narrow the launchCan use, cannot buyControlled launch?Investigate bothBuying interest,product gapBuyer and commercial readiness →Productreadiness↑
A working product still needs a buying journey.Original conceptual illustration · not a client case

The decision in a glance

A working product still needs a buying journey.

Product readiness and market readiness overlap but are not identical. Buyers need an understandable promise, pricing logic, procurement confidence, onboarding, support, commercial evidence and suitable distribution. A working demo does not prove that a buyer will authorize the purchase or that the product can be operated repeatedly. Use a readiness review that tests both the user journey and buyer journey.

Follow the visual explanation ↓

The business situations in this article are fictional illustrations, not accounts of Parikh Advisory client engagements.

A product can pass its tests and still fail its first sale. The demo works, but the buyer cannot understand the offer, procurement cannot review the controls, onboarding requires the founder, and support has no owner. Technical completion is one input to launch readiness. Market readiness asks whether a customer can discover, buy, start and receive value reliably.

Separate readiness dimensions

Check the product journey, evidence of demand, pricing and contract, acquisition route, onboarding, support, security and operational capacity. A green test suite covers only part of this map. The required bar differs by segment: an enterprise buyer may ask for information a small self-service customer does not. Define the intended launch audience before calling the product ready.

Visual explanation · 01

Follow the situation

  1. Customer can achieve the promised job
  2. Buyer can approve and adopt the offer
  3. Team can fulfil support and delivery promises
  4. Procurement or support gap → narrow the launch
Technical readiness and commercial readiness must meet. The exception path matters as much as the expected route.Illustrative framework · no client data

Follow a real buyer

Take a target buyer from first contact to first value. What problem statement gets their attention? Who approves the purchase? What proof, reference or documentation do they request? Can the team explain the price and the implementation effort? Ask someone outside the build team to attempt the journey. The friction they encounter is launch work, even if it is not a software defect.

Run an operational rehearsal

Simulate an incomplete signup, wrong invoice, stalled integration and support escalation. Identify the owner, response path and evidence retained. A launch can be narrow if the team can serve a defined first cohort well; it need not pretend to cover every segment. If core controls or contractual obligations remain unresolved, make those explicit gates rather than burying them in a marketing date.

Visual explanation · 02

Compare the next moves

  1. Product: Test reliability, usability and operational dependencies.
  2. Buyer: Clarify value, pricing, procurement and onboarding.
  3. Delivery: Ensure the team can keep the commercial promise.
Use these choices to frame the next commitment. There is no automatic winner.Illustrative framework · no client data

Decide what the launch should prove

Set a handful of measures: qualified demand, time to first value, activation, repeat use, support burden and commercial conversion where appropriate. Give each a baseline and interpretation. A working product may need a customer discovery cycle, a clearer offer, a tighter pilot or stronger operations before broad promotion. Release only as widely as the organization can learn from and support.

The next decision

Have someone outside the build team attempt the first buyer journey and document every point requiring a founder rescue.

Source note: GOV.UK Service Manual, define success and performance data. Examples are illustrative; the linked source supports the decision method, not the hypothetical business.

Sources & scope

Related primary reading is provided below. The decision framework and fictional examples are Parikh Advisory’s analysis; these references do not establish that the illustrated events occurred.

  1. Understand users and their needsUK Government Digital Service