#11: Accelerate complex problem-solving through weekly 4hr sprints

---

I am going to share with you a way to lead internal projects that accelerates problem solving, especially when you need a cross functional group for decision making and evolution.

Work rarely gets done in meetings.

Let’s be honest. Real work rarely gets done in meetings. The reality for most people I work with is that they are back to back all day in updates, check-ins, 1:1s, and weekly reports and have to find quiet times in the evening to do the critical, complex thinking. There are other reasons why work rarely gets done in meetings:

• meetings are usually too short to dig into anything meaningful

• poor facilitation

• lack of prep work to drive impactful conversations

• missing key individuals or customers for input and feedback

So, we have a meeting to decide on next steps and schedule another meeting. And on and on we go. No wonder why so many of us are burned out!

There is a better way: the 4hr sprint.

---

ACCELERATE COMPLEX PROBLEM-SOLVING THROUGH WEEKLY 4HR SPRINTS

Stop meetings. Start 4hr sprints.

A few years ago, I was working with a 100-year-old manufacturing company that wanted to implement a new internal risk management tool. (I promise you it was a lot more exciting in real life than that 1-liner!)

The idea needed buy-in across Sales, Operations, and Customer Success all with limited capacity and who usually work in siloes.

Old way:

1. Create a 50 page presentation with the approach.

2. Go to each VP to sell the idea.

3. Hire a consulting firm or make an argument for new headcount.

4. Wait weeks or months to get started.

New way (what we did):

1. Created a 4hr weekly working session.

2. Went to each VP to ask for exactly 4hrs/week of time from key team members for 3 weeks. Not a minute more.

3. Didn’t hire anybody but activated facilitation skills.

4. Waited 1 week to get started.

Inspired by Google Ventures

This isn’t a new concept. The concept of Sprints was popularized by Google Ventures as a 5-day process to go from problem definition to tested ideas with customers.

I love leading a good 5-day sprint. It’s fun, immersive and intense.

It also is impractical for most day to day teams, which is why I prefer a 4hr weekly sprint cadence.

Benefits of this approach

• Reduces context switching: Stops the mental fatigue of constantly switching between problems and context every 30 min

• Accelerates problem solving: We aren’t waiting for the right meeting or "a workshop" to start evolving the work, we are just starting.

• Increases team connection: The longer work periods allows people to get to know each other, especially who work in separate teams

• Increases productivity: This isn't a meeting. we are doing the work, people!

• Allows for breathing room: Instead of a traditional 5-day sprint that forces ideas in a short period of time, spreading out the work gives space your brain to digest the content from the week before

When to use it

I tend to use this approach when:

1. there is a discrete problem to solve or idea to evolve

2. you need to bring a cross functional team together

3. they have limited time to work on the problem

4. leadership is asking for quick results

5. you have access to customers/stakeholder for feedback

6. the team has facilitation skills to lead the process

How to design a 4hr sprint

Here is a sample agenda:

Hours 1 and 2: Recaps + Active Problem Solving

30 min: Recaps, strategic warmups and time to connect

Why?: Participants are probably coming from another meeting and need time to fully arrive, get their head into the game, remember past context, and focus on what to expect in the next 4 hours.

90 min: Focused time for problem solving. Design flare, explore or focus frameworks depending on your workshop goal

Why?: Without visual frameworks, you are going to lose people and you risk everyone just talking, no action. Simple fill in the blanks and prompting questions can get people into action. This is also the core of connecting your workshop goal to tactical activities

Hour 3: Break + Prep for stakeholder feedback

30 min: Break.

Why?: Because we are humans, not robots. Invite them to spend 5 minutes to make sure there are no fires happening with their other work and encourage a walk, food and hydration. Do the same for yourself.

30 min: Prep for customer/stakeholder feedback

Why? So the team feels just prepared enough with the right questions to ask to evolve the work you just did

Hour 4: Stakeholder Feedback + prep for next week, feedback

30 min: customer/stakeholder feedback.

Why?: Reduce the time from creation to constructive feedback to accelerate the work. Don’t wait for another meeting. Invite them into the mess. Show them the unfinished work to evolve your idea. Also, having customers and stakeholders in the room gives a reason for your team to stay the whole time :).

30 min: Debrief on the feedback and make a plan for the next 4 hr Sprint

Why?: Because teams always love the post-feedback chit chat on what they learned. It creates engagement and excitement for the next working session.

---

Agenda template I always use

Need help creating and managing your agenda? Here is a free Google Sheet template that I have used for 10+ years to design your next workshop. Feel free to steal it, use it and make it better.

Results from the 100-year-old manufacturing client

We reduced time to market by 75+%.

When we worked in this way, the 100-year-old manufacturing client would normally get a functional tool in front of their internal customers in 12+ weeks.

We did it in 3.

We got the right team, right facilitation and right prototyping mindset to drive action in days and weeks. Not months or years.

#09: How to build team connection through C- work

---

I am going to explain to you how to increase team connection and accelerate tasks by asking for C- work.

Prototyping is a vulnerable act

For most workplaces, Sharing unfinished work to your team or boss can be daunting at best and be risky to your job security at worse.

Paradoxically, in modern product-led organizations we are asked to “fail fast” and to launch unfinished products using names like minimum viable products, beta tests and pilots.

Leaders and teams want the outcome without practicing the behavior.

The good news?

We can be those leaders to create that change by adopting a prototyping mindset in the team meetings we lead. Be vulnerable. Go first.

Vulnerability is the birthplace of connection

Brené Brown is a researcher and storyteller who's spent two decades studying courage, vulnerability, shame, and empathy. After years of research, she concluded that “Vulnerability is the birthplace of connection and the path to the feeling of worthiness.” If you haven’t seen it, I highly recommend her TED talk

In the workplace, we understand the philosophy that connected, high trust groups are needed as a baseline to create a high performing team.

But how do we create those deeply connected teams? I have found it in an unlikely place: prototyping.

I learned this the hard way 12+ years ago 

I was working at a high pace, boutique consulting firm and I had an important client presentation to the next day.

My default behavior, that I exhibited over and over again early in my career, would have been to spend 10+ hours late into the night trying to think my way into making the perfect deck.

Instead, my old boss Tim, set clear expectations for me:

"David, spend no more than 1 hour on this. Show me your best C-work...because you will probably do it wrong”

And then he found 10 minutes later that day to help me evolve that C- version, side by side.

A funny thing happened that day. Instead of feeling fearful of my boss or stuck in my head whether I was going to do a good job, I got to work. My only goal was to make a shitty first draft! The freedom! The ease! And I felt trust knowing my team and leader had my back to help me make it better.

I felt more connected.

From A+ to C-

We all want A+ work. Most of us grew up in an education system that demands it. If you brought a C- report card home, would your parents celebrate it and put it on the fridge?

I am not saying that the end work outcome shouldn't be A+ work. It should. I am saying the path to get there should start with C- work and continuous iterations. Problems are too big and too hairy to think our way out of them. We need new team behaviors of sharing unfinished work quickly and often with each other.

Building team connection through C- work

The old way: Assign Tasks

1. Leader assigns a teammate a task.

2. Teammate works on it for an undefined amount of time until it is hopefully A+ work

3. Then, there is an “update meeting” or a “review meeting”, probably in a week

4. Teammate crosses their fingers and hopes the review goes well

5. Leader gives feedback on what to change for the next update meeting

The old way creates disconnection between the people and the work

We are waiting to give feedback. Leaders aren't rolling up their sleeves. There are also other problems with this way of working.

• Teammates can be confused on what is being asked of them the first time and are afraid to ask

• Update meetings can feel nerve-wrecking like big thumbs up/thumbs down events causing more of a focus to look good in the meeting vs. offering critique of the work

• Wasted time with a task moving in the wrong direction without early feedback

• Leaders not sharing their own vulnerability in not knowing the right answer, causing even more disconnection

There is a better way.

The new way: Co-create with C- work

1. Leader assigns a teammate a task

2. Leader asks for a C- version of the task. (Bonus points if you each make a quick C- version in the room)

3. Leader asks teammate to evolve the work for a very short, defined time

4. They continue to co-create until it's an A+.

Benefits of the new way:

• Builds team connection by making and creating together. Prototyping is a vulnerable act and vulnerability leads to connection.

• De-risks an idea, presentation or work artifact

• Creates a more collaborative environment

• Provides a safe space to practice prototyping mindsets, a critical behavior for modern product development

• Gives confidence to the team on how quickly work can get done

Do you have the courage to share C- work?

It starts with you. Be vulnerable by sharing C- work and watch your team get more connected and accelerate their work.

#06: 3 steps to drive weekly experimentation

---

Here are 3 strategic steps that propel teams from nervous waiting periods into continuous product development.

Step 1: Anchor to a Learning Goal

Step 2: Design an Experiment

Step 3: Ask for the Evidence

You don't need permission from others to get started.

We have all been there. We have a new project at work. There are lots of unknowns and you are unsure how to get started. So, you wait.

• You wait for direction from the senior leader.

• You wait for budget approval.

• You wait until someone tells you that you have a good idea

• You wait until the “alignment meeting”

• You wait until the key stakeholder is back from vacation next week

• You wait for the perfect conditions to get started.

Focus on learning and experimentation instead

There is a better way to activate a team. And it involves new language and behaviors around learning goals and experimentation. Some of the benefits are:

• Creates action with the team

• Turns unknowns into knowns

• Creates a structure for the team during ambiguity

• Allows for safe risk-taking to build confidence

---

3 STEPS TO ACCELERATE EVIDENCE-BASED EXPERIMENTS

Step 1: Anchor to a weekly learning goal

Here are 3 examples from projects I am leading/coaching and the blockers I experienced:

Example 1: Governance dashboards: waiting on senior executive buy-in on strategic direction

Example 2: Product Scoping Templates: debate on whether we have the right solution

Example 3: GenAI for Support data: waiting for budget approval from a business stakeholder

At first glance, each scenario would require the team to wait for approval, direction or buy-in. Yes, we need those from leadership but they don’t have to derail us from taking action in the week.

So, instead, ask your team:

What do you want to learn this week?

You can think about your learning goals through the lens of customer desirability, business viability or technical feasibility?

desirability: does your customer/user want it?

viability: is it valuable to the business/organization

feasibility: can you actually make it?

Based on the 3 examples above, here are my learning goals this week:

1. Governance dashboards: What kind of data do senior executives want to see for their product governance structure? Is this even the right audience?

2. Product Scoping Templates: Would an internal discovery team find a 1-page template helpful to clarify their product scope?

3. GenAI for Support data: Can a GenAI solution make the analyst team more efficient?

Framing these questions as learning goals creates a sense of curiosity and wonder. It helps surface the main unknowns in the project or product direction.

Time-boxing it to 7 days sets expectation of the amount of time we, as a team, are going to be thinking about this question.

Once you have the question framed, it is time to take a new approach on how to learn it:

Step 2: Design an experiment to gather evidence

I am very purposeful on the language of experimentation vs ‘the answer.’ Language matters here.

Experiments evoke imagery of a scientist in her lab trying different chemical combinations out to see what works. Trial and Error. Exploration. Making to Learn.

If you recall, all my project examples are waiting for approval or budget, so we have to be scrappy to test our learning goal to keep moving.

What we are trying this week:

Governance Dashboard

Learning Goal: What kind of information do senior executives want to see for their product governance structure? Is this even the right audience?

Experiment: Async message to 2 execs with Excel charts with fake data about their teams and ask them to take an action.

Product Scoping Templates

Learning Goal: Would an internal discovery team find a new 1-page Template helpful to clarify their product scope?

Experiment: A 55 min workshop the following week to get 5 teams to use the new Template and ask for live feedback.

GenAI for Support data

Learning Goal: Can a GenAI solution make the analyst team more efficient with their support database?

Experiment: Take the most popular support question and make up 3 different answers and feed them to analyst to see their reaction.

--

Note, all the above examples involve getting some first-hand evidence toward your learning goal. Push your teams to get real data - this is what is going to drive decision making and next iterations of your project or product.

Crafting the right experiment is part art and science. There are lots of frameworks and examples out there.

I am currently using the Say/Do framework in the new book: The Experimentation Field Book. 

Step 3: Ask for the evidence at next week’s meeting

One of two things will happen.

1. The will run the experiment

2. They won’t run the experiment

Both are helpful.

If they run the experiment, you have data to talk about! What did you learn? How did it go? Are we on to something? What are we missing? It will be a very constructive meeting and will help inform your next iteration to start back at Step 1: What do we need to learn this next week?

If they don’t run the experiment, you say: "Great! What prevented you from running it?"

Typically, reasons fall into a few categories:

• No access to data

• No access to customers/users

• I didn’t know how (capability)

• I didn’t have time (capacity)

As the team lead and meeting facilitator, you are now getting weekly evidence to evolve your product or surface team blockers.

Either one is helpful and actionable to de-risk your strategy your idea.