Redesigning an innovation-consulting offering nobody could explain

TL;DR

• Context: Designer at an internal innovation lab inside a global pharmaceutical company.
• Problem: The consulting offering was a wide, jargon-heavy menu — business partners didn’t know what to pick, or even what stage their problem was at.
• What I did: Rebuilt the offering into 4 clear problem-maturity phases plus a man-day pricing model.
• Result: New offering shipped after ~2 months; I later led most of the ~60 workshops across 8 countries built on it.

Diagnosis

The first version of the offering was broad and technically precise — which is exactly why it was unreadable to the people it was written for. Business partners (rarely from IT) had to pick the right element from a list of co-creation workshops, PoC builds, and on-site research — without knowing the difference between them, or even what stage their own problem was at. Instead of trimming the list, I reorganized it around the one question a partner could actually answer: “how far along is my problem?” Four maturity phases — not four service types.

flowchart TD
    subgraph Before["Before: menu by activity type"]
        M1["Co-creation workshops"]
        M2["PoC builds"]
        M3["On-site research"]
    end
    subgraph After["After: 4 problem-maturity phases"]
        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:transparent,stroke:#a1a1aa,stroke-width:1px,rx:14,ry:14
    style After fill:transparent,stroke:#a1a1aa,stroke-width:1px,rx:14,ry:14
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

What I did

• Diagnosed four concrete flaws in the first version of the offering (jargon, an overly wide menu, rigidity, no clear path to implementation) from several years of usage.
• Redesigned the offering into four problem-maturity phases — Identification / Iteration / Design / Verification — each with a default, not mandatory, set of activities.
• Built a man-day pricing model — Excel templates based on data from past engagements, for fast ballpark quotes.
• Personally led most of the ~60 workshops across 8 countries that ran on this structure afterward.

Results

• The redesigned offering (v2.0) shipped after ~2 months of work.
• Nearly every past engagement could be cleanly mapped onto the four new phases — a sign the split matched the real shape of the work, not an artificial category.
• After launch, business partners started arriving with more clearly framed needs — fewer “what do you even offer” questions, more “I’m at stage X, what helps me.”
• The structure powered ~60 workshops across 8 countries (US, Germany, Switzerland, Spain, Italy, Serbia, Slovenia, UK) — most led personally end-to-end, from prep to delivery.
• The man-day pricing model became the team’s standard tool for quoting new engagements quickly.

The problem

What was wrong with the first version of the offering?

Four things, visible only after years of use: (1) overly specialized language — partners outside IT didn’t understand what was actually on offer, so couldn’t pick the right element; (2) an overly wide, fragmented menu — co-creation workshops, PoC builds, and on-site research sat as separate, parallel options with no guidance on when to pick which; (3) overly rigid definitions — hard to convince a partner to combine several elements into one engagement; (4) no clear path to implementation — the fragmentation made it hard to show how a workshop led to an actual shipped product.

Why not just shorten the list?

Because the problem wasn’t the length of the list — it was the axis it was organized around. The list was structured by activity type (workshop, research, PoC), and a business partner doesn’t think in those categories. They think: “I’m stuck somewhere in a problem, and I don’t know what’s next.” Shortening the list wouldn’t have fixed that mismatch — the offering needed to be translated onto an axis the partner actually understood.

My role / scope

• I was the main author of the redesigned offering inside the innovation-lab team — from diagnosing the problems, through the phase split, to the pricing model.
• After launch, I personally led most of the ~60 workshops across 8 countries — full ownership of prep and delivery.
• I designed the pricing model (man-day templates) myself, based on data from the team’s past projects.

Process

• Diagnosis from usage data. Several years running the first version of the offering produced enough signal to name four concrete flaws — not guesswork, patterns from real partner conversations.
• Choosing the split axis. Instead of splitting by activity type, I split by the partner’s problem maturity: “I need to identify the problem” → “I have a problem but don’t know how to solve it” → “I have an idea but need to sharpen it” → “I have a designed solution but need to verify it’s worth fully building.” I tested this axis retroactively against past projects — nearly all of them mapped onto it cleanly.
• Default, not mandatory, activities per phase. For each phase I defined a typical activity set based on analyzing past initiatives.

• The pricing model. I gathered data from past engagements and estimated the man-days required per element type — research, a workshop with two facilitators, flat-rate travel costs — and built Excel templates for fast quoting.

Key decisions & trade-offs

• Split by problem maturity, not by service type. Counterintuitive, because that’s not the axis a consulting offering naturally organizes around (usually it organizes around what the team knows how to do). Trade-off: I had to reclassify the entire project history to test whether the axis held up. Payoff: a partner could self-identify without knowing any internal jargon.
• Default activity sets, not mandatory ones. Each phase had a typical recipe, not a rigid requirement — this directly fixed flaw #3 from the first version (overly rigid assumptions). Trade-off: less predictability for team resource planning, more flexibility for the partner.
• Verification as the least structured phase — on purpose. This phase had the least fixed structure of the four, because the goal — testing an idea against “the market” fast, before real money got spent — needed a method matched to the specific case (a timing test, an API check, a cheap MVP), not one fixed process.
• The pricing model as its own deliverable, not an add-on. Without a ballpark cost, partners hesitated to even start the conversation — an unknown price is a hidden barrier to entry. The man-day templates removed it.
• Honest: the “better response” was a qualitative signal, not a measured one. I could see partners arriving with more clearly framed needs and asking “what do you even offer” less often — but I never set up a hard metric at the time (e.g., inbound requests before/after).

How it turned out

The redesigned offering launched after ~2 months of work and became the default way to scope any new engagement on the team. Nearly the entire project history mapped cleanly onto the four phases, confirming the split reflected the real shape of the work rather than an artificial category. The structure held up over time: it powered most of the ~60 workshops I went on to lead across 8 countries, and the man-day pricing templates became the team’s standard tool for fast quoting.

What I took away

• Match the offering’s structure to how the customer thinks, not to your internal service taxonomy. A partner doesn’t think “I want a co-creation workshop” — they think “I’m stuck at some stage.” Design the axis around the second one.
• “Default, not mandatory” kills decision paralysis without killing flexibility. You can give people a simple starting point and still leave room for exceptions.
• Fast, ballpark pricing removes a hidden barrier. Nobody starts something they can’t roughly cost out.
• Not every good outcome gets measured at the time — and that’s a lesson in itself. Next time: an adoption metric (request volume/quality before and after) set up from day one, not reconstructed from memory.