Redesigning an innovation-consulting offering nobody could explain

TL;DR

• Context: Designer in the internal innovation lab of a global pharmaceutical company.
• Problem: The offering was a long list of services described in jargon. Business partners didn’t know what to choose or what stage their problem was at.
• What I did: I rebuilt the offering into 4 phases that describe the stage of the problem, and added a pricing model in days of work.
• Result: The new offering was ready after ~2 months. I ran most of ~60 workshops in 8 countries on it.

Diagnosis

The first version of the offering was broad and technically very precise. That’s exactly why the people it was meant for didn’t understand it. Business partners (rarely from IT) had to pick a co-creation workshop, a PoC build or on-site research from a list. They didn’t know the difference between them and often didn’t even know what stage their problem was at. So I didn’t shorten the list. I organized it around a question partners could actually answer: “what stage is my problem at?”. That’s how the four phases came about.

flowchart TD
    subgraph Before["Before: list by activity type"]
        M1["Co-creation workshops"]
        M2["PoC build"]
        M3["On-site research"]
    end
    subgraph After["After: 4 phases of problem maturity"]
        F1["Identification"] --> F2["Iteration"] --> F3["Design"] --> F4["Verification"]
    end

    classDef good    fill:#e6f2ea,stroke:none,color:#1f4d33,rx:14,ry:14
    classDef bad     fill:#faeaea,stroke:none,color:#5f2626,rx:14,ry:14
    class M1,M2,M3 bad
    class F1,F2,F3,F4 good
    style Before fill:#fdf5f5,stroke:#e0c3c3,stroke-width:1px,color:#5f2626,rx:14,ry:14
    style After fill:#f2f8f3,stroke:#c2dcc8,stroke-width:1px,color:#1f4d33,rx:14,ry:14
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

What I did

• Based on several years of working with the first version, I named its four flaws: jargon, too broad a choice, rigid definitions and no path to implementation.
• I rebuilt the offering into 4 phases: Identification, Iteration, Design and Verification. Each has a default set of activities that can be changed.
• I built a pricing model in days of work (man-days). It’s a set of Excel templates based on data from earlier projects, which let us quote ranges quickly.
• I ran most of the ~60 workshops in 8 countries that were built on this structure.

Results

• The new offering (v2.0) was ready after ~2 months of work.
• Almost all earlier projects could be assigned to one of the 4 phases. For me that was a sign the split matched the real work.
• After the launch, partners came with better-defined needs. They asked “what do you even offer?” less often and said “I’m at stage X, what will help me?” more often.
• ~60 workshops in 8 countries grew from this structure (USA, Germany, Switzerland, Spain, Italy, Serbia, Slovenia, the UK). I prepared and ran most of them myself.
• The pricing model in days of work became the team’s standard tool for estimating new engagements.

The problem

What was wrong with the first version of the offering?

Four things that only showed up after several years:

1. Language. It was too specialized. Partners outside IT didn’t understand what exactly we offered, so they couldn’t choose.
2. Choice. Co-creation workshops, PoC builds and on-site research were separate options, with no hint about when to pick which.
3. Rigidity. The definitions were so strict that it was hard to convince a partner to combine several elements into one project.
4. Path to implementation. Because everything was fragmented, it was hard to show how to get from a workshop to a finished product.

Why not just shorten the list?

Because the trouble was in how the list was organized. It was sorted by activity type (workshop, research, PoC), and business partners don’t think that way. They think more like: “I have some problem, I’m somewhere halfway, and I don’t know what’s next”. A shorter list would still speak a different language than the partner. I had to organize the offering around what partners know about themselves.

My role / scope

• Within the innovation lab team, I was the one who created the new version of the offering: from naming the problems, through the phase split, to the pricing model.
• I designed the pricing model myself, using data from the team’s earlier projects.

Process

• Flaws from real conversations. After several years with the first version, I had enough material to name four specific flaws. I took them from conversations with partners, not from guesses.
• Choosing the split. I divided the offering by how far along the partner is with their problem: “I need to find the problem” → “I have a problem, I don’t know how to solve it” → “I have an idea, I need to refine it” → “I have a solution, I need to check if it’s worth implementing”. Then I checked this split against old projects, and almost every one could be assigned to it.
• A default set of activities in each phase. For each phase I described a typical set of activities based on earlier projects.

• Pricing model. I collected data from earlier projects and calculated how many days of work each element takes: research, a workshop with two facilitators, a flat travel allowance. Based on that, I built Excel templates for quick quotes.

Key decisions & trade-offs

• Splitting by the stage of the problem. Consulting offerings are usually organized by what the team can do. I organized this one by where the partner is. It took a lot of work, because I had to assign the whole project history to the new phases and check whether the split held up. In return, partners could say where they were without knowing any jargon.
• Default activities that can be changed. Each phase had a typical recipe, but it wasn’t mandatory. That directly fixed the third flaw of the old offering, its rigidity. The downside was that it became harder for the team to predict how many people and how much time a project would need.
• Verification has the least structure. I did that on purpose. This phase is about testing an idea in practice quickly, before spending a lot of money on it. So the method has to fit the case: sometimes a timed test, sometimes an API check, sometimes a cheap MVP.
• Pricing as a separate part of the offering. Without cost ranges, partners hesitated to even start a conversation. An unknown cost put them off. The templates in days of work removed that barrier.
• I didn’t measure the better response. I have to admit that “a better response” is my observation, not a number. I saw partners coming with more specific needs, but I didn’t set up any metric at the time, e.g. the number of requests before and after the change.

How it turned out

The new offering launched after ~2 months, and from then on every new engagement in the team started by assigning it to a phase. The structure held up well over time. I ran most of ~60 workshops in 8 countries on it, and the pricing templates stayed in the team as an everyday tool.

What I took away

• It’s worth organizing an offering around how the client thinks. A partner doesn’t think “I want a co-creation workshop”. They think “I’m stuck and don’t know what’s next”. In my view the offering should start from the latter.
• A default choice helps people decide. People get a simple starting point, and there’s still room for exceptions.
• Even a rough price encourages a conversation. Few people start something they can’t estimate, even roughly.
• Next time I’ll measure the effect from day one. Here I was left with an observation only. The number and quality of requests before and after a change need to be tracked from the start, not reconstructed from memory.