A method, not a service menu.
Plenty of studios will hand you a list. Strategy sprint, brand workshop, innovation offsite — pick one, sign here. The list looks reassuring because it makes the work feel known in advance. The trouble is that a genuinely new idea is, by definition, the thing nobody knew to put on the list. If we already had a tidy package that fit your problem, your problem probably wasn't the kind worth bringing to us.
So we work from a method instead. A method is a way of moving, not a fixed sequence of deliverables. It travels well across very different problems because it doesn't presume what the answer looks like before we've met the question. A retailer trying to win back a quiet customer base and a chief ideator staring at a feature nobody opens are wildly different situations on the surface. Underneath, the work of finding a fresh angle on either of them rhymes. The method is that rhyme.
The difference matters in practice, not just in theory. A service menu pushes you toward the engagement that's easiest to sell, then bends your problem to fit it. A method does the opposite. It starts with the problem in its real, awkward shape and asks what kind of thinking it actually needs right now. Sometimes that's a hard look at the question itself. Sometimes it's hunting for a small place to start. Sometimes it's pressure on a bet that's already half-formed. The method lets us bring the right kind of thinking without pretending we knew which kind you'd need before you told us.
The point isn't a tidier plan. It's an idea you didn't have when you walked in.
What follows are the four modes we move between. Read them as a toolkit, not a staircase. Each one does a specific job, each one has a way teams tend to get it wrong, and each one has a tell — a signal in how a problem is behaving that says this is the mode the moment is asking for. We rarely use all four in order, and we almost never use only one. The skill isn't in knowing the modes. It's in feeling which one a conversation needs, sometimes mid-sentence, and reaching for it without losing the thread.
Reframe the problem
Most teams solve the wrong problem beautifully. They take the question as it arrives — fully formed, handed down, never questioned — and pour real talent into answering it. The work is good. The answer is sharp. And it lands with a quiet thud, because the question itself was pointing in a slightly wrong direction the whole time. Reframing is the work of catching that before the effort goes in.
What it means
To reframe is to take a problem apart at the joints and reassemble it until the real opportunity is the thing staring back at you. A problem is rarely stated in its most useful form. It comes wrapped in assumptions, inherited language, and the shape of whoever asked it last. "We need more leads" might really be "the leads we get don't trust us yet." "Our product is too complicated" might really be "we never decided who it's for." Reframing isn't wordplay. It's the deliberate act of testing whether the question you're about to spend money answering is the question actually worth answering.
Why teams get it wrong
The reframe gets skipped because it feels like delay. There's pressure to be seen doing something, and questioning the question reads as stalling. So teams accept the brief as written and sprint. The other failure is subtler: people reframe in name only, swapping a few words but keeping the same underlying assumption intact. Real reframing is uncomfortable, because it often reveals that months of planning were aimed slightly off. That discomfort is exactly why an outside partner helps — we have no sunk cost in the old framing, so we can ask the rude question without it feeling like an accusation.
How we actually do it
We start by writing the problem down in your words, then pulling on each thread. What has to be true for this to be the real problem? Who decided it was framed this way, and when? What would a person seeing it for the first time notice that you've gone numb to? We hold the question up to lenses it's never been held up to — a competitor's, a brand-new buyer's, your own from before you knew this market. We're not looking for the cleverest reframe. We're looking for the one that makes the next move obvious in a way the original framing never did.
What you walk away with
A problem stated in a form you can actually act on — usually narrower and sharper than the one you came in with, occasionally bigger, always more honest. You'll also walk away with the discarded framings, written down, so you understand why the new one is better and can defend it to the people who liked the old one. The deliverable isn't a document so much as a shared sense of relief in the room: oh, that's what we're actually trying to do.
You've tried several solutions and none of them stuck, and the solutions weren't bad. When good answers keep failing, the question is usually the thing that's broken. If your team keeps arguing about how to do something without ever quite agreeing on what or why, that's the tell. Reframe first.
Find the wedge
Big change rarely starts big. It starts with a small, slightly surprising point of entry — the thing you can move first that makes everything after it easier. The wedge is that point. Finding it is the difference between a transformation that stalls under its own weight and one that quietly gathers momentum until it feels inevitable.
What it means
A wedge is the narrow opening you drive into to split something wide. In a business problem, it's the smallest move that changes the most downstream. It might be a single customer segment that, once won, makes the rest of the market believe you. It might be one feature that, once it works, gives the whole product a reason to exist. The wedge is rarely the most obvious or the most ambitious move. It's the most leveraged one — small enough to actually do, positioned so that doing it makes the next ten things easier.
Why teams get it wrong
Ambition gets in the way. When a problem is exciting, teams want to attack it everywhere at once, and the energy of a big plan feels like progress. But a wide push spreads effort thin and gives nothing enough force to break through. The opposite failure is just as common: teams pick a starting point because it's easy, not because it's leveraged, and end up moving something that doesn't change anything else. A good wedge has to be both reachable and consequential. Most teams optimize for one and forget the other.
How we actually do it
We map the problem as a system of dependencies — what unlocks what — and look for the move that sits upstream of the most. Then we apply a brutal filter: of the high-leverage moves, which can you actually start within a horizon short enough to keep belief alive? We're hunting for the intersection of small and consequential. We'll often run the candidate wedges through a simple test out loud: if this one move worked, what would suddenly become possible? The wedge that opens the most doors with the least force is the one we back.
What you walk away with
A single, defensible first move and a clear story for why it comes first. Not a roadmap with everything on it, but the one thing that earns the right to do the next thing. You'll also get the logic of the leverage written plainly, so when someone asks why you're starting there instead of somewhere flashier, you have an answer that holds. The wedge gives a scattered effort a spine.
You have a plan with too many priorities and everything is moving slowly because nothing is moving first. If your team is busy across a dozen fronts and none of them is breaking through, you don't have a wedge yet. The tell is motion without momentum. Find the wedge and let the rest wait.
Pressure-test the bet
An idea worth backing should survive a hard look. Pressure-testing is the deliberate work of stressing an idea before the market does it for you — naming the assumptions it rests on, finding the ones that would sink it, and figuring out the cheapest way to learn whether they're true. It's not about killing ideas. It's about making sure the ones you back can carry the weight.
What it means
Every idea is a stack of assumptions wearing a trench coat. Some of those assumptions are safe; some are load-bearing and unexamined. Pressure-testing pulls the assumptions out into the open and asks, for each one, what would have to be true for this to work — and how badly it hurts if it isn't. The goal is to separate the assumptions you're comfortable betting on from the ones you're quietly hoping about, and to attack the hopeful ones first, because those are where ideas actually die.
Why teams get it wrong
Two ways, opposite directions. The first is falling in love. Once a team has invested belief in an idea, scrutiny starts to feel like disloyalty, and the hardest questions go unasked precisely because everyone senses the answers might hurt. The second is the reverse — testing an idea to death, demanding certainty that no early idea can offer, and strangling it with caution before it gets a chance to breathe. The craft is in stressing the idea hard on the assumptions that matter while staying loose on the ones that don't yet. Most teams can't hold both at once.
How we actually do it
We list the assumptions the idea rides on and sort them by two things: how much rests on each, and how sure you actually are. The assumptions that are high-stakes and low-confidence go to the top — those are the ones worth spending to learn about. Then, for each, we ask the cheapest possible question that would move our confidence: a conversation, a fake door, a rough prototype, a single phone call. We're not trying to prove the idea right. We're trying to find the fastest way to be wrong cheaply, so that if the idea is going to fail, it fails on a small bill instead of a large one.
What you walk away with
A clear-eyed view of what your idea is actually betting on, ranked by risk, plus a short list of the smallest experiments that would tell you whether the riskiest bets hold. You'll know which assumptions you're choosing to trust and which you're choosing to test, and you'll be able to say why out loud. The idea comes out of this mode either more believable or honestly dead — both of which are better than expensive and uncertain.
You have an idea you're excited about and you're about to spend real time or money on it. The excitement is the tell. If a bet feels obviously right and nobody in the room can articulate what would have to be true for it to work, it hasn't been tested — it's been believed. Pressure-test before you commit.
Ship the experiment
An idea isn't real until it touches the world. Shipping the experiment is the work of putting an idea into reach of actual people in a form small enough to learn from quickly — so the next decision rests on something you saw happen, not something you hoped would. This is the mode where thinking stops being a conversation and starts being evidence.
What it means
An experiment is the smallest version of an idea that can still teach you something true. It's not a launch and it's not a pilot in the corporate sense. It's a deliberate, scoped act of putting the idea in front of reality to see what reality does back. The discipline is in keeping it small enough that you can run it soon and survive being wrong, while keeping it real enough that what you learn actually counts. A test nobody could fail teaches you nothing. The art is designing one where the result genuinely could go either way.
Why teams get it wrong
The common failure is shipping something so polished it stops being an experiment and becomes a commitment — by the time it's live, too much is staked on it to read the result honestly. The opposite failure is shipping something so flimsy or so hidden that no real signal comes back, then treating the silence as proof of anything. And there's a quieter trap: running the experiment but never actually deciding in advance what result would change your mind. Without that, a team will see what it wants to see in whatever comes back.
How we actually do it
Before anything ships, we write down what we expect and what would surprise us — the result that would make us change course. Then we strip the idea to the smallest version that still puts the real question in front of real people, and we build only that. We help you put it somewhere the right people will actually meet it, watch closely while it's live, and read the result against the prediction we made beforehand rather than the story we'd prefer afterward. The output of the mode isn't the thing we shipped. It's what the world told us when we did.
What you walk away with
Evidence. A grounded read on whether the idea behaves the way you hoped, drawn from contact with reality rather than another round of debate. You'll also walk away with a next move that's earned — either a bigger version of the bet, a reshaped one, or a clean reason to set it down. Either way the next decision is standing on something solid, which is the whole point of working an idea instead of just admiring it.
You've been debating an idea for longer than it would take to test it. When a question can only be answered by the world and you keep trying to answer it in a meeting, that's the tell. Stop arguing about what might happen and build the smallest thing that will let you watch what does.
The modes don't march in a line.
It would be neater to tell you the four modes happen in order — reframe, then wedge, then test, then ship — and that you graduate from one to the next like levels. That's not how real work behaves, and pretending otherwise would set you up to follow a sequence instead of following the problem. The modes are a set of moves, and the skill is bringing the right one the moment the work calls for it.
In practice the modes loop, interrupt each other, and double back. You might be deep in shipping an experiment when the result quietly reframes the whole problem, and suddenly you're back in mode one with much better information than you had the first time. You might find a wedge, start pressure-testing it, and realize the test is really a small experiment you could just run. A single conversation can pass through all four in twenty minutes — catching a flawed framing, spotting where to start, naming what would have to be true, and sketching how you'd find out.
What ties it together isn't a sequence. It's attention. We're always listening for which mode the moment is asking for: when an answer keeps failing, reframe; when effort is scattered, find the wedge; when belief is running ahead of evidence, pressure-test; when the argument has outlasted its usefulness, ship. The signals at the end of each mode above are the same signals we're reading live, in the room, deciding what kind of thinking to reach for next.
This is why the work doesn't reduce to a checklist. A checklist assumes you know the order in advance. A method assumes you'll know the next move when you feel it — and gives you a small, sharp set of moves worth feeling for. You bring the mode the moment needs, and you keep bringing it until the idea is real.
Working this way, up close.
The method is the what. This is the how it feels — because the experience of the work matters as much as its shape. Growth Idea Group is chief-ideator-led by Jason Kumpf, with a wider network of seasoned operators and builders brought in to fit the problem at hand. That structure isn't an accident; it's what lets the work feel like thinking with a partner rather than receiving a deliverable from a firm.
It's collaborative in the literal sense. We're not off in a back room assembling a verdict to present at the end. We work in the open, with you, building the thinking together so that by the time an idea is real you already understand it in your bones — because you helped make it. The reframe lands harder when you arrived at it yourself with a nudge. The wedge feels obvious in hindsight because you saw it appear. Nothing useful gets handed down from on high; it gets worked out in the room.
It's hands-on. We'd rather build the rough version than describe it, rather make the phone call than recommend you make it, rather sketch the experiment on the spot than schedule a workshop to plan one. The energy comes from making things, not from managing a process around making things. When the moment calls for a prototype, we'd rather have a clumsy one by the end of the afternoon than a polished proposal by the end of the month.
And it's honest. We'll tell you when a beloved idea is fragile and when a boring one is quietly strong. We'll say "we don't know yet, here's how we'd find out" instead of performing certainty. The excitement in the work comes from the ideas themselves and from watching them touch reality — not from claims about how good we are. If that sounds less like a pitch and more like a way of thinking together, that's exactly the point.