What is ‘Growth Thinking’? Part II: Lessons from Design Thinking

This is part II of a series of posts exploring and defining “growth thinking” by comparing it to other popular problem-solving frameworks. Need more context? Jump to Part I.

But first, what is design thinking?

“…the continuum of innovation is best thought of as a system of overlapping spaces rather than a sequence of orderly steps. We can think of them as inspiration, the problem or opportunity that motivates the search for solutions; ideation, the process of generating, developing, and testing ideas; and implementation, the path that leads from the project room to the market. Projects may loop back through these spaces more than once as the team refines its ideas and explores new directions.” —Tim Brown, IDEO

Design thinking is a creative problem solving framework that is human-centered, collaborative, optimistic, experimental, and evolutionary. Design thinking is positioned at the intersection of feasibility, desirability, and viability: what is desirable for an individual person and technologically feasible and economically viable? To find innovative solutions that meet all these constraints, design thinking prescribes a process of researching, prototyping, testing, and sharing. And, of course, constantly iterating through each of these phases.

If you’re interested in learning more, I recommend Change by Design by Tim Brown. If you’re looking for a shorter read (and into education), checkout IDEO’s Design Thinking for Education.

Divergent & convergent thinking

“To have a good idea, you must first have lots of ideas.” —Linus Pauling, Nobel Prize winner

One of the early phases when launching a new feature or experiment is to come up with ideas — lots of them. Good growth teams challenge assumptions, are creative, and aren’t afraid to take risks to try new ideas. But good growth teams are also vicious at prioritizing: no matter how exciting an idea is, if it isn’t impactful, it shouldn’t get prioritized.

This strategy aligns with the divergent and convergent phases in design thinking. In the divergent phase, you open the doors to try new things and don’t close the door on ideas that might have potential. It is amazing what can happen when you push yourself to look for more ideas; It’s good practice to avoid committing to your first idea until you’ve generated several alternatives (At DataCamp, we loved the “Crazy 8s” exercise). But to make sure you are having the greatest impact you can, you also have to be critical and kick less important ideas to the curb, just like you converge on a shortlist of possibilities in design thinking.

On the Growth team at DataCamp, our weekly meeting schedule followed this divergent/convergent pattern: we schedule ideation sessions (divergent thinking) followed by a proposal meeting where the best ideas are pitched to the group (convergent thinking) followed by a refinement session where everyone can help tweak the ideas (more convergence). Then the next week, we start back at the beginning again.

Optimism: things can always be better

“Curiosity does not thrive at organizations that have grown cynical.” —Tim Brown, IDEO

One of the unspoken truths about the mindset of a successful growth team is that you can always improve your product and your business. In our day-to-day, it is easy to take this for granted, but continuous optimism is a crucial component of a team’s success. I was fortunate to work with an amazing team at a company where this attitude is not only welcomed, but is considered the standard. Without optimism, why propose experiment ideas at all?

Growth teams require insatiable curiosity — ”What would happen to conversions if we change our onboarding?”, “Is our pricing page too slow on mobile devices?”, “Are we recommending new users the best first course for them?” — and without the belief that things could be better, this curiosity will dry up.

Empathy

Often, we find areas of opportunity to improve our product in places where we feel we are not meeting our users’ needs. This gut instinct comes from constantly trying to understand our users. At DataCamp, thinking about individual learners’ experiences as they move through our site — rather than solely relying on summary statistics about thousands (or millions) of users — gave us a much deeper understanding of the people we were building DataCamp for.

This type of human-centeredness is a core component of design thinking and is one of the biggest differentiators between design thinking and many other problem solving frameworks. By observing and listening to users, we are able to think creatively about new ways to address their specific needs. If you’re not already, conducting user interviews, collecting survey data, watching screen recordings, reading net promoter score feedback, and skimming through support tickets are all excellent ways to help understand your users as deeply as possible.

Our team was also extremely data-driven, which in some ways makes it even more important to be empathetic to our users. Not enough can be said about the power of mixing quantitative and qualitative data to tell a more complete story. Quantitative data is great at giving insight about how most people are behaving, but more personal (often qualitative) attempts at understanding users have two benefits:

First, we can gain fascinating insights from people at the edges of the spectrum, like power users or people who churn early on.

Secondly, it is a powerful reminder of the impact that our work has on actual human beings. Trying to understand our users as deeply as possible should be a constant effort because it makes it easier to both identify potential problems and propose potential solutions.

Define the problem

One of the reasons that the process of design thinking is so iterative is to make sure that you are addressing the right problem from the beginning (this is also why the first phase of tackling a project using design thinking involves extensive research and observation). As a growth team, we are constantly faced with complex and convoluted challenges. If I’ve learned anything from running split tests, it’s that things that seemed like simple and intuitive fixes often turned out in unexpected ways.

Defining the problem is also especially important for running experiments. To be able to run an experiment, you have to be able to explicitly define a hypothesis that includes what you think the problem is and how your change will improve it in a measurable way.

It is important to be specific. A bad problem statement could be “Our homepage doesn’t convert enough visitors.” A better problem statement could be “Some visitors who land on our homepage don’t convert because they are confused by the technical buzzwords that appear at the top of the page”. The learnings from a test centered on the second problem statement will be a lot more interesting.

Embrace constraints

Although it may sound counterintuitive, constraints are crucial for doing creative work. Adding constraints can help reduce feeling overwhelmed by choice, or the writers-block-equivalent for growth teams (feeling stuck and unable to come up with innovative test ideas).

In reality, sometimes you don’t need to place constraints on yourself or your project — they are already there. For example, at DataCamp, there was a time when our Campus app (the main learning interface for our online courses) didn’t work on mobile (and it wasn’t designed to — at the time, we believed writing code on your phone was a little crazy). We had a lot of mobile traffic and many of our paid ads were viewed on mobile, but it would have required a full rewrite of the app to make it work properly on small screens. We spent a daylong design sprint trying to solve this particular challenge, with the constraint that making the Campus app mobile-friendly was not technically feasible. With the constraints, the team came out of the sprint with some great solutions.

But sometimes, you need to set constraints in place yourself. For one of our first design sprints at DataCamp, we tried to propose solutions to improve our learner dashboard. The problem is that the dashboard is used by a wide variety of user personas and often they have different motives and goals. Without placing constraints on what specific problem we were trying to solve, we ended up not coming away with much at the end of the sprint. Had we placed specific constraints — like the constraint we had when working on the mobile conversions sprint, ”we cannot change X due to technical limitations”, or “we are only focused on improving content discoverability for user persona Y” — I believe the sprint would have been far more productive.

Products, experiences, and tests: differences between growth thinking and design thinking

We used strategies from design thinking all the time on the Growth team at DataCamp. But there are some key differences between growth thinking and design thinking. Although our team’s long term goal is to improve our learners’ experience, the immediate way we do this is by running experiments. We were not a product team, we were the experimentation team.

Although experimentation is an integral part of the design thinking process, for our team, it was one of our end goals (the “things” we created were experiments). Sometimes we needed to be able to use the tools of design thinking in two different ways simultaneously: how might we design a better user experience, and how might we design a suite of tests to help indicate what a better experience could look like?

This is one of the meta-challenges I am excited to continue to think about. Specifically how can a team combine tenets of design thinking to create growth tests most successfully? Do you design a new experience (based on your understanding of your users), then break it into chunks to test and iterate from there? Or do you design many small, narrowly-focused experiments that will eventually contribute to a new design for a user experience?

I love Dan McKinley’s thoughts on iterative product development.

Conclusion

Both design thinking and growth thinking are based on series of rapid iteration, are experiment driven, require boundless optimism, and can benefit from understanding and empathizing with the people your product is for. Hopefully throughout this exploration we’ve started to piece together part of the definition of “growth thinking.”