Framing the Work to Encourage Experimentation

Jeff Gothelf and Josh Seiden are rock stars in the Lean UX world, and the designers, strategists, and co-authors are back with a new book, “Sense & Respond: How Successful Organizations Listen to Customers and Create New Products Continuously.” We mention this new bit of required reading because Jeff and Josh are leading a workshop related to their book at our upcoming Lean Startup Conference New York on May 10–11.

Get a taste of the sharp, actionable nuggets of expertise these Lean Startup gurus have to offer with a blog post they wrote specifically for our community on Framing the Work to Encourage Experimentation.

Sprints. Stand-ups. Retrospectives. Most corporations these days are using an Agile vocabulary in the way they work. Many of those same companies have adopted Lean Startup language as well — the simultaneously celebrated and misunderstood concept of MVP being the most popular term at the moment. When it comes to actually following the practices these terms describe, however, many teams begin to flounder.

Why? What makes it so hard to create a culture of experimentation and continuous learning in high growth and other large organizations?

One reason has to do with how work is chartered for teams. Almost without exception, managers dictate specific work to be done to their direct reports. Managers use specifications or requirements documents; they use project plans, deadlines that reflect a fixed scope. They allocate locked-down budgets that are tied to features and functionality. Teams are left with little choice. They commit to the project: marketing plans set, launch dates and bonuses promised. It’s all based on an initial, assumptions-filled speculation — the assumption that leadership knows the right thing to build.

It’s hard for teams to resist this process. Anything that might cause deviation from the plan is met with resistance from leadership — everyone has a vested interest in supporting the plans once they’re made. While this may make sense in situations where there is little uncertainty (e.g., a manufacturing plant), the foundational material of organizational growth in the 21st century is software. And with software comes uncertainty.

Managers who want to encourage their teams to seek out validated learning, discover the best customer experience, and build a cadence of continuous learning and improvement need to rethink how they frame the work for their teams. Dictating a set of solutions to be implemented is a strategy best saved for the assembly line. Instead, managers need to provide their teams with Business Problem Statements.

Tactic: Business Problem Statements

Business Problem Statements take a customer-centric, outcomes-focused approach to the work that teams need to accomplish. They present an issue that needs solving and provide a customer-centric behavior metric (an outcome) as the measure of success. Instead of specifying a solution, Business Problem Statements ask a question. This allows the best ideas to emerge as the team pursues the answer. Perhaps most importantly, Business Problem Statements encourage Lean Startup-style experimentation, reducing investment in bad ideas and allowing the teams to pivot as new information comes in. In other words, they allow teams (and organizations) to be agile.

The Anatomy of a Business Problem Statement

A business problem statement is made up of three parts:

1. The original goals for the product/service/system.
2. The problem the business has identified that requires some attention and the impact that this issue is having on the business, along with any data, insight, and other corroboration.
3. A specific request for improvement stated as a change in customer behavior (not as a set of features)

Here’s a simple example:

The concession stands scattered around the stadium are an important money maker for our baseball team, and they’re popular with fans.

But long lines at the concession stands limit the amount of business that they do, and discourage fans from buying food and drinks during the game.

How might we supplement the existing concessions system in order to make food buying easier during the game as evidenced by an increase in total sales and a flat profit margin?

When written well, business problem statements constrain the solution space for teams. This is good for the teams. A tighter space means more focused, applicable solutions. Creativity thrives within these constraints. In addition, it gives teams a clear sense of why they are working on something — not just why it’s important for the business, but also for the customer. The foundational philosophy behind this tactic is that customer value is equal to business value. The more successful we can make our customers, the more successful we will be as a business.

Writing a Business Problem Statement

Let’s take a look at how you can write a Business Problem Statement. This is a template that we’ve put together to help teams reframe their work this way:

[Our service/product] was designed to achieve [these goals]. We have observed that the product/service isn’t meeting [these goals] which is causing [this adverse effect/business issue] to our business.

How might we improve [service/product] so that our customers are more successful as determined by [these measurable criteria]?

You can clearly see the three components of the problem statement articulated in the template — the original intent for the product, the problem we’ve observed, and how we’ll measure success. Note that there is no room in the template for specific feature requests. As we mentioned before, this is intentional. The Business Problem Statement is a question, not an answer. A problem, not a solution. Teams should create hypotheses about what the best solutions might be for this problem and then use build/measure/learn loops to discover which ideas work and which ones don’t.

Still, we’ve noticed as we’ve trained teams in this method that solution-oriented thinking is hard to avoid. Many Business “Problem Statements” end up looking something like this:

Example of Poor Business Problem Statement:

Our competitors have all shipped mobile applications in the last 12 months and are advertising them heavily. With the ongoing need to stay competitive, we too must develop more mobile products.

To achieve this we intend to launch an iOS application by Q3 2017 and ensure all of our marketing sites are mobile-friendly by the beginning of Q4. In addition, we will launch a Facebook mobile ad campaign to ensure our acquisition targets are hit this year.

Instead, we want them to look like this:

Example of good Business Problem Statement:

With a tremendous increase in funding for ed-tech startups, we’re concerned by the risk of external disruption by a more nimble competitor. New students both in the US and abroad are entering schools with a mobile-first or mobile-only mindset. Our products are heavy and not mobile-friendly and we risk losing incoming cohorts to these newer competitors.

We believe we should invest in more and more capable mobile offerings but are not sure exactly where those investments should go. Success is defined as a 15% increase in mobile device usage of our flagship learning management system by our student population.

The second example contains all three of the main components of a good problem statement and leaves the door wide open for the teams to come up with their best solution ideas.

How do Business Problem Statements encourage experimentation?

When work is framed this way, teams don’t have a set of features to build and ship. In fact, they have no idea which combination of product, service, features, design, copy, and code will achieve the stated outcomes. They have to discover these answers. The only way to do that is to experiment. It’s incredibly risky for a team to simply choose a direction and spend the entirety of their project’s timeline in that one direction without validating that this is the direction that will yield the desired change in customer behavior.

Teams brainstorm their best ideas and begin to run experiments, build MVPs, and collect qualitative and quantitative feedback on these early ideas. Over time, the better ideas emerge and the team can continue to build/measure/learn their way to a great solution. Since teams are being asked to solve problems rather than ship features, they are not under pressure to hit specific deadlines. Of course, we encourage teams to discover solutions by shipping code, and in doing so, hope that it won’t be long before great, evidence-driven solutions make it into customers’ hands.

Why Business Problem Statements can be difficult

Business Problem Statements can be liberating to teams and leadership. They can help organizations increase their agility. They can help drive a culture of continuous learning. But they can also be challenging to implement. Here are a few things to keep in mind as you go down this path:

• No clear feature-based roadmap: “What’s easy to measure is easy to manage,” or so the saying goes. Shipping features is a binary activity — the team launched a feature or it didn’t. This makes features easy to measure and easy to manage. A manager can easily lay out a feature-based roadmap that communicates to the organization when each feature will launch and how close to “done” the team is at any moment. Business Problem Statements take a different approach: they encourage managing to outcomes instead. It’s harder to state progress, and harder to know when you’re done. (e.g., if our success criteria is to increase retention by 50% and so far we’ve increased retention by 22%, when will we hit 50%?) If a team and their manager can’t clearly communicate their progress and next steps, they may feel pressure to revert back to fixed scope and time planning.
• Redefining “done”: In traditional Agile circles, “done” means we shipped working code that was bug free and passed QA. With Business Problem Statements, “done” means we’ve effectively changed customer behavior. Shipping a feature is the beginning of our work, not the end. This is a significant shift to most software teams and cultures.
• Local optimization: Once adopted and implemented, this technique gives teams the freedom to figure out the best solution to their constrained problem space. Teams may then optimize locally to ensure they hit their goals (and get their incentive) without much concern for other teams’ work. This local optimization may inadvertently harm other teams’ attempts to optimize their workflows. Cross-team coordination and shared outcomes are critical to reducing this risk.
• Problem Statements may be treated as unquestionable: Our friend Jeff Patton often jokes about the day he learned that “the word ‘requirements’ means ‘shut up.’” Problem Statements are not requirements or unquestionable commandments handed down from on high. Problem Statements themselves may contain incorrect assumptions. As teams begin to learn about the problem, they may discover learning that reveals flaws in the Problem Statement itself. They might find out they’re solving the wrong problem, or they might find out that they’ve been given a problem they can’t solve. This can be a thorny conversation that teams may be hesitant to bring up.

Organizational agility can only come if teams learn how to experiment and have the ability to pivot according to their findings. One way to help bring that conversation further upstream in the management conversation is with Business Problem Statements. When leadership frames the work as a set of issues to be solved and redefines success not as a set of features but as changes in customer behavior, this allows teams to begin building a cadence of continuous learning and improvement. And it drives home the idea that experiments, MVPs, and course corrections are not only accepted but welcomed.

Want to learn more from Jeff & Josh during a hands-on workshop? Register for a gold pass to our Lean Startup Conference New York.

Have an idea for a blog post you’d like to contribute? Check out the blog contributor guidelines and submit your pitch through our submission form.

Originally published at Lean Startup Co..