S2 Ep 36: Custom Order or Line Extension? Who Makes the Call

In this episode of A Splice of Life Science Marketing, Dr Matt Wilkinson talks with Dr Jasmine Gruia-Gray about her article, The problem statement your line extension skips. They cover what a bioRxiv study on antibody selection says about where customer trust sits, the problem statement and goal statement a line extension needs before the gate review, and who decides when a custom order becomes a line extension. The transcript has been lightly edited for readability.

Introductions

Speaker: Matt Wilkinson [00:01]

Hey Jasmine, how you doing?

Speaker: Jasmine Gruia-Gray [00:02]

Hello, hello, it's another day in paradise. How about yourself?

Speaker: Matt Wilkinson [00:08]

I'm good, thank you. I'm good. The sun is shining, although you might not be able to see it through my blinds. And, you know, for once in the UK it's not raining. Or actually, I'd say it's not rained much this year, so...

Speaker: Jasmine Gruia-Gray [00:20]

Right, so sort of paradise, but a little disturbing that it hasn't had much rain.

What a bioRxiv antibody study says about trust

Speaker: Matt Wilkinson [00:27]

Well, you know, it makes a nice change. Speaking of changes, you found a really interesting study on bioRxiv this year that asked 107 researchers how they choose an antibody. Now, before we dig into this, I want to make a confession. I actually had to look up how to pronounce bioRxiv, or B-I-O-R-X-I-V as it's spelled, because I didn't actually know how to pronounce it on air. But fortunately Cold Spring Harbor Laboratory, the founders of the journal, explicitly provided the clarification when it was launched. So the good news is we've started off strong, and we're pronouncing bioRxiv correctly.

Now, in the paper itself that you referred to, two factors were rated the most important when choosing an antibody, each by about 78 or 80% of respondents. It was either previous use of the antibody in their own lab, or data used in the literature. The study also drew on a dataset of 614 antibodies tested against knockout controls, and 97 of them, which is about 16%, failed in every application they tested. So trusting what you've used before really isn't irrational. You know, it's the scientist's best defence against a reagent that might not work. Now, we need to be careful and not hold that too tightly, because it's just one study, and it's partly a survey. But I think it does set out a stall about how companies toe a line between product extensions and launching into new markets. They might have the same trusted product, launching it in a new format. Internally, the original is the asset. From the customer side, though, the trust was never really in your brand necessarily. It's in their own track record with the product, built one experiment at a time. So they may trust one antibody, but does that confer onto the next? A new format doesn't necessarily confer that same history across. So it may not start at the same level of trust, no matter how good the original is.

So what you were talking about in your article is really that you're selling the idea that a line extension is continuity with a customer's own results, and the new product development gate review rarely asks whether you can deliver it.

The two sentences the gate review skips

Speaker: Matt Wilkinson [03:19]

Your piece says the new product development gate review often skips two sentences, a problem statement and a goal statement. And I think that's where continuity either gets written down or gets assumed. So where did this whole idea come from?

Speaker: Jasmine Gruia-Gray [03:40]

Yeah, so the word assumption is a really key one here, and we all fall into this trap of assumptions around a line extension. Especially, we assume we know what problem the line extension is solving. We assume we know that the goals of the product meet that problem statement.

And the whole idea behind this blog came from when I was a product manager and, deliberately or unknowingly, wrote the light version of a product requirements document for a line extension, because the review felt already decided. My learning was that the launch materials that came out of this light version missed out on the jobs that the customers were hiring the product to do. The positioning and the value propositions weren't as solid as they should have been, and the application note missed some key points it needed to prove.

What I took from that is the argument in the piece. Before the new product development gate review, a line extension needs those two sentences: a problem statement, which describes the customer's world with your current product still in it, and a goal statement, which describes a result the customer could check for themselves. Without these two statements, the review takes into account a lot of assumptions, as I found out myself.

Custom order or line extension

Speaker: Matt Wilkinson [05:24]

Interesting. But you said that the launch materials missed the jobs the customers were hiring the product to do. Yet this came from a specific request from a key account that was telling you exactly what they wanted. They asked for a conjugated version of an antibody clone that you already license exclusively. So if the request is that specific, why isn't the request itself the job? And what would a problem statement have told the team that the account's own ask didn't?

Speaker: Jasmine Gruia-Gray [05:59]

So, because the request tells you what one account wants, and the gate review has to judge whether a market wants it. So, two different scales, if you will. That's the difference between a custom order, a single customer wanting a product, and a fully marketed line extension. Don't get me wrong, there is nothing wrong with doing a custom order. A custom order may answer a very important key account request, and you build it to their specific spec and price it to cover the work. A line extension, however, means putting your name behind it for customers, plural, you may not have met yet, with a datasheet, an application note, support and so on. The request looks identical in both cases.

The problem statement is what tells them apart. It asks what the customer loses today, what it costs them to do nothing, and what they do in the meantime. The last one matters most to me, because the workaround shows how many people live with this problem. If it shows up at one account, you have a custom order. If it shows up across a segment, you may have a line extension, and the review should hold it to that standard.

The account is your best evidence. It's just one data point until the statement shows who else has the same loss or losses.

Writing a goal statement the customer can check

Speaker: Matt Wilkinson [07:38]

Okay, so we've discussed the problem statement. Tell me a bit more about the goal statement. It seems that that's the piece that teams find easier to write. They can say "launch the conjugated version by the third quarter". How would a review tell a real goal for a product rather than, kind of, an internal timeline?

Speaker: Jasmine Gruia-Gray [08:07]

Yeah. In both the case of the problem statement and the goal statement, the customer is at the centre. So a real goal describes a change in the customer's world. Launching a conjugated version by the third quarter: the customer doesn't care about the third quarter or the first quarter. So, the customer's world, in terms they could check themselves.

The first test is the spec sheet test. If a competitor could print it on their own spec sheet, it's not your goal. It's not unique to you as a company and as a product line. So then I borrow three questions. One by Itamar Gilad, who asks whether the goal statement is falsifiable. Teresa Torres asks whether it names a specific segment and a specific unmet need. So there you go again, with the customer at the centre. And Melissa Perri asks whether it's a customer outcome or a roadmap item in disguise.

A statement can pass all three and still be a spec. So then I add the Clay Christensen question: what is the customer hiring the product to do? For a line extension, the answer is often a check the customer can run in their own hands. The same sample with the original product and the new version, and the same answer. And if you don't have anything exclusive to anchor it, look for what else only you can deliver. For example, lot-to-lot consistency that spans years of customers' own experiments.

Stage-Gate and the case for a lighter process

Speaker: Matt Wilkinson [09:58]

Great, thank you. Now, moving a little bit away from the customer and on to Stage-Gate, which was developed by Robert Cooper. He argues that pushing small projects through the big process often wastes time, and that when companies used one process for everything, teams simply circumvented it for everything. He describes lighter versions for extensions rather than innovative new products. A twenty-minute review is arguably the system working as designed, and your statements are one more document a busy PM has to produce. Where does the time come from, and why isn't this the kind of overhead that gets circumvented as well?

Speaker: Jasmine Gruia-Gray [10:41]

Yeah. So I'd agree. It's important to right-size the process for the product that's being developed. It's the agile process that Robert Cooper often refers to. A full review for every extension would definitely be a waste, and I'm certainly not advocating that.

And I don't have a dataset showing the two statements pay for themselves. What I have is my own light requirements document as the example, and the launch that it produced. Where I hold the line is that light should mean fewer stages, not less evidence, and the time is smaller than it sounds. The writing isn't going to be more than a couple of hours, because much of the evidence is already in the building. What I mean by that: you've got support tickets, you've got technical service calls, you've got the account team's notes. Your customers have already written the problem statement and the goal statement for you. You've just got to pull those pieces of evidence together and rearticulate the problem and goal statements in their words. I'd start there before booking a single new interview.

And if you can't write the two statements from what you already have, the evidence that I just mentioned, that tells you the line extension was less decided than it felt at the very beginning of the meeting. And maybe it does require some voice of customer research.

Who makes the call

Speaker: Matt Wilkinson [12:36]

It still brings me back to that idea of having a custom order and holding it distinct from a product line extension. In most companies the call gets made by whoever's closest to the customer, and the fastest path is always to call it a custom order and then ship it. So who actually makes the call to graduate a custom order into a line extension?

Speaker: Jasmine Gruia-Gray [13:07]

Yeah, so I think at the heart of it, the product manager owns that decision, or at least bringing that decision to the portfolio management group. And sales logs every request, so it's visible how many times this custom order is being requested. Then I'd use two triggers.

It's a custom order when it's built to one account's spec, with no claims beyond that. The first trigger is an unrelated customer asking for the same thing. The second is anyone wanting to tell a customer who hasn't asked, whether that's a catalogue listing, a datasheet, an application note or a campaign. Either one, and it's a line extension, and it goes to the review with the two statements. Then check it isn't really a new product: if the customer, the workflow or the application differs from the parent.

The weakness is that the second request is a lagging signal. By the time it arrives, the first account may have been shipping for months, and the only way I know to see it sooner is to get sales to log every request. So I think it comes down to volumes of these requests. If it truly is a one-off ask, and the revenue behind it and the strategic importance behind it are high enough, then the product manager makes the call that it's a custom order.

Three weeks to the gate review

Speaker: Matt Wilkinson [14:57]

Brilliant. So let's hope there are a few product managers listening, and they all have key account requests sitting on their desks and a review in three weeks' time. Walk me through what they should be doing over those three weeks. What do they do first? What do they do with the free samples everyone wants to send? And what do they bring back into the decision-making process?

Speaker: Jasmine Gruia-Gray [15:22]

So I'd say initially start with 30 minutes with the end users and the lab manager who made the request. Ask four things. What are you doing today to work around the problem that resulted in this request? What does that cost you in time and samples? What have you already tried instead? And who else is stuck on the same thing? That last answer is also your early signal, if you will, for more accounts that may have this same need.

With the answers to those questions, you can then write the problem statement, run the ten-second test, and then hand it to someone outside the project and ask them to name the customer. It's just good practice to have a second person looking at this. See if they can name the application and the loss after one read. That gives you a good sense of how concise and how precise your problem statement is, focused on the customer.

And in the second week, maybe you would want to plan for some free samples that address the problem statement, and pick some labs that run the application you wrote down in the problem statement. Tell each one what result would convince them, and ask them for that result back. Then the samples become the experiment, or some of the data and evidence that you can use when you go to launch.

And then, subsequent to that, bring the questions from the table in the piece. Did this come from observing customers, or from what one account asked for? Would everyone in the room agree on what result means we missed? If nobody can answer the second one, the project isn't ready.

When sales has already promised the deal

Speaker: Matt Wilkinson [17:37]

Brilliant. Thank you so much for digging into that in so much detail. Say that sales has already promised this to a key account. How do you get the problem statement written without it looking like you're actually blocking the deal?

Speaker: Jasmine Gruia-Gray [17:55]

Yeah, that's a tough one, and a lot of product managers, me included, have been in that position. A promise nobody can test is weaker than a goal sales can repeat. And if those labs tell you they've dropped a target from a panel of different biomarkers, that ends up being your goal. Ask for the customer time as a way to help close the deal.

It also pays back later when marketing starts the launch work. If the datasheet says labs can skip labelling and validating the antibody themselves, that claim traces back to the loss you documented, and the application team knows which experiments it has to run to prove it. So see yourself as a partner in getting the deal closed, in making sure that the product actually delivers what the customer absolutely needs. And I think through that kind of partnership, you won't be seen as blocking the deal.

Closing

Speaker: Matt Wilkinson [19:05]

Brilliant. Well, thank you so much for helping me explore the fascinating article that you published for us. The full article is called The Problem Statement Your Line Extension Skips, and it can be found on strivenn.com/thinking. And we'll put the link in the show notes as usual. The piece gives you a question to ask at the review, in development and before launch.

Speaker: Jasmine Gruia-Gray [19:40]

Super. And I'd like to invite anybody listening: if you've had this kind of issue and would like to discuss it further, how to work around the situation, how to write better problem and goal statements, please book a growth consultation with us at strivenn.com/contact.

Speaker: Matt Wilkinson [20:05]

Thank you so much, Jasmine. Great to speak with you today.

Speaker: Jasmine Gruia-Gray [20:08]

You as well, thanks, Matt. Bye for now.

Q&A

How do I find out whether a key account request is shared across a segment without commissioning new research?

Start with what is already in the building. Pull recent support tickets, technical service calls and account notes, and search them for the application and the workaround the key account described. Then book thirty minutes with the requesting lab and ask who else is stuck on the same thing. If the workaround appears at one account, treat it as a custom order. If it appears across several unrelated labs, write the problem statement and take it to review.

Who should own the decision to graduate a custom order into a line extension?

The product manager owns the case and brings it to the portfolio management group. Two triggers put it on the agenda. The first is an unrelated customer asking for the same thing. The second is anyone wanting to tell a customer who hasn't asked, through a catalogue listing, a datasheet, an application note or a campaign. Agree those triggers with sales this week, and ask them to log every request so the second one is visible when it arrives.

What makes a goal statement strong enough for a gate review?

Write it as a change in the customer's world that they could verify for themselves, then run the spec sheet test. If a competitor could print the same line on their spec sheet, rewrite it. Check it is falsifiable, names a specific segment and unmet need, and describes a customer outcome. Then ask what the customer is hiring the product to do. For a line extension, the answer is often a side-by-side check on the same sample with the original and the new version.

How should I use free samples in the three weeks before the review?

Send them only to labs that run the application named in your problem statement. Before anything ships, agree with each lab what result would convince them, and ask them to send that result back. The samples then become a small experiment, and the data can feed the application note at launch. A handful of well-chosen labs with an agreed success criterion is enough to give the review real evidence on a modest budget.

How do I write the problem statement when sales has already promised the product?

Frame the work as protecting the deal. Ask the account manager for thirty minutes with the end users and lab manager who made the request, and write the statement from what they describe. If they tell you they had to drop a target from their panel, you have a goal sales can repeat and the application team can validate against. That claim later traces straight into the datasheet, so the team knows which experiments it needs to run.