Productizing your expertise with AI: start with one slice

You deliver the same work every month. The questions, the analysis, the structure of the report: most of it follows a pattern you could teach. Yet the method still lives in your calendar, and every new client costs you the same hours as the last one.

AI makes the next step feel close. As one Hacker News commenter put it, "now the Subject Matter Experts (SMEs) can directly guide AI ... to translate the vision into code" (HN). Another wrote that productized consulting is "one I've read about but not yet seen delivered" (HN). Both are true: the tools are within reach, and finished products are still rare.

This guide will not explain your field to you. It covers the product decisions: which slice to build first, where AI may draft and where you sign, how to test before you build, and whether to build it yourself.

Find the slice: most repeated, least judgment-heavy

The common instinct is to put the whole method into software. That turns a product into a platform, and platforms take a long time to finish. The better advice is to productize "a slice rather than a platform" (Ship with AI).

To find it, write down every step of your last five engagements, from first call to final handover. Then score each step on two questions:

1. How often does it repeat? Steps you do the same way for nearly every client score high.
2. How much judgment does it need? Steps where you weigh trade-offs, read the room or take responsibility for a recommendation score high on judgment.

Your first slice sits where repetition is high and judgment is low. Typical candidates are intake and data collection, a structured assessment, a first-draft report, or a recurring check. For example, imagine a pricing consultant whose work starts with the same competitor review every time. That review is a strong slice; the pricing recommendation that follows is not.

A good slice also has a clear finish line. The client receives something they can use on its own, even before they speak to you.

Decide where AI drafts and where you sign

Unpredictable AI output is the main risk to your reputation. The fix is not a better prompt. It is a clear rule about which steps AI may complete alone and which ones need you.

A useful default for expert products: AI drafts, the expert signs. AI gathers, summarises and structures. You review anything that carries your name, a recommendation, or a consequence for the client's money, health, legal position or staff.

Write this down before you build, so that whoever builds it, including you, works to the same boundary. Start with two lines that describe the product itself.

[Product name] helps [client type] [complete the repeated step] by [what the software does].
It does not [the judgment call you keep]; that stays with [you or your team] at [the point where you review].

Then add a review rule to your product brief. A brief is the short document a builder works from; this rule tells them where the software must stop and wait for you.

AI may draft: [list outputs, e.g. intake summary, first-draft findings, data tables].
A named expert must approve before the client sees: [list outputs, e.g. recommendations, scores, anything with a figure or deadline].
Every AI draft shows its sources and the input it used, so the reviewer can check it in [target review time].
If the input is incomplete or outside [the cases the method covers], the product says so and routes the client to [you or a call].
Handover rule: the client receives a reviewed result, never an unreviewed draft, unless they asked for a draft and it is labelled as one.

If you want a structured way to work through these boundaries, the AI readiness worksheet asks the same questions step by step.

Test the slice with three past clients first

Before anyone writes production code, put a prototype in front of three clients who have already bought the service. A prototype is a clickable version of the workflow that looks and behaves like the product, but is not yet built for real use. Past clients are the right testers because they know what the result should look like and will tell you what is missing.

Run each test as a working session, not a demo:

• Give them the prototype and a real input from their own case, with their permission.
• Ask them to complete the slice without your help, and watch where they stop.
• Compare the output with what you delivered by hand last time.
• Ask one buying question: would they use this instead of booking that part of your time, and what would they expect it to cost?

You are testing three things: whether they can finish the slice alone, whether the output meets your standard after your review, and whether anyone would pay for it. If two of the three sessions go poorly, change the slice before you build anything.

Build it yourself or work with a team

AI building tools are good, and for some experts building it yourself is the right call. Here is a fair way to decide.

Build it yourself when

• The slice is a form, a document generator or an internal tool used only by you and a few clients.
• No client data that would harm anyone if exposed is stored or processed.
• You enjoy the work and have evenings to spend on it, and a slow first version costs you little.
• You are still testing whether the slice sells, so speed of learning matters more than durability.

Work with a team when

• Clients will log in, pay, or upload sensitive information.
• The product needs to connect to other systems your clients rely on, such as their accounting, CRM or records software.
• Wrong output could damage a client, and you need reliable review steps, logging and testing.
• Your time is the scarce resource, and every evening spent debugging is an evening not spent with clients.

Building alone with AI tools takes you a long way through a prototype. It tends to stall at the parts clients never see: sign-in, permissions, data handling, error recovery and keeping the product running after launch. A sensible middle path is to build the prototype yourself, test it with past clients, then bring the brief and prototype to a team for the production version. If you hire, ask any self-described AI developer to show where the review rule lives in the code and what happens when the AI is wrong.

Keep the client relationship as the moat

A moat is whatever makes your product hard to copy. Competitors can copy a workflow. They cannot easily copy the trust your clients place in your judgment, or the context you hold about their situation. As another commenter put it, "The relationship also builds a natural moat" (HN).

Design the product so it strengthens that relationship rather than replacing it:

• Put your review and your name on the outputs that matter.
• Use the product to bring clients to a better conversation with you, not to avoid one.
• Feed what you learn in reviews back into the method, so the product improves with your expertise.

The goal is recurring revenue that does not depend on your hours, with your judgment still where it matters.

Common mistakes

• Productizing the whole method. Start with one repeated, low-judgment step and a clear finish line.
• Letting AI output reach clients unreviewed. Write the review rule into the brief before anything is built.
• Testing with strangers first. Past clients know the expected result; start with three of them.
• Treating a working prototype as a finished product. Plan separately for sign-in, data handling and maintenance.
• Pricing the software instead of the result. Price against the part of your time and outcome the slice replaces.

Questions experts ask

Your next step

This week, list the steps of your last five engagements and score each on repetition and judgment. Pick the one slice that scores highest on repetition and lowest on judgment, write its two-line boundary statement, and name three past clients you could ask to test a prototype.