Digital Product Development Consulting

Digital product development consulting is the work of turning a funded idea into a specific product that exists: what it is for, who gives up what to use it, what the first release contains, and in what order the rest gets built. It is narrower than deciding which products a company should have, and it starts earlier than the engineering. Vivaldi has done this work since 1999.

Vivaldi is a strategy firm, not a software development shop. We do not write code, staff engineering teams or ship releases. We work on what the product is, what the first release has to contain to be worth paying for, and the sequence the build follows, alongside your engineers or your build partner. Saying so early saves a wasted meeting.

• Since 1999product definition and creation work
• 200+published case studies
• 10 officeson four continents
• 5xWirtschaftsWoche Best of Consulting, Strategy and Innovation

When companies bring us in

• A product is funded and staffed, and nobody can state in one sentence what it replaces for the person expected to use it.
• The backlog has grown past what the first release can hold, and every item has a stakeholder attached to it.
• An engineering team is ready and waiting, and the product definition is not finished enough to build against.
• A first version shipped, registrations came in, and repeat use did not follow.
• A company that has only ever sold through intermediaries is building something its end users will touch directly for the first time.

Why a roadmap assembled from requests does not produce a product

Most roadmaps are an accumulation rather than a decision. A feature is on the list because a large customer asked, because a competitor shipped something like it, or because a sales conversation went badly and somebody promised. Each item is defensible on its own. The set of them is not a product, because nothing in the process ever required the team to say what the thing is for.

The cost shows up at the same place every time. A first release that contains everything arrives late, and when it arrives it cannot be explained to a customer in a sentence. Adoption then stalls at the group that would try anything, and the team reads that as a marketing problem.

The underlying error is sequencing. The question of what should exist got answered by the people best equipped to build, because they were the only people in the room with a plan. Our job is to settle what the product is and what the first release must contain before the build consumes the budget, and then to stay involved while that definition survives contact with real constraints.

What our digital product development consulting services include

1. Demand and displacement definition

What customers are trying to get done, described as a job rather than a segment, and the specific thing the product has to displace. Usually that is not a competitor. It is a spreadsheet, an email thread or a habit that is already paid for and already works well enough. A product with no named displacement has no adoption story, and no amount of build quality supplies one.

2. Product definition and first release scope

The smallest coherent version that someone would pay for, written down, with the reasoning for each exclusion recorded next to it. The exclusions are the deliverable. A scope document that only lists what is in gets reopened the first time a senior stakeholder asks why their item is missing.

3. Concept development and validation

Concepts developed in consumer language rather than internal language, then narrowed against evidence from the people expected to use the product. What matters here is the record of what was disproven, because that is what stops a rejected idea returning in the next planning cycle under a different name.

4. Development sequencing and build partner selection

The order the product gets built in, expressed so that a wrong assumption costs one increment rather than a program, and a clear specification your engineering team or your build partner can work against. Where you are choosing that partner, we help you brief and assess them. We do not take the build ourselves.

5. Instrumentation and post-launch iteration

What gets measured, decided before launch rather than retrofitted after it, so the team can tell a trial from a habit. Alongside it, written criteria for removing a feature, which almost no roadmap has and every roadmap needs, and a handover that leaves the product reasoning inside your organization.

How a digital product development engagement works

1. Frame. Interviews with your executives and your users, a review of what the product is currently specified to be, and an honest account of what it would displace. The output is a written statement of the demand and the displacement, or a record that neither can yet be stated.
2. Define. Concepts developed and narrowed with your product and commercial people in the room, each carrying the cost of building and serving it. The output is a small number of options rather than one recommendation, with what was ruled out and why.
3. Validate. The shortlist put in front of the people expected to use the product, tested against what they do rather than what they say they would do. The output is a first release scope with its exclusions justified.
4. Sequence. A build order, a specification your engineers or your build partner can work against, the measures that will show whether the product is being adopted, and the criteria for stopping. The output is something your teams can run without us.

Why companies choose Vivaldi for digital product development

We are accountable for whether the product should exist, not for the ticket count. That is a narrower offer than a product studio makes, and it is the part that is usually missing when a well-built product fails to get used.

McGraw Hill is the clearest example in our published work. For its student study app, Sharpen, the product did not begin as a feature list. It began with qualitative research and a quantitative student segmentation into learners’ goals, motivations and unmet needs, and a market analysis that located the competitive white spaces. Concepts came out of ideation workshops with the McGraw Hill team, were stretched and refined and whittled down to a key few, then were written in consumer language and validated in focus groups before anything was committed to. Only then did we map the user journey, the key use cases and the feature sets into a product development roadmap to guide the creation of the final product. The sequence is the point: the research, the narrowing and the recorded rejections all happened upstream of the build, which is why the build had something to be right about. You can read the full McGraw Hill story, which covers the wider partnership as well.

The second reason is that we stay honest about the boundary. When the constraint is engineering rather than definition, we say so and point you at the people who should hold it.

How to evaluate a digital product development consultant

• Ask what they will refuse to build. A firm that accepts the feature list as given is a development vendor. That is a legitimate purchase, and the wrong one if the roadmap is the problem.
• Ask how they decide what goes in the first release. If the answer is a prioritization framework with no reference to what the product displaces, the scope will grow until the launch date moves.
• Ask who owns the roadmap after launch. A product handed over without the reasoning behind it degrades within two quarters, because the next decision has no precedent to reason from.
• Ask what they measure in the first ninety days. Downloads and registrations are activity. Repeat use by the group the product was built for is the thing that predicts survival.
• Ask whether the strategy people and the build people are the same team. If they are separate firms, ask who pays for the translation loss between them. It is usually the client.

Strategy consultancy vs product studio vs development agency?

Related work

This page is about creating one specific product. The services around it answer different questions.

• Digital products and platforms decides which digital products and platforms a company should have at all, which is the question above this one.
• Product and service innovation builds the capability and the pipeline that keeps producing candidates, rather than taking one candidate to market.
• Prototyping and testing is the validation step on its own, where the concept exists and the question is whether it holds up.
• Customer experience design works across every encounter a customer has with you, not inside a single product.
• Interaction design is for when the product exists and how the system behaves is what needs redesigning.
• User interface design is for when the direction is settled and the execution of the surface is where the risk sits.
• User insights and research supplies the evidence this work runs on, and is bought on its own when the question is what users actually do.
• Service design, the parent of this service, covers the service the product sits inside and the handoffs between the functions that deliver it.
• Technical and DevOps architecture owns how the underlying system is structured and operated, which is the engineering question this page deliberately does not answer.

Digital product development consulting in the US and worldwide

We work with companies in the US, Europe and Asia from ten offices on four continents, and most product engagements run with a client team spread across at least two of them. The work travels because the hard part is not local. What a product displaces, and what the first release has to contain, are decided the same way in New York as in Munich or Singapore, and the answers only differ in what the local alternative happens to be.