An illustration of a person working on laptop with a glimse inside his thought process

Growth designer mindset: a shift from product designer

Growth design is a user-centered approach that uses experimentation to drive business metrics. It requires a different mindset from traditional design, with a focus on quantitative data, shipping quickly, and learning from failures. Growth designers design for customer success.

Sajal Chaplot
Bootcamp
Published in
5 min readOct 17, 2021

--

If you stumbled upon this article, you probably might have heard of Growth design and want to know what it is about. Like me, maybe you are the first growth designer in your company and need a get started guide.

This article talks about the mindset shift that will help you get comfortable with the idea quickly. It is also helpful for designers, in general, to understand the impact design can bring to business metrics through experimentation.

Disclaimer: Please note this article is a collection of personal thoughts and data points. The content written hereby does not reflect in any way the position of the company I work for.

What is the need for growth?

The goal in Growth is to optimise the value users get from the product and thereby drive business metrics. It’s still a user-centered approach augmented with a business mindset.

When products are simple (1 or 2 JBTD), users can find value in well-designed products with relative ease. When it becomes a platform that supports multiple JBTD, finding value for different users becomes a bit difficult. In growth, we do experiments to ensure that users become successful with the product. The idea is if users are successful, they will continue to use the product and add value to the business.

The way to go about it is experimentation. But it’s not so simple. Without a basic understanding, you will be spending your energy unnecessarily. When I first started, it took about 3x the time because I didn’t understand how growth design works. Once I accepted the following mindset shift, I started adding real value by reducing the time and creating more impact.

Let’s enter the mind 🧠 of a growth designer.

Difference #1

Design just enough ‘good experience’ for users to validate the hypothesis. Not more, not less.

Like in science, the goal is to have limited variables to measure that the hypotheses are correct and that solutions are driving impact. Plus, there is always a design and development cost involved. You do the bare minimum to test since ‘the design’ may be discarded because the experiment didn’t create an impact.

As an example, we wanted to increase the number of invites sent and teams getting formed. We changed the invite CTA color to make it more prominent, resulting in a 30% increase in invites sent.

Just enough good experience. It took me a few specs to understand ‘enough experience’ for growth experiments.

A screenshot from the Postman’s original experience where the invite people button is grey and get’s camouflaged with the rest of UI. This was used as baseline for A/B testing.
a) Invite CTA in product
A screenshot of the experimental design where we changed the invite button’s color to more prominent blue color, so our users can easily find it. This led to a 30% increase in number of invites sent, which was an important metric for us.
b) Experimental Design that led to a 30% increase in new invites.

Difference #2

Quantitative Data becomes part of your everyday design process.

During experimentation, we form hypotheses that will help our users get the best value from our product. These hypotheses should be established by understanding user behaviour in the product. Interacting with data helps us identify what needs to be resolved, at which part of the journey we should experiment, whether considerable users face similar issues, and what impact we can create by experimentation.

As a growth designer, you interact with data more as it helps you identify impactful experiments that will result in greater user satisfaction and improve business.

And here I thought - Math wouldn't be necessary as a designer. 😂

This is an illustration showcasing 4 bars in a bar graph out of which one is saying “I am sorry man, but we can’t trust you..” This is to signify that only statistically significant results can be trusted.

Difference #3

Ship faster, measure, learn and iterate.

While some experiments succeed and others fail, the important part is we learn what is stopping our customers from being successful with the product. The faster we know, the quicker we solve problems and drive business.

From the invite button example above, simple and quick changes can drive a considerable impact.

Difference #4

Designing for growth requires knowledge of JBTD and funnels across the product.

To sell, you need to understand what Jobs are enabled by the product. What parts of the product can be leveraged to direct users into the business funnels. In-depth knowledge isn’t needed about features functioning, interactions, etc. Only the right amount that you can use to create growth levers for different JBTD.

PS: You can always deep-dive on a need basis.

Difference #5

We don’t design product experience. We design for customer success.

The growth model is about bringing users back into the funnel and not designing/redesigning features. The product team and product designers own that. Experimentation isn’t released to everyone, so you don’t need to handle every edge case. But, growth designer needs to supply their feedback from experiments to product designers so that new experiences from future designs will lead to faster growth.

Conclusion

I just started with growth design and learning more each day. But one thing I have learned is, no matter what problem space you are designing for, the base of design thinking is the foundation. If I were to make an analogy, growth design is creating a new dish with noodles with the main ingredient as noodles (design thinking) itself.

Food for thought

While I talked about the growth designer mindset, I think every designer can benefit from experimentation. We say the design process is iterative, but are we talking about iteration when the project is in the design phase? Or are we talking iterative work in the longer vision of satisfying customer needs?

As a young designer, I feel this doesn’t naturally come to mind unless you work for a few years. The PMs usually handle the iterative process when they work on product specs. In a way, it’s great that they are helping you there. But designers are the voice of users in an organization and we should strive to be active partners of the PMs in this iterative philosophy.

But this thought leads to another question — what will differentiate Product Managers and Designers if we do so? Stay tuned….

--

--

Sajal Chaplot
Bootcamp

Currently, working as Product Designer at Builder.io. Previously worked at Postman & Infosys. Interested in design, business, photography and travelling.