One Simple Trick To Save Your Organization Months & Millions

Faraaz Ahmed
7 min readSep 16, 2022

--

Since I left my CEO role at Gust, I have spent a large chunk of my time doing advisory work for mid-to-large companies around their innovation and transformation efforts. It has been fascinating watching these organizations try to change the way they do business (or in their words, “innovate or transform”), and there are two things I have learned: 1)They’re not very good or efficient at this, and 2) There is one reason why: they shun simplicity.

While it is understandable that large organizations are complex, what surprised me is the complexity of their processes. When the goal of an endeavor is change or creativity, simplicity is paramount and not embracing it results in these firms wasting time, resources, and money building large sweeping solutions that seldom achieve their desired results.

There is an entire separate post to be written on the reasons for this complexity, but for now I wanted to share a framework I’ve used to get leaders at these organizations to focus on simplifying their processes for “innovative” type of work. I have them run a pre-mortem.

Pre-mortems are a a technique introduced in Gary Klein’s HBR article on pre-mortems. They are often used by teams when launching products or initiatives and are a very helpful tool in predicting problems that may derail a project. While pre-mortems are traditionally used to find hidden problems in tactics and under appreciated threats (check out Shreyas Doshi’s version of using pre-mortems for product teams here), they are also very powerful in ensuring the efficiency of an innovation project. They do this by forcing simplicity. A successful pre-mortem for an innovation or transformation project will get answers to the feasibility of an idea exponentially faster and save firms lots of money and time.

Think Failure

My method of running a pre-mortem for a transformation or innovation project begins with having the team running the project start by filling out a simple operating model for their project. This varies slightly if it’s an innovation project or an internal process transformation one, but let’s look at an example for what this would look like if a company was launching a new type of product or an initiative that falls outside their core offering or market. Such an initiative would typically come from their “innovation” group.

  1. Audience: who is the user we want to sell to
  2. Value Prop: what problem are we solving for them
  3. Channel: how do we get to them
  4. Revenue/user: how much do we charge users
  5. Cost/sale: how much money and resources is it going to cost us to build and maintain the product

We then try to articulate answers to these prompts. The answers should be no more than a sentence, and written in plain and easy to understand words. This can take a while given people’s desire to make things sound complex.

So you start with the first prompt and ask if this product failed because of the audience, and what could be the reasons behind that. Then you drill down into the answers and try to come up with all the assumptions that are being made that wound up being proven wrong. Validating these assumptions is the work these teams need to focus on before doing anything else. And this validation work usually entails just talking to people.

Get something in front of them ASAP and judge their response. Show a potential partner a simple marketing page of your idea and see if they want to sign up and what reservations they may have, set up a meeting with an internal team and walk them through how their processes will change if a new technology is implemented and see the questions and objections they raise, go to a conference and set up a booth with some basic materials and ask potential users, partners, etc. what would make them NOT want to be part of your product. Things of that nature, and then get to work on understanding if and how you can overcome any of the issues that emerge. Once that exercise is done, go back to the operating model and see if the validation work changes any of the answers. Does your validation work confirm there is a market large enough, can you actually charge users at the level you need to, etc. This will answer the question if the endeavor is even worth undertaking.

Simple is Hard

There is nothing worse than wasting money and resources on a pointless endeavor. While innovations teams at large companies believe this, they for some reason think that you have to spend tons of money and resources to discover if an idea is even worth pursuing. This exercise shows that they do not have to. But its simplicity results in it being met with a bit of hesitation (or downright disdain) by leadership when I try to run it. They just can’t take it seriously. They are used to viewing complex slide decks with serious sounding acronyms and charts and struggle with the ‘basic’ nature of this type of work. In those cases, I remind them that the simplicity of this exercise is its greatest strength, and also they have already paid me a bunch of money, so they might as well try it and doing so is going to save them an exponential amount more.

Eyes on the Prize

The simplicity of this exercise can extend beyond it as well. For instance, another huge waste of resources and time that I have encountered in these settings is the inordinate amount of effort that goes into keeping people updated about a project. These updates are for people who aren’t part of the day-to-day of the endeavor and usually encompass senior leadership. Because these leaders want to know what is happening, and given their stature, teams spend time preparing for meetings in which updates are provided to them. Time that could be better spent moving the project forward rather than on pretty slide decks.

So once the pre-mortem is completed, I tell the entire team how they can best communicate and stay on track with the project. And this is via a simple shared 1-page document that is updated every month.

The first section starts with the answers from the initial pre-mortem prompt and a column that articulates if there are any changes to these due to the work that was performed this month.

The next section has another table with 3 columns:

Lastly you have a table showing growth. These could be a number of metrics, and this warrants a deep discussion on what those could be. In an ideal world it would be revenue and users.

Now the most resistance I meet with this is, why there is a growth metric entry at this early of a stage? And that’s true, any new process or product will show zeros here for a while, but that doesn’t mean these zeros are pointless. They serve as a reminder that:

  1. Growth here is the only thing that eventually matters, and while teams may be working hard on something, as long as that number is at zero nothing really has been accomplished, and
  2. Every effort has to be done in service of these metrics. It helps filter and prioritize what questions everyone needs to be working on.

That’s it. In each subsequent month they should create a new page in this document and paste these same prompts and answer them. Every answer should be no more than a line or two. Anyone from senior management who wants to know where things stand should be asked to refer to this document. Questions they have should be written down in the questions for next month. This pushes them to really think through a question before pushing the team to commit time to work on it.

Another value from running a process using this document is that it allows one to improve. If a project or process fails or runs into delays, looking back at all the monthly 1-pagers serves as a good review and a way to pinpoint where things started going off the rails.

It Always Works

So there you have it, the one simple trick to save you months and millions. If you find yourself scoffing at it ask yourself why. If it is because it is too basic or you believe there is no way anyone in my firm is going to actually buy into this, that is more of a critique of you and your organization. I am not saying it is going to be easy to run a process like this, only that if you can it is guaranteed to work.

--

--