The gap between a good idea and a shipped product is rarely engineering. It’s the translation layer: what exactly are we building, for whom, and what does done mean? That’s the layer this practice owns.

What this covers

Product strategy and discovery — stakeholder interviews, customer research, competitive analysis
Roadmaps and prioritization that say no out loud
Requirements engineers can build from without a translator: PRDs, user stories, acceptance criteria
Vendor evaluation, build-vs-buy analysis, and technical feasibility
Delivery: release planning, UAT, engineering and QA coordination
Launch, adoption planning, and documentation people actually read
Product analytics, KPI development, and experimentation

How the work runs

It starts with the decision, not the feature. Before I book a single interview I write the sentence the engagement has to end in — by the end of this you will have decided whether to build it, buy it, or drop it — and everything in discovery exists to answer it. Discovery with no decision attached is research, and research is where product work goes to die quietly.

Discovery begins with interviews and reviewing existing material. I talk to the people who will live with the thing, not only the people who asked for it. I read what already exists: the backlog, the requirements document nobody finished, the support queue, the spreadsheet somebody built because the product does not do the thing. Workarounds are the most honest documentation in any organization. A team running a weekly export into a spreadsheet is describing a requirement out loud — they are just not using the word.

Then the cutting. You get a list of everything anyone has asked for, ordered, with the reason written next to each item, and a “not now” column naming what is being dropped and why. A roadmap that contains only yes is a wish list. The argument about the not-now column is the useful part, and it is much cheaper in week three than in a retro in month nine.

Requirements come after the cut, never before. Context, behavior, edge cases, and what done means — written so an engineer can build from them without a translator. If I stay through delivery, I write the acceptance criteria, sit in the standups, answer the questions the requirements did not anticipate, and run UAT. The person who wrote the requirement should be the person who says whether it was met. Handing that off is how a build drifts.

What you leave with

Artifacts, not a deck. Each one is built to be usable by somebody who was not in the interviews:

A one-page decision memo — the recommendation, the options I rejected, and what would have to be true for me to change my mind
A roadmap with the reason attached to every item and a dated not-now list
Requirements with acceptance criteria: context, behavior, edge cases, and a definition of done an engineer will accept
A scored shortlist when there is a build-vs-buy or vendor choice, with criteria and weights fixed before anyone watches a demo
A scope somebody can sign, including the part that says what is outside it
The measurement — the two or three numbers that will say whether this worked, each traced back to the row that produces it

Inspect a worked product brief

This fictional example shows the shape of a discovery deliverable. It is not a client case study, a shipped product, or a claim of measured results. The request: “We need a portal so customers stop asking for status updates.”

Start with the decision

Decide whether a self-service status page would answer a recurring customer question reliably. Before choosing software, inspect recent status inquiries, interview the people answering them, and identify who owns each status change. If the underlying records are unreliable, a portal would expose that problem rather than solve it.

Define one useful release

A signed-in customer can view their own request, its current stage, the last update time, and what happens next. An authorized operator can update the stage. The first release excludes payments, document uploads, live chat, and automated predictions of completion dates.

Make “done” testable

Correct record: a customer with two requests sees both with the matching reference and status. A customer with no requests sees an explanation and a contact route.
Private by default: changing a request ID in the address or API call never reveals another customer’s record. The server enforces access.
Honest freshness: each status includes its recorded update time. If the source is unavailable, show that the status cannot be confirmed; do not invent an update.
Recoverable updates: a failed save leaves the operator’s input available and offers a retry. A success message appears only after the server acknowledges the update.
Usable on a phone: the customer can read the status and reach help using touch or a keyboard, without horizontal page scrolling.

Choose evidence before promising an outcome

Measure status inquiries per active request before the pilot, then compare a defined pilot period while recording changes in request volume and complexity. Test whether customers can find and explain their next step without coaching. Watch for stale records, access failures, and increased support work. Set success thresholds with the team after establishing the baseline; no reduction is assumed here.

The handoff is a decision brief, a bounded release scope, acceptance scenarios, and a measurement plan. Use this structure for your own idea, or bring the uncertain decision to Kenny. Discovery determines whether to proceed; implementation is scoped separately.

When this is not the right call

If you already know exactly what to build and the problem is that nobody is building it, you need engineers, not me. A product person dropped into that room produces good documents about work that is not happening. Hire the builder first.

If the decision has already been made upstairs and what is wanted is a document that supports it, this will go badly. I write down what I find. Sometimes what I find is that the thing you are about to build is the wrong thing, and that goes in the memo.

If nobody on your side can give a few hours a week, wait until somebody can. Discovery runs on access — to users, to the support queue, to the person who remembers why that field exists. Without it I would be guessing, and guessing with more confidence than you, which is worse than hiring nobody.

And if the product works and too few people know it exists, that is a positioning problem. Rewriting the roadmap is an expensive way to avoid it.

Explore the method

Work through the method in the lessons below. Free lessons require an account; Series lessons also require eligible learning access. Each lesson link is labelled so you can check the requirement before starting. Learning paths may contain lessons with different access requirements.

Run a discovery that ends in a decision (Series access required) — how to write the decision down before you book the first interview, so the work cannot end in a document nobody acts on
Cut a roadmap in half without losing the outcome (Series access required) — a cutting method that survives the people who asked for the items you cut
How to write product requirements engineers actually understand (Series access required) — the format itself: context, behavior, edge cases, and what done means
Write requirements engineers respect — the full sequence, from a vague ask to a document a team can build from

If you run that yourself and the roadmap comes out clear, you did not need me. That is a good outcome.

Start with the product strategy assessment

A scoped review of one product or portfolio: the decision to make, the evidence available, the main constraints, and a recommended sequence of work. The proposal defines deliverables, access, timing, fees, and exclusions.

Agree on the engagement

Start by describing the problem and what would make the work useful. The proposal defines the deliverables, responsibilities, access needed, acceptance criteria, fees, and timing before paid work begins. Implementation, third-party tools, production changes, and ongoing support are included only when explicitly scoped.

Work with Kenny. Sending an inquiry does not commit you to an engagement or require permission to publish your work.

Strategy to implementation

Kenny can carry the work from assessment into requirements and delivery support when those stages are included in the agreed scope. See all six service families, or start a conversation.

Digital Products