chapter 9 move forward

CLOSING THE LOOP

Kevin Rodriguez had a dream: he wanted to open a gelato store in New York, selling the delicious Italian ice cream he was such a fan of consuming.

As it happened, Kevin was a good friend of Ashley Albert, the entrepreneur behind the Royal Palms Shuffleboard Club.* Naturally, he asked for her help in realizing his dream.

Ashley crushed Kevin’s dream in less than eight hours.

She did this by inviting Kevin to walk around the city together, visiting gelato stores and chatting up their owners. As she told me:

For the entire day, no matter where we went, we were never, ever in a situation where we couldn’t find a nearby gelato store. And when we spoke to the owners, it became clear that it was not a very profitable business either: most of them survived by selling coffee. From the visits, one thing was totally clear: this was not a problem that needed solving.

At first glance, crushing someone’s dream sounds like a bad thing. But consider the alternative: Kevin might have gone ahead and launched his gelato store, spending his savings and a few years of his life on something that would never take off. Ashley’s insistence on a simple idea—let’s just go out and check how things are going for the gelato store owners—allowed Kevin to shift his energy to a more promising problem (which he did; see the endnotes if you are curious).

Test your problem

Most people know that you should test your solution before you commit to it. What is less well recognized is that before you test your solution, you should make sure to test your problem. Like a doctor who runs a few tests to confirm his diagnosis prior to operating, good problem solvers also work to confirm that they have framed the problem correctly before they switch back into solution mode.

This is a central point, because even the process of testing a solution can quickly become a serious time sink. In your excitement to build the solution, it’s easy to think, Hmm, what should I call my gelato store? Would a focus group help? What kind of ice should I sell? And how about the decor—can I get an interior designer to do a mock-up? For technical solutions, the temptation is even greater: Can we actually build this terribly exciting gadget I’m dreaming of? Let’s head into the engineering lab for eight years and give it a try.

What’s worse, testing solutions can create a bad form of momentum that’s unconnected to whether the problem is valid. Once you find the perfect name for your gelato store, it gets a lot harder to go back and challenge whether opening a gelato store is a good idea in the first place.

To avoid these situations, the last step in the reframing process is to plan how you’ll validate your problem framing through real-world testing. Doing this closes the reframing loop (for now) and brings people back into solution mode. It is similar to action planning, but with the specific focus on making sure your efforts are pointed in the right direction.

In the following, I’ll share four specific methods for problem validation:

Describe the problem to the stakeholders.
Get outsiders to help you.
Devise a hard test.
Consider “pretotyping” the solution

1. DESCRIBE THE PROBLEM TO THE STAKEHOLDERS

When he’s dealing with armed hostage takers, the FBI hostage negotiator Chris Voss swears by a simple yet powerful technique called labeling.* As Voss describes it:

If you’ve got three fugitives trapped in an apartment on the twenty-seventh floor of a building in Harlem, they don’t have to say a word for you to know that they’re worried about two things: getting killed, and going to jail.

Voss doesn’t start the conversation by trying to convince them to do anything: you can’t escape, so drop your weapons and come out or things will go badly! Instead, he starts by labeling their fears, using a very specific wording:

It looks like you don’t want to come out. It seems like you worry that if you open the door, we’ll come in with guns blazing. It looks like you don’t want to go back to jail.

As Voss points out, there is something powerful about hearing your problem described accurately. Like you’ll recall from the pfizerWorks posters—these documents have to be done in eighteen hours?—when someone shows that he or she understands your problem, it creates trust and opens the door to collaboration. Voss himself credits the method for resolving countless hostage situations. (And as he observes, if you get the problem wrong, you can always say “I’m not saying it’s true. I just said it seems like that.”)

Problem meetings

The method is useful not only to negotiators. If you need to validate your problem framing, one of the most cost-effective things you can try is simply to describe the problem to the people that are involved.

In the startup world, for instance, Stanford professor Steve Blank advocates for “problem meetings,” in which you (as an entrepreneur) go to your intended customers and try to describe their own problems to them.* The point is not to convince anyone of the framing, but to test whether it resonates. As Blank puts it, “Your goal is to get the customers to talk, not you.”

Startup Cisco

I also saw the method used in a corporate setting, when Cisco employees Oseas Ramírez Assad, Edgardo Ceballos, and Andrew Africa created an in-house service called Startup Cisco that aimed at testing ideas rapidly.*

“Cisco’s people regularly come up with amazing ideas and technical innovations,” Oseas noted, “but we weren’t always great at testing those ideas quickly and seeing if they actually matched a problem our customers had. So we started running workshops that focused on doing that.”

The need for rapid validation was inspired by an external consultant, Steve Liguori, who drew on his experience working with GE:

There was a strong cultural norm of never showing anything to a customer until it was immaculate. Instead, the engineers would say, We can build this, and validation would typically happen in a room of executives saying, How do we feel about this idea? The customer would hear, You’re gonna love it, for three years without actually seeing the thing. And then it would come out, and it would be perfect, but then the customer would say, Okay, but why doesn’t it do this? And then, when it didn’t sell, people would go, Oh, stupid marketing and sales people, they didn’t sell it properly.

In the beginning, a similar thing would happen at Startup Cisco’s workshops. As Oseas said:

People would come to us with strong ideas about the technical product they wanted to build, and would effectively reverse engineer the customer needs so they justified their idea. After trying that a few times, it became clear that we needed to delay the solution-building until the problem had been properly understood.

To gain that understanding, Oseas and his team relied heavily on the idea of connecting with clients early. Oseas commented on their method:

We go to the client and say, “We are researching this issue. Is that issue actually a problem for you? Can you tell me more about that?” The key is to focus on their problem rather than the solution—because that’s what makes them relate to it, and that’s the core thing we need insights about. Are we getting their problems right?

In one instance, a Cisco veteran named Juan Cazila had come up with a promising idea for refineries and gas-extraction sites. However, the project had been stuck in Cisco’s internal processes for about a year, so Cazila joined the Startup Cisco workshop to try to move it forward:

The team pushed me to ignore the usual processes and instead go directly to our customers and talk to them. So on day two of the workshop, we drafted an email and sent it to fifteen high-level executives at companies such as Exxon, Chevron and Shell.

That same afternoon, Cazila got on the line with three of the clients for an informal discussion. We were wondering, do you have this problem at your refineries? You do? How much does that cost you?

As it turned out, all three clients had the problem, and were very interested in solving it. Armed with this information, Cazila then contacted Cisco’s head of services and requested resources to move the project forward. Two hours later, he got a positive reply, allowing the project to go ahead. As of this writing, the project has gotten funded and is being tested with one of Cisco’s largest clients in Latin America.

2. GET OUTSIDERS TO HELP YOU

Outsiders can be a great resource to help validate your problems, as they’re less emotionally attached to your preferred view of the problem (or solution). This can be particularly helpful when you aren’t dealing with a product or service, but something less tangible.

For example, consider the experience of Georgina de Rocquigny, founder of the Hong Kong–based branding agency Untapped and an experienced hand at reframing.* One of Georgina’s clients was a local management consulting company that had been around for a few years but had not yet defined a brand for itself. As the firm grew, it increasingly came up against other, more clearly branded competitors. That made the partners come to Georgina with a problem: We need your help to brand ourselves as a strategy firm.

The client’s framing of the problem was understandable. In management consulting, there’s an implied hierarchy between the strategic consulting houses and the more hands-on “implementation” firms. Strategic work is considered finer—and it often pays better too. For that reason, lots of consulting firms wish to be seen as strategy-focused.

Georgina, however, understood the need to validate the problem. So instead of starting in on the branding work, she convinced the client to let her interview some customers, employees, and partners. As she told me:

The key thing was to get different perspectives into the process, to test whether they were solving the right problem. And as it turned out, they weren’t. The client seemed to feel a mild sense of embarrassment about being at the more hands-on end of the spectrum: We don’t want to be perceived as just a body shop. But as the interviews showed me, the clients actually liked that about them. Clients and collaborators alike said things like, I hired them because they do more than strategy, and I love working with them because while they are smart, they also aren’t afraid of rolling up their sleeves and doing the work.

Interview results in hand, Georgina convinced the consultants that they shouldn’t try to brand themselves purely as a strategic partner, and should leverage—and be proud of—their ability to get things done. The end result was a powerful new positioning around bridging strategy and execution that has resonated with the firm and its clients, and has contributed to the firm’s continued growth.

Georgina reflected on the process: “It’s been interesting to me to see how big a role that feelings play in the job of defining yourself and your company’s brand. Many clients come to me feeling slightly ashamed of what they do, thinking they need to become someone else to succeed. But often, when I talk to their clients, it turns out that the very thing that they are ashamed of is in fact a source of strength for them.”

As Georgina’s story shows, validating problems isn’t necessarily a binary referendum on your problem, in which you discover either Yes, I’ve got the right framing, or No, this framing doesn’t hold water. Sometimes your framing is correct overall—yet validating it surfaces an important nuance about the problem that leads to an even better solution. In this case, the consulting company was in fact right that it should aspire to a more strategic branding. Georgina’s analysis didn’t reject that idea. Rather, it helped the firm see that such branding wasn’t incompatible with touting the company’s execution-based strengths as well. The new positioning also differentiated the firm from the many others that tried to go for the strategy-only branding.

3. DEVISE A HARD TEST

When you are validating a problem, you are not just looking to find out whether it’s real. It can be equally important to test whether the problem is big enough for your stakeholders to really want to solve it. The key to doing so is to devise a test that gets real answers out of the stakeholders. Here’s a story of two entrepreneurs who did that.*

How Managed by Q validated its problem

When Saman Rahmanian bought his first apartment, he decided to join the board of the building it was in. He quickly learned how much of a hassle it was to run a residential building:

I was getting really frustrated by the cleaning provider in particular. They were reputed to be one of the better ones, but the service felt horrible. There was little transparency around whether they did their job properly—my wife would ask, “did they clean the stairs today?” and I wouldn’t know. There were no good ways to communicate with the cleaning crew either, short of either calling their office or hoping that a Post-it note would be noticed and followed.

Saman got an idea: he could create a one-stop-shop service for residential buildings that would professionalize the delivery of cleaning and other services, so board members like him could manage their buildings with a lot less hassle.

Excited by the opportunity, Saman started exploring the idea with colleagues. One was the former community organizer Dan Teran, who ended up as Saman’s cofounder.

Being well versed in lean startup practices, Dan and Saman set out, before they built the service, to validate that their idea was actually something customers cared about. To do so, they created a pitch deck describing the service as if it already existed, and then tried to sell it.

Saman explained: “We set up meetings with twenty different boards of residential buildings and spent a week visiting them and pitching the service. The reactions were very positive: many of them expressed interest and said it was a great idea.”

If Dan and Saman had left it at that, they could easily have believed that they were right on track, and might have started building the service. But they knew from experience that that test was too easy: what customers say isn’t necessarily the same as what they do. So, at the end of their pitch, they requested a down payment. Great that you love our service! We have some open spots starting in a few months—so if you give us your credit card right now and make the first payment, you can secure a spot.

As Saman explained: “Everything you are told before asking for people’s credit card info is not to be trusted, no matter how positive they are. When you ask for their credit card details, then the real reservations come out.”

Their caution was warranted. Only one of the twenty boards they pitched signed up for the service. Bad cleaning was indeed a problem—but clearly, not one that was big or urgent enough to prompt clients to take action.

That, however, was not the end of the story. During their tests, they met with a large commercial real-estate broker whose reaction was immediate: “This would be great in offices.” Saman:

We had a feeling that offices might work, and decided to tweak the sales pitch a bit and give it a try. So something like two weeks after our disappointing meetings with the residential boards, we set up twenty-five pitches to office managers. As it turned out, eighteen of them signed up with their credit cards after the first meeting. At that moment, we knew we had found the right problem to solve.

They named it Managed by Q—as a reference to the handy quartermaster in the James Bond movies. They would eventually go on to attract more than $100 million in funding and serve offices all over the country. They also gained acclaim for their innovative and humane labor practices. Breaking with the much-maligned contractor model employed by other startups, the founders decided to employ their cleaners full time, give them 5 percent of the company, and create real career paths for them. As a result, perhaps for the first time in history, cleaning has become more than a dead-end job.

Four years in, Dan—who had become the company’s CEO—received a US government award on behalf of the company in recognition of its leading-edge labor practices. (Saman is off building his next startup, in the health-care space.) Shortly before this book went to press, Managed by Q was acquired for a sum reported to be over $200 million.*

4. CONSIDER “PRETOTYPING” THE SOLUTION

In some cases, instead of validating the problem, it’s possible simply to test the problem and the solution at the same time. The key is a method called “pretotyping.”* Coined by the Google employee Alberto Savoia, pretotyping is different from prototyping in that you don’t actually build the solution at all, but instead focus on finding ways to simulate the product and see if clients will buy it.

Here’s an example of that. Remember Henrik Werdelin of BarkBox and the Net-90 story? One day, at a team dinner, some of BarkBox’s people started pitching new business ideas to each other for fun.

Inspired by an opened wine bottle, one partner said, You know, I bet we could come up with a fun new dog-inspired design for wine stoppers.* Here’s Henrik:

One thing led to another, and suddenly, people got competitive. Somebody pulled out a laptop and drew a realistic 3-D model of a fun-looking wine stopper. Someone else thought, Hey, I’m just going to set up a site where you can buy it. A third person created an ad for the product and started running a few campaigns on social media. At no point during all this did anyone ever intend to actually pursue the idea.

The team sold their first wine stopper shortly after dessert was served, to a customer who saw it on Facebook. Henrik happened to have taken note of the time from idea to first real-world sale: seventy-three minutes.

Satisfied with having demonstrated their business prowess and fearing that their newly created monster would actually come to life and suck them into a branding Venn diagram involving dogs and alcohol, the team promptly closed down the site and refunded the customer’s money.

Validating your problem is not always necessary. If you can test your ideas this quickly and simply, don’t worry too much about problem diagnosis. Just throw stuff at the wall—or in this case the internet—and see what sticks.

* * *

Once you’ve made a plan for how to move forward, the reframing process is at an end. However, one more step remains: to plan your next reframing check-in. To that end, we’ll take a look at another domain in which regular problem check-ins are a matter of life and death.

THE IMPORTANCE OF REVISITING THE PROBLEM

When Scott McGuire arrives at the scene of an accident and finds someone who’s hurt, he follows a simple routine called ABC:*

Airway: Is the person’s airway clear?
Breath: Is the person breathing normally?
Circulation: Is the person’s pulse steady?

The test ensures that the patient is not in immediate danger before Scott starts treating them for other injuries. If Scott is alone on the scene, he does something else before starting treatment: he sticks a strip of tape on his leg and writes down the time for the next ABC check. “If the patient is in critical condition, I might check his vitals every three-to-five minutes. If he’s more stable, I check every ten minutes. Writing it down is a way to make sure it gets done even if lots of other things are going on.”

Since volunteering for a search and rescue team at age thirteen, Scott has served as a firefighter, an emergency medical technician, a wilderness guide, a mountain guide, and much more. In all these jobs, emergency protocols teach him to reassess the situation regularly:

It can seem like backtracking, but it often reveals newly discoverable information. Sometimes the information was always present—but it requires a revisit of the original perspective to see it clearly. Other times, the situation changes. If someone has broken their ribs, they might not actually feel any pain the first time you check, because their adrenaline is acting like a painkiller. When you check their torso again ten minutes later, that’s when you discover the problem.

Problem framing is similar to ABC checks in that you don’t just assess the problem once—you have to do it at regular intervals.

In part, this is important because problems change over time. Even if your problem diagnosis is initially right, it’s dangerous to stick with it, just as it would be dangerous for Scott to do only one ABC check and then assume everything was fine from then on. As the design scholar Kees Dorst writes of organizations:*

[I]n conventional problem-solving, the “definition of the problem” is always the first step … but by defining the problem, they inadvertently freeze the context too, and more often than not this is a grave mistake that will come back to haunt them as they try to implement their new solution.

Regular check-ins also help in situations with time constraints. Instead of trying to complete the diagnosis upfront, it’s generally better to do a swift round of reframing, move forward, and then return to the problem diagnosis again later, once you’ve gained more information.

FOUR WAYS TO REVISIT YOUR DIAGNOSIS

To make sure you revisit the problem on occasion, you can:

Schedule reframing after each round. At the end of a reframing process, immediately slot the next round into your calendar. The interval depends on the “clock speed” of your project, of course, but it’s generally better to be overaggressive with scheduled check-ins.
Assign the reframing role to someone. When fighting fires, one of the people on Scott’s team is assigned the role of incident commander. That person’s job is to stay at the back and monitor how the fire develops. In a similar manner, it can help to assign someone the job of keeping an eye on the problem and scheduling follow-ups.
Create routines in your team. Routine check-ins can be helpful. In disaster zones, Scott and his fellow emergency workers have a routine in which they have an all-hands meeting every four hours. The meeting might be as short as fifteen minutes. Similarly, teams that work with so-called agile methods often start every day with a “stand-up” in which each team member shares the problems he or she is working on. Can you incorporate reframing into some of your existing routines, such as in weekly staff meetings?
Practice the mindset. Finally, with enough practice, reframing will become second nature to people, allowing them to have a kind of “double vision” to keep both the solution and the problem in mind. In rapidly changing situations, this instinct can help trigger a new review of the problem, even in the absence of structural reminders.

CHAPTER SUMMARY

move forward

Take a look at your problem statements. For each one, figure out how to move forward.

How can you test your problem?

Novice problem solvers look to confirm their theory: Isn’t my solution great? Let’s see if we can do it. Expert problem solvers don’t try to confirm the framing they believe in—they look for ways to prove it wrong. Like Ashley did when Kevin pitched his gelato idea, is there a way to quickly engage with the real world to determine whether you are targeting the right problem?

To validate your framing of the problem, use one of the four tactics we covered:

Describe the problem to the stakeholders. Like the Cisco team did, talk to the involved parties and describe the problem to them. Don’t try to sell them on your framing. As Steve Blank points out, the idea is to see if your framing resonates and to get them to give you more information.
Get outsiders to help you. If you suspect you are too close to your own idea—or if you think people won’t give you honest feedback—can you use an outsider to help you? Remember Georgina’s story about the consulting firm that used her to validate their assumptions around branding.
Devise a hard test. Recall how Managed by Q used a credit card sign-up to test whether people really felt strongly enough about the problem they had in mind. How can you set up a similar test for your problem (or your solution)?
Consider “pretotyping” the solution. If it’s easy and risk-free to test a given solution, just go ahead and try it. Consider using Alberto Savoia’s concept of pretotyping to find nimble ways of testing your solution, like the BarkBox team did with their wine stopper idea.

These are not the only ways you can validate a problem. If you need more inspiration, consult the startup literature—or better yet, talk to someone who has startup experience, just like Kevin did with Ashley.

Finally, before you close the reframing loop and swing back into action, make sure you have planned your next reframing check-in.