Digital Product Consultant vs Developer: Why Strategy Has to Stay Connected to Build

Splitting 'strategy' and 'build' looks adult on a slide. In practice it is how products get a beautiful specification and a codebase that cannot run it. A digital product consultant who never touches the repo is writing fiction. A developer who never owns the product decisions is closing tickets on a moving target.

I work as an AI Product Engineer and product developer: strategy that has to survive auth, data, CMS, and the first real users. I stay through build. That is not a slogan. It is the only way the strategy stays honest when a Sanity schema or a Supabase policy disagrees with the deck.

This is a different job from a website strategy consultant, and a different job from a fractional CTO. If you hire the wrong one, you will get either a marketing sitemap or an architecture lecture, and still no shippable product.

Why the strategy / build split fails

The split fails because the expensive decisions are implementation-shaped. 'Users can invite teammates' is strategy until you hit seats, roles, email, and what happens when someone leaves the company. 'Marketing can publish without engineering' is strategy until you choose a CMS, preview, and who can break production.

Another failure mode: the strategy vendor optimizes for alignment workshops. Alignment is useful. It is not a data model. I have watched teams leave a two-day offsite with a north star statement and still no decision on whether the marketing site and the app share a domain, a design system, or a CMS. Those three decisions change the build more than any vision paragraph.

AI features make the split worse. A slide that says 'AI assistant' has no acceptance criteria. In the repo you need prompts or structured outputs, evaluation examples, rate limits, logging, and a fallback when the model is wrong. If the consultant will not write those constraints, the developer will invent them under deadline, and the product will behave like a demo forever.

Agencies love the split because it sells two retainers. Founders love it because it feels like governance. Then the strategist leaves a 40-page Notion, the developers estimate from a Figma that skipped empty states, and nobody owns the gap. Six weeks later everyone agrees the spec was 'unclear.'

• The spec assumed a CMS field that the chosen tool cannot query cleanly.
• Auth was 'we will use a provider' with no decision on SSO, invites, or admin.
• SEO URLs were designed after routes were already coded.
• AI features were promised as magic, then scoped as unbounded API spend.

If the person who wrote the roadmap cannot sit in the pull request review, the roadmap is a wish list.

What a digital product consultant should own

Own the problem, the constraints, and the first version that can be used. Not every backlog item. Not the brand film. The consultant should be able to say what we are not building this quarter, and why that protects the product.

1. A written product boundary: marketing site, app, admin, and what stays out of v1.
2. A data and auth sketch that names the real entities, not 'users and content.'
3. A CMS or content plan if marketing pages and the product share a domain.
4. A build sequence with one vertical slice you can demo, not 12 parallel workstreams.
5. A stay-through-launch rule: who is in Slack when production auth breaks.

If they cannot talk about empty states, permissions, and what happens when a webhook retries, they are a workshop facilitator. Hire them for facilitation. Do not hire them to 'own product.'

Ownership also means saying which tools you will not add. A product consultant who collects a new SaaS every workshop is not reducing risk. The stay-connected version of the job is to pick the smallest stack that can run the slice: one app framework, one auth, one CMS if you need publishing, one database. Extra tools need a named owner or they become archaeology.

Where a developer-only engagement breaks

A strong developer will build what you asked. That is the problem if you asked for the wrong thing. Without someone holding the product line, scope creeps through tickets: one more role, one more export, one more AI button. The repo grows. The story does not.

Developer-only also fails on the surfaces that feel like 'just frontend': SEO for the marketing routes, redirects from the old site, preview for editors, and analytics that match the conversion you actually care about. Those are product decisions with technical teeth.

Strategy that has to survive the codebase

I treat strategy as something you can implement this month. That means Next.js route structure, Sanity document types, Supabase tables and RLS, or whatever stack you already have. It also means saying no to an AI feature that cannot be evaluated, logged, or paid for.

On AI product work specifically, the consultant should force structured outputs, fallbacks, and a definition of done that is not 'it felt smart in the demo.' If the strategy doc cannot name failure modes, it is not ready for build.

This is why I still write public-site discovery as a separate job. If the 'product' is mostly a marketing site, start with what website strategy discovery should cover. Do not put app auth on that invoice.

How this differs from a website strategy consultant

Website strategy is ICP, IA, offer, proof, SEO inventory, CMS for publishing. Digital product consulting is the authenticated system: accounts, data, workflows, and the admin someone will hate at 11pm. They overlap on the public pages that sit next to the app. They are not the same hire.

A website strategist who has never shipped auth will over-promise personalization. A product consultant who has never shipped a marketing site will trash SEO URLs because 'the app router is cleaner.' You want someone who has been burned by both.

Shared domain work is where the two roles collide. Logged-out marketing pages and logged-in app routes on one host need one owner for trailing slashes, canonicals, and which sitemap they belong to. Split vendors will each assume the other did robots.txt. That is how you index app search params and noindex the blog.

How this differs from a fractional CTO

A fractional CTO ranks bets across the whole technology function: hiring, vendors, security baseline, what to stop. They may not implement your Next.js app. A digital product consultant should be close enough to the build to change the spec when the database disagrees.

If you need someone to kill vendor sprawl and set a hiring bar, that is fractional CTO territory. If you need a v1 that ships with auth and a CMS the team can run, you need a product developer who will not disappear after the workshop.

Stay connected: one owner through launch

The model that works for the companies I take: one person (or a tiny studio) who can write the boundary, implement the risky slice, and remain accountable when marketing asks for a field on Friday. Agency strategy plus offshore build plus a project manager in the middle is how you buy delay.

Week one should produce the boundary and the vertical slice, not a 40-page research appendix. Week two should touch the real auth or the real CMS, even if the UI is ugly. Week four should be something a user can click without a staging password that only the agency knows. If the first month is only workshops, you hired a facilitator.

Staying does not mean unlimited Slack. It means a named owner for product integrity, a decision log, and a rule that spec changes go through the person who will implement them. When a new role appears in a sales call, that owner either adds it to the model or says no this quarter.

I price and schedule this as product work, not as a slide deck. The deliverable is a running slice plus the written boundary, not a workshop recording. If a candidate wants a month of research before they will open the repo, they are selling consulting hours, not a product. That can still be useful. It is not the job in this article.

That does not mean one person does every pixel. It means one person owns the integrity of the product decisions. Designers, specialists, and extra engineers can join. They should not be the only people who understand why a table exists.

When you are ready to put numbers on that build, the scoping question is not 'agency energy vs freelancer energy.' It is whether the statement of work includes auth, CMS, SEO preservation, and repo ownership. I wrote that up as how to scope a real Next.js product build.

A briefing test you can run this week

1. Write the v1 user and the one job they complete.
2. List the systems that already exist (auth, CMS, CRM, billing).
3. Circle the decisions that are still political.
4. Ask the candidate to mark what they would implement themselves versus what they would only advise.
5. If they will only advise, you still need a builder. Budget for that, or hire someone who does both.

Ask them to critique your current architecture live, the same way you would interview a fractional CTO, but keep the focus on the product slice you want shipped. If they cannot talk about migrations, empty states, and who owns production env vars, they will not survive contact with the codebase.

I would rather own the product long enough to see the first real users than drop a strategy PDF and vanish. If you want that kind of engagement, send the current app or the Notion spec. I will tell you whether the split is already the problem.