Existing product: problem statement template

Problem statements for existing products are made up of three elements:

• The current goals of the product or system

• The problem the business wants addressed (i.e., where the goals aren’t being met)

• An explicit request for improvement that doesn’t dictate a specific solution

You can use the template shown in Figure 3-2 to express your problem statement. Keep in mind though that there’s nothing magical about this template—or really any of the templates we share in this book. You should adapt the templates so that they make sense to you, your team, and your context.

Figure 3-2. Problem statement template for existing products and services

All too often, teams are tasked with poorly worded business problem statements. In fact, these are rarely problem statements at all. They are typically poorly hidden requirements requests. Take this “problem statement,” for example:

Our competitors have all shipped mobile applications in the past 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 Q2 of this year and ensure that all of our marketing sites are mobile-friendly by the beginning of Q3. In addition, we will launch a Facebook mobile ad campaign to ensure that our acquisition targets are hit this year.

This statement fails to declare a real business problem (other than feature parity concerns with our competition) nor does it indicate the impact (good or bad) this is having on the product or service. Finally, instead of providing a clear business measure of success, it lists a specific set of features and tactics the team is expected to deliver. This way of assigning work to a team does very little to raise their Product IQ or inspire any creativity in finding the right solutions. The team is tasked with a solution to implement rather than a problem to solve.

Here is an alternative version for a hypothetical company working in the educational technology space:

Our Learning Management System (LMS) was intended to provide a central platform to facilitate communication, student body management, and assessment for parents, students, and teachers in most educational contexts.

We have observed new students both in the United States and abroad entering schools with a mobile-first or mobile-only mindset. We have also observed a significant rise in funding for competing educational technology startups catering to this new behavior model. Our products are heavy and not mobile-friendly which increases our risk of losing incoming cohorts of new students through decreased usage and dependency on the LMS.

How might we create more capable and compelling mobile offerings so that our high school and university students increase their usage of the LMS through their preferred mobile device?

This version of the problem statement sets a clear issue for the team to solve. It provides the source of the concern and a sense of the impact it might have on the company’s business and ultimate success. Finally, it provides clear guidelines for how the team should proceed without dictating a specific set of features for them to build, instead opting for an outcome, a change in customer behavior, for them to achieve.

New product: problem statement template

Problem statements for new products are also made up of three elements (see Figure 3-3):

• The current state of the market

• The opportunity the business wants to exploit (i.e., where current solutions are failing)

• A strategic vision for a product or service to address the market gap

Figure 3-3. Problem statement template for new products and services

Let’s continue our example from the educational technology space and write a new product problem statement:

The current state of the educational technology market has focused primarily on selling large installations to school systems focused on making teachers’ and administrators’ lives simpler. These services were created in a desktop world and serve only the providers of education, not the students. These services fail to capture the way incoming students use technology today—a mobile-first or, in some cases, mobile-only consumption pattern. Our new Learning Management System product will address this gap by building mobile-friendly learning experiences tailored to the way primary and secondary school students use technology today as well as how they learn.

Regardless of which type of product you’re working on or who created them, problem statements are also filled with assumptions. The team’s job is to dissect the problem statement into its core assumptions. Here’s how to do that.

Running the exercise: business outcomes

Business outcomes are your definition of done. They are the result your business seeks, and the measuring stick for success. When you manage with outcomes, the question isn’t, “Did you ship it?” Instead, the question is, “How did this create a good result for us, for the customer, or for us both?” When you’re creating hypotheses to test, you want to try to be very specific regarding the outcomes you are trying to create. We discussed earlier how Lean UX teams focus less on output (the documents, sketches, products, and features that we create) and more on the outcomes that these outputs create. Can we make it easier for people to log in to our site? Can we encourage more people to sign up? Can we encourage greater collaboration among system users?

Together with your team, look at the problem you are trying to solve. You probably have a few high-level outcomes that you are trying to create (increasing sign-ups, increasing usage, etc.). Consider how you can break down these high-level outcomes into smaller parts. What behaviors will predict greater usage? More visitors to the site? More downloads of your app? Increasing number of items in the shopping cart? Sometimes, it’s helpful to run a team brainstorm to create a list of possible outcomes that you believe will predict the larger outcome you seek.

In the example in Figure 3-5 (from Giff Constable), an executive leadership team brainstormed and then voted on which Key Performance Indicators (KPIs) the company should pursue next. After consolidating down to the list shown in the photo, each executive was given four M&M’s. As long as they managed not to eat their votes, these executives were able to vote with candy for each metric they felt was most important. Ties were broken by the CEO.

Figure 3-5. Brainstorming a list of possible outcomes

Another way to get to your initial business outcomes is to use a framework called “Startup Metrics for Pirates.” Created by Dave McClure, an early employee of PayPal and the founder of 500 Startups, this framework is based on a customer lifecycle funnel (Figure 3-6). New customers come into the top of the funnel and move through increasing stages of engagement with a business. It also talks about pirates, which is fun.

Figure 3-6. Dave McClure’s Startup Metrics for Pirates

The Startup Metrics for Pirates framework is condensed into the acronym AARRR (Pirates!) and, when expanded, looks like this:

Acquisition

Can we get customers to our new feature or product?

Activation

After we get them there, can we get them to use it?

Retention

Can we get them to use it again? And again?

Referral

Can we get them to tell their friends, colleagues, bosses, or others about it?

Revenue

Can we get them to pay us for this feature?

Each step in this framework indicates a greater level of engagement from your customers. And, in a digital product or service, these are all measurable behaviors, which means they serve as great business outcomes to determine the initial traction of your efforts and where to focus your optimization efforts.

Running the exercise: users

If your team already has a well-defined set of personas, the only thing you need to consider at this point is which ones you will be using in your hypothesis statements. If it’s been a while since you last reviewed your personas, things might have changed. This makes for a great opportunity to ensure that they are still relevant and that you and your colleagues still believe they are representative of your target audience. If you don’t have personas yet, though, this section will tell you how we like to create personas for the Lean UX process.

Running the exercise: user outcomes

Despite the proliferation of Agile techniques like user stories, the user and their goals often become lost in the lengthy debates over features, designs, and implementations. Empathy is at the heart of great products and services. Designers often have been responsible for advocating for the user from an empathetic point of view. As we now know, this is not uniquely a designer’s responsibility. To achieve broader shared understanding of users and a deeper sense of empathy for what they are trying to achieve, we ask our teams to declare their assumptions about what users are trying to do, in the form of user outcomes.

To do that, ask your teams the following:

• What is the user trying to accomplish? Example: I want to buy a new phone.

• How does the user want to feel during and after this process? Example: I want to feel like I got the phone I need at a good price and that I’m keeping up technologically with my peers (i.e., I want to feel cool).

• How does our product or service get the user closer to a life goal or dream? Example: I want to feel tech-savvy and respected for it.

Note that not every user outcome exists at all three levels. But thinking about outcomes in these terms can help you to find important dimensions of your solution to work on, from the functional, task-oriented outcomes to the more emotional experience-oriented outcomes.

User outcome brainstorming process: Again, sticky notes and whiteboards are our preferred tools here (see Figure 3-11). Allow individuals on the team to generate many ideas in silence and then organize those ideas with an affinity mapping exercise to drive the team toward convergence.

Figure 3-11. A team brainstorming together

Running the exercise: features

After you have a list of business outcomes in mind and have set your focus on a group of users and their needs, it’s time to begin thinking about what tactics, features, products, and services you can put in place to achieve them. This is typically the part where everyone on the team has a strong opinion—after all, features are the most concrete things we work with, so it’s often easiest for us to express our ideas in terms of features. Too often, though, our design process begins when someone has a feature idea, and we forget to investigate whether the feature will create meaningful results for the business, or for its customers and users. In Lean UX, features exist to serve the needs of the customer and the business.

Feature brainstorming process: Employing the same techniques described earlier, we like to create feature lists by brainstorming them as a team. We’re looking for features we think will help users achieve the user outcomes they seek. If the feature is just a cool idea, but not in service of a user outcome, it’s unlikely to create value. For example, if you’re trying to drive greater collaboration between users of your product and the team comes up with the idea of using a scan to match people with similar eye color into collaboration groups, that is unlikely to achieve the desired outcome and instead is simply an excuse for the team to solve for new technologies.

Have each team member write each idea, using a thick felt pen, on a sticky note. When time is up, ask everyone to post their notes to the wall. Finally, have the group arrange them into themes.

Running the exercise: assembling your feature hypotheses

With all of your raw material created, you’re ready to organize this material into a set of tactical, testable hypotheses. We like to create a table like the one in Figure 3-12 and then complete it by using the material we’ve brainstormed. If you’ve been creating all of this raw material in a workshop context, you’ll need a lot of material on sticky notes. Physically move your notes into the appropriate boxes to make rows of related ideas.

Figure 3-12. A hypothesis table

You’ll find during this exercise that there are gaps in your initial brainstorms. Some business outcomes might have no features created for them, whereas some features might not drive any value for the customer or the business. That’s the point of this exercise: to make sense of your initial round of thinking. After you’ve identified the gaps in your brainstorms, fill them in with new sticky notes or leave the less relevant ideas off the chart, as depicted in Figure 3-13. This will help make sense of the undoubtedly large number of ideas your team generates.

Figure 3-13. Working on the hypothesis chart

After you’ve completed the chart—7 to 10 rows are a good initial target—begin extracting feature hypotheses from it. Use the hypothesis template shown in Figure 3-4 to ensure you’re including all the relevant components of the hypothesis statement.

As you write your hypotheses, consider which persona(s) you’re serving with your proposed solutions. It’s not unusual to find solutions that serve more than one at a time. It’s also not unusual to create a hypothesis in which multiple features drive similar outcomes. When you see that happening, refine the hypothesis to focus on just one feature. Hypotheses with multiple features are not easy to test. The important thing to remember in this entire process is to keep your ideas specific enough so that you can create meaningful tests to see if your ideas hold water.