A Framework for Driving Complex Decisions 🚗

A framework I've been noodling on for getting multiple stakeholders to a shared decision.

Hi friends 👋

Welcome to the first of many Sunday evening discussions centered around solving problems and wowing customers.

The idea behind this weekly email is pretty simple.

1. I have more ideas when I’m forced to regularly write and share with others.

2. The process of writing helps to clarify my thinking.

3. Input from others helps to further shape and stress-test my thinking.

So, view this as a forcing function of sorts to learn in public.

I also hope to make this a two-way street. I’d love to hear what you’re working on as well. The reply button is encouraged!

On a more somber note, my heart breaks for Ukraine 🇺🇦. It’s incomprehensible to imagine what they’re going through right now. I’m hoping desperately for a resolution, but I did want to highlight two resources - one from Oyster and another I found via LinkedIn - in case they’re helpful for anyone. ❤️

Let’s get on with the meaty topic for today, and I’ll see you next Sunday evening.

Have a great week!

Jeremey

Please say hi (reply here or at jeremeylduvall@gmail.com). I’d love to hear from you.

---

A Template for Driving Big Decisions With Multiple Stakeholders

Many times in the past, I’ve found myself guiding a group towards a decision. Often times, members each have juggling priorities that can seem at odds with one another.

There are two extremes in outcome:

1. With planning and forethought, you can arrive at a clear decision with everyone onboard.

2. When you rush towards a decision, you lose buy-in along the way and take longer to arrive at the destination.

I’m here to admit that I’ve done my fair share of rushing. 🙋‍♂️

I recently put some thought into this and came up with a templated process to become a better decision maker within an organization.

This template works like a ladder in that if you skip a rung, you’re much more likely to fall back to the bottom and start back over. On the flip side, if you follow each step, it should be clear to an outside observer how you went from bottom to top.

Rung #1: Problem Statement

It feels obvious that everyone should agree on the problem you’re trying to solve before talking solutions. But, in my experience, it can be common to begin debating solutions when a hard reset comes up in conversation:

Wait, is that the problem we’re trying to solve here? I thought it was ____.

Agreeing on this upfront in the process reduces the chance that you’ll have to circle back and start over later on.

For phrasing, I’ve used two approaches.

1. State the problem clearly. (e.g. “Churn is up 40% for a segment of our users.”)

2. Describe the solution in JTBD-esque format. (e.g. “We need to implement 1-3 options that cuts churn for a segment of our users by 20%.”)

Rung #2: First Principles, Constraints, and Future State

Now, it’s time to explicitly state first principles, constraints, and the future state. Get these out of heads and onto paper so you’re all operating with the same mental map of the situation.

First principles - Cornerstone beliefs and assumptions. First in our churn example, first principles could be:

• We believe the rise in churn is a real problem and not a temporary blip.

• The customers churning are ones we should be retaining. The real problem here is retention, not qualifying appropriate customers.

Constraints - Factors that will influence the feasibility of options for this particular problem. This could look like:

• Options should need minimal to no engineering effort.

• We need to ship an experiment within the next two weeks.

Future State - How this thinking could impact future plans. For example:

• We’re shipping V2 of this product later in the year so any solution here should be adaptable.

Rung #3: Evaluation Criteria

Given the everything we know now including the problem statement, constraints, etc, how are we going to evaluate ideas?

If you don’t take the time to state these criteria explicitly, everyone will proceed with a slightly different rubric in their own mind. Take the time to make the implicit explicit.

This takes three broad steps:

1. Ask yourself questions like, “When evaluating options against one another, what dimensions make sense? Are some dimensions more important than others?”

2. Get granular enough on each criteria that everyone can have a shared definition.

3. If possible, turn the criteria into a Yes/No answer based on the constraints.

For example: Speed → Can this be shipped to users in less than 2 weeks?

I’ve found it helpful to have a “Summary” section that lists the criteria and then evaluates each option in a table format.

Example of a Summary section I’ve found to be helpful when comparing multiple options.

Rung #4: Gather and Check Options

We can finally start throwing spaghetti at the wall! This is the step most folks gravitate to immediately when faced with a decision.

Instead of evaluating each suggestion as it comes your way, break this into four distinct pieces:

1. Gathering ideas. Best case scenario, you round these up from up, down, and diagonally across the org. Float the problem and context to anyone involved and encourage them to dump ideas in a central place. More ideas from a diverse set of people means less chance you’ll miss something.

2. Group similar ones. Look beyond the surface level and try to understand which ideas are fundamentally similar. Going back to our churn example:

   • Launch a 4-part educational email series for new users.

   • Offer 1:1 introductory sessions with all new customers.

   These ideas both share the fundamental kernel of user education.

3. Generate explicit options. At this point, you’ll have something akin to a grouping of Post-It note ideas for each fundamental theme. Your job is to translate these to detailed options with clear trade-offs.

4. Rank options. Use the selected criteria to compare each option against the others! Present this information in a clear, summarized view for everyone to see.

Rung #5: Decision

Now, the hard easy part! And, I mean that seriously.

Decisions are difficult because we skip over the necessary rungs that keep everyone on the same page and gives them the same context. When we race to a decision then, it shouldn’t be surprising that everyone has a different opinion. We’re all operating with different information!

Following the necessary steps of defining the problem, gathering the context, establishing the criteria, etc means two things:

1. The “right” options becomes almost self-evident. At the very least, it’s clear which 1-3 options offer the best solution to the problem.

2. Any disagreements are much more specific and informed.

The second piece is critical. Without the context and criteria, our disagreements might be hard to resolve because it’s tricky to really understand what we’re disagreeing about. By making this all explicit, we give everyone the language to express their opinions clearly:

I disagree because I don’t think we can deliver Option A in two weeks, and I actually do think it will require engineering resources, which we’ve said is not possible.

What’d I Miss?

Do you have a different process for getting everyone aligned? Did I miss a key component? Let me know! I’d love to hear from you.

---

Misc.

Interesting tools, books, and articles I stumbled across this week.

• I just finished reading An American Sickness, which goes into great depth about the downsides of our healthcare system in America. It’s a terrific read if you’re interested in the subject. Got me very fired up about what we’re working on at Ness.

• Retool is the coolest app/product I’ve seen in quite some time.

• The 10 Commandments of Salary Negotiation

• Taking a Problem From Beginning to End

• All About Building and Growing Waitlists