Strategy, in reverse

Why the typical strategy process wastes too much time.

Our current strategy process follows an old-school waterfall. We can’t develop ideas until we have a strategy. And we can’t write strategy until we have insights. And we don’t have insights until we immerse ourselves in the landscape.

The sad truth: the executable ideas are the most important thing. It’s what the client cares about most.

Yet, for every single Undercurrent project, I’d wish we spent more time on the ideas and less on preparation. For an 8-week project, we don’t begin addressing executable ideas until the final week.

For our past project with Amex, we abandoned the waterfall and did strategy like an agile developer: 5-day idea sprints.

Yes, we still had brilliant strategy statements and research-driven insights, except that they were executed in parallel — exhaust of our idea sprints.

The benefits: instead of spending one week on the recommendation, we spent eight. Instead of recommendations based on research/taste, they’re based on customer-feedback. Instead of words on a slide, we had prototypes and MVPs, a head-start on every idea.

In short, we achieved one thing that no waterfall process can: usage.

Usage is like oxygen for ideas. You can never fully anticipate how an audience is going to react to something you’ve created until it’s out there. That means every moment you’re working on something without it being in the public it’s actually dying, deprived of the oxygen of the real world.
— Matt Mullenweg.

The following process describes our ship-first mindset for strategy development. We failed early and abandoned poor paths. We cycled as fast as possible and received feedback on every idea.

This model is based on design-thinking and customer development. I’ve experimented a lot and adapted the process to a typical strategy project, one that isn’t around a product. This version works especially well for an outcome that requires a plan with detailed recommendations.

Here’s how it worked:

Week 1: We located all of the client’s documentation and developed 50 hypotheses of our final deliverable — the thing that we would recommend Amex go and do (not an abstraction, i.e., a strategy statement).

We developed value propositions and simple paper prototypes of all 50 ideas. Each value proposition is grounded in a problem, creating the beginning of our library of research. It’s also supported by an internally or externally-drawn insight.

Week 2: we had customers complete a survey that ranked each value proposition. We chose six to iterate on. This was supported by insights drawn from the client’s documents.

Week 3-6: our design sprints were inspired by the product-design sprint from Google Ventures, but adapted for strategy development. In one week a team can sketch, prototype, test, and report-out feedback on an idea.

Monday: we sketched out the most important user story for the idea. We used Google Ventures’ mind-mapping and crazy eights exercises. Finally, we storyboarded what we wanted to design for the user.

Tuesday: we repeated Monday’s process for 1-2 additional ideas. We wrote assumption-test pairs for everything that would be tested.

Wednesday: this was maker day, where we would develop all of our mock-ups for testing. We worked in Codiqa for ideas that required complex UX. We used Keynote (with Keynotopia) for ideas that only required UI.

Thursday: this was demo day. We recruited a few customers who would validate our assumptions via our Keynote/Codiqa mock-up. We also invited the client to sit-in on this process.

Friday: this was a scrum day. We quickly translated our feedback into insights and spent an hour with the client reviewing our mock-ups, feedback, and insights. We also collectively decided what we’d mock-up and test the following week.

In parallel with the weekly design sprint, we extrapolated strategy from our ideas. We created a library of insights and strategy statements.

Each week, we decided to iterate on an existing idea, throw it out, or consider it “validated.” Over four weeks, we tested roughly eight ideas.

Week 7: after 7 weeks, we had a deep library of mock-ups, strategy statements, and insights. At this point, the client’s involvement in scrums had exposed them to every idea and insight. We had all the pieces of an awesome strategy and could spend two weeks converging. We prioritized our ideas again and considered any broader themes that they represented.

We then asked ourselves:

• What can we infer about strategy when we consider our favorite ideas? Is there a bigger vision at-hand?
• What problems do our ideas solve?
• Is there a narrative that can connect our favorite ideas to a broader theme?

We developed a strategy that was explicit enough to tee up a v1 (our prototyped ideas) and potentially future ideas that we had yet to explore. We wrote the strategy artifact (the deck) in 2nd person to a customer, as a startup product page would. The strategy wouldn’t be some vague consulting-y language, but prose as you would write for a human.

We developed an MVP of each idea that the client could take into an execution phase.

Week 8: this was a maker week. We created a Keynote presentation that explained (1) market shifts, (2) customer needs, (3) our strategy, (4) our recommended path forward, and (5) MVPs that the client should go make and bring-to-market.

Compared to typical waterfall projects, items 1, 2, and 3 would just be finishing up at the beginning of week 8. In such a case, we’d have a measly 5 days to tackle item 5.

With Amex, we spent 7 weeks instead of 5 days, which yielded a far more detailed recommendation and without making compromises on the deliverable.

UPDATE: I think that this process is best used for the Blank-ism “unknown problem, unknown solution,” or sometimes referred to as a “wicked problem,” one that could be clearly defined only by solving it. Another mental model is Gentry Underwood’s “ethnography by prototype” — you can really only understand a user’s problem/need by attempting to solve it.