Digital Product Consulting

Digital product consulting is the work of deciding which digital products and platforms a company should build, for which demand, and on what architecture, before anyone commits a budget to code. Most things presented to a board as a platform are software with an API. A platform earns the name when the work done for one capability becomes the starting condition for the next, and that property is designed in at the start or it is absent for good. This group decides it, and the five capabilities below build it.

• Since 1999demand, commercial and customer strategy
• 200+published case studies
• 10 officeson four continents
• No vendor tiesno model, platform or cloud partnership sits behind our advice
• The Interaction Fieldwritten by our founder

When companies bring us in

• The roadmap is funded and nothing on it compounds. Years of product investment, a respectable release history, and no asset anyone can point to that is worth more now than it was at the start.
• The second capability costs the same as the first. Each new thing is a fresh build. That is a delivery arrangement wearing the word platform.
• Before a platform or vendor commitment. A standard is about to be set for the whole company before anyone has named the customer situations it is meant to serve.
• The product works and the data sits in someone else’s format. The capability is real and the asset it produces is accruing to a supplier.
• Nobody can say what you own at the end. The question was left to the closing phase of the contract, which means it has already been answered against you.

Why most platform programs do not compound

A product has a fixed value that depreciates as the technology around it becomes ordinary. A platform accumulates something: grounded knowledge of how your business actually works, and a path from outcomes back into behavior, so that use makes the next use better. One of those is a cost that recurs. The other is capital. A great deal of enterprise platform investment is building the first kind while being funded as though it were the second, and the gap shows up two years later, when the thing needs replacing rather than extending.

Three failures produce it, and they tend to arrive in this order. The knowledge is not grounded, so the system answers from general capability rather than from what your company knows. The workflow is not connected, so context is rebuilt by hand at every handoff between tools and approvals, and a technically capable system is practically slow. And there is no feedback path, so outcomes do not change future behavior and the system a year in is the system at launch with more usage on it. Most executives never see the results the business case promised, and the reason is rarely the technology choice.

We design for the third failure first, because it is the one that decides whether the spending becomes an asset or an operating expense. The prior question, before any of it, is which demand you are building to own and what gives you the right to win it. Building quickly toward the wrong demand space is the most expensive outcome available, and it is reached faster by competent teams than by slow ones.

What our digital product consulting services include

Five capabilities sit in this group. Most engagements need two or three, and the first phase decides which, depending on whether the constraint is delivery, data, connection, interaction or the economics between participants. Each can be engaged on its own.

1. The delivery and platform architecture underneath it

How fast the second capability arrives is an architecture decision, not a staffing one. The delivery model, the platform layer and the cloud commitments are set here, and your teams and build partners implement them. That work is technical and DevOps architecture.

2. The data and knowledge layer it reasons from

A platform that answers from general capability rather than from what your company knows is plausible, generic and occasionally wrong in ways nobody catches. Readiness, knowledge architecture, grounding and governance are decided before the build, through data strategy consulting.

3. The connection to the systems where work happens

A capability that cannot reach the workflow is a demonstration. Connecting platforms, applications and partner systems so context travels with the work rather than being rebuilt at each handoff is API system integration.

4. The interaction the customer actually has

Architecture decides what is possible and the interaction decides whether anyone returns to it. Designing the moments where people and the product meet, and tying those moments to a measurable business effect, is digital interaction design.

5. The economics between participants, not inside the firm

Some value is created between participants rather than within the company that convenes them, and that changes what the platform is for. Where the unit of analysis is the ecosystem, the work is AI-driven ecosystem strategy.

How a digital product engagement works

1. Establish the demand. Which customer situations the product serves, stated from the customer’s life rather than from your product taxonomy, and which of them you have the right to own. This is the step that makes everything after it defensible.
2. Test what is already funded against it. Every product and platform initiative in flight placed against that demand and against where value is genuinely defensible, with a stated order, the reasoning written down, and an explicit list of what we would not build.
3. Decide the architecture and what you own. Knowledge held in your architecture rather than a supplier’s, technology choices made per workload and kept reversible, governance placed inside the workflow, and ownership of the system, the data and the IP settled in writing at the start.
4. Build, measure and hand over. We build where building is the fastest route to proof, with a feedback path designed before launch rather than retrofitted after it, and a handover plan naming who operates it afterwards. A platform your team cannot run without us is a dependency, not an asset.

Why companies choose Vivaldi for digital product and platform work

• We start at demand, not at the backlog. The order comes from where the business can win, which is the only version of the question with a defensible answer.
• We have nothing to sell you downstream. No model, platform or cloud partnership sits behind the recommendation, so advising you to buy rather than build costs us nothing.
• We build as well as advise. Our recommendations come from decisions made under real constraints, including on Fifth Season, the intelligence platform we are building for expertise-driven businesses.
• Ownership is settled at the start. The system, the data, the knowledge architecture and the capability to operate all three, named in the contract rather than negotiated at the end.
• We will tell you what not to build. The exclusion list is usually the more useful half of the work.

How to evaluate a digital product consultant

Worth asking of every firm on your shortlist, including us.

• What does the second capability cost? If the answer is the same as the first, you are buying delivery rather than a platform, and it should be priced and governed as delivery.
• Who owns the data, the knowledge architecture and the IP? Ask for the answer in the contract, not in the pitch. Settled at the end means settled against you.
• Who are they partnered with? A firm with a commercial relationship to a platform or model provider is not a neutral advisor on which one you should use. That is structure, not dishonesty. Ask, and weigh the answer.
• What happens when the technology underneath changes? The answer should describe a deployment decision, not a rebuild.
• Describe a build you advised a client against. A firm that has never talked a client out of a platform has either been lucky or has not been advising.

Strategy consultancy, product studio or platform vendor?

Where this work sits

This group is part of business technology strategy at Vivaldi, the firm behind the Demand Landscape and the Interaction Field. Two neighboring groups answer questions this page does not. If the prior question is where artificial intelligence and emerging technology change your economics at all, and in what order, that is AI technology consulting. If the product already exists and the problem is that the channels around it do not pass customer context to each other, start with connected commerce. Our thinking on when a product should become a platform at all is set out in platform business transformation and in how to design a platform business.

Digital product consulting in the US and worldwide

Vivaldi is headquartered in New York and has a second US office in Los Angeles. Outside the US, our teams work from London, Zürich, München, Hamburg, Düsseldorf, Singapore, Buenos Aires and Lima. We work with US companies nationwide from our two US offices. Read who Vivaldi Group is and how we work.